Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

Luca Boccassi writes: > Moved as suggested. Also incorporated your suggestion on the versioned > virtual package dependency verbatim. Okay, I felt like doing editing this evening, apparently, so even though only you, Sam, and Simon had a chance to respond, I went ahead and did the editing. I'm

Bug#885698: What licenses should be included in /usr/share/common-licenses?

Quoting Russ Allbery (2023-09-10 23:24:24) > Jonas Smedegaard writes: > > > I have so far worked the most on identifying and grouping source data, > > putting only little attention (yet - but do dream big...) towards > > parsing and processing debian/copyright files e.g. to compare and assess >

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 970234 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to

Bug#970234: consider dropping "No hard links in source packages"

Guillem Jover writes: > I'm not really sure what the footnote really refers to, TBH, as I'm not > aware of any such check, or what would require a fair amount of > work. Yeah, it seems to be a mystery to everyone. There is an explicit entry in the debian/changelog of Policy from Ian Jackson

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

> "Russ" == Russ Allbery writes: Russ> I therefore would like to propose a first: I think Policy Russ> should simply say that any package that provides a system Russ> service should use debhelper and rely on dh_installsystemd to Russ> put the appropriate commands in its

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 10:15 PM Russ Allbery wrote: > Luca Boccassi writes: > > > systemd upstream will drop support for the transitional sysv generator > > in the near future. The transition is long finished, it's been at least

Bug#1031403: debian-policy: missing quotes in sh script example in file policy/ap-pkg-diversions

Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 6:33 PM Russ Allbery wrote: > Control: tags -1 pending > > Max-Julian Pogner writes: > > > consulting the debian policy manual whether it contains suggestions how > > to best implement diversions (see `man

Bug#830913: debian-policy: Allow amd64 systems without /lib64

Please remove the following email address: e.little...@gmail.com On Sun, Sep 10, 2023 at 2:15 PM Russ Allbery wrote: > Russ Allbery writes: > > > It's now been about a year and it looks like this message didn't get a > > reply, so I'm going to go ahead and close this bug because I don't think

Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area

Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 5:48 PM Russ Allbery wrote: > Gunnar Wolf writes: > > > It has been four months since the General Resolution 2022/vote_003 was > > voted¹, but it has not yet been completely adopted. The archive area was >

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 10:12 PM Russ Allbery wrote: > Package: debian-policy > Version: 4.6.2.0 > Severity: important > X-Debbugs-Cc: r...@debian.org > > As part of reviewing #1039102, I took a detailed look at Policy 9.3 > on

Bug#1050322: Partial versus complete replacement of a package by another

Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 6:51 PM Russ Allbery wrote: > julien.pu...@gmail.com writes: > > > Oh. I think I had two problems: > > (1) thinking "Replaces" meant "replaces" ; > > (2) thinking d/control controlled packages. > > > Let me

Bug#1030382: marked as done (encourage Vcs-Git over other Vcs-* headers)

Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 10:39 PM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Your message dated Sat, 09 Sep 2023 19:35:06 -0700 > with message-id <87a5tu21t1@hope.eyrie.org> > and subject line Re: Bug#1030382:

Bug#1024367: In 4.9.1, the example uses not recommended install -s

Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 6:18 PM Russ Allbery wrote: > Enrico Zini writes: > > > Hello, and thank you for maintaining the Policy! > > > Policy paragraph 4.9.1 has an example debian/rules which contains these > > lines: > > >

Bug#991984: closed by Russ Allbery (Re: Bug#991984: Please document minimal environment variable needed for sensible-utils)

Please remove the following email address: e.little...@gmail.com On Sun, Sep 10, 2023 at 4:21 AM Bastien Roucariès wrote: > Le dimanche 10 septembre 2023, 04:33:06 UTC Debian Bug Tracking System a > écrit : > > This is an automatic notification regarding your Bug report > > which was filed

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

Please remove the following email address: e.little...@gmail.com On Sun, Sep 10, 2023 at 1:42 PM Russ Allbery wrote: > This patch from a while back is still waiting for one more second before > it can be merged for the next Policy release. It previously got one > second from Wouter. I

Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field

Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 5:57 PM Russ Allbery wrote: > Samuel Thibault writes: > > > I didn't find a previous discussion on this: it would be useful to > > support negated architecture specifications in the debian/control > >

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

Please remove the following email address: e.little...@gmail.com On Sun, Sep 10, 2023 at 2:33 PM Russ Allbery wrote: > Guillem Jover writes: > > > Seems I missed another file: > > > * .changes: > > policy → «upload control file» / «Debian changes file» > > dpkg → «upload control

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

Please remove the following email address: e.little...@gmail.com On Sun, Sep 10, 2023 at 1:33 PM Russ Allbery wrote: > Here is an updated proposed change for this bug, incorporating Guillem's > suggestions. It is ready for seconds. > > -- > Russ Allbery (r...@debian.org)

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 10:54 PM Russ Allbery wrote: > Luca Boccassi writes: > > > Sure, updated as suggested. > > I have a bunch of minor wording fixes that I'd want to make at this before > merging, but that should be

Bug#970234: consider dropping "No hard links in source packages"

Please remove the following email address: e.little...@gmail.com On Sun, Sep 10, 2023 at 1:45 PM Russ Allbery wrote: > This patch is still waiting for one more second. It was previously > seconded by Helmut. > > Russ Allbery writes: > > > Here is a patch dropping the restriction on hard

Bug#970234: consider dropping "No hard links in source packages"

Hi! On Thu, 2022-09-22 at 19:20:00 -0700, Russ Allbery wrote: > Russ Allbery writes: > > The fact that this has gone unnoticed in a source package in an existing > > release makes a pretty strong argument that nothing in Debian cares and > > we should just remove the constraint. > > Here is a

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

Hi! On Sun, 2023-09-10 at 16:31:30 -0700, Russ Allbery wrote: > Guillem Jover writes: > > Hmm, the "For this case" comes just after the "no binary packages" which > > to me reads as being somewhat referring to it, perhaps the "no binary > > packages" sentence should be put at the end of the

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

Guillem Jover writes: > Hmm, the "For this case" comes just after the "no binary packages" which > to me reads as being somewhat referring to it, perhaps the "no binary > packages" sentence should be put at the end of the paragraph to avoid > confusion, or the "For this case" moved instead after

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

> "Luca" == Luca Boccassi writes: Luca> On Sun, 10 Sept 2023 at 03:19, Russ Allbery wrote: >> >> Russ Allbery writes: >> >> > -If a service unit is not present, ``systemd`` uses dependency >> information > -contained within the init scripts and symlinks in >>

Bug#877697: marked as done (debian-policy: discourage using all 4 digits numbers in Standards-Version)

Your message dated Sun, 10 Sep 2023 16:26:20 -0700 with message-id <87y1hdtxsz@hope.eyrie.org> and subject line Re: Bug#877697: debian-policy: discourage using all 4 digits numbers in Standards-Version has caused the Debian Bug report #877697, regarding debian-policy: discourage using all 4

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 877697 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

Hi! On Sun, 2023-09-10 at 10:30:41 -0700, Russ Allbery wrote: > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 4bab7df..904fa52 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -812,10 +812,11 @@ See :ref:`s-descriptions` for

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

> "Luca" == Luca Boccassi writes: Luca> On Sun, 10 Sept 2023 at 11:31, Simon McVittie wrote: >> >> On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote: >> > Luca, am I right that service directories are specific to, >> well, services? > If so, what would you

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

> "Russ" == Russ Allbery writes: Russ> Here is an updated proposed change for this bug, incorporating Russ> Guillem's suggestions. It is ready for seconds. Russ> -- Russ Allbery (r...@debian.org) Russ> I have reviewed the patch; I support

Bug#885698: What licenses should be included in /usr/share/common-licenses?

Jonas Smedegaard writes: > I have so far worked the most on identifying and grouping source data, > putting only little attention (yet - but do dream big...) towards > parsing and processing debian/copyright files e.g. to compare and assess > how well aligned the file is with the content it is

Bug#917995: marked as done (debian-policy: drop section 1.6 Translations)

Your message dated Sun, 10 Sep 2023 14:11:41 -0700 with message-id <87fs3lvilu@hope.eyrie.org> and subject line Re: Bug#917995: debian-policy: drop section 1.6 Translations has caused the Debian Bug report #917995, regarding debian-policy: drop section 1.6 Translations to be marked as done.

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 917995 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to

Bug#885698: What licenses should be included in /usr/share/common-licenses?

Quoting Russ Allbery (2023-09-10 21:41:59) > Jeremy Stanley writes: > > > I'm surprised, for example, by the absence of the ISC license given that > > not only ISC's software but much of that originating from the OpenBSD > > ecosystem uses it. My personal software projects also use the ISC > >

Bug#885698: What licenses should be included in /usr/share/common-licenses?

* Russ Allbery [2023-09-10 09:16]: In order to structure the discussion and prod people into thinking about the implications, I will make the following straw man proposal. This is what I would do if the decision was entirely up to me: Licenses will be included in common-licenses if they

Bug#885698: What licenses should be included in /usr/share/common-licenses?

Johannes Schauer Marin Rodrigues writes: > I very much like this idea. The main reason maintainers want more > licenses in /usr/share/common-licenses/ is so that they do not anymore > have humongous d/copyright files with all license texts copypasted over > and over again. If long texts could be

Bug#885698: What licenses should be included in /usr/share/common-licenses?

At 2023-09-10T21:47:36+0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Bill Allombert (2023-09-10 18:29:36) > > On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote: > > > Jonas Smedegaard writes: > > > >> Hmm, how about providing license-common package and that > > > >> depends

Bug#885698: What licenses should be included in /usr/share/common-licenses?

On 2023-09-09 20:35:27 -0700 (-0700), Russ Allbery wrote: [...] > Finally, as promised, here is the count of source packages in > unstable that use the set of licenses that I taught my script to > look for. This is likely not accurate; the script uses a bunch of > heuristics and guesswork. [...]

Bug#885698: What licenses should be included in /usr/share/common-licenses?

Hi, Quoting Bill Allombert (2023-09-10 18:29:36) > On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote: > > Jonas Smedegaard writes: > > > Quoting Hideki Yamane (2023-09-10 11:00:07) > > >> Hmm, how about providing license-common package and that depends on > > >>

Bug#885698: What licenses should be included in /usr/share/common-licenses?

Jeremy Stanley writes: > I'm surprised, for example, by the absence of the ISC license given that > not only ISC's software but much of that originating from the OpenBSD > ecosystem uses it. My personal software projects also use the ISC > license. Are you aggregating the "License:" field in

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 590511 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

Guillem Jover writes: > Seems I missed another file: > * .changes: > policy → «upload control file» / «Debian changes file» > dpkg → «upload control file» / «.changes control file» / > «Debian .changes file» / «Debian changes file» [...] > For changes I think

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 1020248 ...

Processing commands for cont...@bugs.debian.org: > user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was r...@debian.org). > limit package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to

Bug#830913: debian-policy: Allow amd64 systems without /lib64

Russ Allbery writes: > It's now been about a year and it looks like this message didn't get a > reply, so I'm going to go ahead and close this bug because I don't think > we have enough information to act on it. If there are more details > about my questions above, feel free to open it. For

Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas

Simon McVittie writes: > Here are some updated patches for Policy, incorporating this requirement. > I have not attempted to incorporate the corner case involving > build-profiles. I think if we were going to do that, it would require > documenting build-profiles first (#757760), and maybe even

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

Russ Allbery writes: > This patch from a while back is still waiting for one more second before > it can be merged for the next Policy release. It previously got one > second from Wouter. I revised the patch to mention the experimental > suite as well as the backports suites. Argh, wrong

Bug#970234: consider dropping "No hard links in source packages"

This patch is still waiting for one more second. It was previously seconded by Helmut. Russ Allbery writes: > Here is a patch dropping the restriction on hard links in source > packages that I think is ready for seconds. I'm copying Guillem for his > review, in case there's some dpkg concern.

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

This patch from a while back is still waiting for one more second before it can be merged for the next Policy release. It previously got one second from Wouter. I revised the patch to mention the experimental suite as well as the backports suites. -- Russ Allbery (r...@debian.org)

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

Here is an updated proposed change for this bug, incorporating Guillem's suggestions. It is ready for seconds. -- Russ Allbery (r...@debian.org) >From 66175d3775f238a5ce3a2254388ad974e81d462f Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue,

Bug#885698: What licenses should be included in /usr/share/common-licenses?

Quoting Russ Allbery (2023-09-10 18:16:07) > Russ Allbery writes: > > > In order to structure the discussion and prod people into thinking about > > the implications, I will make the following straw man proposal. This is > > what I would do if the decision was entirely up to me: > > >

Bug#885698: What licenses should be included in /usr/share/common-licenses?

On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote: > Jonas Smedegaard writes: > > Quoting Hideki Yamane (2023-09-10 11:00:07) > > >> Hmm, how about providing license-common package and that depends on > >> "license-common-list", and ISO image provides both, then? It would be > >>

Bug#885698: What licenses should be included in /usr/share/common-licenses?

Russ Allbery writes: > In order to structure the discussion and prod people into thinking about > the implications, I will make the following straw man proposal. This is > what I would do if the decision was entirely up to me: > Licenses will be included in common-licenses if they meet all

Bug#885698: What licenses should be included in /usr/share/common-licenses?

Jonas Smedegaard writes: > Quoting Hideki Yamane (2023-09-10 11:00:07) >> Hmm, how about providing license-common package and that depends on >> "license-common-list", and ISO image provides both, then? It would be >> no regressions. I do wonder why we've never done this. Does anyone know?

Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field

Adam Borowski writes: > Agreed, but it might be good to say "it would be good to have this", and > send a bug/mail to the relevant teams, asking if there are objections > before anyone spends work to implement this. > I for one have currently no less than three related ideas: > * this > *

Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field

On Sat, Sep 09, 2023 at 02:53:00PM -0700, Russ Allbery wrote: > Samuel Thibault writes: > > Architecture: !s390 !s390x > > Architecture: !hppa !hurd-any !kfreebsd-any > > Architecture: linux-any kfreebsd-any !hppa !m68k-any > > which would be understood as [ (linux-any or kfreebsd-any) and not

Bug#885698: What licenses should be included in /usr/share/common-licenses?

On Sun, 10 Sept 2023 at 04:36, Russ Allbery wrote: > Licenses will be included in common-licenses if they meet all of the > following criteria: > > * The license is DFSG-free. > * Exactly the same license wording is used by all works covered by it. > * The license applies to

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

On Sun, 10 Sept 2023 at 11:31, Simon McVittie wrote: > > On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote: > > Luca, am I right that service directories are specific to, well, services? > > If so, what would you think of moving them to Policy 9.3 alongside the > > other discussion of

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

In general I support this direction. On Sun, 25 Jun 2023 at 16:55:44 +0100, Luca Boccassi wrote: > Packages shipping ``tmpfiles.d`` snippets should > +depend on the appropriate virtual packages in the following order: > +``default-systemd-tmpfiles | systemd-tmpfiles``. I think it's worth saying

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

On Sun, 10 Sept 2023 at 03:19, Russ Allbery wrote: > > Russ Allbery writes: > > > -If a service unit is not present, ``systemd`` uses dependency information > > -contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide > > -which scripts to run and in which order. The

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote: > Luca, am I right that service directories are specific to, well, services? > If so, what would you think of moving them to Policy 9.3 alongside the > other discussion of systemd units? They feel out of place here, since > packages that

Bug#885698: What licenses should be included in /usr/share/common-licenses?

On Sat, 09 Sep 2023 20:35:27 -0700 Russ Allbery wrote: > Licenses will be included in common-licenses if they meet all of the > following criteria: How about just pointing SPDX licenses URL for whole license text and lists DFSG-free licenses from that? (but yes, we should adjust short

Bug#885698: What licenses should be included in /usr/share/common-licenses?

Quoting Hideki Yamane (2023-09-10 11:00:07) > On Sat, 09 Sep 2023 22:41:48 -0700 > Russ Allbery wrote: > > > How about just pointing SPDX licenses URL for whole license text and > > > lists DFSG-free licenses from that? (but yes, we should adjust short > > > name of licenses for DEP-5 and SPDX

Bug#885698: What licenses should be included in /usr/share/common-licenses?

On Sep 10, Enrico Zini wrote: > I like this. I'd say that even if a license is shorter than 25 lines I'd > appreciate to be able to link to it instead of copypasting it. Me too. > I like to be able to fill the license field with a value, after checking > that the upstream license didn't diverge

Bug#885698: What licenses should be included in /usr/share/common-licenses?

On Sat, 09 Sep 2023 22:41:48 -0700 Russ Allbery wrote: > > How about just pointing SPDX licenses URL for whole license text and > > lists DFSG-free licenses from that? (but yes, we should adjust short > > name of licenses for DEP-5 and SPDX for it). > > Can we do this legally? If we can, it

Bug#991984: closed by Russ Allbery (Re: Bug#991984: Please document minimal environment variable needed for sensible-utils)

Le dimanche 10 septembre 2023, 04:33:06 UTC Debian Bug Tracking System a écrit : > This is an automatic notification regarding your Bug report > which was filed against the debian-policy package: > > #991984: Please document minimal environment variable needed for > sensible-utils > > It has