Bug#884228: debian-policy: please add OFL-1.1 to common licenses

On Fri, 29 Dec 2017 at 22:24:23 +0100, Markus Koschany wrote: > Am 29.12.2017 um 00:06 schrieb Jonathan Nieder: > > Using 'Files: *' when different files are under different licenses > > sacrifices precision, but it doesn't sacrifice accuracy. You can say > > > > Files: * > > License: GPL-2

Bug#884964: using "su - " in postinst causing some installs to fail

On Sat, 23 Dec 2017 at 19:42:05 +, Sean Whitton wrote: > control: retitle -1 Discourage 'su -' in maintscripts, in favour of plain 'su' Plain 'su' is also problematic, because it inherits the entire environment, including variables like HOME, XDG_RUNTIME_DIR, XDG_*_HOME,

Bug#884964: using "su - " in postinst causing some installs to fail

On Sat, 23 Dec 2017 at 22:04:44 -0600, LinuxChix SysAdmin wrote: > Changing the shell to /bin/bash for tuptime for example, eliminates the > error with using 'su -'. When writing profile.d snippets, you can't assume that every user has bash as their login shell. profile.d snippets need to be

Re: Bug#884224: ebian-policy: please add CC-BY-3.0 to common licenses

On Wed, 27 Dec 2017 at 13:54:41 -0800, Russ Allbery wrote: > license-count numbers: > > CC-BY 1.0 2 > CC-BY 2.0 3 > CC-BY 2.511 > CC-BY 3.0 165 > CC-BY 4.028 > CC-BY-SA 1.0 3 > CC-BY-SA 2.0 44 >

Bug#884225: debian-policy: please add CC-BY-4.0 to common licenses

On Wed, 27 Dec 2017 at 13:55:37 -0800, Russ Allbery wrote: > CC-BY-SA 3.0285 > CC-BY-SA 4.0 61 > > 4.0 is a pretty niche license right now. Maybe that's expected to grow at > the cost of 3.0, though I would hope that it is expected to grow, given that CC-BY-SA 3.0

Bug#883950: Next steps on "[GPL-3+]" proposal

On Sun, 29 Jul 2018 at 00:50:34 +1000, Stuart Prescott wrote: > Let us consider this proposed syntax in terms of what someone unfamiliar > with the format is going to see Along these lines, it might be helpful for people with an interest in pushing this forward to convert some d/copyright files

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling

On Wed, 25 Jul 2018 at 20:57:41 -0700, Jonathan Nieder wrote: > a) The work must carry prominent notices stating that you modified >it, and giving a relevant date. I don't think this is normally interpreted as requiring that *all* modifications be listed, only that the existence of

Bug#228692: User/group creation/removal in package maintainer scripts

On Tue, 31 Jul 2018 at 17:53:50 +0200, Andreas Henriksson wrote: > previously created users should *not* (ever) be removed There has been a suggestion in the past that these users should be locked on package removal and unlocked on reinstallation, as implemented in (for example) openarena-server.

Bug#883950: Bug#904729: Policy 12.5: Must the license grant be included in debian/copyright?

On Fri, 27 Jul 2018 at 17:18:42 +0800, Sean Whitton wrote: > If we want to implement anything like what's being discussed > in #883950, we need section 12.5 to state explicitly that the license > grant need not be included. suggests

Bug#883950: Next steps on "[GPL-3+]" proposal

On Sun, 12 Aug 2018 at 13:52:57 +0200, Wouter Verhelst wrote: > The obvious objection to that would be the fact that the SPDX > identifiers are not set in stone; a future update of the SPDX > identifiers might then conflict with one of the identifiers that we add. > Either we'd need [...], or a

Bug#906949: Clarify documentation location in a Python2-less distribution

On Thu, 23 Aug 2018 at 15:43:06 +0100, Ian Jackson wrote: > There are two reasons for the standardised paths in /usr/share/doc: > 1. So that the user can find the right documentation. > 2. So that you avoid clashes with other packagkes. > > Not moving the docs about assists 1. As does

Bug#906949: Clarify documentation location in a Python2-less distribution

On Thu, 23 Aug 2018 at 01:20:44 +1000, Stuart Prescott wrote: > d) revert to /usr/share/doc/python-foo-doc: do we ignore policy's > recommendation, overriding (or changing) dh_installdocs? While > /usr/share/doc/main-package is only a recommendation in policy, 700 > python-foo-doc packages

Bug#804018: options to avoid service startup on package installation

On Wed, 25 Jul 2018 at 05:11:15 +0100, Ian Jackson wrote: > ISTM that in days gone by this would have been (should have been) a > wishlist item for invoke-rc.d. The interface was defined in > invoke-rc.d(8) and README.policy-rc.d.gz. ... > Nowadays, there is systemd too. I have no idea whether >

Bug#795402: base-files: Please add Creative Commons license texts

On Mon, 09 Jul 2018 at 15:16:27 +0100, Jonathan Dowland wrote: > CC-BY-SA3.0 303 Note that some of those will be CC-BY-SA-3.0-US, some will be CC-BY-SA-3.0 Unported, and some might be a different (legally distinct) localization (there are many). Some uses of Creative Commons

Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]

On Sun, 11 Mar 2018 at 14:48:40 +0530, Pirate Praveen wrote: > On വെള്ളി 09 മാർച്ച് 2018 08:39 വൈകു, Simon McVittie wrote: > > And for executables, perhaps something like this: ... > > * should not be named node-* without a suffix like -bin or -tools (?) > > I don't think th

Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]

On Fri, 09 Mar 2018 at 17:50:30 +0530, Pirate Praveen wrote: > How about the change given below? (is the intent clear at least even if > disagreement on content remains) > > 5. should add 'Provides: node-foo' in debian/control and install > package.json in /usr/lib/nodejs/foo, if the script is

Bug#881431: proposed wording

On Wed, 04 Apr 2018 at 11:47:09 -0700, Sean Whitton wrote: > > §3.2.2 Uniqueness of version numbers > > > > The part of the version number after the epoch must not be reused for > > a version of the package with different contents once the package has > > been accepted into the archive, even if

Bug#850156: Please firmly deprecate vendor-specific series files

On Wed, 18 Apr 2018 at 14:36:14 +0200, Mike Gabriel wrote: > On Wed, 4 Jan 2017 13:41:53 + Ian Jackson > wrote: > > But [vendor.series] is quite wrong, because it means that the same > > source package has different "contents" on different computers. > > The

Bug#850156: Please firmly deprecate vendor-specific series files

On Thu, 19 Apr 2018 at 08:00:28 +, Mike Gabriel wrote: > One example, where the vendor.series file is really helpful is: > https://anonscm.debian.org/cgit/pkg-mate/mate-terminal.git/tree/debian/patches/2001_fix-find-next-previous.patch That one-line change could easily be guarded by #ifdef

Bug#850156: Please firmly deprecate vendor-specific series files [and 1 more messages]

On Wed, 18 Apr 2018 at 21:11:11 -0700, Steve Langasek wrote: > The examples given are for series.ubuntu, which is certainly the case I've > seen in the wild. Ubuntu, as a project, did not ask for this. As an Ubuntu > developer, it has never benefitted me. I have only ever seen it used by >

Bug#881431: proposed wording

On Thu, 29 Mar 2018 at 08:12:15 -0700, Sean Whitton wrote: > Seeking seconds: > > > §3.2.2 Uniqueness of version numbers This has lost the part of Adam's wording where he explicitly said that this applies to all three of these namespaces: * (source package name, source version without epoch) *

Bug#747320: Mandate "type" in /bin/sh

Control: retitle -1 Mandate "type" and/or "command -v" in /bin/sh On Sat, 07 Jun 2014 at 21:52:34 +0200, Jakub Wilk wrote: > * Ian Jackson , 2014-05-07, 14:32: > > It seems to me that given that dash and bash both provide `type', and > > the underlying

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

On Sat, 03 Mar 2018 at 19:53:42 +0530, Pirate Praveen wrote: > What do you think about the case of handlebars? In that case I think a > separate binary is required because the command line tool must declare a > dependency on nodejs, whereas the javascript library (libjs-*), does not > require it.

Bug#787816: Replace FHS 2.3 by FHS 3.0 in the Policy.

On Sat, 23 Jun 2018 at 21:05:07 +0100, Sean Whitton wrote: > 1. FHS 3.0 allows distributions to create directory hierarchies under > user's home directories conforming to the XDG Base Directories or > the GLib conventions on user directory contents. > > We don't permit packages to

Bug#904248: Beginnings of a patch to add netbase to build-essential

On Fri, 12 Oct 2018 at 13:45:06 +0200, Mattia Rizzolo wrote: > On the note of /etc/hosts, I'm fixing the original bug rised by Simon > McVittie (that was triggered by tests.reproducible-builds.org not > resolving localhost) within pbuilder (#905307) btw. I think this is a better solut

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

On Tue, 16 Oct 2018 at 20:31:54 +0200, Andreas Henriksson wrote: > I'm still leaning towards thinking just dropping this section is > better than doing a direct translation of it to the current systemd > reality which might just end up being confusing and help noone. One part of this section that

Bug#824495: debian-policy: Source packages "can" declare relationships

On Sat, 10 Nov 2018 at 19:29:03 -0700, Sean Whitton wrote: > On Thu 08 Nov 2018 at 02:51PM GMT, Ian Jackson wrote: > >(ii) output packages with additional features or functionality. > >Such additional features MAY imply additional functional runtime > >dependencies, which then SHOULD

Bug#833401: debian-policy: virtual packages: dbus-session-bus, default-dbus-session-bus

On Fri, 07 Dec 2018 at 19:26:50 -0700, Sean Whitton wrote: > diff --git a/virtual-package-names-list.yaml b/virtual-package-names-list.yaml > + - name: dbus-session-bus > + description: provides the D-Bus well-known session bus for most or all > user login sessions > + - name:

Bug#833401: debian-policy: virtual packages: dbus-session-bus, default-dbus-session-bus

On Sat, 03 Nov 2018 at 14:07:18 -0700, Sean Whitton wrote: > On Thu 04 Aug 2016 at 01:43PM +0100, Simon McVittie wrote: > >> Other options > > I note that no such binary package exists right now. Does this issue > remain unresolved? I also note recent discussion on d-de

Bug#917431: debian-policy: virtual packages: logind, default-logind

On Sun, 30 Dec 2018 at 15:39:58 +0100, Adam Borowski wrote: > On Sat, Dec 29, 2018 at 02:07:25PM +, Sean Whitton wrote: > > Ideally, this would be reviewed and seconded by people working on init > > stuff, so I'm not going to second it myself unless we don't get interest. > > I asked around,

Bug#917431: debian-policy: virtual packages: logind, default-logind

On Fri, 28 Dec 2018 at 02:52:09 +0900, Ansgar Burchardt wrote: > Adam Borowski writes: > > Thus, the wording would be (as proposed by fsateler): > > > > logind: an org.freedesktop.login1 D-Bus API implementation > > > > default-logind: should be provided by the distribution's default logind > >

Re: Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy

On Sat, 15 Sep 2018 at 08:47:19 -0700, Sean Whitton wrote: > On Fri 10 Aug 2018 at 08:23AM +0200, Michael Biebl wrote: > > There is also: > > 65536-4294967293: > > Dynamically allocated user accounts. By default adduser will not > > allocate UIDs and GIDs in this range, to ease compatibility

Bug#924401: base-files fails postinst when base-passwd is unpacked

On Thu, 14 Mar 2019 at 10:21:30 +0100, Santiago Vila wrote: > The reason I'm often asked to add hacks to base-files.postinst is only > that base-files is usually configured in the second place I think it's also fair to say that base-files is exactly a collection of the miscellaneous files and

Bug#924401: base-files fails postinst when base-passwd is unpacked

It would probably be good for the overall robustness of the system if we try to solve this from multiple angles. On Tue, 12 Mar 2019 at 16:17:10 +0100, Helmut Grohne wrote: > A. /etc/passwd is part of base-passwd's interface and base-files is >right in relying on it working at all times. Then

Bug#761219: debian-policy: document versioned Provides

On Thu, 06 Jun 2019 at 21:54:40 +0100, Dominic Hargreaves wrote: > This is a fair comment. The wording was potentially misleading. How about > the attached instead? This mostly looks good, just one thing that I would add: > -If a relationship field has a version number attached, only real >

Re: Bug#919507: Reboot required patch for Debian policy

On Sat, 20 Jul 2019 at 20:27:04 -0700, Russ Allbery wrote: > "Karl O. Pinc" writes: > > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst > > index 59c92ec..8276bfe 100644 > > --- a/policy/ch-opersys.rst > > +++ b/policy/ch-opersys.rst > > @@ -1040,3 +1040,33 @@ Debian, so this section

Bug#172436: Updated BROWSER proposal

On Sun, 21 Jul 2019 at 21:08:15 -0700, Russ Allbery wrote: > I think it's clear that we're not making forward progress here, and the > lack of a clear specification for the BROWSER environment variable doesn't > seem to be causing a lot of noticable ongoing pain. I'm therefore going > to close

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

On Mon, 22 Jul 2019 at 13:39:31 +0200, Ansgar wrote: > What sort of dependencies are we talking about? Package-level > dependencies (e.g. Depends: systemd-sysv directly or indirectly)? Probably yes. systemd-cron and dbus-user-session are examples of packages that rely on the systemd service

Bug#941198: initscripts: packages should ship systemd units

On Fri, 01 Nov 2019 at 12:21:43 +0100, Ansgar wrote: > Dmitry Bogatov writes: > > Does it mean that lack of systemd unit file is RC-critical bug? Or I > > will be able to waive it with "you are welcome to contribute a patch" > > response? I think in general the answer is that it should be a

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

On Fri, 22 Nov 2019 at 14:05:50 +0100, Ansgar wrote: > I'm fairly sure that systemd-tmpfiles doesn't require systemd as pid-1 It doesn't, but its dh_installsystemd integration currently does, so maintainer scripts relying on it would currently be buggy. I think it would be premature to recommend

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

On Sat, 30 Nov 2019 at 10:58:23 -0800, Russ Allbery wrote: > Guillem Jover writes: > > I don't mind much how this could end up being hooked into various init > > systems and chroot/container managers. I can see how it could be done by > > the respective imeplementations themselves or provided by

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

On Fri, 22 Nov 2019 at 09:03:29 +0100, Ansgar wrote: > I would like to recommend packages to use tmpfiles.d(5) to manage > creating directories in locations such as /var or /etc instead of > maintainer scripts. Using tmpfiles.d(5) seems like a good thing to encourage, but using them *instead of*

Bug#942051: debian-policy: [4.9] requirement to write only to /tmp, /var/tmp, ${TMPDIR} is too strict

On Wed, 09 Oct 2019 at 17:51:53 +0200, Ansgar Burchardt wrote: > +--- > | 4.9 > |Required targets must not write outside of the unpacked source > |package tree, except for TMPDIR, /tmp and /var/tmp. > +--- If you are interested in this sort of thing, is

Bug#942051: debian-policy: [4.9] requirement to write only to /tmp, /var/tmp, ${TMPDIR} is too strict

On Wed, 09 Oct 2019 at 18:08:09 +0200, Bill Allombert wrote: > On Wed, Oct 09, 2019 at 05:51:53PM +0200, Ansgar Burchardt wrote: > > There are > > other paths that should be fine to be written to during the build > > process, for example /dev/shm > > Do you have example of packages that does that

Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong

Package: debian-policy Version: 4.5.0.0 Severity: minor X-Debbugs-Cc: syst...@packages.debian.org If a package has a single system service with a systemd service unit, and the system service's name does not match the package's name, current Policy implies that this is probably a (non-RC) bug. I

Re: Proposal for next steps for systemd-related policy

On Sun, 29 Dec 2019 at 10:47:44 -0800, Russ Allbery wrote: > 3. Start a discussion on debian-devel to see if we can come up with some >idea for how to declare dependencies on availability of system >services. Do you mean "systemd features", or do you mean system services more generally?

Re: Guidance on solving the username namespacing problem

On Sat, 04 Jan 2020 at 13:52:51 +0100, Philipp Kern wrote: > now that we are talking again about standardizing user creation using > sysusers, I wonder if you could give me any guidance on how to attack > the Debian system user namespacing problem. It's a good reminder, but I think the naming

Re: Proposal for next steps for systemd-related policy

On Sun, 29 Dec 2019 at 10:47:44 -0800, Russ Allbery wrote: >We probably also want to recommend Type=notify where possible and >Type=exec where not, over Type=forking, when the daemon supports that. I'm not sure what you mean by "where possible" - it'll usually be possible to implement

Re: Guidance on solving the username namespacing problem

On Sun, 05 Jan 2020 at 17:16:58 +0100, Philipp Kern wrote: > On 1/4/2020 5:08 PM, Simon McVittie wrote: > > It's also worth noting that the 61184-65519 uid range used for DynamicUser > > by default collides with the rarely-used 6-64999 uid range for system > > use

Bug#948275: is Debian POSIX compliant?

On Mon, 06 Jan 2020 at 12:12:23 +0100, Harald Dunkel wrote: > I haven't found it mentioned in the policy manual, so I wonder if > Debian is supposed to be POSIX compliant (unless noted otherwise)? I suspect what we aim for is "approximately POSIX". Neither the Linux kernel nor the various

Bug#940144: developers-reference: document self-service givebacks in wanna-build section

On Fri, 13 Sep 2019 at 10:16:25 +0800, Paul Wise wrote: > https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html ... >As an alpha trial I implemented self-service givebacks as a web >script. As SSO for Debian developers is now a thing, it is trivial >to add

Bug#980069: Better documentation of x-terminal-emulator

On Wed, 13 Jan 2021 at 22:49:27 +, Bastien Roucariès wrote: > gnome-terminal -e sleep 60 The upstream-provided gnome-terminal executable does not claim to be an implementation of the x-terminal-emulator alternative. It has its own command-line interface, which uses GNU-style long-option

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

On Thu, 01 Apr 2021 at 18:17:59 -0700, Russ Allbery wrote: > +- ``upstream_version`` components in native packages or > + ``debian_revision`` components in non-native packages ending in > + ``~debNuX`` also indicate a stable update, but of a different type. > + This version convention indicates

Bug#984511: debian-policy: please clarify how archive areas can be combined in source packages

Package: debian-policy Version: 4.5.1.0 Severity: normal X-Debbugs-Cc: ftpmas...@debian.org Package maintainers (including me, most of the time) tend to assume that each source package has to exist in exactly one archive area, and all of its binary packages have to go into that same archive area.

Bug#992601: Allow non-64-bit packages to install to /usr/lib64/ again

On Fri, 20 Aug 2021 at 14:45:01 -0700, Sean Whitton wrote: > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst > index 83b71b1..131b450 100644 > --- a/policy/ch-opersys.rst > +++ b/policy/ch-opersys.rst > @@ -48,8 +48,8 @@ Debian Policy. The following exceptions to the FHS apply: >

Bug#989581: autopkgtest: ADTTMP is now obsolete

On Fri, 20 Aug 2021 at 14:32:27 -0700, Sean Whitton wrote: > I believe that it's been AUTOPKGTEST_TMP for a very long time now Just over 5 years, FYI (autopkgtest 4.0, 2016-06-08). smcv

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

proposed patches for Policy. Their commit messages attempt to capture the rationale for why the other situations are not allowed; corrections/clarifications welcome. Thanks, smcv >From eda0f325301bd514e5ac94328dd4b5a01960634a Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Thu, 9 Sep 2021

Bug#907051: Finding rough consensus on level of vendoring for large upstreams

On Fri, 03 Sep 2021 at 02:46:20 +0200, Jonas Smedegaard wrote: > I suspect that it helps if separating reasons for _encouraging_ > embedding (tiny upstream projects and deeply integrated sets of > upstreams, I guess) from reasons for _discouraging_ embdding (all other > cases, I guess). If the

Bug#998165: debian-policy: document and allow Description in the source paragraph

On Mon, 27 Dec 2021 at 15:08:03 -0700, Nicholas D Steeves wrote: > The following is only Informational level, but the existence of > Lintian's "duplicate-long-description" tag suggests that producing > duplicate bin:Descriptions in bin:libfoo and bin:foo packages is not > ideal, thus a straight

Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus

On Fri, 29 Oct 2021 at 12:40:34 +0200, Adam Borowski wrote: > On Fri, Oct 29, 2021 at 11:12:03AM +0100, Simon McVittie wrote: > > * dbus, the portable reference implementation > > * dbus-broker, a Linux-specific reimplementation > > > > so it seems like a good time t

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

On Thu, 09 Sep 2021 at 21:15:06 +0200, Ansgar wrote: > On Thu, 2021-09-09 at 17:39 +0100, Simon McVittie wrote: > > In the form of a table, the allowed source/binary combinations are: > > > >   |    binary   | > >

Bug#984511: debian-policy: please clarify how archive areas can be combined in source packages

Control: forcemerge 994008 984511 On Thu, 04 Mar 2021 at 13:09:04 +, Simon McVittie wrote: > Package maintainers (including me, most of the time) tend to assume that > each source package has to exist in exactly one archive area, and all > of its binary packages have to go into

Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus

ed wording attached. Thanks, smcv >From cc65839b65e9a41ca0e9e633ac32a085cec66fa2 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Fri, 29 Oct 2021 10:58:13 +0100 Subject: [PATCH] virtual-package-names-list: Add dbus-system-bus, default-dbus-system-bus This is the same as dbu

Bug#1004522: debian-policy: Proposing new virtual packages: wayland-session, x-session

n than an x-window-manager". smcv >From 0ddc90382dda161060459f286f81fe26ecaffc4e Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Fri, 18 Feb 2022 20:34:33 + Subject: [PATCH] Describe how to register X11 and Wayland sessions Closes: #1004522 --- polic

Bug#1004522: debian-policy: Proposing new virtual package: wayland-session

Package: debian-policy Version: 4.6.0.1 Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org GNOME's gdm3 and KDE's sddm both enumerate possible Wayland sessions in /usr/{,local/}share/wayland-sessions/*.desktop and make them available as desktop sessions that users can choose, in

Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus

On Thu, 23 Dec 2021 at 21:26:53 -0700, Sean Whitton wrote: > On Fri 29 Oct 2021 at 11:12AM +01, Simon McVittie wrote: > > it seems like a good time to introduce {default-,}dbus-system-bus > > virtual packages, mirroring {default-,}dbus-session-bus. > > virtual-package

Bug#1004522: debian-policy: Proposing new virtual packages: wayland-session, x-session

On Sat, 29 Jan 2022 at 20:12:21 +, Simon McVittie wrote: > I propose this entry for virtual-package-names-list.yaml: > > - name: wayland-session > description: a Wayland desktop session > (/usr/share/wayland-sessions/*.desktop) Having looked more closely at display manag

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#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#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

On Wed, 06 Sep 2023 at 16:51:10 -0600, Sam Hartman wrote: > I'd consider it a non-RC bug if someone were manually writing > #!/usr/bin/sh As long as our official buildds are non-merged-/usr, I would consider use of that path in scripts that get run at package build time to be potentially RC, in

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

On Thu, 07 Sep 2023 at 00:50:54 +0100, Luca Boccassi wrote: > On Thu, 7 Sept 2023 at 00:45, Sam Hartman wrote: > > I.E. in the cases you adjust, I think it is already > > not a bug, and it would be inappropriate to use existing policy language > > to complain about which interpreter path people

Bug#567033: Decide if we should continue recommending /usr/games

On Mon, 11 Sep 2023 at 10:19:13 -0700, Russ Allbery wrote: > I am inclined to agree [with no longer recommending /usr/games]; > it's just one more thing for people to think about > while packaging things, and I don't think it serves much of a useful > purpose. However, the bug log has a couple of

Re: Does iproute2 moving config files to /usr/lib violate section 10.7.2?

On Sun, 17 Sep 2023 at 02:03:52 +0200, Santiago Vila wrote: > If the files are intended to be modified "in place" by the > system admin, we call them configuration files (and we try hard > to put them in /etc). If they are not intended to be modified by > the system admin, we don't call them

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

On Tue, 12 Sep 2023 at 22:17:44 -0700, Russ Allbery wrote: > >> Maybe the right way to do this is just have two examples, one as the > >> default and another if you're using tmpfiles.d functionality added in a > >> specific version of systemd that's newer than the version shipped with > >> the

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

On Wed, 23 Aug 2023 at 09:22:41 +0200, julien.pu...@gmail.com wrote: > In src:mathcomp-analysis 0.6.4-2, I declared that libcoq-mathcomp- > classical Breaks libcoq-mathcomp-analysis (<< 0.6.4) and closed the > bug. It was swiftly re-opened because I hadn't used Breaks+Replaces > according to

Bug#696185: [copyright-format] Use short names from SPDX

Please keep the subject line in place when replying to bugs, to give readers some context (maintainers will often be seeing bug mail as a single message among many unrelated messages). On Sat, 03 Sep 2022 at 16:22:46 +0500, Akbarkhon Variskhanov wrote: > FSF[1] as well as SPDX[2] request using

Bug#975631: debian-policy: window manager: remove reference to Debian menu

On Tue, 20 Sep 2022 at 21:45:28 -0700, Russ Allbery wrote: > I just found https://bugs.debian.org/838777, which says packages that only > provide a window manager without a mechanism for launching programs should > not register as x-window-manager See also https://bugs.debian.org/1004522 in which

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

On Thu, 22 Sep 2022 at 19:11:38 -0700, Russ Allbery wrote: > I also reworded the paragraph about backports to hopefully address > Holger's reading. It's just trying to say that backports uses aptitude in > the normal way and doesn't do anything special to transform the > alternative. It's

Bug#1026231: debian-policy: document droppage of support for legacy locales

On Wed, 21 Dec 2022 at 18:15:11 +0100, Adam Borowski wrote: > On Mon, Dec 19, 2022 at 07:08:09PM +0000, Simon McVittie wrote: > > On Fri, 16 Dec 2022 at 19:21:37 +0100, Adam Borowski wrote: > > > * The execution environment (usually init system or a container) must > &

Bug#1026231: debian-policy: document droppage of support for legacy locales

On Fri, 16 Dec 2022 at 19:21:37 +0100, Adam Borowski wrote: > As of Bookworm, legacy locales are no longer officially supported. For clarity, I think when you say "legacy locales" you mean locales whose character encoding is either explicitly or implicitly something other than UTF-8 ("legacy

Bug#1026231: debian-policy: document droppage of support for legacy locales

On Wed, 18 Jan 2023 at 16:30:46 -0700, Anthony Fok wrote: > In their mind, GB 18030 encompasses a lot more than just > a character encoding mapping table. It is the full support package > (including fonts, display, printing, input methods, etc.) for Han > Chinese and all other minority languages

Bug#1026231: debian-policy: document droppage of support for legacy locales

On Fri, 20 Jan 2023 at 09:54:21 -0700, Anthony Fok wrote: > supposedly some older Chinese websites are still using "GBK" as > encoding, probably something like: > > > > which has less than 30,000 characters and thus a very limited subset > of Unicode. And, presumably not everyone has the

Bug#1015784: source-only upload requirement not documented

t; binary package have to do a sourceful upload regardless, and I'd prefer to encourage maintainers to be responsible for their packages' migration to testing rather than centralising that responsibility into the release team. smcv >From 96ea2e40f43ce32895d3d2a30e1b5c3319aa1540 Mon Sep 17 00

Re: nocheck (don't run) vs nodoc (don't build)

On Wed, 26 Apr 2023 at 18:59:46 +0200, Christian Kastner wrote: > Policy 4.9.1 states that (emphases mine): > * "[nocheck] says not to *run* any build-time test suite" > * "[nodoc] says to skip any *build* steps" > > My reading with regards to 'nocheck' was that where tests were available >

Re: nocheck (don't run) vs nodoc (don't build)

On Wed, 26 Apr 2023 at 16:48:43 -0600, Sam Hartman wrote: > Simon> - the nocheck option SHOULD NOT alter the contents of any > Simon> binary package > > I agree this is true--possibly even as a MUST--for the nocheck build > profile, but > I think DEB_BUILD_OPTIONS are allowed to modify the

Re: nocheck (don't run) vs nodoc (don't build)

On Wed, 26 Apr 2023 at 23:24:58 +0200, Christian Kastner wrote: > On 2023-04-26 20:42, Russ Allbery wrote: > > It's just > > less common (although certainly not unheard of) for test suites to have > > test-suite-only build dependencies (as opposed to test-only runtime > > dependencies, which are

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

(Newly cc'd elogind maintainers: Please see #945269 for context) On Sun, 04 Jun 2023 at 12:15:41 +0100, Luca Boccassi wrote: > On Sun, 4 Jun 2023 at 12:02, Sean Whitton wrote: > > On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi wrote: > > > For now I've kept only a mention of the

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

On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote: > On Sun, 4 Jun 2023 at 14:56, Simon McVittie wrote: > > So I think the only realistic options for packages that hard-require > > this functionality (not all do) are: > > > > 1. Depends: systemd | systemd-tmpfi

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

On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote: > If it is useful, adding a "default-tmpfiles" or so virtual package > would be fine by me - but with the kfreebsd port being retired soon, > and i386 (for hurd) going the way of the dodo, I'm not sure it would > be very useful? I don't

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

On Tue, 06 Jun 2023 at 20:40:52 -0700, Russ Allbery wrote: > Luca Boccassi writes: > > +Packages might need additional files or directories to implement their > > +functionality. Directories that are located under ``/var/`` or > > +``/etc/``, and files that are located under ``/var/``, must not

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

On Tue, 06 Jun 2023 at 11:37:51 +0100, Sean Whitton wrote: > On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie wrote: > > Another possible mitigation which I haven't previously seen proposed > > is giving *elogind* a Depends or Recommends on systemd-*-standalone. > > I

Re: 6.1.3. Multiple binary packages question

On Sun, 18 Jun 2023 at 23:18:24 +, Holger Levsen wrote: > On Sun, Jun 18, 2023 at 11:19:06PM +0200, Bill Allombert wrote: > > The drawback of dh_install is that it requires more diskspace to build than > > dh_movefiles but is less error prone. > > So unless your package is very large, it is

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

On Sun, 25 Jun 2023 at 18:51:24 +0100, Luca Boccassi wrote: > Tentatively this should happen within Trixie's development cycle. Of > course it's free software and generators are not that difficult to > maintain, so if someone wanted to lift the sysv generator out of the > systemd repository and

Bug#872587: Document the Protected field

On Wed, 27 Mar 2024 at 14:43:40 +0200, Martin-Éric Racine wrote: > ke 27. maalisk. 2024 klo 14.00 Andrey Rakhmatullin (w...@debian.org) > kirjoitti: > > "Essential: yes" are always installed. Tools and dependencies assume they > > are installed. Bootstrapping tools install them implicitly.

<    1   2