Bug#1069858: libkrb5-3: krb5.conf seems to ignore rdns = false
Lukas Grässlin writes: > It's ldapsearch in all cases with libsasl2-modules-gssapi-mit:amd64 > 2.1.28+dfsg-10 on Debian and cyrus-sasl-gssapi-2.1.27-6.el8_5.x86_64 on > the RHEL machine. I suspect you are being bitten by: https://web.mit.edu/Kerberos/krb5-devel/doc/admin/princ_dns.html#openldap-ldapsearch-etc (at the bottom of the page), which is not under the control of the Kerberos libraries. It's a very long-standing issue in Cyrus SASL that some of us used to patch locally. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
Sean Whitton writes: > We have two seconded solutions, so you and I should perhaps break the > tie. I prefer the Bill's 'Autobuild: no' solution as the more > conservative change: we only have data about packages that are currently > autobuilt, not those that aren't, so we might be making those buggy if > we just ban network access for all non-free packages. How about you? Yup, let's go with Bill's change since it's a bit more conservative. I think it accomplishes the same goal. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
Philipp Kern writes: > On 04.04.24 20:51, Bill Allombert wrote: >> I still think we should allow Autobuild: no as an escape hatch. If we >> want to require non-free package to be autobuildable, we should be more >> explicit about it (and probably require more feedback from >> debian-devel). > There is no requirement for non-free to be autobuildable today. This > change also does not introduce this, except for everything that is to be > built on official builders to not require network access. I think Bill's point is that the section of Policy being changed here isn't only for autobuilt packages. It sets general requirements for all Debian packages, including non-free packages that are never autobuilt, and therefore arguably prohibits network use during the build of a non-free package that was never intended to build on the autobuilders, which is a bit outside the scope of the original motivation for this change. (I didn't understand that point at first.) I'm not sure what I think about that. We have a general escape hatch already for non-free packages in Policy 2.2.3 that says they may not fully comply with Policy, which may be sufficient. Builds that use the network seem like a bad idea even in non-free packages because it means we may not be able to rebuild them since all of the relevant data is not in the Debian source package. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Tobias Frost writes: > On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote: >> Thanks Philipp. Following that result, please find a patch proposal: >> >> --- a/policy/ch-source.rst >> +++ b/policy/ch-source.rst >> @@ -338,9 +338,9 @@ >> For example, the build target should pass ``--disable-silent-rules`` >> to any configure scripts. See also :ref:`s-binaries`. >> >> -For packages in the main archive, required targets must not attempt >> -network access, except, via the loopback interface, to services on the >> -build host that have been started by the build. >> +Required targets must not attempt network access, except, via the >> +loopback interface, to services on the build host that have been started >> +by the build. >> >> Required targets must not attempt to write outside of the unpacked >> source package tree. There are two exceptions. Firstly, the binary > LGTM, Seconded. Also looks good to me. Seconded. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1065768: libauthen-krb5-perl: FTBFS on arm{el,hf}: Krb5.xs:1040:17: error: implicit declaration of function ‘krb5_free_address’; did you mean ‘krb5_free_addresses’? [-Werror=implicit-function-dec
gregor herrmann writes: > I'm by far not any expert on C code and gcc flags; but yes, given the > above findings and unless someone more knowledgeable steps up in the > next couple of week, I think we have to remove libauthen-krb5-perl (and > libauthen-krb5-admin-perl). Authen::Krb5 has a bunch of stuff that dates from the pre-GSS-API era of Kerberos, and there were other things that at one point got me to start writing my own version of the same idea (although alas I never finished). In theory, one could delete the pieces of the module that try to do things that no one should really be doing from Perl and the rest of it remains somewhat useful, but given that upstream has archived the project, I would go ahead and remove it. Maybe someday I'll dust off and finish a proper Kerberos Perl module that uses the modern C API. In my copius free time. :) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1068047: Suspicious commit merged in 2021 from account responsible for xz backdoor
Package: libarchive13t64 Version: 3.7.2-1.1 Severity: important X-Debbugs-Cc: r...@debian.org So far it looks like no one has been able to figure out an obvious way for this to be exploitable, but I wanted to make sure that you were aware of this upstream issue: https://github.com/libarchive/libarchive/pull/1609 The author of this commit is the same GitHub account that was used to create the xz backdoor. Upstream has merged a revert of this change at: https://github.com/libarchive/libarchive/pull/2101 It may be worth expediting getting this change into Debian in case the potential attacker knows something that we don't. However, I don't have any reason to currently believe that this is a security vulnerability, so I've kept the severity at important and not applied the security tag. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libarchive13t64 depends on: ii libacl12.3.2-1 ii libbz2-1.0 1.0.8-5.1 ii libc6 2.37-15.1 ii liblz4-1 1.9.4-1+b2 ii liblzma5 5.6.1+really5.4.5-1 ii libnettle8t64 3.9.1-2.2 ii libxml22.9.14+dfsg-1.3+b2 ii libzstd1 1.5.5+dfsg2-2 ii zlib1g 1:1.3.dfsg-3.1 libarchive13t64 recommends no packages. Versions of packages libarchive13t64 suggests: pn lrzip -- no debconf information
Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology
Josh Triplett writes: > Mostly, recent discussions in various places regarding whether packages > are required to use *cron* to run periodic jobs. Policy says what > packages must do if they install a cronjob, but that itself does not > mandate the use of cron specifically. It seemed worth explicitly stating > the understood-but-unwritten interpretation that having Policy about XYZ > does not mandate that packages use XYZ. There is a near-universal human tendency to argue with the medium if one disagrees with the message. As part of the old saying among lawyers, often attributed to Carl Sandburg, goes: "If the facts are against you, argue the law. If the law is against you, argue the facts." I don't think these discussions were truly about the wording of Policy, and I don't think changing the wording of Policy in the way you propose would have changed those discussions. There is no magic wording of Policy that, if we get all of the sentences just right, will cause the project disagreement over the appropriate role of systemd to somehow melt away. It is possible that someone unaware of the long-standing project debates about systemd and timers and so forth (I take it on faith that somehow such people still exist) might, upon reading Policy and seeing only one description of how to handle periodic tasks, assume that's the only one that Debian supports. I don't think the solution to that problem is to add a generic statement elsewhere in Policy that they are neither likely to read nor likely to connect to the problem they're trying to solve. I think a better solution is to document the other way of doing things in Policy. Then we can argue about whether Policy should recommend one method over another, which is the real heart of the disagreement that at some point we need to confront. (I know, I know, I'm one to talk given that I dropped all my Policy work on the floor and disappeared for six months. But still, I would give myself the same advice.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts
Sam Hartman writes: > However, I think it is essential that we spend significant time figuring > out how we can do better with future upgrades and decision processes, > possibly at a point where we have enough distance that we can hear each > other without anger, while not so much distance that we have lost the > technical detail. +1 There were some very important technical and social lessons to be learned from this whole process, as well as a whole lot of incredibly valuable research and a greater understanding of some misunderstandings and fragility in how are full ecosystem of packaging tools fits together. I think the only way out for the /usr-merge transition specifically is through, and until we finish that we're probably not in a good position to absorb those lessons in a more comprehensive way, but I hope we don't skip that step. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1063710: lintian: apache2-deprecated-auth-config ignores mentioned workaround
Roland Rosenfeld writes: > I observe the following warning in xymon package: > W: xymon: apache2-deprecated-auth-config Allow > [etc/apache2/conf-available/xymon.conf:23] > N: > N: The package is using some of the deprecated authentication configuration > N: directives Order, Satisfy, Allow, Deny, or > N: > N: These do not integrate well with the new authorization scheme of Apache > N: 2.4 and, in the case of and have confusing > N: semantics. The configuration directives should be replaced with a > suitable > N: combination of , , Require all, Require local, > N: Require ip, and Require method. > N: > N: Alternatively, the offending lines can be wrapped between N: !mod_authz_core.c> ... or ... > N: directives. > N: > N: Visibility: warning > N: Show-Always: no > N: Check: apache2 > But this xymon.conf already uses the mentioned > ... > wrapper: This is definitely a bug in that the tag doesn't match the tag description, but it may also be worth noting that Apache 2.4 was released in February of 2012 and Apache 2.2 has been officially end of life and entirely unsupported since July of 2017. I think one can make a good argument that both the Lintian tag description and xymon should just drop all support for Apache versions prior to 2.4. Hopefully no one is still running it, since it almost certainly has significant unfixed security vulnerabilities at this point. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1060146: libnews-article-nocem-perl: Signature hash hardcoded to SHA1
I think the critical thing I missed in the original message is that
News::Article::NoCeM is constructing an inline signature by calling
pgp_sign. The Hash header here is before the signed body, not before the
signature, which is obvious in your original message but which I failed to
pay proper attention to.
Christoph Biedl writes:
> So, a blank line doesn't help. The message by gpgv is
> | gpgv: Signature made Fri Jan 5 18:21:01 2024 UTC
> | gpgv:using RSA key 87FB8F9D33883045A832B4FFD90D76CC97A7B20D
> | gpgv: WARNING: signature digest conflict in message
> | gpgv: Can't check signature: General error
> and this leads to an error message from perl-nocem:
> | Article : unknown error (ID D90D76CC97A7B20D)
> where "WARNING: signature digest conflict in message" is the same as
> I had seen in the first place, when there was the hardcoded "SHA1".
> For completeness, this is gpgv 2.2.40-1.1, from Debian 12 ("bookworm").
> Also, neither the NoCeM message nor the key are publicly available.
I think this is a bug in News::Article::NoCeM. It is constructing an
inline signed document using PGP::Sign's pgp_sign function, but pgp_sign
creates detached signatures. Detached and inline signatures are subtly
different, which has historically been the cause of all sorts of pain and
suffering trying to deal with OpenPGP signatures.
This is explicitly called out in the PGP::Sign manual page, although it
should be clearer since it implies the only issues are with whitespace
munging, but it seems like there are more issues than just that.
The whitespace munging support addresses the most common difference
between cleartext and detached signatures, but does not deal with all
of the escaping issues that are different between those two
modes. It's likely that extracting a cleartext signature and verifying
it with this module or using a signature from this module as a
cleartext signature will not work in all cases.
The other use cases for PGP::Sign (control message signatures and
PGPMoose) both use detached signatures, and it does try to document that
it only deals with detached signatures:
This module supports only two OpenPGP operations: Generate and check
detached PGP signatures for arbitrary text data.
Again, though, I should make this clearer.
I'm not sure where that leaves this bug, though. It's quite
understandable that News::Article::NoCeM doesn't want to implement the
annoying logic of figuring out the correct flags to call GnuPG, but if the
expectation for NoCeM messages is that they use inline signatures (which I
believe is the case, although ideally they should use multipart/signed and
application/pgp-signature), PGP::Sign doesn't do that. I do have other
use cases for inline signatures currently, so I am not completely opposed
to adding that support, although the more correct thing for me to do with
those other use cases would be to switch to multipart/signed instead. At
least the last time I looked, inline signatures were very poorly
documented and standardized.
It's possible that this specific bug could be fixed if there were a way to
pass the desired hash algorithm into the sign() method of PGP::Sign so
that News::Article::NoCeM can force SHA-1 as a hash algorithm, thus making
the signature match the headers. You suggested that in your original
message. That's a bit more within the remit of PGP::Sign and I feel more
comfortable supporting that. But I fear that may not be a full fix, since
there's still the detached versus inline signature mismatch that I think
is quite likely to produce more problems in the future. (And of course
there's also the problem that News::Article::NoCeM really should be using
SHA-256, but that raises backwards compatibility issues. There are a lot
of ancient PGPs out there in Usenet world.)
> It is indeed present there, I used pgpdump to reveal the hash algorithm
> is actually SHA512. So this is a design decision I don't quite follow,
> but possibly there is or was a need to do things that way.
This is ringing a vague bell. I think the issue with inline signatures is
that since the document is stream-processed, the hash function that should
be used for the text has to be specified *before* the signed body text.
By the time the signature is read, it's too late; the body has already
been consumed and hashed with the default hash algorithm, and the correct
hash is no longer available.
I believe what hash algorithm GnuPG uses by default is controlled by local
GnuPG configuration, and it may well default to SHA-256 these days.
Also, all of these modules should switch to a sane interface to OpenPGP
signing and verification, like sup, but that's a whole other discussion.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1060146: libnews-article-nocem-perl: Signature hash hardcoded to SHA1
Christoph Biedl writes: > * Omitting the hash declaration is not an option either, perl-nocem > fails then. I'm somewhat surprised by this, as my impression was that these Hash lines are optional and GnuPG did the right thing if they were omitted entirely (although you do still need a blank line). I have not looked into this in detail, but I thought the hash algorithm was also present in metadata inside the signature itself. This is essentially required for the main use case of PGP::Sign, Usenet control messages, since the syntax of the X-PGP-Sig header has nowhere to put this metadata and thus it is always lost. perl-nocem itself doesn't seem to care and just copies the whole input into a temporary file for GnuPG. What's the nature of the failure? Is GnuPG failing to validate the resulting file if the hash algorithm is omitted? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1057057: debian-policy: Please make Checksums-Sha1 optional
Dimitri John Ledkov writes: > Dak currently requires Checksums-Sha1, but I am happy to facilitate in > patching dak to make Checksums-Sha1 optional if this bug report is > accepted. The field is documented as mandatory precisely because DAK requires it, which makes it mandatory for Debian packages. As soon as DAK doesn't require it, I'm happy to make it optional (and indeed it would arguably be a bug in Policy if it's optional in the archive but Policy claims it's mandatory). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1042853: docknot: FTBFS with Perl 5.38: t/spin/errors.t failure
gregor herrmann writes: > On Wed, 06 Sep 2023 08:21:24 -0700, Russ Allbery wrote: >> gregor herrmann writes: >>> According to https://github.com/rra/docknot/issues/6 fixed upstream >>> (in git, not released yet). >> Yeah, I'm sorry about the delay here. I'm trying to get a new release >> out shortly and if I fail at that I'll patch this in the Debian >> package. Please feel free to move forward with Perl and don't block on >> this package; this is totally my own (known) problem. > in the light of #1055955 (perl5.38 transition bug) -- do you think > you can upload a fixed version (the current version plus a patch or a > new release) in the near future, or should I upload an NMU with your > upstream commit or should we just ignore docknot for the transition … > or something else? :) I've uploaded a fix; I'm so sorry for the absurd delay. I'd meant to get to this months ago and kept not making time to finish it. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1041731: Hyphens in man pages
"G. Branden Robinson" writes: > How about this? > \- Minus sign. \- produces the basic Latin hyphen‐minus > specifying Unix command‐line options and frequently used in > file names. “-” is a hyphen in roff; some output devices > replace it with U+2010 (hyphen) or similar. Sorry for my original message, which was very poorly worded and probably incredibly confusing. Let me try to make less of a hash of it. I think what I'm proposing is something like: \- Basic Latin hyphenminus (U+002D) or ASCII hyphen. This is the character used for Unix commandline options and frequently in file names. It is non-breaking; roff will not wrap lines at this character. "-" (without the "\") is a true hyphen in roff, which is a different character; some output devices replace it with U+2010 (hyphen) or similar. What I was trying to get at but didn't express very well was to include the specific Unicode code point and to avoid the term "minus sign" because this character is not a minus sign in typography at all (although it is used that way in code). A minus sign is U+2212 and looks substantially different because it is designed to match the appearance of the plus sign. (For example, the line is often at a different height.) I don't know if *roff has a way of producing that character apart from providing it as Unicode. The above also explicitly says that it's non-breaking (I believe that's the case, although please tell me if I got that wrong) and is more (perhaps excessively) explicit about distinguishing it from "-" because of all the confusion about this. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1041731: Hyphens in man pages
Minor point, but since you posted it "G. Branden Robinson" writes: > ... > \- Minus sign or basic Latin hyphen‐minus. \- produces the > Unix command‐line option dash in the output. “-” is a > hyphen in the roff language; some output devices replace it > with U+2010 (hyphen) or similar. The official name of "the Unix command-line option dash" is the hyphen-minus character (U+002D). Given how much confusion there is about this, and particularly given how ambiguous the word "dash" is in typography (the hyphen-minus is one of 25 dashes in Unicode), you may want to say that explicitly in addition to saying that it's the character used in UNIX command-line options (and, arguably as importantly, in UNIX command names). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1041731: Hyphens in man pages
Wookey writes: > I was left not actually know what - and \- represent, nor which one I > _should_ be using in my man pages. And that seems to be the one thing we > should be telling the 'average maintainer'. - turns into a real hyphen (, U+2010). \- turns into the ASCII hyphen-minus that we use for options, programming, and so forth (U+002D). I think my position at this point as pod2man maintainer (not yet implemented in podlators) is that every occurrence of - in POD source will be translated into \-, rather than using the current heuristics, and people who meant to use ‐ should type it directly in the POD source. pod2man now supports Unicode fairly well and will pass that along to *roff, which presumably will do the right thing with it after character set translation. Currently, pod2man uses an extensive set of heuristics, but I think this is a lost cause. I cannot think of any heuristic that will understand that the - in apt-get should be U+002D (so that one can search for the command as it is typed), but the - in apt-like should be aptlike, since this is an English hyphenated expression talking about programs that are similar to apt. This is simply not information that POD has available to it unless the user writing the document uses Unicode hyphens. I believe the primary formatting degredation will be for very long hyphenated phrases like super-long-adjectival-phrase-intended-as-a-joke, because *roff will now not break on those hyphens that have been turned into \-. People will have to rewrite them using proper Unicode hyphens to get proper formatting. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#967443: gnubg: depends on deprecated GTK 2
Bastian Germann writes: > Am 14.10.23 um 21:41 schrieb Russ Allbery: >> Upstream specifically says that the Gtk-3 support is buggy, does not >> work, and should not be used. How thoroughly did you test it? > I have played a round against the computer and have not seen a problem. Okay, thanks! I guess this is probably the best of a bunch of bad options at this point, absent more development velocity upstream. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#967443: gnubg: depends on deprecated GTK 2
Bastian Germann writes: > I am uploading a NMU to DELAYED/10 in order to fix this. The gtk3 > version uses a different OpenGL binding, so you might want to try to > reenable it. Upstream specifically says that the Gtk-3 support is buggy, does not work, and should not be used. How thoroughly did you test it? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1053812: Pretty sure #1053812 is fixed in 4.2
Jonathan Kamens writes: > So, Russ sent me his apt-listchanges database and I took a lot at it and > it was very messed up. > There was a bug in 4.1 which was uncovered and fixed a couple of days ago > as a result of Alexandre Detiste's push to add typing hints to the > program. This bug would have caused the type of corruption that I saw in > Russ's database, so I'm pretty sure it will go away in 4.2. I installed 4.2 locally and then did an apt upgrade and everything worked correctly, so I am also hopeful. 4.2 is on its way to experimental now. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1053863: Terminal problems after suspending less during apt-listchanges output
Package: apt-listchanges Version: 4.1 Severity: normal X-Debbugs-Cc: r...@debian.org As of apt-listchanges 4.1, if I suspend the less command showing the report with Ctrl-Z and then resume with fg or %, the terminal state is incorrect. The report screen is not refreshed, Ctrl-L doesn't work, and q doesn't work to exit unless it's followed by Enter. I suspect that this may be due to setting LESSSECURE, which I talked you into. If so, I think I was wrong that it wouldn't cause problems. I'm not sure that's the issue, but it feels like the most relevant change. -- Package-specific info: ==> /etc/apt/listchanges.conf <== [apt] frontend=pager email_address=none confirm=0 save_seen=/var/lib/apt/listchanges which=both no_network=false headers=false reverse=false -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-listchanges depends on: ii apt2.7.6 ii debconf [debconf-2.0] 1.5.82 ii python33.11.4-5+b1 ii python3-apt2.6.0 ii python3-debconf1.5.82 ii sensible-utils 0.0.20 ii ucf3.0043+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser] 118.0.5993.70-1 ii firefox [www-browser] 118.0.2-1 ii google-chrome-stable [www-browser] 118.0.5993.70-1 ii links [www-browser] 2.29-1+b1 ii lynx [www-browser] 2.9.0dev.12-1 ii postfix [mail-transport-agent] 3.8.2-1 ii python3-gi 3.46.0-1 ii w3m [www-browser] 0.5.3+git20230121-2 ii xterm [x-terminal-emulator] 385-1 -- debconf information: * apt-listchanges/which: both * apt-listchanges/headers: false * apt-listchanges/frontend: pager * apt-listchanges/reverse: false * apt-listchanges/save-seen: true * apt-listchanges/email-address: * apt-listchanges/no-network: false apt-listchanges/email-format: text * apt-listchanges/confirm: false
Bug#1053812: apt-listchanges showing old changelog entries during upgrade
Jonathan Kamens writes: > Again, I hate to do this, but until we've figured this out, can the two > of you please do me a favor? Before you run each apt upgrade, please > save a backup copy of /var/lib/apt/listchanges, then if the problem > happens during the upgrade, please send me the backup copy of the file > as well as the new version of the same file that should have been > modified during the upgrade. I think this must have something to do with > what's in your seen database but I am unable to recreate a database that > triggers the issue, so I think I need to see yours. I'm sending you this via direct mail. I'm now seeing the problem with each apt upgrade (in other words, I feel like 4.1 might be worse than 4.0, which seemed to exhibit the problem only with some packages). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1053812: apt-listchanges showing old changelog entries during upgrade
Package: apt-listchanges Version: 4.1 Severity: normal X-Debbugs-Cc: r...@debian.org Looks like some variation of this bug still exists in 4.1, although I'm not sure if it's the same bug. But the following upgrades: Unpacking golang-1.21-doc (1.21.3-1) over (1.21.2-1) ... Unpacking golang-1.21-src (1.21.3-1) over (1.21.2-1) ... Unpacking golang-1.21-go (1.21.3-1) over (1.21.2-1) ... Unpacking golang-1.21 (1.21.3-1) over (1.21.2-1) ... showed a bunch of old changelog entries for golang-1.19, golang-1.18, golang-1.17, etc. -- Package-specific info: ==> /etc/apt/listchanges.conf <== [apt] frontend=pager email_address=none confirm=0 save_seen=/var/lib/apt/listchanges which=both no_network=false headers=false reverse=false -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-listchanges depends on: ii apt2.7.6 ii debconf [debconf-2.0] 1.5.82 ii python33.11.4-5+b1 ii python3-apt2.6.0 ii python3-debconf1.5.82 ii sensible-utils 0.0.20 ii ucf3.0043+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser] 117.0.5938.149-1 ii firefox [www-browser] 118.0.2-1 ii google-chrome-stable [www-browser] 118.0.5993.70-1 ii links [www-browser] 2.29-1+b1 ii lynx [www-browser] 2.9.0dev.12-1 ii postfix [mail-transport-agent] 3.8.2-1 ii python3-gi 3.46.0-1 ii w3m [www-browser] 0.5.3+git20230121-2 ii xterm [x-terminal-emulator] 385-1 -- debconf information: * apt-listchanges/confirm: false * apt-listchanges/save-seen: true * apt-listchanges/frontend: pager apt-listchanges/email-format: text * apt-listchanges/email-address: * apt-listchanges/which: both * apt-listchanges/headers: false * apt-listchanges/reverse: false * apt-listchanges/no-network: false
Bug#1053725: apt-listchanges: Shows NEWS for package tor from 2008
Jonathan Kamens writes: > Not the same bug. #1053696 only applies to changelog entries, not NEWS > entries, since the latter can't be downloaded via apt. > I am thus far unable to reproduce this. Still investigating. Ah, whoops, sorry, I wasn't reading carefully enough. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1053725: apt-listchanges: Shows NEWS for package tor from 2008
Control: merge 1053696 1053725 Axel Beckert writes: > after the upgrade to 4.0, apt-listchanges showed me this ancient NEWS > when upgrading tor from 0.4.8.6-1 to 0.4.8.7-1. [...] > Might be related or the same as #1053696 by Russ (X-Debbugs-Cc'ed). Yeah, fairly sure this is the same problem. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1053696: Upgrading Python packages showed numerous ancient changelog entries
Jonathan Kamens writes: > TLDR this will be fixed in 4.1 and it's a significant enough fix that I > should probably release 4.1 to experimental Great, thank you! Let me know when that's ready to go. > So, this was one of the edge cases mentioned in the design documentation > for the revamped changelog filtering logic: when the persistent database > is not being used in a particular invocation of the program or there is > no data for a particular package in the database (this is what you ran > into), and the changelog data for a package is being fetched over the > network because it is not present in the package, we can't use > historical changelog data to determine which entries to display and > which to filter out. I probably should know this, but I guess I don't: why did you have to fetch changelog data for those packages from the network? Both of them ship truncated changelogs, but the changelogs are truncated well, well before any entries that would be of any interest to apt-listchanges on my system. I probably don't understand the design model here, but I would have expected changelogs to only be fetched over the network if apt-listchanges exhausted the changelog shipped with the package and still couldn't find the beginning of the entries it wanted to display. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1053696: Upgrading Python packages showed numerous ancient changelog entries
Package: apt-listchanges Version: 4.0 Followup-For: Bug #1053696 X-Debbugs-Cc: r...@debian.org Same thing happened with the following upgrades: Unpacking gcc-12 (12.3.0-10) over (12.3.0-9) ... Unpacking libgcc-12-dev:amd64 (12.3.0-10) over (12.3.0-9) ... Unpacking cpp-12 (12.3.0-10) over (12.3.0-9) ... Unpacking gcc-12-base:amd64 (12.3.0-10) over (12.3.0-9) ... apt-listchanges displayed what I think is the entire gcc changelog, including the entries for 12.3.0-9 which were already installed. It's not happening with every package, though. I'm not sure yet what the common pattern is, unless it's packages that have multiple package names in their changelog. -- Package-specific info: ==> /etc/apt/listchanges.conf <== [apt] frontend=pager email_address=none confirm=0 save_seen=/var/lib/apt/listchanges which=both no_network=false headers=false reverse=false -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-listchanges depends on: ii apt2.7.6 ii debconf [debconf-2.0] 1.5.82 ii python33.11.4-5+b1 ii python3-apt2.6.0 ii python3-debconf1.5.82 ii sensible-utils 0.0.20 ii ucf3.0043+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser] 117.0.5938.149-1 ii firefox [www-browser] 118.0-1+b1 ii google-chrome-stable [www-browser] 117.0.5938.149-1 ii links [www-browser] 2.29-1+b1 ii lynx [www-browser] 2.9.0dev.12-1 ii postfix [mail-transport-agent] 3.8.2-1 ii python3-gi 3.46.0-1 ii w3m [www-browser] 0.5.3+git20230121-2 ii xterm [x-terminal-emulator] 385-1 -- debconf information: * apt-listchanges/confirm: false * apt-listchanges/headers: false * apt-listchanges/which: both * apt-listchanges/email-address: * apt-listchanges/reverse: false * apt-listchanges/save-seen: true * apt-listchanges/frontend: pager * apt-listchanges/no-network: false apt-listchanges/email-format: text
Bug#1053696: Upgrading Python packages showed numerous ancient changelog entries
Package: apt-listchanges Version: 4.0 Severity: normal X-Debbugs-Cc: r...@debian.org An apt run that included the following upgrades: Unpacking python3.11-dev (3.11.6-3) over (3.11.6-2) ... Unpacking libpython3.11-dev:amd64 (3.11.6-3) over (3.11.6-2) ... Unpacking libpython3.11:amd64 (3.11.6-3) over (3.11.6-2) ... Unpacking python3.11-venv (3.11.6-3) over (3.11.6-2) ... Unpacking python3.11 (3.11.6-3) over (3.11.6-2) ... Unpacking libpython3.11-stdlib:amd64 (3.11.6-3) over (3.11.6-2) ... Unpacking python3.11-minimal (3.11.6-3) over (3.11.6-2) ... Unpacking libpython3.11-minimal:amd64 (3.11.6-3) over (3.11.6-2) ... Unpacking python3.11-doc (3.11.6-3) over (3.11.6-2) ... appears to have gotten confused about what entries I would have seen before and showed me what appeared to be the entire python3.11 changelog. I thought it may have only been because the package name in that changelog changes over time, but it also showed me the entries for 3.11.6-2 and 3.11.6-1, which have the same source and binary package names and were already installed. That makes me think something more fundamental may have gone wrong. I'm not completely sure which package the changelog entries were pulled from. I spot-checked a few of them on disk and they all seemed to be truncated at python3.8, but apt-listchanges found and displayed changelog entries going back to python2.* versions. -- Package-specific info: ==> /etc/apt/listchanges.conf <== [apt] frontend=pager email_address=none confirm=0 save_seen=/var/lib/apt/listchanges which=both no_network=false headers=false reverse=false -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-listchanges depends on: ii apt2.7.6 ii debconf [debconf-2.0] 1.5.82 ii python33.11.4-5+b1 ii python3-apt2.6.0 ii python3-debconf1.5.82 ii sensible-utils 0.0.20 ii ucf3.0043+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser] 117.0.5938.149-1 ii firefox [www-browser] 118.0-1+b1 ii google-chrome-stable [www-browser] 117.0.5938.149-1 ii links [www-browser] 2.29-1+b1 ii lynx [www-browser] 2.9.0dev.12-1 ii postfix [mail-transport-agent] 3.8.2-1 ii python3-gi 3.46.0-1 ii w3m [www-browser] 0.5.3+git20230121-2 ii xterm [x-terminal-emulator] 385-1 -- debconf information: * apt-listchanges/headers: false apt-listchanges/email-format: text * apt-listchanges/frontend: pager * apt-listchanges/email-address: * apt-listchanges/reverse: false * apt-listchanges/confirm: false * apt-listchanges/which: both * apt-listchanges/save-seen: true * apt-listchanges/no-network: false
Bug#1003112: apt-listchanges uses sensible-pager now, should this be sensible-pager's job?
Jonathan Kamens writes: > apt-listchanges no longer calls less by default, it calls > sensible-pager. It feels to me like perhaps settings LESSSECURE should > be sensible-pager's job if anybody is going to do it, not > apt-listchanges's job. What do you think? I'm not sure how sensible-pager could do this job, since it doesn't know whether it is being invoked in a circumstance where secure model should be enabled. That information is not part of its API, and enabling secure mode whenever it is invoked seems obviously incorrect. I assume the problem that the original bug reporter is trying to solve is that they want to grant sudo access to run apt upgrade, but that is equivalent to granting full root shell access because of: apt -> apt-listchanges -> less -> !command I think this is one of those awkward cases where there is no great place to put this configuration, because none of those components have enough information to know that it is appropriate. But I think the original bug report is correct that none of the features LESSSECURE disables are likely useful in the apt-listchanges context. The two places where it would make sense to set this to me are in the sudo configuration using env_file or the like, or setting it in apt-listchanges since apt-listchanges at least knows what it is invoking the pager to do and can make an educated guess at what UI options the user is likely to want. I think the other pieces in the chain have even less information and are even less suited to making this decision. Of those two options, having apt-listchanges do it would be less obscure (it's not immediately obvious that apt could run less), although possibly surprising. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package
Jonathan Kamens writes: > * Speaking as an end user, I do not agree with the statement, "I see that > python3-selenium now has a NEWS.Debian entry that points to > README.Debian, which seems like a reasonable way to bring this to users' > attention." Most users don't know to look for either of these > files. Just a quick side note on this point: I strongly encourage everyone running Debian to install apt-listchanges. I feel like we added that to the default install these days but maybe we didn't. You can configure it to show you only NEWS.Debian files, not the full changelog. Any new NEWS.Debian file entry for a package that you have installed is generally worth reading, and this is the supported way (other than the Release Notes for the full stable release) that Debian communicates major breaking changes like this to users. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package
Jonathan Kamens writes: > 2. Download a bazel binary from >https://github.com/bazelbuild/bazelisk/releases and make it >executable in your search path This is going to be the biggest obstacle in the way of any proper fix for this bug. All Debian packages in main must be built with tools that are already packaged in Debian main. This is a hard requirement that we will not change under any circumstances; it goes to the heart of what Debian is and what it means to be a distribution. Bazel is *incredibly* difficult to support in Debian because it is a massive Java and C++ application with a bunch of other dependencies and complex bootstrapping requirements. I see there are some Bazel packages now in the archive, but I don't believe they're a complete Bazel system. The work was being coordinated at https://salsa.debian.org/bazel-team but it looks like it may have stalled based on the last commit times. It sounds from your summary like packaging Selenium Manager will first require packaging Bazel, which I believe has been attempted before without complete success, or rewriting the upstream build system to not use Bazel. I believe this is also blocking inclusion of tensorflow in Debian (although there may be some forward progress there by using CMake instead of Bazel), so you are not alone in wanting this, but also if it were striaghtforward we would have done it already. If it's possible to build Selenium Manager directly with Cargo, that may bypass this part of the problem and would make the problem more tractable, but that would presumably require some research since it sounds like that's not what upstream is recommending. (And someone would still need to ensure that any Rust crates it depends on are packaged.) None of this is a problem created by the maintainer and overriding the maintainer will not help. Someone will have to do this work, and it is very far from trivial. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
Niels Thykier writes: > Russ Allbery: >> Ooo, this is a great framing of the problem. I have a lot of thoughts >> about this. Unfortunately, I'm not sure if they're actionable thoughts >> since my grand vision requires someone to sit down and do some serious >> Policy restructuring and produce a radically different document. But >> maybe if I write them all down and enough people feel similarly, it >> would be worth doing. I would love to work on this, I am just afraid >> that it is the sort of project that I would start and never finish and >> thus never accomplish anything of use. > Indeed, it is definitely the thing I would personally prefer to > pre-align on before adventuring on something of this scale myself (were > I in your shoes), so I totally feel your concern about actionability. I do to some extent want people to encourage me to work on this if they think it would be awesome, since people being happy with it would be what would make all the work worthwhile (although I will probably also need help). :) > Interesting choice with the mixing. I was of the understanding that the > idea was one should try to avoid mixing documentation styles according > to Divio. Admittedly, I find it hard to fully stick to exactly one type > of style, so I would be happy if I had just overlooked the "advice on > mixing". So, I have to admit that I have not read Divio in detail although I have been pointed at it many times and have had the high-level concepts explained to me. I've read bits and pieces, but I'm not sure what it says about mixing. But in terms of what makes an effective Policy document, I think a general structure of an explanation section introducing a part of packaging followed by how-to sections for the underlying tasks would work. > As for the content: The "How-to" style would make sense for the target > audience. I am less clear if all of these headlines makes up a "Policy" > as they sounds like something you could find in a "Debian Packaging 101" > guide. I think that about a quarter of Policy currently is already how-to text. For example, look at Policy 3.4: https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions This is a disguised how-to document on how to write a good package description. There's a ton of stuff in Policy like this. What distinguishes it from a Debian Packaging 101 guide is that the how-to goes into *way* more depth than a 101 guide: edge cases, exceptions, advanced bits of packaging, etc. The main problem from the perspective of helping the typical packager, is that this is mixed in with oodles of advice that is irrelevant to anyone except debhelper maintainers. To take another short example, look at the section on symbolic links: https://www.debian.org/doc/debian-policy/ch-files.html#symbolic-links Half of that section is a specification for the packaging helper, which will fix symbolic links to follow those rules. The rest is sort of a how-to (mixed in with some basic shell command advice). > Side question: Does Policy add anything on the specification for > `symbols` and `shlibs` files as a reference document that is not covered > by dpkg's documentation for these formats? I assume the "symbols guide" > (on /when/ to use symbols and when not too) would go in the previous > section. Well, one can read the two side-by-side and see, and I'm biased as the person who wrote it, but I think it does. Policy duplicates dpkg documentation quite a lot, so this is a question worth asking, but I do think Policy has a good answer. The value that Policy adds over the dpkg documentation generally falls into three categories: 1. Policy is much more opinionated about what features supported by dpkg should be used in packages and how they should be used. There are sometimes things dpkg *can* do that we don't do. A bunch of this is how-to, but I think some of this is reference. 2. Policy is sometimes a lot more verbose and offers worked examples, and sometimes benefits from the additional formatting tools available in Sphinx. This could be imported into the dpkg documentation to some extent, of course, but as it stands I think there's value there. 3. dpkg documentation has to cover the complete operation of dpkg, whereas Policy, even in reference sections and packaging helper sections, should only need to cover the surface area that's visible to packaging at the lowest level. I agree that this is a source of some duplication of effort, although in my experience it's not the part that takes the most time. (But I haven't written triggers or multiarch documentation for Policy yet, so maybe it's part of the problem.) > What is it you would see go into this section [packaging helper > specification] that is not the previous section? Literally everything in Po
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
ely free to just make changes without going through a very formal process as long as those changes reflect reality. This is, by nature, going to be incomplete and possibly out of date, but I do think the project should have *somewhere* outside of any specific package where people can write down the details of, oh, the other options to Rules-Requires-Root that we aren't currently using. But we would stick a lot of disclaimers on it and make it clear that this is internals that only 10-20 people really need to know about. I don't know if we can get here, but personally I think it would be a massive improvement over where we are now, even if we spend the next ten years sorting out structural problems with how we moved things around. But it's a *ton* of work, so realistically it's never going to happen unless it excites other people as much as it does me. Anyway, that's a very long-winded answer to Niels's question. I think Policy should primarily have an audience of packagers, including packagers who need to coordinate cross-package integrations, secondarily have an audience of tool makers who need a reference manual for Debian's file formats and integrations, and then have a deprioritized tertiary audience of toolchain maintainers. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Alexandre Detiste writes: > The ugly magic behind the curtain: > ls /usr/libexec/cruft/ -1 > LOGROTATE -> that parses these for path > SERVICES -> added today reading this discussion, it reads > CacheDirectory= & StateDirectory= from *.service > TMPFILES -> that parses these for path > This whole thing, while being already usefull & used, > is more like a mockup of what could be a "perfect" dpkg. > These tiny shell scripts could be converted into something else > that plugs into dpkg ... for example tiny .so plugins that answer > which package own which dynamic file ? > (for runtime evaluation, other possibility is debhelper magic at > compile-time that generate a list of possible files) Based on previous discussion with Guillem, I think the direction Guillem is headed is something like adding a new member (or field in another member) to the deb format that holds a list of volatile files that the package considers itself responsible for. I think I agree with Guillem's position (at least as I understand it) that it doesn't make sense for dpkg to parse other files to populate that list. That can very easily be handled outside of dpkg. So the idea would be that the package would install tmpfiles.d files, service units, and similar files as normal, and then debhelper would parse those files, extract the list of paths that they manage, and use that to write a control file or the like that dpkg consumes to register those files. If I'm correct about that design, an intermediate step in that direction from where cruft is today would be to add that logic to debhelper and then have debhelper ship that database in the package in /usr/share/cruft/ or some similar directory, and then cruft could just consume that database of registered paths to get attribution information until such time as that can move into dpkg. This design is just off the top of my head, and I'm probably missing some problems and some details. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Bill Allombert writes: > As I said, filling the caches in /var/cache. For that they need to exist > with correct ownership and permissions. Sorry, I think I saw that and then edited my message more and lost it again. That use case makes sense to me, and without the directory already present, you have to know what directory to create and you have to get the ownership and permissions correct. But there's a couple of reasons why I don't think that's a problem: 1. Installing the package creates the directories since it invokes systemd-tmpfiles via postinst, so the directory will normally be there with correct ownership and permissions. The only case where it wouldn't be is in cases where the packages were installed without running postinst, which feels like an unusual use case. 2. Presumably you would be copying these caches from another system, which will normally have the directory with correct ownership and permissions. This isn't necessarily true if you're mixing versions of Debian, of course, but in that case it's not clear the cache format will be correct either. Also, you need to get the ownership and permissions of the files right, which the directory structure doesn't necessarily help you with, and if you're copying that over already, the same mechanism can handle the ownership and permissions of the parent directory. So, by definition any directory that's shipped in the deb cannot have dynamic ownership, which also limits the range of permissions it could have. > even populate /var/www with your website, etc. /var/www is a whole separate problem that I agree has not yet been addressed and would need to be. We've known that /var/www is weird for a while (we have a special exception in the FHS for it because it's breaking the FHS file system layout rules), and there have been a few attempts to handle it some other way, but none of them so far have been successful. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
m very bad at this and have to be reminded repeatedly: stop arguing with people about specifics and use that energy to write down a design with a justification. It will make the arguments much less annoying and repetitive, because a lot of the repetition is because everyone else is sadly incapable of reading your mind and doesn't understand what you are assuming is well-known. > We are working on that. This means that tmpfiles.d would be able to both > create the files/dirs when needed, and remove them when unneeded, ie on > purge - as far as I can tell, that would be the only useful thing that a > dpkg integration would provide. dpkg -S is the most useful feature this supports for me personally (and some related things, such as cruft-finding). More generally, dropping directories that are currently registered with dpkg from dpkg's database is a regression. I think it's a minor regression, but I also think it's an avoidable regression; the amount of work required to maintain an entry in dpkg's database for empty directories that currently can be shipped in the deb is not very high. > I am pretty sure running checksums on local variable data would be a > pretty useless exercise given, well, it's variable. Empty directories don't have checksums, so I don't think this is relevant to this discussion. I'm only talking about empty directories, not files. Packages shipping files in /var is a different problem; there are some packages that do that currently for various reasons (/var/www for web servers comes to mind), and I think we should probably phase that out whether or not we do factory reset and am not intending to entrench that here, but I think it's a different Policy change. > On the contrary I suspect it would break things or at the very least get > in the way, as explained above. Of course I haven't tested this as we > aren't there yet, so can't be 100% sure. But from what I've seen from > some experiments, expectations around /var being fixed and > package-managed is already creating some headaches, and requiring > workarounds. Specifics! Specifics! My kingdom for specifics! :) Bug numbers for these headaches would be helpful, or detailed descriptions, or *something*. You're giving me nothing to work with here, which means that I'm likely to go forward with requiring some of these empty directories be registered with dpkg because that's the less invasive change and avoids a regression. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: Post-/usr-merge paths for script interpreters
Ansgar writes: > But the subject of this issue talks about "script interpreters", not > just `/bin/sh` (which I guess is safe to assume would be one of the > "handful"). > It is unclear what files the Jackson symlink farm proposal would leave > in /bin. Would /bin/python3 stay? Or would it stay first, but dropped > at some later point? What about /bin/perl, /bin/zsh, /bin/env, ...? Oh, okay, I see what you're syaing now. This is a bit beyond the scope of the areas of Policy touched by Luca's proposal, but I can see why it would indeed arise under Ian's proposal. We've introduced new /bin interfaces for every binary in /usr/bin, and if we went down that path we'd remove most of those interfaces again. That is indeed an argument for (c) for *most* things, just not the areas touched by this diff (with the possible exception of /bin/csh; I'm not sure if that would qualify for an exception or not, these days). So yes, I agree that the resolution of this bug would significantly affect what we want to say in Policy about /usr-merge in general, even if not what we say about /bin/sh. I still don't feel like we need to wait for the TC bug to be resolved, since there is a standing TC decision to make /bin a symlink to /usr/bin and we can always change our wording later if that decision changes, but we need to wait for the buildd /usr-merge anyway, so either way I don't think we're ready to merge patches for this bug right now. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Bill Allombert writes: > On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote: >> On Sep 17, Russ Allbery wrote: >>> (I am a little confused by this wording, but I think what you're >>> saying is that /usr is encrypted and read-only, and /var is recreated >>> on each boot. That at least is my understanding of the pattern that >>> you're trying to enable.) >> The general idea is to be able to create /var on the first boot. > Does not that would break users expectation that the system image > contains /var before the first boot ? > A lot of things in /var are caches that are mostly instance-independent > and can be prefilled, but for that, users expect a minimal directory > hierarchy to be present before first boot. Not that I think we're particularly close to achieving this design currently (and to be clear we haven't decided we're working towards this yet), but while I understand why a user would have that expectation today, I'm not sure why it would practically matter. If all of that directory structure appears on first boot, and no static data is stored in /var, what use case requires the directory structure already exist in /var before the first boot? I think you're thinking of cases where the user puts data into /var and expects it to be used by the system after boot, but configuration data would go into /etc, so I'm not sure what data that would be. Also, I think that scenario would still work. My understanding of the design is that /var isn't tmpfs; while there's no precreated directory structure, the user could still make one if they wanted. There wouldn't be the guide of existing empty directories, but this is a fairly sophisticated use case, IMO. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Luca Boccassi writes: > Aside from more practical considerations, shipping /var content in > packages is problematic because it's supposed to be local variable data, > that can be removed without breaking a system. Unless I'm missing something, including the directory in the deb won't make any difference here. dpkg won't break if a directory that was included in the package is deleted. It would show as an inconsistency if someone checked the file system against the dpkg database, but as soon as systemd-tmpfiles runs, it will create the directory again and fix the inconsistency, so I don't see what problems that would create. > More practically, one of the purposes of the hermetic-usr pattern is to > allow several modernizations. The easiest one to achieve is to create > /var/ on firstboot, and encrypt it against the tpm, so that it can be > enabled by default, always, so we can't have packages ship and expect > content in /var from their packages. (I am a little confused by this wording, but I think what you're saying is that /usr is encrypted and read-only, and /var is recreated on each boot. That at least is my understanding of the pattern that you're trying to enable.) Here too, I don't see how including an empty directory in /var in the deb will make any difference here. When you create such a system, you would delete /var, so it wouldn't matter if packages created files in there (and in fact, under every proposal in this bug, installing packages *would* create files there, since systemd-tmpfiles would be invoked by the maintainer scripts anyway). > On top of that, as you mentioned already things will inevitably get out > of sync, and one will have to duplicate everything. One would need to duplicate empty directories in /var (that don't have dynamic ownership). I'm dubious that's a significant burden (it's two or three lines in debian/rules), but if it is, one could even automate this in debhelper by parsing tmpfiles.d if one really wanted to. The main thing that could get out of sync is the ownership, which is indeed not ideal, but I'm also not sure it's going to cause major problems even if people do get it wrong. I was trying to remember if dpkg changes directory (as opposed to file) ownership if it sees a directory owned by an unexpected user. I kind of think it doesn't, but I'm not sure about that. The benefit we gain from this is attribution of the directories in the dpkg database, which is useful (although I understand that one can argue about how useful). So... I think the answer to my question of whether this will interfere with your use case is no? I understand that you don't want to do it, and expected that, and that opinion is important for the discussion, but I'm also trying to figure out if it will *break* anything. > And if dpkg gets the ability to read tmpfiles.d - then that's great, > and even more reasons not to change policy for something that would > only be a temporary stop-gap. I'm not going to assume that this is going to happen on any particular time scale. dpkg has to gain a mechanism for registering transient files first, which in my understanding depends on other significant dpkg architectural work. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Simon McVittie writes: > The key piece of information that was missing from your previous > proposal was that systemd-tmpfiles interface versions match upstream > systemd version numbers. As a concrete example, if someone wants to > upload an implementation other than the one from systemd, it cannot have > Provides: systemd-tmpfiles (= 254) > until it has at least a basic implementation of the new "X", "C+" and > "--graceful" features introduced in systemd 254. Yeah, I had missed that, thank you. I think that's now captured. > If the package benefits from running tmpfiles.d but does not strictly > require it (for example dbus-daemon, where /run/dbus/containers is > needed for some optional functionality), would a Recommends or Suggests > be allowed by this wording, or are we intending for this to be a > mandatory hard dependency? I'm not sure it's going to make a lot of difference in practice, since I think it will be hard to end up with a system that doesn't have a systemd-tmpfiles implementation installed, but I agree that in theory this is too strong. I'll try to come up with a rewording that allows for the possibility of Recommends or Suggests. Maybe just a parenthetical that says or Recommends or Suggests if this more accurately fits the nature of the dependency? I think apart from this and resolving whether to add empty directories into the deb, the remaining issue before we can merge this is to make sure that the sysvinit maintainers are okay with adding the requirement that the init system invoke a systemd-tmpfiles implementation periodically. As I would expect, the systemd-standalone-tmpfiles package only provides the binary, not any init system integration. Does anyone know if that integration has already been done to invoke systemd-tmpfiles during boot on systems using sysvinit? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#915583: debian sphinx styling: second attempt
Stéphane Blondon writes: > I've done a new version. It's based on 'sphinx_rtd_theme' theme. So, to > build the site, the package 'python3-sphinx-rtd-theme' requires to be > added to dependencies. A new file 'debian.css' is specific to set some > colors and renderings. > Reusing 'Read the docs' theme allows to have a responsive design > automatically. > The theme could be modified more but it could be considered as a first > step which is already usable. > There are temporary demos available: > - for debian-policy: http://stephane.yaal.fr/tmp/policy/ > - for (draft sphinx) release-notes: > http://stephane.yaal.fr/tmp/release-notes/ > What do you think about it? Hi Stéphane, Thank you so much for this! I poked around a little bit on your draft render of Policy and personally I'm quite happy with it. The sidebar management with small screens seemed to work for me and is definitely better that what we have right now. I would encourage others to also take a look and provide feedback. My inclination is to merge this in a future release of Policy. The one minor thing that I noticed was that the version number of Policy in the left sidebar at the top is very difficult to read because it's almost the same color as the background. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: Post-/usr-merge paths for script interpreters
Bill Allombert writes: > One of the issue in the past is that reproducible build was broken > because different build environment lead to different paths. We at least > need to address that. I believe the reproducible build problem specifically will be largely fixed by /usr-merging the buildds so that they look like all other Debian systems. I suspect the problems that you ran into in the past were precisely because some systems on which the package was built were /usr-merged and others were not. But you make a good point that just because the /bin and /usr/bin paths both work does not mean that package build systems can pick randomly between them, since that undermines build reproducibility. They need to pick one or the other consistently. I do think packages should be allowed to do a PATH search, and it's up to the people doing a reproducible build to make sure the PATH stays consistent from one build to the next. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: Post-/usr-merge paths for script interpreters
nt to argue for (a) with no enforcement mechanism in packages. > 1) Policy should encourage /bin paths for binaries traditionally in > /bin. (At a minimum I'd like to see this for /bin/sh and /bin/bash). > That at most makes it a minor bug if you don't follow that > encouragement. I think this is the only part of your proposal that I have qualms about, because I agree with Luca that people would use such encouragement to file bugs about it, and I'm not sure we want to encourage those bugs. It may not matter a lot because the bugs will probably exist anyway, but I know that putting things in Policy can sometimes raise the temperature of even minor bugs. I'd be happy to make some sort of statement in the section about shell scripts that /bin/sh and /bin/bash are the traditional paths and will work even if the script is copied to some non-Debian system, but I'm reluctant to issue Policy advice that one therefore should use those paths. But I could be convinced as long as it's just advice, not a should. (But, again, Policy is not a style guide.) > 2) The examples in policy should use the standard interface paths. > (This is the thing I care most about). I agree with this and I'm not seeing any disagreement in the discussion so far. > 3) I'd like to see policy point out that /usr/bin paths will end up > being used, and packages SHOULD work regardless of which path is used. This is the thing that I care the most about and would like to say explicitly somewhere in Policy, even though that's beyond the scope of Luca's original report. I don't think Policy says anything about /usr-merge at all right now, and once the buildds are merged and all Debian systems relevant to unstable development are /usr-merged, we probably should. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1050001: Bug#1051371: Post-/usr-merge paths for script interpreters
Control: unblock 1051371 by 1050001 Ansgar writes: > However, there is a proposal by Jackson for an alternative filesystem > layout based on symlink farms in consideration by the technical > committee. This advocates removing compat symlinks in /bin, /sbin over > time[1], thus requiring (c). This is not a correct summary of Ian's proposal. In the message that you linked, Ian says: /bin and /lib etc. remain directories (so there is no aliasing). All actual files are shipped in /usr. / contains compatibility symlinks pointing into /usr, for those files/APIs/programs where this is needed (which is far from all of them). Eventualloy, over time, the set of compatibility links is reduced to a mere handful. I am absolutely certain that Ian would consider /bin/sh to be one of the programs for which a compatibility symlink is needed, and one of the remaining handful of links that would exist indefinitely into the future. Indeed, he mentions /bin/sh explicitly later in that message. Given that, I believe Ian's proposal is orthogonal to this bug. For /bin/sh and /usr/bin/sh, it would create the same aliasing and thus would create the same question about how to talk about those paths in Policy. I therefore don't think resolution of this bug blocks on the TC bug. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: Post-/usr-merge paths for script interpreters
Luca Boccassi writes: > On Wed, 13 Sept 2023 at 04:48, Russ Allbery wrote: >> Simon pointed out that this bug is not yet ready to act on, which was >> very helpful. Thank you. However, presumably the buildds will be >> /usr-merged at some point in the not-too-distant future, and we do need >> to decide what to do after that point. > While that could be said for the original revision, in my view that's > not really the case for the latest that I posted? > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371#120 > So I would prefer if this was a clone rather than a retitle/repurpose. > Unless I'm missing something, the changes linked above should be > uncontroversial and simply remove excessively normative language in what > are essentially examples that should have been taken as such - and that > currently are not. So, could that be taken forward independently of the > problem you define below? I believe it would be an error to move Policy away from explicitly saying /bin/sh as long as we have unmerged systems. For as long as we have to support unmerged systems, which includes the buildds because quite a surprising range of packages end up needing to be installed on buildds during package builds, packages must use /bin/sh and may not use /usr/bin/sh. This is not currently explicit in Policy because previously it wasn't necessary. Packages using /usr/bin/sh would simply not work, thus forcing the issue. But right now, if we were writing Policy from scratch, we would need to explicitly say that using /bin/sh is a must in order to avoid breaking the buildds, since /usr/bin/sh would appear to work locally and then potentially cause weird problems during package builds. (Ideally build failure, but a lot of strange things can happen when paths are missing during a build.) Presumably this is getting fixed in short order, so it's not worth the intermediate Policy change to add that language only to remove it again. But similarly, I don't think it's correct to relax Policy language about the /bin/sh path for as long as using /usr/bin/sh is potentially a release-critical bug. Obviously this all becomes moot as soon as the buildds are /usr-merged. > I think b would work out fine, but if we want to start being normative > then it probably would make more sense to go for the new layout rather > than the old. It would seem strange to have lived with the old layout > and no rule, and suddenly add a rule for the old layout just as it has > been phased out, no? The reason why this is not strange to me (which is not to say that this is my personal preference) is that previously we had a rule requiring /bin/sh enforced by a much harsher mechanism than Policy: using /usr/bin/sh would simply break. So we *did* have a de facto rule, which we implicitly dropped by doing /usr-merge, and the debate is whether to replace it with a de jure rule. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Guillem Jover writes: > Not shipping these empty directories in the .deb seems like a regression > or a disservice to me. Even for things that might get deleted because > things like our policy or the FHS allows for it (say stuff under > /var/cache), as «dpkg --verify» can be useful. Because of course, these > in addition, can be defined via tmpfiles.d, so that they can possibly be > recreated if needed (until dpkg provides its own interfaces to do that). Luca, are there any drawbacks for your purposes in both shipping the directories in the deb *and* defining them with tmpfiles.d for those cases where it is possible to ship them in the deb (no dynamic owner or group, for instance)? At first glance, it feels like this should be fine, since tmpfiles.d will recreate the directories and dpkg will then be happy with them. It does potentially create problems if dpkg and tmpfiles.d have different ideas about what the ownership or permissions of the directories should be, but at present I don't think such conflicts would create a lot of practical problems (tmpfiles.d should essentialy always win), so I think it's a fairly minor point. It's a bit more complicated to specify in Policy because it's not possible to include the directory in the deb file in cases where it needs to have ownership set based on users or groups created dynamically by the maintainer scripts, but hopefully not overly complicated. This has the valuable benefit, as Guillem points out, of retaining dpkg database awareness of the association between that directory and a package until such time as dpkg is aware of files defined in tmpfiles.d (directly or indirectly via debhelper magic to register the tmpfiles.d targets with a new dpkg dynamic file database; the latter is my guess about where we're headed based on previous discussions). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Russ Allbery writes: > Russ Allbery writes: >> 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 stable version of Debian prior to the one you're targeting. > Here's an updated version with that change plus some other minor fixes. Er, right, helps to rebase first. Here's the actual patch. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/policy/ch-files.rst b/policy/ch-files.rst index b34c183..fa3e5be 100644 --- a/policy/ch-files.rst +++ b/policy/ch-files.rst @@ -722,6 +722,70 @@ The name of the files and directories installed by binary packages outside the system PATH must be encoded in UTF-8 and should be restricted to ASCII when it is possible to do so. +.. _s-tmpfiles.d: + +Volatile and temporary files (``tmpfiles.d``) +- + +Some packages require empty directories in ``/var`` or ``/etc``, or +symlinks or files with trivial content in ``/var``, to implement their +functionality. Examples include directories under ``/var/cache`` that are +writable by the package as cache areas, an initially-empty directory in +``/etc`` intended for local overrides added by the local system +administrator, or a file in ``/var`` that should default to a symlink +elsewhere on the system but may be changed later. + +Rather than include these symlinks, files, or directories in the binary +package or create them in package maintainer scripts, packages should use +the ``tmpfiles.d`` mechanism to specify the files and directories that +should be created. This allows associating these files and directories +with specific packages (not currently possible when creating them in +maintainer scripts), and allows local administrators to delete the +contents of directories such as ``/var/cache`` with the assurance that +``tmpfiles.d`` can recreate the necessary file structure without +reinstalling packages or re-running maintainer scripts. + +For information on how to specify files and directories that should be +managed by the ``tmpfiles.d`` mechanism, see :manpage:`tmpfiles.d(5)`. + +If the files or directories are only needed by a system service or +otherwise should only be created when that service is running, packages +should define those files and directories in the ``systemd`` unit for the +service (and, for alternative init systems, in the configuration for that +init system) instead of using the ``tmpfiles.d`` mechanism. See +:ref:`s-services-dirs` for more details. + +The ``tmpfiles.d`` mechanism may also be used to create and manage files +and directories under ephemeral file systems such as ``/tmp`` and +``/run``, although these are more likely to be associated with a running +service and in those cases should be defined in the ``systemd`` unit for +the service. + +All packages that ship ``tmpfiles.d`` configuration should declare a +dependency on:: + +default-systemd-tmpfiles | systemd-tmpfiles + +If the package uses ``tmpfiles.d`` features that are not supported by all +implementations of the ``systemd-tmpfiles`` virtual package in the stable +release prior to the release being targeted, instead use:: + +default-systemd-tmpfiles (>= v) | systemd-tmpfiles (>= v) + +where ``v`` is the version of ``systemd`` in which the features were +introduced. + +All packages that ship ``tmpfiles.d`` configuration should arrange for +that configuration to be processed during package installation. This +should be handled by the packaging helper framework; for example, packages +using ``debhelper`` should use ``dh_installtmpfiles``, which will add the +appropriate commands to the package maintainer scripts. + +The init system must ensure that ``tmpfiles.d`` configuration is applied +during boot and that ``tmpfiles.d`` cleanup rules are invoked +periodically. See :manpage:`systemd-tmpfiles(8)` for more information on +how to do this. + .. [#] If you are using GCC, ``-fPIC`` produces code with relocatable position independent code, which is required for most architectures diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst index 724074c..e43340f 100644 --- a/policy/ch-maintainerscripts.rst +++ b/policy/ch-maintainerscripts.rst @@ -50,6 +50,11 @@ absolute pathname. Maintainer scripts should also not reset the appending package-specific directories. These considerations really apply to all shell scripts. +Maintainer scripts should not be used to create empty directories in +``/var`` or ``/etc``, or symlinks or files with trivial content in +``/var``. Instead, use the ``tmpfiles.d`` mechanism to manage those +directories and files. See :ref:`s-tmpfiles.d` for more information. + .. _s-idempotency: Maintainer scripts idempotency diff --git a/policy/ch-opersys.rst b/policy/ch
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Russ Allbery writes: > 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 stable version of Debian prior to the one you're targeting. Here's an updated version with that change plus some other minor fixes. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/debian/changelog b/debian/changelog index 4cead28..44a3710 100644 --- a/debian/changelog +++ b/debian/changelog @@ -24,17 +24,6 @@ debian-policy (4.6.3.0) UNRELEASED; urgency=medium Seconded: Helmut Grohne Seconded: Guillem Jover Closes: #970234 - * Policy: Binary and Description fields may be absent in .changes -Wording: Russ Allbery -Seconded: Sam Hartman -Seconded: Guillem Jover -Closes: #963524 - * Policy: systemd units are required to start and stop system services -Wording: Luca Boccassi -Wording: Russ Allbery -Seconded: Luca Boccassi -Seconded: Sam Hartman -Closes: #1039102 -- Sean Whitton Wed, 14 Jun 2023 16:58:40 +0100 diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index d5c9d68..4bab7df 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -278,7 +278,7 @@ The fields in this file are: - :ref:`Source ` (mandatory) -- :ref:`Binary ` (mandatory in some cases) +- :ref:`Binary ` (mandatory) - :ref:`Architecture ` (mandatory) @@ -292,7 +292,7 @@ The fields in this file are: - :ref:`Changed-By ` -- :ref:`Description ` (mandatory in some cases) +- :ref:`Description ` (mandatory) - :ref:`Closes ` @@ -812,16 +812,12 @@ See :ref:`s-descriptions` for further information on this. In a ``.changes`` file, the ``Description`` field contains a summary of -the descriptions of the binary packages being uploaded. If no binary -packages are being uploaded, this field will not be present. - -When used inside a ``.changes`` file, the ``Description`` field has a -different format than in source or binary control files. It is a multiline -field with one line per binary package. The first line of the field value -(the part on the same line as ``Description:``) is always empty. Each -subsequent line is indented by one space and contains the name of a binary -package, a space, a hyphen (``-``), a space, and the short description -line from that package. +the descriptions for the packages being uploaded. For this case, the +first line of the field value (the part on the same line as +``Description:``) is always empty. It is a multiline field, with one +line per package. Each line is indented by one space and contains the +name of a binary package, a space, a hyphen (``-``), a space, and the +short description line from that package. .. _s-f-Distribution: @@ -931,8 +927,7 @@ every architecture. The source control file doesn't contain details of which architectures are appropriate for which of the binary packages. When it appears in a ``.changes`` file, it lists the names of the binary -packages being uploaded, separated by whitespace (not commas). If no -binary packages are being uploaded, this field will not be present. +packages being uploaded, separated by whitespace (not commas). .. _s-f-Installed-Size: diff --git a/policy/ch-files.rst b/policy/ch-files.rst index b34c183..fa3e5be 100644 --- a/policy/ch-files.rst +++ b/policy/ch-files.rst @@ -722,6 +722,70 @@ The name of the files and directories installed by binary packages outside the system PATH must be encoded in UTF-8 and should be restricted to ASCII when it is possible to do so. +.. _s-tmpfiles.d: + +Volatile and temporary files (``tmpfiles.d``) +- + +Some packages require empty directories in ``/var`` or ``/etc``, or +symlinks or files with trivial content in ``/var``, to implement their +functionality. Examples include directories under ``/var/cache`` that are +writable by the package as cache areas, an initially-empty directory in +``/etc`` intended for local overrides added by the local system +administrator, or a file in ``/var`` that should default to a symlink +elsewhere on the system but may be changed later. + +Rather than include these symlinks, files, or directories in the binary +package or create them in package maintainer scripts, packages should use +the ``tmpfiles.d`` mechanism to specify the files and directories that +should be created. This allows associating these files and directories +with specific packages (not currently possible when creating them in +maintainer scripts), and allows local administrators to delete the +contents of directories such as ``/var/cache`` with the assurance that +``tmpfiles.d`` can recreate the necessary file structure without +reinstalling packages or re-running maintainer scripts. + +For information on how to specify fil
Bug#1051371: Post-/usr-merge paths for script interpreters
Control: retitle -1 Post-/usr-merge paths for script interpreters Simon pointed out that this bug is not yet ready to act on, which was very helpful. Thank you. However, presumably the buildds will be /usr-merged at some point in the not-too-distant future, and we do need to decide what to do after that point. I think the root problem behind this bug is that it is revealing we have not made a decision about /bin and /usr/bin path references in Debian after /usr-merge. Various people, myself included, made assumptions about what the policy would be, but we never actually decided anything that I am aware of and people's assumptions are not matching. I think we need to talk about this directly, after which what to do with this bug will probably become obvious. So far as I can tell, there are three main possibilities: (a) Although /bin and /usr/bin are merged (and likewise for the other merged paths), Debian will continue to require (or at least recommend) use of /bin paths for things such as /bin/sh that historically used those paths. (b) Since /bin and /usr/bin (and likewise for the other paths) are merged, /bin/sh and /usr/bin/sh are equivalent. Packages can use whichever path they want, and Debian will end up with a mix of both references. (c) Although /bin and /lib technically work due to the aliasing, they are deprecated and everything in Debian should stop using those paths. All paths should point to /usr/bin and /usr/lib now. Although Luca made a few arguments in the direction of (c), my understanding of his current patch is that it essentially implements (b) for script interpreters, although without encoding into Policy an explicit decision between these three options (quite understandably because he was trying to deal with a narrower issue). Several other people were, I think, arguing for (a), but I'm not sure if they would continue to do so when it's put in these terms. Policy currently says nothing significant about this (hence most of the text so-far discussed being informative) because, up until now, (a) was the de facto policy. If you didn't follow (a), you would get not-found errors and your package would have an RC bug because it wouldn't work. If we do nothing, we'll get (b). I think that's reasonably obvious, since there is no technical factor forcing either (a) or (c). Both paths will work without any noticable difference, so some people will use /bin and some people will use /usr/bin. That said, I would rather make an explicit choice rather than decide by default, since otherwise this seems like the kind of thing where people are going to get conflicting advice, which is frustrating for everyone. If someone wants to argue for (a) or (c), I think the biggest problem with either of them is an enforcement mechanism. How are we going to check whether packages are following the rules? Lintian and a bunch of grep patterns is sort of an unsatisfying 90% solution, and people will ignore it or just not use Lintian. There is also no technical reason why both paths will not work, so people are going to get grumpy about being told what to do and some people will view this as makework. I think any proposal to pick (a) or (c) needs to wrestle with that. I will also say that it will be very hard to convince me that Debian should give Policy advice like (a) or (c) but not actually enforce it anywhere. We have a long history to look at for how those sorts of mandates go. Conscientious packagers who read Policy carefully follow the rules and go to extra effort to do so, but other people will never see that advice or not pay attention to it. That means that the effort is mostly wasted, because no one can rely on the invariant that either (a) or (c) is attempting to achieve. I am not a big fan of asking people to do extra work without some clear benefit from doing that work, which mostly requires uniformity. One last point about this decision: although there are a few style recommendations in it, Policy is not a style guide. The point of Policy is to describe the things we should or must do, or at least that the project as a whole wants to encourage, that have a concrete effect on the quality of the distribution. I'm reluctant to add more style advice to Policy, particularly about things that are not specific to Debian. If we're going to require or recommend something, I think we need to have a concrete goal in mind for what that requirement or recommendation is going to achieve. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#793499: debian-policy: The Installed-Size algorithm is out-of-date
Guillem Jover writes: > How about the attached patch, based on the text in deb-substvars(5)? This looks great, thank you. Seconded. > From 024d94daeb0ab0e7c447868a1b8f9ff953850404 Mon Sep 17 00:00:00 2001 > From: Guillem Jover > Date: Tue, 12 Sep 2023 22:47:27 +0200 > Subject: [PATCH] Update Installed-Size algorithm used by dpkg since 1.18.0 > The previous algorithm relied entirely on du(1) computing the used > size, but depended on the filesystem in use on the build system. > The new algorithm used by dpkg since 1.18.0 (implemented in > commit 9ed7d4d47b73ffe67e1f7d31f899a1dfd43d490b), guarantees a > constant and reproducible size regardless of the build system > filesystem being used. Although it is still an approximation of > the actual size that the package will use on the installed system. > Closes: #793499 > --- > policy/ch-controlfields.rst | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 45776ea..2871658 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -939,8 +939,9 @@ space required to install the named package. Actual > installed size may > vary based on block size, file system properties, or actions taken by > package maintainer scripts. > > -The disk space is given as the integer value of the estimated installed > -size in bytes, divided by 1024 and rounded up. > +The disk space is given as the accumulated size of each regular file and > +symlink rounded to 1 KiB used units, and a baseline of 1 KiB for any other > +filesystem object type. > > .. _s-f-Files: -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051801: document DEB_BUILD_OPTIONS value nopgo
Helmut Grohne writes: > more and more packages implement a technique called profile guided > optimization. The general idea is that it performs a build that is > instrumented for profiling first. It then runs a reasonable workload to > collect profiling data, which in turn is used to guide the optimizer of > a second build which is not thus instrumented. The idea is that this > second build probably is faster than a regular build. > Quite obviously this approach completely breaks cross building. It also > is unclear how it affects reproducible builds since such builds depend > on the performance characteristics of the system performing the build. > This makes it very obvious that the pgo technique has downsides that > warrant disabling it in some situations. > A number of packages have agreed on disabling such optimization when > DEB_BUILD_OPTIONS contains nopgo. I'm aware of the following packages: > * binutils > * cross-toolchain-base > * gcc-VER > * halide > * pythonVER > I'll also be filing a patch for foot to support this option. > Is this sufficient coverage to document the option already? Yes, I think that's plenty. I would love to have Policy be a bit more proactive about documenting things like this. > Proposed wording: > This tag requests that any optimization performed during the build > should not rely on performance characteristics captured during the > build. Such optimization is usually called profile guided > optimization. Could you specifically mention cross-building (and possibly reproducible builds) as an example of why someone may want to set this option? I think having those sorts of explanations add a lot of value to Policy, since they help explain to the reader how Debian is designed beyond just a mechanical set of instructions. If you have a chance, feel free to send a proposed diff to add this to the DEB_BUILD_OPTIONS section. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Jonas Smedegaard writes: > Strictly speaking it is not (as I was more narrowly focusing on) that > the current debian/copyright spec leaves room for *ambiguity*, but > instead that there is a real risk of making mistakes when replacing with > centrally defined ones (e.g. redefining a local "Expat" from locally > meaning "MIT-ish legalese as stated in this project" to falsely mean > "the MIT-ish legalese that SPDX labels MIT"). Right, the existing copyright format defines a few standard labels and says that you should only use those labels when the license text matches, but it doesn't stress that "matches" means absolutely word-for-word identical. I suspect, although I haven't checked, that we've made at least a few mistakes where some license text that's basically equivalent to Expat is labelled as Expat even though the text is not word-for-word identical. Given that currently all labels in debian/copyright are essentially local and the full text is there (except for common-licenses, where apart from BSD the licenses normally are used verbatim), this is not currently really a bug. But we could turn it into a bug quite quickly if we relied on the license short name to look up the text. To take an example that I've been trying to get rid of for over a decade, many of the /usr/share/common-licenses/BSD references currently in the archive are incorrect. There are a few cases where the code is literally copyrighted only by the Regents of the University of California and uses exactly that license text, but this is not the case for a lot of them. It looks like a few people have even tried to say "use common-licenses but change the name in the license" rather than reproducing the license text, which I don't believe meets the terms of the license (although it's of course very unlikely that anyone would sue over it). A quick code search turns up the following examples, all of which I believe are wrong: https://sources.debian.org/src/mrpt/1:2.10.0+ds-3/doc/man-pages/pod/simul-beacons.pod/?hl=35#L35 https://sources.debian.org/src/gridengine/8.1.9+dfsg-11/debian/scripts/init_cluster/?hl=7#L7 https://sources.debian.org/src/rust-hyphenation/0.7.1-1/debian/copyright/?hl=278#L278 https://sources.debian.org/src/nim/1.6.14-1/debian/copyright/?hl=64#L64 https://sources.debian.org/src/yade/2023.02a-2/debian/copyright/?hl=78#L78 An example of one that probably is okay, although ideally we still wouldn't do this because there are other copyrights in the source: https://sources.debian.org/src/lpr/1:2008.05.17.3+nmu1/debian/copyright/?hl=15#L15 This problem potentially would happen a lot with the BSD licenses, since the copyright-format document points to SPDX and SPDX, since it only cares about labeling legally-equivalent documents, allows the license text to vary around things like the name of the person you're not supposed to say endorsed your software while still receiving the same label. We therefore cannot use solely SPDX as a way of determining whether we can substitute the text of the license automatically for people, because there are SPDX labels for a lot of licenses for which we'd need to copy and paste the exact license text because it varies. At least if I understand what our goals would be. (License texts that have portions that vary between packages they apply to are a menace and make everything much harder, and I really wish people would stop using them, but of course the world of software development is not going to listen to me.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Jonas Smedegaard writes: > If you mean to say that ambiguous MIT declarations exist in > debian/copyright files written using the machine-readable format, then > please point to an example, as I cannot imagine how that would look. I can see it: people use License: Expat but then include some license that is essentially, but not precisely, the same as Expat. If we then tell people that they can omit the text of the license and we'll fill it in automatically, they'll remove the actual text and we'll fill it in with the wrong thing. This is just a bug in handling the debian/copyright file, though. If we take this approach, we'll need to be very explicit that you can only use whatever triggers the automatic inclusion of the license text if your license text is word-for-word identical. Otherwise, you'll need to cut and paste it into the file as always. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#872587: Document the Protected field
Control: retitle -1 Document the Protected field Adam Borowski writes: > On Fri, Aug 18, 2017 at 02:28:22PM -0700, Sean Whitton wrote: >> Do you have any idea how long we can expect to wait until dpkg supports >> the field? I would suggest that we wait until dpkg has defined >> behaviour for the field, as it will make documenting it much easier. >> It will also allow us to be more confident that there is no serious >> disagreement about the purpose of the field. > Right, let's have dpkg maintainers tell us what they think. >> I couldn't find a bug against dpkg, but if there is one, it should >> probably be set to block this bug. > 872587 < 872589, I filed the Policy one first. Block added. Per the resolution of #872589, this was implemented as the Protected field instead. Retitling the bug accordingly. The documentation from deb-control(5) is: Protected: yes|no This field is usually only needed when the answer is yes. It denotes a package that is required mostly for proper booting of the system or used for custom system-local meta-packages. dpkg(1) or any other installation tool will not allow a Protected package to be removed (at least not without using one of the force options). It's probably also worth noting the parenthetical comment in the documentation of Essential: Essential: yes|no This field is usually only needed when the answer is yes. It denotes a package that is required for the packaging system, for proper operation of the system in general or during boot (although the latter should be converted to Protected field instead). dpkg(1) or any other installation tool will not allow an Essential package to be removed (at least not without using one of the force options). (And while we're there, we don't document the Build-Essential field either.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
Sam Hartman writes: >>>>>> "Luca" == Luca Boccassi writes: > Luca> Thank you, looks good to me, seconded. > LGTM too, seconded. Thanks! This has now been merged for the next Policy release. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads
Guillem Jover writes: > Seconded. Thanks! I think the wording changes subsequent to Sam's second are informative and within the changes the Policy Editor can make without seconds, so I'm proceeding with this and Sam's second and have merged this change for the next Policy release. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1041731: groff-base: "-" mapped as HYPHEN
Guillem Jover writes:
> On Mon, 2023-08-14 at 14:18:51 +0200, Samuel Thibault wrote:
>> Yes, we'd ideally want to fix all manpages to have everything set
>> alright. But we have to do that before the release. And if that's not
>> complete, release with the
>>
>> .char - \-
>>
>> workaround.
> Whenever I've maintained man pages in roff I tend to be precise in
> the usage of - and \-, but TBH this has seemed like a lost battle,
> more so since at least lintian stopped emitting tags for it. And
> another problem which I think it's going to be very hard to fix is
> with man page generators from other formats, such as pod2man, where
> it currently has heuristics to determine when to use - or \-, but it
> does not currently has a way to accurately do this always.
Yes, I understand why upstream really wants to find a way to make the
distinction between a language hyphen and an ASCII hyphen to work. They
are different characters in the *roff language, and in a proper
typesetting system such as troff is intended to be, it is important to
distinguish between them for the best output.
That said, I was surprised to see the attempt to go down this path again
given how many problems we had the last time, and I am quite dubious that
we will be successful. Not only is this a fiddly point of *roff that a
lot of people writing man pages simply don't pay attention to, man pages
are also generated from a host of other formats that simply do not have
this distinction in their language and therefore *cannot* make this
distinction in generated *roff except by guessing.
Just to give you an idea of the sort of thing that I'm trying to maintain
in order to be "correct" about this distinction, here is the current code
from podlators:
s{
( (?:\G|^|\s|$NBSP) [\(\"]* [a-zA-Z] ) ( \\- )?
( (?: [a-zA-Z\']+ \\-)+ )
( [a-zA-Z\']+ ) (?= [\)\".?!,;:]* (?:\s|$NBSP|\Z|\\\ ) )
\b
} {
my ($prefix, $hyphen, $main, $suffix) = ($1, $2, $3, $4);
$hyphen ||= '';
$main =~ s/\\-/-/g;
$prefix . $hyphen . $main . $suffix;
}egx;
This is still obviously buggy, though. For example, command names
mentioned in the text look like words with hyphens and I don't think
there's any real way to tell the difference.
I have to admit that I am somewhat tempted to at least make this
transformation optional and instead let people configure pod2man to simply
escape every single - character as \- in the output. This is not
"correct", but I think it's more correct than what is happening now, and
it's at least consistent. However, I have a note that I have to do this
translation or *roff will produce unacceptable output, and I don't
remember what problem there was that made me write that comment in the
first place. Maybe the problem with breaking long lines with
lots-of-words-that-are-all-conncted-by-hyphens, although that's somewhat
rare.
My opinion is that the world of documents that are handled by man do not
encode meaningful distinctions between - and \-, and man should therefore
unify those characters.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
be doing. It would enable future competition around better packaging helpers (and I do think debhelper will not be the last word). But I also want to be realistic about whether we're really capable of maintaining that specification. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#567033: Decide if we should continue recommending /usr/games
Antoine Beaupré writes: > On 2023-09-11 11:25:34, Russ Allbery wrote: >> Antoine Beaupré writes: >>> I get the argument against bad binaries not being in PATH but we have >>> some tooling for that, don't we? /usr/libexec, no? >> /usr/libexec isn't a replacement because it's not on any user's PATH. >> /usr/games is intended to be added to a regular user's path but not >> root's, which is a distinct use case. > That's an odd argument to make: /usr/games isn't on any user's PATH > either, is it? It's common to add it, and I'm fairly sure we have documentation that tells you to add it, whereas adding /usr/libexec to your PATH is a bug and something that you should not do. The binaries in /usr/libexec are not intended to be invoked directly, may conflict with other binaries, may do bizarre things when run from the command line, etc. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#567033: Decide if we should continue recommending /usr/games
Antoine Beaupré writes: > I get the argument against bad binaries not being in PATH but we have > some tooling for that, don't we? /usr/libexec, no? /usr/libexec isn't a replacement because it's not on any user's PATH. /usr/games is intended to be added to a regular user's path but not root's, which is a distinct use case. Thanks, Simon and Bill. I had forgotten about that point even though it has come up before (just not in this bug). I agree that's a more compelling argument for keeping /usr/games. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#567033: Decide if we should continue recommending /usr/games
Antoine Beaupré writes: > I wonder if we should just do the same. I'm not sure I see the point of > having all that stuff in a separate directory, personnally, but at least > in this case we shouldn't needlessly diverge from upstream... although > in terms of upstream for bsd-games, things are kind of hazy, at best, > from what I understand. I am inclined to agree; 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 concrete objections. Axel Beckert objected because games may conflict with other tools installed in /usr/bin. I feel like this is already a bug and merging the two namespaces to force us to deal with that bug may be a feature in disguise, because having two binaries with entirely different purposes on the user's PATH is a recipe for confusion and problems. The two bugs cited were: https://bugs.debian.org/845629 https://bugs.debian.org/752114 which are about a conflict between the game pacman and the package manager pacman. The game pacman now appears to be orphaned but does indeed still ship /usr/games/pacman, and /usr/bin/pacman is provided by pacman-package-manager. There was also one request (from Alexandre Detiste) to retain this separation that, if I understood it correctly, was based on wanting to block access to games for children with accounts on the system. This is similar the old multiuser timeshare use case for separating games back when they competed for resources with other uses of the system and administrators wanted to be able to stop people from running them until after hours. I feel like this use case is exceptionally rare at this point, and I'm not sure it's worth the packaging thought to maintain a separation just for that. Alexandre also requested keeping games data separate so that it could be moved out of the /usr partition because it could be quite large. This is another concern that I think in the subsequent eight years has become a bit less compelling due to the increase in the size of disks (which is only sort of keeping up with full commercial games, but is certainly keeping up with the games packaged in Debian). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Luca Boccassi writes: > Two more things went missing: Simon's suggestion on the versioned > dependencies on the virtual packages, Ah, yes, I'm sorry, I talked myself out of that and then completely forgot the previous discussion so didn't say anything. My concern is that it felt like we were providing a detailed description of an entirely normal dependency management situation (you always have to depend on the version of a package you use that provides the interface you're using unless it's old enough that it doesn't matter), and I wasn't sure what was special about this one that warranted spelling that out other than the need to add the version constraint to both stanzas. So I kept that part but omitted the rest. The phrasing Simon proposed I think would be appropriate if we thought most packages would need a version constraint, but I didn't think the functionality was changing that quickly. Am I wrong about that? It felt awkward to include the version constraints and then tell people to remove them if they're going to be able to remove them 95% of the time, but I don't know if that's the case. 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 stable version of Debian prior to the one you're targeting. > and the link from the tmpfiles section to the service directory section > (given it was moved). It's there (last sentence): +If the files or directories are only needed by a system service or +otherwise should only be created when that service is running, packages +should define those files and directories in the ``systemd`` unit for the +service (and, for alternative init systems, in the configuration for that +init system) instead of using the ``tmpfiles.d`` mechanism. See +:ref:`s-services-dirs` for more details. You don't need to spell out the section title; Sphinx defaults to adding that for you based on the heading that you're linking to. (I think we are excessively explicit in a bunch of places in Policy currently due to a conversion artifact from DebianDoc-XML.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
As usual, the things I notice only after I post text, even though I'd already read it several times. Russ Allbery writes: > +Volatile and temporary files (``tmpfiles.d``) > +- > + > +Some packages require empty directories, files with trivial content (such > +as short fixed strings), or symlinks in ``/var`` or ``/etc`` to implement > +their functionality. Luca carefully worded this to avoid talking about files in /etc, and then I lost that distinction. I now have: Some packages require empty directories in ``/var`` or ``/etc``, or symlinks or files with trivial content in ``/var``, to implement their functionality. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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 guessing we still have some discussion to get through, but attached is a revised diff that I think captures the content of your diff but adds some additional explanation and justification that I was kind of craving. Please let me know if I messed up any of the meaning here. Note that this adds a must (held over from Luca's "required") for init systems. I don't want to introduce that into Policy until the sysvinit maintainers have had a chance to weigh in or someone can confirm that sysvinit already handles running systemd-tmpfiles appropriately when it is installed. I should note that I dropped the admonition in the maintainer scripts section to use upstream's tmpfiles.d files because admonitions of this type (from Lintian and elsewhere) annoy me. The maintainer is in the best possible position to balance the advantages of using upstream configuration that is shared across distributions, bugs in the upstream version that aren't fixed, upstream's ability to maintain those files directly, whether upstream accepts contributions promptly, and whether there are Debian-specific integration concerns that need to be addressed. Less personally and more specific to Policy, making appropriate decisions about when to use upstream files and when to use Debian-specific files is a maintainer experience and expertise issue, not a Policy issue. Policy defines how the packages should work and is agnostic about where the pieces of it come from. If we want to give maintainers advice on how to integrate upstream packages, I think that should go into Developers Reference instead. There was some earlier discussion in this bug about the possibility of using tmpfiles.d to manage things like /run directories that, under sysvinit, are currently managed in a somewhat ad hoc and untrackable way, such as via mkdir in the init script. I still think there's something there, but I don't see a good way to describe it without creating possible problems, so I left it out. > We don't have to handle it with this change/bug and as mentioned I've > already reworded it as suggested, but to clarify my thinking there, the > place I was coming from was the factory reset and first boot angle. When > doing a first boot with only the OS vendor tree under /usr and nothing > else, you want to get to a working system, and if there are complex > files created under /var by maintainer scripts, that's kinda of a > problem. Should Debian decide to adopt the OS vendor tree concept, I certainly understand how what gnubg does would interfere with that. This seemed like the best of a set of bad options at the time. I may adopt Simon's idea of just putting the generated file in /usr, which would also allow me to drop a Debian-specific patch; I didn't do that because putting files in /usr that dpkg doesn't know about felt icky, but Simon is correct that there are a lot of other precedents. > Perhaps those complex binaries should be created by oneshot services > that run at boot with a ConditionPathExists=!/var/some/complex/binary > other than maintainer scripts? That way if /var is blown away, you still > get a working system on next boot. Yes, I could also do something like that. Of course, the point may be moot if upstream never ports GNU Backgammon to anything newer than Gtk+ 2, and the chances of that port currently aren't looking great. > But again, happy to shelve this for now, as it's a more complex topic. Agreed, we don't have to cross this bridge today. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> diff --git a/policy/ch-files.rst b/policy/ch-files.rst index b34c183..cc685fe 100644 --- a/policy/ch-files.rst +++ b/policy/ch-files.rst @@ -722,6 +722,65 @@ The name of the files and directories installed by binary packages outside the system PATH must be encoded in UTF-8 and should be restricted to ASCII when it is possible to do so. +.. _s-tmpfiles.d: + +Volatile and temporary files (``tmpfiles.d``) +- + +Some packages require empty directories, files with trivial content (such +as short fixed strings), or symlinks in ``/var`` or ``/etc`` to implement +their functionality. Examples include directories under ``/var/cache`` +that are writable by the package as cache areas, an initially-empty +directory in ``/etc`` intended for local overrides added by the local +system administrator, or a file in ``/var`` that should default to a +symlink elsewhere on the system but may be changed later. + +Rather than include these files and directories in the binary package or +create them in package maintainer scripts, pa
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 about it for version 2.1.1, but all it says is: * Hard links are forbidden in source packages (they didn't work anyway, and can't easily be made to work reliably). This is from when Ian was maintaining dpkg, so presumably he thought something was broken at the time, but it seems to have been lost in history. They do obviously work now. > Besides the other potential issues mentioned on the bug, which I agree > we might not care much about, a case that comes to mind would be that > patching hard linked source files can end up being very confusing, and > might not really break the build but can end up not producing what one > might expect. I've quickly prepared the attached tentative and > completely untested patch, to add a warning in that case, which I guess > I might be targeting for dpkg 1.22.1 (once I've added some tests). Thanks, that does seem like a good idea. > But given that hard links in source packages do not seem prevalent at > all, and that the tooling or linters can be improved in that direction I > suppose it might make sense to lift this specific restriction. Thank you for the review! Now applied for the next release of Policy. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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 the "It is a > multiline field" one or something along those lines? I knew I should have listened to my instincts and reworded that paragraph some more to make it explicit that the format of the field in the .changes file is different. (Unfortunate, but oh well, too late now.) Here is an updated patch that restructures this paragraph to try to make this clearer. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 516d0a327e247c35bd1bb95ff2a9bfc773f87c21 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue, 20 Sep 2022 21:17:55 -0700 Subject: [PATCH] Binary and Description optional in .changes In .changes files for source-only uploads, the Binary and Description fields are not present. Document this, and be clearer in the description of the Description field for .changes files that only descriptions of binary packages are included. --- policy/ch-controlfields.rst | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 4bab7df..d5c9d68 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -278,7 +278,7 @@ The fields in this file are: - :ref:`Source ` (mandatory) -- :ref:`Binary ` (mandatory) +- :ref:`Binary ` (mandatory in some cases) - :ref:`Architecture ` (mandatory) @@ -292,7 +292,7 @@ The fields in this file are: - :ref:`Changed-By ` -- :ref:`Description ` (mandatory) +- :ref:`Description ` (mandatory in some cases) - :ref:`Closes ` @@ -812,12 +812,16 @@ See :ref:`s-descriptions` for further information on this. In a ``.changes`` file, the ``Description`` field contains a summary of -the descriptions for the packages being uploaded. For this case, the -first line of the field value (the part on the same line as -``Description:``) is always empty. It is a multiline field, with one -line per package. Each line is indented by one space and contains the -name of a binary package, a space, a hyphen (``-``), a space, and the -short description line from that package. +the descriptions of the binary packages being uploaded. If no binary +packages are being uploaded, this field will not be present. + +When used inside a ``.changes`` file, the ``Description`` field has a +different format than in source or binary control files. It is a multiline +field with one line per binary package. The first line of the field value +(the part on the same line as ``Description:``) is always empty. Each +subsequent line is indented by one space and contains the name of a binary +package, a space, a hyphen (``-``), a space, and the short description +line from that package. .. _s-f-Distribution: @@ -927,7 +931,8 @@ every architecture. The source control file doesn't contain details of which architectures are appropriate for which of the binary packages. When it appears in a ``.changes`` file, it lists the names of the binary -packages being uploaded, separated by whitespace (not commas). +packages being uploaded, separated by whitespace (not commas). If no +binary packages are being uploaded, this field will not be present. .. _s-f-Installed-Size: -- 2.40.1
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 supposed to cover. > So if I understand your question correctly and you are not looking for > the output of `licensecheck --list-licenses`, then unfortunately I have > nothing exciting to offer. I think that's mostly correct. I was wondering what would happen if one ran licensecheck debian/copyright, but unfortunately it doesn't look like it does anything useful. I tried it on one of my packages (remctl) that has a bunch of different licenses, and it just said: debian/copyright: MIT License and apparently ignored all of the other licenses present (FSFAP, FSFFULLR, ISC, X11, GPL-2.0-or-later with Autoconf-exception-generic, and GPL-3.0-or-later with Autoconf-exception-generic). It also doesn't notice that some of the MIT licenses are variations that contain people's names. (I still put all the Autoconf build machinery licenses in my debian/copyright file because of the tooling I use to manage my copyright file, which I also use upstream. I probably should change that, but I need to either switch to licensecheck or rewrite my horrible script.) Also, presumably it doesn't know about copyright-format since it wouldn't be expecting that in source files, so it wouldn't know to include licenses referenced in License stanzas without the license text included. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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 reduced to a reference that get > expanded by a machine it would make debian/copyright look much nicer and > would make it easier to maintain while at the same time shipping the > full license text in the binary package. > Does anybody know why such an approach would be a bad idea? I can think of a few possible problems: * I'm not sure if we generate binary package copyright files at build time right now, and if all of our tooling deals with this. I had thought that we prohibited this, but it looks like it's only a Policy should and there isn't a mention of it in the reject FAQ, so I think I was remembering the rule for debian/control instead. Of course, even if tools don't support this now, they could always be changed. * If ftp-master has to review the copyright files of each binary package separate from the copyright file of the source package (I think this would be an implication of generating the copyright files during build time), and the binary copyright files have fully-expanded licenses, that sounds like kind of a pain for the ftp-master reviewers. Maybe we can deal with this with better tooling, but someone would need to write that. * If we took this to its logical end point and did this with the GPL as well, we would add 20,000 copies of the GPL to the archive and install a *lot* of copies on the system. Admittedly text files are small and disks are large, but this still seems a little excessive. So maybe we still need to do something with common-licenses? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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 copyright files > too, or is it really simply a hard-coded list of matching patterns? It's only a hard-coded list of matching patterns, and it doesn't match any of the short licenses because historically I wasn't considering them (with the exception of common-licenses references to the BSD license, which I kind of would like to make an RC bug and clean up so that we could remove the BSD license from common-licenses on the grounds that it's specific to only the University of California and confuses people). If we go with any sort of threshold, the script will need serious improvements. That was something else I wanted to ask: I've invested all of a couple of hours in this script, and would be happy to throw it away in favor of something that tries to do a more proper job of classifying the licenses referenced in debian/copyright. Has someone already done this (Jonas, perhaps)? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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 something like the following might be a more clear > option (and has the minor bonus of aligning perfectly on the first > words! :), with it mentioning explicitly this is about changes being > uploaded, and that it is a control file (but I'm not sure I'm entirely > convinced about it): > * .changes: «Debian upload changes control files» [...] > I've also found instances of «record» and «section» referring to fields > or stanzas. [...] > I also recalled another term that has always seemed very confusing in > context: «control information files» or «control information area». For > example in a sentence such as “the control file is a control information > file in the control information area in a .deb archive”. :) This also > seems confusing when some of the files in the .deb control member are > not really “control files” with a deb822(5) format. > My thinking has been going into calling these as the «metadata files», > and being located in either the «metadata part of the .deb archive» or > explicitly the «control member of the .deb archive», in contrast to the > filesystem part. In dpkg I'd be eventually switching to meta/metadata > and fsys/filesystem, from control or info and data. I've added a patch > with the proposed change, but again nothing set in stone, and I'm again > open to discussing pros/cons of this. > Attached the proposals for discussion/review, and I might again have > perhaps missed instances or similar. All of these changes seem straightforward and uncontroversial to me, and there are huge advantages to using consistent terminology between Policy and dpkg. I have applied all of them for the next Policy release. Thank you! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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 the sake of the record on this now-closed bug, I got a reply from Javier Serrano Polo asking if I had received a message related to this bug last year. I don't remember receiving one, and it's not present in the BTS. I attempted to reply to that message saying so, but the jasp.net mail server rejected my mail message with the following bounce message: : host www.jasp.net[84.126.37.22] said: 550-The message does not meet the trust level of one recipient at least 550-See http://www.jasp.net/smtp/trust.xhtml 550 Administrative prohibition (in reply to end of DATA command) I don't think this changes anything about the original analysis, so I'm leaving this bug closed, but I wanted to clarify my last message; apparently there is some communication blockage here. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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 then it's too
> much of a corner-case to be documenting unless/until it actually
> happens.
I also second these changes. In the name of expediency, and since I
believe all the proposed wording changes were informative, I applied these
patches for the next release and made the wording changes suggested by
Holger and Sean. Attached are the changes as committed.
Subsequent to this work, we added the non-free-firmware archive area.
Simon's patch therefore doesn't add a statement to that section about
whether source packages in non-free-firmware are allowed to produce
binaries in non-free, or if source packages in non-free are allowed to
produce binaries in non-free-firmware, and I don't know what the answer to
that is.
Would the following wording be correct?
If a source package is in the *non-free-firmware* archive area, then
each of the binary packages that it produces must also be in the
*non-free-firmware* archive area.
Please let me know, and I will propose some follow-up wording for that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
diff --git a/debian/changelog b/debian/changelog
index 66d6fa0..a5e3e3e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -11,6 +11,11 @@ debian-policy (4.6.3.0) UNRELEASED; urgency=medium
Seconded: Russ Allbery
Seconded: Holger Levsen
Closes: #1035733
+ * Policy: Source packages in main may build binary packages in contrib
+Wording: Simon McVittie
+Seconded: Holger Levsen
+ Seconded: Russ Allbery
+Closes: #994008
-- Sean Whitton Wed, 14 Jun 2023 16:58:40 +0100
diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index c7cd340..eb8978a 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -136,6 +136,27 @@ In addition, the packages in *main*
- must meet all policy requirements presented in this manual.
+If a source package is in the *main* archive area, then at least one of
+its binary packages must be in the *main* archive area, and each of the
+remaining packages must be in either the *main* or *contrib* archive
+area. Each binary package's archive area is indicated by its ``Section``
+field: see :ref:`s-subsections`.
+
+Source packages in *main* with a mixture of *main* and *contrib* binary
+packages are more complex for archive tooling to handle, and therefore
+should be limited to situations where it would be inconvenient to split
+the source package. If it is straightforward to split the source package
+into a *main* part and a *contrib* part that are built separately, then
+those parts should be represented as separate source packages.
+
+When a *main* source package has a mixture of *main* and *contrib* binary
+packages, the source package and the *main* binary packages must follow
+the requirements for *main* packages, but the *contrib* binary packages
+may follow the weaker requirements for *contrib* packages. In particular,
+source packages in *main* must not have build dependencies outside *main*,
+but the *contrib* binary packages may have runtime dependencies outside
+*main*.
+
.. [2]
See `What Does Free Mean? <https://www.debian.org/intro/free>`_ for
more about what we mean by free software.
@@ -192,6 +213,10 @@ Examples of packages which would be included in *contrib* are:
- wrapper packages or other sorts of free accessories for non-free
programs.
+If a source package is in the *contrib* archive area, then each of the
+binary packages that it produces must also be in the *contrib* archive
+area.
+
.. _s-non-free:
The non-free archive area
@@ -214,6 +239,10 @@ In addition, the packages in *non-free*
- must meet all policy requirements presented in this manual that it is
possible for them to meet. [4]_
+If a source package is in the *non-free* archive area, then each of the
+binary packages that it produces must also be in the *non-free* archive
+area.
+
.. [4]
It is possible that there are policy requirements which the package
is unable to meet, for example, if the source is unavailable. These
diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
index 54a473b..6009819 100644
--- a/policy/upgrading-checklist.rst
+++ b/policy/upgrading-checklist.rst
@@ -44,6 +44,13 @@ Version 4.7.0
Unreleased.
+2.2.1
+Document that source packages in the *main* archive area may build
+binary packages in the *contrib* archive area, although this is
+discouraged unless the source package is inconvenient to split. This
+does not relax the requirement that source packages in *main* must not
+have build dependencies outside of *main*.
+
2.2.
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 patch, sorry. Here is the one that was actually updated to include experimental. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 7ee49f6c892d6057b9a0d2f9eb84ff0f35d1d436 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue, 20 Sep 2022 19:11:54 -0700 Subject: [PATCH] Improve alternative build dependency discussion Alternatives in build dependencies are normally (except for backports) handled specially by autobuilders to try to maintain consistent builds. This was documented in Policy, but in a footnote that people often didn't see. Move this text into the main body of the discussion of build dependencies and reword it for additional clarity. Add a pointer to this discussion where alternative dependencies are introduced. --- policy/ch-relationships.rst | 61 +++-- 1 file changed, 45 insertions(+), 16 deletions(-) diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst index 5074428..ffafbf1 100644 --- a/policy/ch-relationships.rst +++ b/policy/ch-relationships.rst @@ -15,7 +15,10 @@ control fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols ``|``. In such a case, that part of the dependency can be satisfied by any one of the -alternative packages. [#]_ +alternative packages. (Alternative dependencies in ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` are interpreted +specially by Debian autobuilders. See :ref:`Relationships between source +and binary packages ` for more details.) All of the fields may restrict their applicability to particular versions of each named package. This is done in parentheses after each individual @@ -620,6 +623,47 @@ earlier for binary packages) in order to invoke the targets in ``Build-Conflicts-Arch`` fields must be satisfied when these targets are invoked. +Alternative dependencies are allowed in the ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields, but Debian's +autobuilders normally discard the dependencies after the first. This is +done to give alternative dependencies a consistent interpretation that +reduces the risk of inconsistencies between repeated builds. If, for +example, the first-listed dependency would normally be available but is +temporarily not installable, the autobuilder fails rather than install a +subsequent dependency that may significantly change the behavior of the +package. + +More specifically, Debian autobuilders perform the following +transformation on alternative dependencies in the ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields: + +#. Discard any alternatives that are restricted to architectures that do + not match the host architecture. +#. Discard any alternatives specifying different package names than the + now-first alternative. (Alternatives specifying the same package name + are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.) + +For example, an autobuilder for the ``amd64`` architecture would treat the +following dependency:: + +foo-special [armhf] | foo (<= 4) | foo (>= 4.2) | bar + +as if it were:: + +foo (<= 4) | foo (>= 4.2) + +The normal effect is to use only the first alternative that is valid on +the relevant architecture and fail if that alternative is not installable. + +While this rule for build dependencies may limit the usefulness of +alternatives, they can still be used to provide flexibility when building +the package outside of Debian's autobuilders. + +The autobuilders for the Debian backports and experimental suites do not +perform this transformation and instead use the same dependency resolution +rules as normal package installations to choose which alternative +dependency to install. + .. _s-built-using: Additional source packages used to build the binary - ``Built-Using`` @@ -666,21 +710,6 @@ requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies. -.. [#] - While ``Build-Depends``, ``Build-Depends-Indep`` and - ``Build-Depends-Arch`` permit the use of alternative dependencies, - those are only used for the backports suite on the Debian autobuilders. - On the other suites, after reducing any architecture-specific restrictions - for the build architecture in question, all but the first alternative are - discarded except if the alternative is the same package name as the fi
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. > From 12b014c4b930577a728dfb1254b64aac6a5eb1e0 Mon Sep 17 00:00:00 2001 > From: Russ Allbery > Date: Thu, 22 Sep 2022 19:15:52 -0700 > Subject: [PATCH] Allow hard links in source packages > It's not clear why this restriction was in place, and Debian > included a package containing hard links without anyone noticing > in the last release. > --- > policy/ch-source.rst | 11 ++- > 1 file changed, 2 insertions(+), 9 deletions(-) > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index c7415fc..a7df539 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -282,8 +282,8 @@ source files in a package, as far as is reasonably > possible. [#]_ > Restrictions on objects in source packages > -- > > -The source package must not contain any hard links, [#]_ device special > -files, sockets or setuid or setgid files.. [#]_ > +The source package must not contain device special files, sockets, or > +setuid or setgid files. [#]_ > > .. _s-debianrules: > > @@ -918,13 +918,6 @@ must not exist a file ``debian/patches/foo.series`` for > any ``foo``. > would be nice if the modification time of the upstream source would > be preserved. > > -.. [#] > - This is not currently detected when building source packages, but > - only when extracting them. > - > - Hard links may be permitted at some point in the future, but would > - require a fair amount of work. > - > .. [#] > Setgid directories are allowed. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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) <https://www.eyrie.org/~eagle/> >From 6a4e1b261f5f5765fa164e4bfd063f67d40a9a47 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue, 20 Sep 2022 19:11:54 -0700 Subject: [PATCH] Improve alternative build dependency discussion Alternatives in build dependencies are normally (except for backports) handled specially by autobuilders to try to maintain consistent builds. This was documented in Policy, but in a footnote that people often didn't see. Move this text into the main body of the discussion of build dependencies and reword it for additional clarity. Add a pointer to this discussion where alternative dependencies are introduced. --- policy/ch-relationships.rst | 61 +++-- 1 file changed, 45 insertions(+), 16 deletions(-) diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst index 5074428..e8978af 100644 --- a/policy/ch-relationships.rst +++ b/policy/ch-relationships.rst @@ -15,7 +15,10 @@ control fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols ``|``. In such a case, that part of the dependency can be satisfied by any one of the -alternative packages. [#]_ +alternative packages. (Alternative dependencies in ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` are interpreted +specially by Debian autobuilders. See :ref:`Relationships between source +and binary packages ` for more details.) All of the fields may restrict their applicability to particular versions of each named package. This is done in parentheses after each individual @@ -620,6 +623,47 @@ earlier for binary packages) in order to invoke the targets in ``Build-Conflicts-Arch`` fields must be satisfied when these targets are invoked. +Alternative dependencies are allowed in the ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields, but Debian's +autobuilders normally discard the dependencies after the first. This is +done to give alternative dependencies a consistent interpretation that +reduces the risk of inconsistencies between repeated builds. If, for +example, the first-listed dependency would normally be available but is +temporarily not installable, the autobuilder fails rather than install a +subsequent dependency that may significantly change the behavior of the +package. + +More specifically, Debian autobuilders perform the following +transformation on alternative dependencies in the ``Build-Depends``, +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields: + +#. Discard any alternatives that are restricted to architectures that do + not match the host architecture. +#. Discard any alternatives specifying different package names than the + now-first alternative. (Alternatives specifying the same package name + are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.) + +For example, an autobuilder for the ``amd64`` architecture would treat the +following dependency:: + +foo-special [armhf] | foo (<= 4) | foo (>= 4.2) | bar + +as if it were:: + +foo (<= 4) | foo (>= 4.2) + +The normal effect is to use only the first alternative that is valid on +the relevant architecture and fail if that alternative is not installable. + +While this rule for build dependencies may limit the usefulness of +alternatives, they can still be used to provide flexibility when building +the package outside of Debian's autobuilders. + +The autobuilders for the Debian backports suite do not perform this +transformation and instead use the same dependency resolution rules as +normal package installations to choose which alternative dependency to +install. + .. _s-built-using: Additional source packages used to build the binary - ``Built-Using`` @@ -666,21 +710,6 @@ requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies. -.. [#] - While ``Build-Depends``, ``Build-Depends-Indep`` and - ``Build-Depends-Arch`` permit the use of alternative dependencies, - those are only used for the backports suite on the Debian autobuilders. - On the other suites, after reducing any architecture-specific restrictions - for the build architecture in question, all but the first alternative are - discarded except if the alternative is the same package name as the first. - The latter exception is useful to specify version ranges like - ``foo (rel x) | foo (rel y)``. This is to reduce the risk of inconsistencies - betwee
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) <https://www.eyrie.org/~eagle/> >From 66175d3775f238a5ce3a2254388ad974e81d462f Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Tue, 20 Sep 2022 21:17:55 -0700 Subject: [PATCH] Binary and Description optional in .changes In .changes files for source-only uploads, the Binary and Description fields are not present. Document this, and be clearer in the description of the Description field for .changes files that only descriptions of binary packages are included. --- policy/ch-controlfields.rst | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) 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 @@ -278,7 +278,7 @@ The fields in this file are: - :ref:`Source ` (mandatory) -- :ref:`Binary ` (mandatory) +- :ref:`Binary ` (mandatory in some cases) - :ref:`Architecture ` (mandatory) @@ -292,7 +292,7 @@ The fields in this file are: - :ref:`Changed-By ` -- :ref:`Description ` (mandatory) +- :ref:`Description ` (mandatory in some cases) - :ref:`Closes ` @@ -812,10 +812,11 @@ See :ref:`s-descriptions` for further information on this. In a ``.changes`` file, the ``Description`` field contains a summary of -the descriptions for the packages being uploaded. For this case, the -first line of the field value (the part on the same line as -``Description:``) is always empty. It is a multiline field, with one -line per package. Each line is indented by one space and contains the +the descriptions of the binary packages being uploaded. If no binary +packages are being uploaded, this field will not be present. For this +case, the first line of the field value (the part on the same line as +``Description:``) is always empty. It is a multiline field, with one line +per binary package. Each line is indented by one space and contains the name of a binary package, a space, a hyphen (``-``), a space, and the short description line from that package. @@ -927,7 +928,8 @@ every architecture. The source control file doesn't contain details of which architectures are appropriate for which of the binary packages. When it appears in a ``.changes`` file, it lists the names of the binary -packages being uploaded, separated by whitespace (not commas). +packages being uploaded, separated by whitespace (not commas). If no +binary packages are being uploaded, this field will not be present. .. _s-f-Installed-Size: -- 2.40.1
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 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 at least 100 source packages in Debian. > * The license text is longer than 25 lines. In the thread so far, there's been a bit of early convergence around my threshold of 100 packages above. I want to make sure people realize that this is a very conservative threshold that would mean saying no to most new license inclusion requests. My guess is that with the threshold set at 100, we will probably add around eight new licenses with the 25 line threshold (AGPL-2, Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and OFL-1.1, and I'm not sure about some of those because the CC licenses have variants that would each have to reach the threshold independently; my current ad hoc script does not distinguish between the variants), and maybe 10 to 12 total without that threshold (adding Expat, zlib, some of the BSD licenses). This would essentially be continuing current practice except with more transparent and consistent criteria. It would mean not including a lot of long legal license texts that people have complained about having to duplicate, such as the CDDL, CeCILL licenses, probably the EPL, the Unicode license, etc. If that's what people want, that's what we'll do; as I said, that's what I would do if the choice were left entirely up to me. But I want to make sure I give the folks who want a much more relaxed standard a chance to speak up. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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? common-licenses is in an essential package so it doesn't require a dependency and is always present, and we've leaned on that in the past in justifying not including those licenses in the binary packages themselves, but I'm not sure why a package dependency wouldn't be legally equivalent. We allow symlinking the /usr/share/doc directory in some cases where there is a dependency, so we don't strictly require every binary package have a copyright file. >> I expect license-common-list data as below >> >> license-short-name: URL >> GPL-2: file:///usr/share/common-licenses/GPL-2 >> Boost-1.0: https://spdx.org/licenses/BSL-1.0.html > Ah, so what you propose is to use file URIs. > I guess Russ' response above was a concern over using http(s) URIs > towards a non-local resource. Yes, I think the https URL is an essential part of the first proposal, since it avoids needing to ship a copy of all of the licenses. But I'm dubious that would pass legal muster. The alternative proposal as I understand it would be to haave a license-common package that includes full copies of all the licenses with some more relaxed threshold requirement and have packages that use one of those licenses depend on that package. (This would obviously require a maintainer be found for the license-common package.) > License: Apache-2.0 > Reference: /usr/share/common-licenses/Apache-2.0 This is separate from this particular bug, but I would love to see the pointer to common-licenses turned into a formal field of this type in the copyright format, rather than being an ad hoc comment. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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 > * richer arch aliases (better than current dpkg aliases; could be >implemented like shell foo-$@-bar word multiplication, thus linux-64bit >would expand to linux-amd64 linux-arm64 linux-s390x ...); idea was kind >of shot before though > * replacing explicit arch names in source packages by facets (like: >x86, little-endian, sse2, time64, ...) that are expanded at build time; >procrastiplanning to propose this > It's good to discuss such things -- if someone offers to implement such a > change. Yes, I agree. >> going to have to close this bug against Policy as unactionable since I >> don't know of any efforts towards implementing this support, and Policy >> would only be able to change once the support is available. > Could we oh so please have this as a policy policy in other cases, too? Yes, historically I've been reluctant to close Policy bugs that indicate real problems even if no apparent forward progress is being made on that bug, but I'm starting to think this is too conservative and keeping really old stalled bugs open is often not useful. However, there are a lot of bugs and I don't touch them very frequently, since I'm trying to focus on closing bugs that do have forward progress. If you or anyone else has a list of bugs that you think fall into that category (no known efforts towards an implementation, Policy can't change until that implementation happens), please do send a list. (Feel free to send that privately if you think it might be controversial.) I'm happy to take a look. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Hideki Yamane writes: > 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 > name of licenses for DEP-5 and SPDX for it). Can we do this legally? If we can, it certainly has substantial merits, but I'm not sure that this satisfies the requirement in a lot of licenses to distribute a copy of the license along with the work. Some licenses may allow that to be provided as a URL, but I don't think they all do (which makes sense since people may receive Debian on physical media and not have Internet access). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#885698: What licenses should be included in /usr/share/common-licenses?
by it. * The license applies to at least 100 source packages in Debian. * The license text is longer than 25 lines. I will attempt to guide and summarize discussion on this topic. No decision will be made immediately; I will summarize what I've heard first and be transparent about what direction I think the discussion is converging towards (if any). 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. AGPL 3 277 Apache 2.0 5274 Artistic 4187 Artistic 2.0337 BSD (common-licenses)42 CC-BY 1.0 3 CC-BY 2.015 CC-BY 2.513 CC-BY 3.0 240 CC-BY 4.0 159 CC-BY-SA 1.0 8 CC-BY-SA 2.0 48 CC-BY-SA 2.5 16 CC-BY-SA 3.0425 CC-BY-SA 4.0237 CC0-1.01069 CDDL 67 CeCILL 30 CeCILL-B 13 CeCILL-C 9 GFDL (any) 569 GFDL (symlink) 55 GFDL 1.2289 GFDL 1.3231 GPL (any) 20006 GPL (symlink) 1331 GPL 1 4033 GPL 2 10466 GPL 3 6783 LGPL (any) 5019 LGPL (symlink) 265 LGPL 2 3850 LGPL 2.1 2926 LGPL 3 1526 LaTeX PPL46 LaTeX PPL (any) 40 LaTeX PPL 1.3c 32 MPL 1.1 165 MPL 2.0 361 SIL OFL 1.0 11 SIL OFL 1.1 258 -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
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 straightforward to do. Before I invest the time in that, I want to check the opinions of everyone else following along and see if the semantics of Luca's change have general approval. Could folks take a look at this patch and see if the basic gist of it is something that they would second (or, for that matter, is something they would object to)? I think I would second it (with wording adjustments), with one caveat mentioned below. The whole thing is at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269#295 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 do not use services cannot use this functionality, and there's already a statement in the tmpfiles.d section pointing to them as more appropriate for services. > +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/``, should not be > +created manually via maintainer scripts, but instead be declaratively > +defined via the `tmpfiles.d > +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`_ > +interface. Files and directories under ephemeral filesystems such as > +``/tmp/`` may also be created and managed via ``tmpfiles.d`` snippets. I understand the empty directory part, but I don't believe "files that are located under /var" is correct unless you specifically mean *empty* files (and even then, I'm not clear on precisely when this would be needed). For example, /var/lib/gnubg/gnubg_ts0.bd is created by the gnubg package maintainer script, and I can see no possible way that action could (or should) be handled by the tmpfiles.d mechanism. What am I missing? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
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 ``sysv-rc`` runlevel system > -for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which > -scripts to run and in which order at boot time and when the init state (or > -"runlevel") is changed. See the ``README.runlevels`` file shipped with > -``sysv-rc`` for implementation details. Other alternatives might exist. > +``systemd`` uses dependency and ordering information contained within the > ++enabled unit files to decide which services to run and in which order. > +The ``sysv-rc`` runlevel system for ``sysvinit`` uses the same symlinks in > +``/etc/rcn.d`` to decide which scripts to run and in which order at boot > +time and when the init state (or "runlevel") is changed. See the > +``README.runlevels`` file shipped with ``sysv-rc`` for implementation > +details. Other alternatives might exist. And of course I have to post the diff to see the bugs. The part that says "uses the same symlinks" should now say "uses symlinks". -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
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 system services and realized that it is largely obsolete and is not followed by most Debian packages that provide system services. Specifically: * There is no real documentation of systemd units except in the introduction, and most of the section describes init scripts as if they were the only way to start a service. * All packages are told they must use update-rc.d, but systemd units no longer use update-rc.d. They instead use deb-systemd-helper in ways that are not documented in Policy and I believe are maintained primarily in debhelper. * All packages are told they should use invoke-rc.d, but systemd units no longer use invoke-rc.d. They instead use deb-systemd-invoke, which also supports the policy-rc.d interface. * The policy-rc.d interface is undocumented. This part of Policy is also a bit of a mess of deleted sections due to a desire to avoid section renumbering. I started a rewrite of this section, but quickly ran into the question of how to document the correct invocations of deb-systemd-helper and deb-systemd-invoke. After thinking about this for a while, the conclusion I reached was that documenting this in Policy is both extra make-work that we do not have the resources to keep up with, and serves no real purpose for nearly every reader of Debian. debhelper is already maintaining the correct code to set up systemd services in close cooperation with the systemd and init-system-helpers maintainers, that code contains temporary workarounds and other fixes that Policy is not going to keep up with, and it's hard to justify duplicating that work in a Policy statement. I therefore would like to propose a first: I think Policy should simply say that any package that provides a system service should use debhelper and rely on dh_installsystemd to put the appropriate commands in its maintainer scripts. (We can then discuss whether we should do the same for init scripts and dh_installinit, although its stanzas are simpler.) Previously we have tried to avoid doing this, and have maintained the principle that debhelper is simply an *implementation* of Policy, and it still falls to Policy to describe what debhelper should do. However, I think it is now abundantly obvious that debhelper has considerably more development resources available to it than Policy has writers, debhelper developers are quite rightfully not waiting for things to be added to Policy before they can be implemented, and essentially every Debian package that does anything non-trivial uses debhelper now. I also don't see any truly useful purpose served by dumping a wad of shell code into Policy that essentially no one will use because it's what debhelper would add for them. I have some other questions about the rewrite of these sections (such as how hard we should try to retain section numbering), but I think we should resolve this question first, since it has dramatic effects on what text we should write. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 5.3.0-7 Versions of packages debian-policy suggests: pn doc-base -- no debconf information
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
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 > a decade, and it's time for the tail of packages still shipping only > init scripts but not units to be updated. > 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 adapt it to be a standalone binary there's > nothing stopping them. But I wouldn't want the systemd package to depend > on such a backward compat tool, so packages needing this hyptothetical > package should depend explicitly on it. This is just mentioned for > completeness, it's been at least a decade and writing a unit file is > beyond trivial so there shouldn't be any issue adding the few remaining > ones. The mass bug filing happened, and although there were some objections on debian-devel, I don't think any of them were blocking. Specifically, I did not see anyone present a concrete plan for how to keep the systemd unit generator or some equivalent alive, and given that systemd upstream is dropping support for this feature, I believe that's the only way for this change to not be effective mandatory. Therefore, I think the time is ripe to proceed with this Policy change. I took a detailed look at this part of Policy today, and the whole system service section needs serious work. I believe the instructions it currently provides for constructing package maintainer scripts won't actually work with a current Debian system, and most Debian packages are technically violating the current Policy because it hasn't been updated for how systemd units work today. I started on overhauling that section, but it became clear that this is going to be a larger project with some potentially controversial decisions, so I'm going to open a new bug about that so that we don't block this change on that work. I made the following changes to your last diff: * Move the "should" about integrating with service management to the parent section. * Explicitly say that systemd is the default init system and service manager (it feels like we should say this somewhere, and I don't think we already do). * Add an explicit exception for packages intended only to support alternate init systems. (As an obvious example, sysvinit isn't going to ship a systemd unit, nor should it.) * Delete the paragraph suggesting that packages without systemd units should write an init script, since this will no longer accomplish the goal of getting that system service to work with systemd and therefore no longer seems to serve a purpose. Here is what I came up with. I think it is ready for seconds or objections. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 474a9f4c74bc2c3a1d162de33e377a3585e641af Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Sat, 9 Sep 2023 18:39:16 -0700 Subject: [PATCH] systemd unit files are now a must systemd is dropping support for the generator that allows it to automatically create units for init scripts. As a result, all packages that want to integrate with systemd service management must start shipping systemd units. State that arranging for services to be automatically started or stopped is a should, but if the package wishes to do that, a systemd service unit is a must unless the package is only intended for use with alternate init systems. Avoid saying that systemd uses /etc/rcn.d links to determine service ordering. --- policy/ch-opersys.rst | 35 --- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 207b3c0..bee16f2 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -323,20 +323,25 @@ which try to write to a home directory will fail to build. Starting system services +Debian packages that provide system services should arrange for those +services to be automatically started and stopped by the init system or +service manager. This section describes how that is done. + .. _s-services-intro: Introduction -Packages that include system services should include ``systemd`` service -units to start or stop those services. See :manpage:`systemd.service(5)` -for details on the syntax of a service unit file. In the common case that -a package includes a single system service, the service unit should have -the same name as the package plus the ``.service`` extension. +The default init system and service manager in Debian is ``systemd``. +Packages that wish to automatically start and stop system services must +include ``systemd`` service units to do so, unless the service is only +intended for use on systems runn
Bug#1050322: Partial versus complete replacement of a package by another
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 try to see if I'm getting at something: > (*) Replaces doesn't really mean "can be used in place of" > -- that would be expressed with Breaks+Provides. > (*) Replaces shouldn't come without Breaks, but doesn't imply it > so we have to put in both (why?). Yes, this is a good question. I recently was confused about this myself despite having worked on Debian and maintained Policy and, at times, Lintian for years, which implies that we don't do a very good job of documenting the ins and outs of this. https://lists.debian.org/debian-devel/2023/06/msg00354.html is the best explanation of this that I've seen. The short summary is that the one case where Breaks is not required is if the package with Replaces also depends on a new version of the package that it is replacing. This prevents the scenario described in the footnote. The other thing that's worth noting is that sometimes you want Breaks and sometimes you want Conflicts, and both Breaks and Conflicts are useful without Replaces for other reasons, so none of them can really imply any of the others. I also saw your other bug (#1050221) about promoting that footnote to the main text. That's a partial fix, but I think we should include some portion of Helmut's explanation directly in Policy as well. (We sort of say this, but we're not nearly as explicit about it as we could be, and we don't use normative language.) > (*) In 7.6.1's example, what happens if the system has foo 1.2-2 and > the user tries to install foo-data 1.2-3? Do we end up with foo 1.2-2 > and foo-data 1.2-3 unpacked and apt/dpkg complaining it can't configure > them or does it refuse with a clear error message? It refuses to begin the operation because foo-data 1.2-3 breaks foo 1.2-2 and foo 1.2-2 is currently configured. foo 1.2-2 has to be unconfigured first before the installation of foo-data 1.2-3 can procede. (This is documented in Policy 7.3 where Breaks is discussed.) What normally happens is that users use apt rather than dpkg directly. I believe apt will force an upgrade of foo because it sees that it is broken by foo-data and will not allow installation of foo-data without either upgrading or removing foo. (dpkg does not do this because dpkg in general operates on only the packages it's told to operate on and doesn't expand the scope of one invocation to change other packages.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1031403: debian-policy: missing quotes in sh script example in file policy/ap-pkg-diversions
Control: tags -1 pending Max-Julian Pogner writes: > consulting the debian policy manual whether it contains suggestions how > to best implement diversions (see `man dpkg-divert`), i noticed syntax > errors in the provided shell script example snippets. > a patch fixing these typos is attached. Thanks, applied for the next Policy release. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1024367: In 4.9.1, the example uses not recommended install -s
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: >INSTALL_PROGRAM = $(INSTALL) -p-o root -g root -m 755 >ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS))) >INSTALL_PROGRAM += -s >endif > However, paragraph 10.1 recommends against it: >It is not recommended to strip binaries by passing the "-s" flag to >"install", because this fails to remove .comment and .note sections, >and also prevents the automatic creation of dbgsym binary packages by >tools like "dh_strip". > I would personally prefer if the example built on debhelper. If the > intention is to show what are the expectations at a lower level then > I wish the example had a comment saying "This snippet serves to explain > what are the expectations as a lower level. You usually want to use > debhelper instead" I looked at this snippet and I think it has worse problems than the use of install -s. For example, it predates the existence of dpkg-buildflags, which would also handle noopt. I'm also dubious that it serves any useful purpose given that nearly every package should just use debhelper. The typical current Debian packager seems more likely to be confused by this fragment than aided by it. I'm therefore going to propose fixing this bug with the following patch, which is more aggressive than you propose. I think this is informative rather than normative and therefore technically doesn't require seconds, but I'll give this some time for other people to take a look and talk me out of deleting this section if they wish. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> >From 409bbd815a946a7bb7b1eea8cab8198c494dd7d4 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Sat, 9 Sep 2023 15:10:21 -0700 Subject: [PATCH] Remove old Makefile DEB_BUILD_OPTIONS example The correct way to implement most DEB_BUILD_OPTIONS these days is to just use debhelper. The detailed Makefile fragment was probably more confusing than helpful, given that it predates dpkg-buildflags, uses install -s (which Policy elsewhere recommends against), and manually does other work debhelper would automate. Replace it with a note that packaging helper frameworks do much of this work. --- policy/ch-source.rst | 35 +++ 1 file changed, 3 insertions(+), 32 deletions(-) diff --git a/policy/ch-source.rst b/policy/ch-source.rst index 4307e89..b6f2c86 100644 --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -588,38 +588,9 @@ The meaning of the following tags has been standardized: Unknown flags must be ignored by ``debian/rules``. -The following makefile snippet is an example of how one may implement -the build options; you will probably have to massage this example in -order to make it work for your package. - -.. code-block:: Makefile - -CFLAGS = -Wall -g -INSTALL = install -INSTALL_FILE= $(INSTALL) -p-o root -g root -m 644 -INSTALL_PROGRAM = $(INSTALL) -p-o root -g root -m 755 -INSTALL_SCRIPT = $(INSTALL) -p-o root -g root -m 755 -INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755 - -ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS))) -CFLAGS += -O0 -else -CFLAGS += -O2 -endif -ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS))) -INSTALL_PROGRAM += -s -endif -ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) -NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) -MAKEFLAGS += -j$(NUMJOBS) -endif - -build: -# ... -ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) -# Code to run the package test suite. -endif - +Packaging helper frameworks such as debhelper will automatically support +many of these options without any further work required by the package +maintainer. .. _s-debianrules-gainrootapi: -- 2.40.1
Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field
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 > Architecture field, so that we can e.g. write: > Architecture: !s390 !s390x > (for xorg stuff) > Architecture: !hppa !hurd-any !kfreebsd-any > (for java stuff) > and even things like > Architecture: linux-any kfreebsd-any !hppa !m68k-any > which would be understood as [ (linux-any or kfreebsd-any) and not hppa > and not m68k-any ]. I.e. if no positive specification is set, an "any" > positive specification is assumed. > That would help to remove quite a few entries of > https://buildd.debian.org/quinn-diff/experimental/Packages-arch-specific > and avoid packages with some java bits to have to hardcode the list of > ports on which java jni bindings packages should be built. > I guess support would be needed in dpkg, lintian, etc. Hi Samuel, I agree that this would be useful. This has come up frequently over the years, and back when I was maintaining architecture-specific packages, the lack of this feature was often annoying. But (as may be obvious from the long delay in even getting a response), Policy can't drive the implementation of this change and therefore probably isn't a good place to start with the request. I think it would need to start with dpkg and ftp-master (for DAK). I'm therefore probably going to have to close this bug against Policy as unactionable since I don't know of any efforts towards implementing this support, and Policy would only be able to change once the support is available. If I misunderstood the current state, please do let me know. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area
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 > created and at least a package was uploaded to it in October, but it has > not seen further movement. Two days ago, a call to action for moving > packages was sent by Cyril Brulebois², and I just sent a mail checking > for other places where it should be included³. > ¹ https://www.debian.org/vote/2022/vote_003 > ² https://lists.debian.org/debian-boot/2023/01/msg00150.html > ³ https://lists.debian.org/debian-project/2023/01/msg00018.html > To my surprise, the non-free-firmware archive area has not yet been > discussed for inclusion in the Policy. > I am (now!) aware there is a clear process to get changes included in > the Policy, but this is the first time I do this, so please excuse me > for jumping all the way to "State D: Wording proposed" (of course, my > words can be checked and improved, particularly given I'm not a native > English speaker). > ⁴ https://www.debian.org/doc/debian-policy/ap-process.html > I am suggesting the following patch, which I'm attaching to this bug > report, and also uploaded them to my fork of debian-policy in Salsa: > > https://salsa.debian.org/gwolf/policy/-/commit/79c58a40065c01f56850f86e883d8fa482c7cca0 Thank you! I also second this change, and have merged it for the next version of Policy, including the fixes suggested by James Addison. I numbered the footnotes in chapter two so that both non-free and non-free-firmware could reference the same footnote. An editorial note: Gunnar's patch introduced non-free-firmware after main and before contrib and non-free, and after some consideration I kept that order because I think it reflects the high likelihood that the typical user will encounter the non-free-firmware archive area given the results of the GR. That does mean that the contrib and non-free sections have been renumbered to 2.2.3 and 2.2.4, which resurrects a section 2.2.4 that previously was for non-US back when we had cryptography restrictions. I don't think this will cause any actual problems (and one of my long-term wishlist items is for Policy to rely less on section numbering, which is inherently unstable, and switch to some sort of persistent ID), but it seemed worth mentioning. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
ever. We have a process for making decisions because sometimes consensus is not achievable, and the people who don't agree with those decisions may, in fact, *never* agree with those decisions. They get to do that. It's not a crime. It's also not a personal offense against you. When people voice that disagreement, again, to a decision-making body and the immediate response is for multiple members of that body to politely but quite clearly indicate that, although they're willing to listen, the discussion is probably going nowhere and no decisions will change, this is what winning an argument looks like. This is what you're going to get. You're not going to get unanimous consensus. Take the win and *leave it alone*. Right now, you keep risking undermining architectural decisions that you've worked hard to achieve because you pile into discussions with your intensity knob already maxed and say a whole lot of confrontational stuff, some of which is careless or imprecise, and then the people *who already agree with you* feel obligated to disagree and clarify. And *then you start fighting them*, and absolutely nothing about this is achieving any goal that you have. Please, for the sake of my blood pressure, I beg of you, dial it *way down*. I swear that when I do process Policy bugs I will read all the messages and understand the technical arguments and clearly state what I think the most convincing points are, and everyone will get a chance to review that, and changes can even be reverted later if we get it wrong. Nothing is going to happen by surprise, and you do not have to be the last arguer standing in order to get your change into Policy. The more messages there are, and the more emotional heat there is, the more energy the whole process requires and the longer it takes. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1042853: docknot: FTBFS with Perl 5.38: t/spin/errors.t failure
gregor herrmann writes: > On Tue, 01 Aug 2023 23:06:54 +0300, Niko Tyni wrote: >> This package fails to build from source with Perl 5.38 (currently in >> experimental.) >> >> This looks like just a test-only diagnostics change, but >> please file a bug against perl to add a Breaks entry if >> there's actual runtime breakage after all. > According to https://github.com/rra/docknot/issues/6 fixed upstream > (in git, not released yet). Yeah, I'm sorry about the delay here. I'm trying to get a new release out shortly and if I fail at that I'll patch this in the Debian package. Please feel free to move forward with Perl and don't block on this package; this is totally my own (known) problem. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1043539: project: Forwarding of @debian.org mails to gmail broken
Helge Kreutzmann writes: > It's just that I never had this problem with mails to people with > @debian.org addresses, so either my new configuration or some other > change, I don't know. The problem I suspect is with email forwarding, and specifically email forwarding to Gmail, which has recently ramped up the amount of verification it does on messages. Because of email forwarding, Gmail sees a message purportedly from helgefjell.de but actually delivered by debian.org mail servers, and has now decided to be suspicious of that. If that's correct, you'll only have this problem with Debian developers who forward their @debian.org addresses to Gmail. Gmail handles some large percentage of all email on the Internet, so this probably isn't rare, but Debian developers are less likely to use it than random Internet users for obvious reasons, so it doesn't surprise me you've not run into the problem before. (In other words, I doubt this is a problem with your local configuration.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1043539: project: Forwarding of @debian.org mails to gmail broken
Helge Kreutzmann writes: > I don't know how it worked so far, and the error could be on my side, as > I recently switched my e-mail setup; however, I don't see anything I can > do to make DKIM/SPF point to @debian.org instead of @helgefjell.de, when > transferring e-mail to gmail. The mail to which I'm resonding also comes from your @helgefjell.de domain, so I'm suspecting some DKIM/SPF issues there if you're using that same address in your original mail message. But just in case you were trying to send from your @debian.org address, one option is to send all of your outgoing mail that is from your debian.org address through the debian.org mail servers. See: https://dsa.debian.org/user/mail-submit/ I don't think this is the direct answer to your original question, but I suspect it would work around the problem. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1014255: Long lines should also be ignored from non-code text files
"Dr. Bas Wijnen" writes: > Axel writes that README.md and LICENSE are likely valid cases. I > disagree. While I (and I expect many developers in Debian) are used to > using short lines in text files, this is not that common for other > people. Many will use the automatic word-wrap feature of text editors > and write a whole paragraph on a single line. Or, if not a whole paragraph, there are pretty strong arguments for following https://xkcd.com/1285/ whenever writing in any markup language, including Markdown, which can lead to long lines for complex sentences. That's the standard for our projects at my current employer. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1038400: /usr/share/perl/.../Pod/Man.pm: String C+: use '\s+2' not '\s0'
Russ Allbery writes: > Bjarni Ingi Gislason writes: >> wrong type size is created with, for example in gcc(1), >> .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' >> combined with >> \s-1ISO \*(C+\s0 >> # >> Do not use "\s0" in a string definition but an absolute number, >> as the size of the string could be changed. >> Then a situation of "\s-X...\s-Y...\s0...\s0" could emerge. >> Type size changes have an effect in "groff", but not in "nroff". > I believe this is fixed in Perl 5.8, currently in experimental, Sorry, that was supposed to be Perl 5.38. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1039605: perltoc.1: weird formatted text in chapter "Portability"
Bjarni Ingi Gislason writes:
> Part of the text needs correct formatting.
> The formatted text in chapter
> Portability
> Alphabetical Listening of Perl Functions
> begins so (with column width of 100):
>Portability
>Alphabetical Listing of Perl Functions
>-X FILEHANDLE
>, -X EXPR, -X DIRHANDLE, -X, abs VALUE , abs, accept
> NEWSOCKET,GENERICSOCKET ,
>alarm SECONDS , alarm, atan2 Y,X, bind SOCKET,NAME ,
> binmode FILEHANDLE, LAYER
> , binmode FILEHANDLE, bless REF,CLASSNAME , bless REF, break,
> caller EXPR,
>caller, chdir EXPR , chdir FILEHANDLE, chdir DIRHANDLE,
> chdir, chmod LIST ,
>chomp VARIABLE , chomp( LIST ), chomp, chop VARIABLE ,
> chop( LIST ), chop,
>chown LIST
> , chr NUMBER , chr, chroot FILENAME , chroot, close
> FILEHANDLE , close,
>closedir DIRHANDLE , connect SOCKET,NAME , continue BLOCK ,
> continue, cos EXPR
> , cos, crypt PLAINTEXT,SALT
> , dbmclose HASH , dbmopen HASH,DBNAME,MASK , defined EXPR
> , defined, delete EXPR , die LIST
> , do BLOCK , do EXPR , dump LABEL , dump EXPR, dump,
> each HASH , each
>ARRAY , eof FILEHANDLE , eof (), eof, eval EXPR
This appears to be an upstream bug. Upstream is making extensive use of
the X<> escape, which expands to the empty string and is used just to add
an index entry to formatters that support indexing, but they have
surrounded each of those X<> escapes with whitespace. This is incorrect;
the whitespace is then preserved and results in the weird formatting you
see, with spaces before commas. There should never be whitespace around
an X<> escape.
I think whoever is maintaining this documentation may not understand what
X<> is for, since its use of X<> doesn't make any sense to me. This is a
list of available documentation that doesn't contain any documentation
itself, so the index entries for everything mentioned seem spurious. You
would not want to follow an index reference and have it lead to nothing
but a list of all available topics.
perlpodspec:
"X" -- an index entry
See the brief discussion in "Formatting Codes" in perlpod.
This code is unusual in that most formatters completely discard this
code and its content. Other formatters will render it with invisible
codes that can be used in building an index of the current document.
perlpod:
"X" -- an index entry
This is ignored by most formatters, but some may use it for building
indexes. It always renders as empty-string. Example: "X"
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1038400: /usr/share/perl/.../Pod/Man.pm: String C+: use '\s+2' not '\s0'
Bjarni Ingi Gislason writes: > Dear Maintainer, > wrong type size is created with, for example in gcc(1), > .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' > combined with > \s-1ISO \*(C+\s0 > # > Do not use "\s0" in a string definition but an absolute number, > as the size of the string could be changed. > Then a situation of "\s-X...\s-Y...\s0...\s0" could emerge. > Type size changes have an effect in "groff", but not in "nroff". I believe this is fixed in Perl 5.8, currently in experimental, which I believe includes the latest podlators. All of this size manipulation code, and the C++ macro, have been removed in podlators 5.00, which drops all of the troff-specific guesswork formatting. It has proven much to difficult to maintain and has created lots problems for fairly minor formatting benefits. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1041158: perl: pod2man propagates duplicate space in the man page
Vincent Lefevre writes: > pod2man propagates duplicate space in the man page (contrary to > pod2text). > For instance, /usr/sbin/pam_getenv contains > This tool will print out the value [...] > with 2 space characters between "tool" and "will" (this is probably > unwanted, but this shouldn't yield inconsistencies in their handling). > The pod2text utility generates only one space: > zira:~> pod2text /usr/sbin/pam_getenv | grep tool > This tool will print out the value of *env_var* from /etc/environment. > but pod2man keeps both spaces, so that one gets them in the man page: > "pod2man /usr/sbin/pam_getenv | man -l -" gives > [...] > DESCRIPTION >This tool will print out the value of env_var from /etc/environment. > [...] The thing that's surprising to me in this is that *roff doesn't collapse the spaces. I feel like this is changed behavior and it used to do so, although I'm not sure. The root underlying issue here is unfortunately quite complex, and it's very easy to break things in this area while trying to fix unfortunate rendering such as that. See the discussion in the Pod::Man manual page under CAVEATS in the current version (which I think may only be in experimental at this point): Sentence spacing Pod::Man copies the input spacing verbatim to the output *roff document. This means your output will be affected by how nroff generally handles sentence spacing. nroff dates from an era in which it was standard to use two spaces after sentences, and will always add two spaces after a line-ending period (or similar punctuation) when reflowing text. For example, the following input: =pod One sentence. Another sentence. will result in two spaces after the period when the text is reflowed. If you use two spaces after sentences anyway, this will be consistent, although you will have to be careful to not end a line with an abbreviation such as "e.g." or "Ms.". Output will also be consistent if you use the *roff style guide (and XKCD 1285 <https://xkcd.com/1285/>) recommendation of putting a line break after each sentence, although that will consistently produce two spaces after each sentence, which may not be what you want. If you prefer one space after sentences (which is the more modern style), you will unfortunately need to ensure that no line in the middle of a paragraph ends in a period or similar sentence-ending paragraph. Otherwise, nroff will add a two spaces after that sentence when reflowing, and your output document will have inconsistent spacing. For various historical reasons, Pod::Text defaults to collapsing all spacing to single spaces and you have to set the sentence option (the -s flag) to get more equivalent behavior. If you run pod2text -s on that same man page, you will see the same problem. The difference in defaults is partly historical accident and backwards compatibility, but the more defensible justification is that *roff has its own opinions about whitespace formatting and prefers two spaces after periods, so it's much easier to get consistent output from *roff if pod2man doesn't try to second-guess one space vs. two spaces. (Determining whether a given double space is at the end of a sentence in a way compatible with multiple languages is incredibly hard to do and is not something I'm very enthused about trying to tackle in a Perl core module.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
Benda Xu writes: > I take care of packages that does not meet the proposed policy. And I > don't have a systemd test environment. I am curious what is the > recommended way to go forward. > - upload a generator-converted .service without any test; > - set low-NMU to encourage interested party to upload a .service; > - leave the lack-of-systemd-service bug open until some one submit a > patch or a merge request; > - you name it. systemd unit files for "typical" daemons are very simple to write (simpler than an init script in a lot of cases) and generally don't change much. I would, if I were you, be tempted to just write an obvious and simple unit file and upload it and let people report bugs if it breaks. This isn't ideal, but at least for simple daemons the risk is probably relatively low? Maybe I'm too cavalier, though. I suspect there are also a fair number of people who would be happy to help write systemd unit files for packages, since (at least in my opinion) it's kind of fun. This isn't the right place to coordinate that, but there must be some good spot in Debian. debian-mentors, maybe? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
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 > a decade, and it's time for the tail of packages still shipping only > init scripts but not units to be updated. Has there already been a mass bug filing for packages that ship init scripts but not systemd unit files? > 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 adapt it to be a standalone binary there's > nothing stopping them. But I wouldn't want the systemd package to > depend on such a backward compat tool, so packages needing this > hyptothetical package should depend explicitly on it. This is just > mentioned for completeness, it's been at least a decade and writing a > unit file is beyond trivial so there shouldn't be any issue adding the > few remaining ones. > Once the policy is updated I plan to ask Lintian to bump the severity > of the existing check: > https://salsa.debian.org/lintian/lintian/-/merge_requests/407 Assuming the mass bug filing hasn't already happened and I missed it, I think this is the wrong order. This sort of large-scale breaking change should always start with a mass bug filing against all affected packages. I think the right process is: * Raise this in debian-devel and propose a mass bug filing requiring all packages to add systemd unit files if they currently only have init scripts. This gives people the opportunity to object or take over maintenance of the unit file generator and document how to depend on it if they wish to do that instead. (I don't think that's a good idea, but we should let the discussion happen.) * Unless something surprising happens in that discussion, do a mass bug filing for this transition and bump the Lintian severity at the same time. * Once that has consensus and is underway, *then* change Policy to reflect this project decision. If the mass bug filing already happened and I just didn't notice, my apologies. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
