Bug#1082430: krb5-kdc, krb5-keytab-backend: Permission mismatch for /etc/krb5kdc/
Control: reassign -1 krb5-keytab-backend Guillem Jover writes: > While analyzing the archive for mismatched file metadata (as part of the > preparation to add support into dpkg), thanks to Helmut gathering the > data from the archive. I noticed that these two packages have a mismatch > in the permissions for the /etc/krb5kdc/ directory, where there could be > security implications, if the contents are expected to contain secrets > that only root is supposed to read, as the permissions of the directory > are decided by the first package being unpacked, and subsequent > directory unpacks get ignored (including any change in permissions). > $ dpkg-deb -c krb5-kdc_1.21.3-3_amd64.deb | grep etc/krb5kdc > drwx-- root/root 0 2024-07-05 19:25 ./etc/krb5kdc/ > $ dpkg-deb -c krb5-keytab-backend_1.5-1.1_all.deb | grep etc/krb5kdc > drwxr-xr-x root/root 0 2024-08-02 01:29 ./etc/krb5kdc/ > -rw-r--r-- root/root 287 2024-06-20 19:20 ./etc/krb5kdc/allow-extract > I'm not sure which one is correct. Whoops, thanks, this is an oversight in krb5-keytab-backend. The krb5-kdc permissions are correct. I will take a look. > Assigned to both for awareness and coordination purposes, feel free to > reassign to whichever might need to adapt the permissions. If this has > security implications then it might be worth to set the security tag, > and rise the severity and perhaps prepare a change for a stable update > too? If there are no security implications, it would still be good to > make the permissions consistent, otherwise dpkg would start warning or > erroring out on mismatched metadata once the support gets in and is > enabled. I don't think there are obvious security implications (I think the permissions are more precautionary, and it's also fairly unlikely that anyone will have installed krb5-wallet before krb5-kdc), although Sam, please let me know if you think I'm wrong. krb5-wallet has never been in a stable release, so no worries about stable fixes. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1081174: O: gnubg -- graphical or console backgammon program with analysis
Package: wnpp Severity: normal X-Debbugs-Cc: gn...@packages.debian.org, r...@debian.org Control: affects -1 + src:gnubg I intend to orphan the gnubg package. The package is in good shape, but I rarely use it and am not the best person to continue to maintain it. The package description is: GNU Backgammon is a strong backgammon program (world-class with a bearoff database installed) usable either as an engine by other programs or as a standalone backgammon game. In addition to supporting simple play, it also has extensive analysis features, a tutor mode, adjustable difficulty, and support for exporting annotated games. It can be played either from a GTK+ graphical interface, optionally with a 3D board, or from a simple text console. Packaging is on Salsa and uses git-buildpackage with an explicit patch queue. The package is in generally good shape. Upstream is active, although resource-constrained and could use help with porting the package to newer GTK+ ecosystem packages. Experience with the GTK+ ecosystem is a huge plus in maintaining this package and is one of the reasons why I'm not the best maintainer for it. There is one Debian-specific patch to move the location of some optional databases to /var. This approach should be rethought in conjunction with upstream so that Debian no longer has to carry a patch. All recent uploads have been done with dgit. Obviously, whether to continue using that tool is up to whoever adopts it.
Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Russ Allbery writes: > Sure, no problem. I'll file a bug against dash. #1007263 had already been filed and was on a very similar topic, so I have added some supplemental information to that bug report. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1007263: Document upgrading dash will change the /bin/sh no matter what
Package: dash Version: 0.5.12-9 Followup-For: Bug #1007263 X-Debbugs-Cc: r...@debian.org This topic came up in Policy bug #1074014. It sounds like there is a plan to document the transition in the release notes, but, going forward, the mechanism to change the shell underlying /bin/sh sounds like it changed as part of the current work and users should now do a local diversion of /bin/sh and create a new symlink. I think it would be a good idea to add user-facing documentation explaining how to do that, and I wasn't able to find any in dash (or bash, which is the most likely but not the only target shell). It probably should be in more than just NEWS.Debian, as well, since this will continue to be something some users need to do going forward, such as to handle local #!/bin/sh scripts that have bashisms. Maybe the README.Debian file of this package would be an appropriate place? -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.10.3-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 dash depends on: ii debianutils 5.20 ii libc62.39-6 dash recommends no packages. dash suggests no packages. -- debconf information: * dash/sh: true
Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Helmut Grohne writes: > Such concern is unwarranted. When dpkg unpacks a .deb, it unpacks all > the files with a .dpkg-tmp suffix appended. Hence, we also get a file > /usr/bin/mksh.dpkg-tmp. Once all of these are synced, it issues a > sequence of renames, including rename(/usr/bin/mksh.dpkg-tmp, > /usr/bin/mksh). This will atomically replace mksh even though it was > formerly /bin/mksh (but the same file via aliasing). At no time will > looking up /bin/mksh yield -ENOENT. That part I understand, and it's why there was never a window without /bin/mksh before all of the moves. What I was worried about is that here, dpkg thinks the old package *also* has a file named /bin/mksh. Presumably dpkg deletes the files that were present in the old package but not present in the new package at some point. If it does that before the renames, wouldn't it delete /bin/mksh (which happens to also be /usr/bin/mksh), outside of a rename? However, thank you very much for the turnkey experiment: > mmdebstrap bookworm /dev/null --variant=apt --include=strace > --customize-hook='sed -i -e s/bookworm/trixie/ "$1/etc/apt/sources.list"' > --chrooted-customize-hook='apt-get update && apt-get -y install libc6 && > apt-get download dash' --chrooted-customize-hook=bash > In there, strace dpkg -i dash_*.deb. I can confirm that dpkg never unlinks /bin/dash. I'm not sure why, but hopefully this means dpkg somehow figures this out. It does stat that file a couple of times, so maybe it derives some information from that. > dh_movetousr has nothing to do with protective diversions. It does not > add nor remove diversions nor does it change any. All it changes is > locations of files in the data.tar of a .deb. All of the protective > diversions that we ever installed for DEP17 are managed in maintainer > scripts and dh_movetousr does not touch maintainer scripts at all. Ah! Thank you. > Your reasoning makes sense to me. I do not intend to work on this > matter, because I am not interested in changing /bin/sh. Sure, no problem. I'll file a bug against dash. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1073608: Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Thorsten Glaser writes: > There is absolutely no reason to force files to move, given they are now > aliased already *anyway*. I think this is the relevant Policy point. I pretty strongly disagree with this, and I think we also have a consensus on the Policy list that, no, we need to force all the files to move. Obviously we shouldn't do that in a way that creates RC bugs, but that should be our goal. There has been a ton of discussion about why this is, and I'm not sure if you're already familiar with all of that and disagree or if you haven't been following the details (which is not a criticism; the discussions have been long and I also haven't been following all of the details for a while). But the core point is that dpkg doesn't understand that /bin is aliased to /usr/bin, and therefore if we keep shipping files in both /bin and /usr/bin, we are asking for a lot of trouble. The list of types of trouble is long and complicated and I won't try to reiterate all of the edge cases, but there are enough of them and they are hard enough to reason about that we do need to get all package files moved into /usr so that we can stop trying to hold this complicated problem in our heads. Essentially, right now, we're creating a dpkg database inconsistency with the file system, which was the original technical objection to usrmerge. The extensive work that has happened over the past months is to wrestle with the implications of that inconsistency and minimize its impact. One critical component of that work has been to transition every Debian package except base-files to only shipping things in /usr, because that removes entire classes of future problems. This does not completely resolve the inconsistency issues, since dpkg still doesn't fully understand that the paths are aliased, but my understanding is that it gets our packages into a state where those remaining problems shouldn't cause the more serious end of problems that we otherwise would have, and thus gets us into a basically stable position until dpkg can gain full understanding of the path aliasing. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1073608: Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Helmut Grohne writes: > What changed over time is that we first added diversions for > transitioning from bash to dash and later removed that mechanism as the > transition is complete and the desire to choose your /bin/sh is not as > prevalent as it used to be (mainly because choice of /bin/sh no longer > affects boot speed much). Just as a quick side note on this point: there will be an ongoing need and desire to switch /bin/sh to bash, and I am dubious of the belief that this will become less prevalent as long as dash is the default /bin/sh, which appears to still be the case to me based on dpkg -L. It's unforutnately still common to see shell scripts, particularly in proprietary software, that use bashisms in #!/bin/sh scripts. Changing /bin/sh to point to bash is very common in some environments to avoid having to manually fix all of those scripts to point to bash directly. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Helmut Grohne writes: > I was looking at this too narrowly from a mksh-perspective only and I > still think that the addition of dh_movetousr to mksh does not worsen > the situation on the mksh side. What I didn't see as clearly earlier is > that the way people tend to use mksh is by adding a local diversion for > /bin/sh and such a diversion is subject to DEP17 problems and in > particular, it is rendered ineffective by dash/0.5.12-9, which moves > /bin/sh to /usr/bin/sh. Say I have a bookworm system with mksh and > /bin/sh locally diverted. Now I upgrade dash to trixie. In that process, > dpkg will honour the diversion during deletion and then see that no > diversion affects the new location /usr/bin/sh happily overwriting > /usr/bin/sh (and via aliasing /bin/sh) breaking the user's earlier > choice to link /bin/sh to lksh. I'm glad that we were able to track this down, and thank you for following up on this to get it fixed. Just to be sure, though, I don't think this is the problem that Thorsten was worried about. My understanding of the problem Thorsten was reporting was slightly different: 1. A user has pointed /bin/sh to mksh, via a local diversion, changed symlink, or whatever other mechanism. The current mksh package, which from dpkg's perspective provides /bin/mksh, is installed. 2. A new version of mksh is uploaded that no longer provides /bin/mksh and does provide /usr/bin/mksh. 3. dpkg unpacks and installs that package. This involves some sequence of operations that, from dpkg's perspective, remove /bin/mksh and install /usr/bin/mksh. However, these are both the same file. My understanding of Thorsten's concern is that there may exist a window during which dpkg would delete /bin/mksh, since it is no longer included in the package, before it installs /usr/bin/mksh, and thus there could be a window where /bin/sh is a broken symlink. If the system crashes in that window, recovery could be annoying. I am unfortunately not very familiar with the ordering guarantees provided by dpkg and with the precise mechanism of dh_movetouser. I did look over the source of the latter and didn't see anything that obviously seemed to handle this case, but I quite likely missed something. This presumably has come up with other packages (libc6, for example), so maybe there's something that makes this safe that I'm not aware of? Maybe the protective diversions also protect against this problem as well as the problem of moved files? I unfortunately failed to spot where the protective diversions were added in dh_movetouser (if that even is the right place to be looking), so I'm fairly sure I'm missing something. > bash and dash earlier had a mechanism based on package-issued diversions > and debconf. I managed to remove this mechanism before the release of > bookworm and now the only supported way of changing /bin/sh is local > diversions. Indeed, bash and dash did not handle this at all as we > deemed messing with local diversions to be too much risk of getting the > user's intention wrong. Rather, we will be extending the release-notes > and add a section on local diversions asking users to duplicate them > before upgrading. Do we document for users somewhere how to change /bin/sh, as a replacement for the debconf questions? When I was investigating this, I tried to find documentation in the bash and dash packages and was unsuccessful. That's not a Policy question, of course, just an aside, but this sounds somewhat complicated and I'm not sure a user would be able to figure out the new, correct way to change /bin/sh. It sounds like the plan is to cover this in the relesae notes, which is great, but we probably also need ongoing documentation for the future. I'm not sure the best place to put that. Maybe just in README.Debian for whatever package currently provides /bin/sh by default. > I don't think the CTTE has actually issued a ruling on DEP17 or > /usr-move short of repealing the moratorium in order to enable moving > forward. The initial DEP17 as I proposed it suggested leaving all files > in place and enabling dpkg to understand the aliasing. However, that is > not the solution that consensus emerged around. I then adopted and > pursued the /usr-move path that I perceived as reaching most agreement. > There are two occasions where this could be seen as having been vetted. > One is elaborate discussions on d-devel with consensus summaries that > have not been objected to. The other is a transition bug that has been > acknowledged by the release team. In any case, I do not think we can use > the CTTE to back up my proposed policy change. Ah, thank you. I had misunderstood some of the previous discussion in this bug. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
(Dropping the pax bug because I think the potential danger to a user's system is specific to mksh because of the /bin/sh symlink.) Thorsten Glaser writes: > If I have a link from /bin/sh to a binary from the mksh package, then on > normal upgrades dpkg updates it atomically. Diverting the binary in > /bin/ away will leave the symlink from /bin/sh (which is managed by the > local admin because the dash package ignored two(!) rc bugs regarding > its changed /bin/sh management behaviour, when they broke it, for more > than two releases so the bug got eventually closed so mksh couldn’t > offer package-controlled /bin/sh management that was coordinated with > bash post-lenny) dangling. My summary (just repeating what you said back to you to make sure I understood) is that the problem you're seeing is that dh_movetouser diverts the moved file, which in the case of mksh may mean that /bin/sh is temporarily nonexistent if it is a symlink to mksh. I think there's two angles to this. First, from a Policy standpoint, I don't think this problem is blocking the Policy change. Policy is primarily a set of instructions for how people should create Debian packages in general, and there are often edge cases that it doesn't capture. If someone were packaging a new shell that is a valid /bin/sh target, we would want them to ship that shell in /usr/bin, not in /bin, to ensure that we don't create new potential dpkg database inconsistencies. I think Policy should say as much, even if there are problems with migrating the existing mksh package to that layout. If we need to make an exception for mksh, that's fine; there a lot of ways to do that, many of which don't require writing anything explicitly into Policy. Second, you believe the existing migration strategy will not work safely for mksh because of the potential /bin/sh symlink. Helmut, do you disagree with this? I'm not sure I'm clear on the precise point of disagreement: is the argument a factual disagreement about the behavior of the tools and the upgrade process, or an argument about acceptable risk? Both bash and dash have already done this migration; how did they handle this problem? Presumably they are at least as widely used as /bin/sh as mksh is, and I don't recall this breaking people's systems. Perhaps I missed those problems? > This is fragile, and the “benefits” are nowhere even near worth it: > /usr-merge per top-level symlinks per CTTE was forced on all systems, so > we got that now, and it is absolutely unnecessary for packages that are > not part of the pseudo-Essential set to move their files because their > implicit Pre-Depends on the Essential set will ensure that the /bin > symlink is already in place so this is a total nōn-issue. Packages that do not have problems such as the /bin/sh symlink should move their files so that we have consistency across the distribution and so that we're not left with variations that we know can cause inconsistency in the dpkg database and all of the related problems that come with that. We still have tool and system representation problems after this move, but they are smaller and more predictable and I believe more tractable to address. I don't think this is really open for discussion at the Policy Editor level since my understanding is that the CTTE has decided that this is how we're going to do the transition. In the case where this approach risks harm to the user's system, obviously that is something that needs to be analyzed and appropriately addressed, but in the typical case, no, the files in the packages should move so that we get to the more predictable and easier-to-reason-about end state that was the goal of the migration fix adopted by the CTTE. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
Thorsten Glaser writes: > You got your merged /usr already, and to force packages to move their > files WILL break users’ systems. In particular, mksh as /bin/sh is a > supported configuration. Could you explain how this would break a user's system? From your second sentence I'm guessing that you're anticipating some problem related to diversions, but I can't put the pieces together without some more details. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1075146: libauthen-sasl-xs-perl: ftbfs with GCC-14; patch ready
Niko Tyni writes: > On Fri, Jul 26, 2024 at 10:26:29PM +0200, Étienne Mollier wrote: >> Control: tags -1 + patch >> I pushed a patch[1] to salsa to proceed to targeted changes to >> the libauthen-sasl-xs-perl, but I'm not entirely confident >> touching a library that seems security sensitive. I'm notably >> feeling a bit bugged by the initial type discrepancy of a >> variable passed to an IV. >> >> I'll hold my horses a couple of days before upload, in case >> someone is interested to have a look over the weekend. >> >> [1]: >> https://salsa.debian.org/perl-team/modules/packages/libauthen-sasl-xs-perl/-/raw/debian/latest/debian/patches/gcc-14.patch?ref_type=heads > Thanks for your work on this. > The explicit casts of the callbacks look good to me FWIW. But I also > wonder about the pointer to integer cast in XS.xs:1886. > If it's really the right thing to do, I suppose casting to an IV would > be more correct than either int or long int. But I suspect that the > intention might be to dereference the pointer instead. FWIW I tried that > at home and the test suite still passed, so clearly it's not covering > these parts. I agree. I think the upstream code is buggy here and was incorrectly returning the value of the pointer rather than the underlying property value. sasl_getprop has a unified interface for all properties of whatever type. It sets the third argument to a pointer pointing to a const representation of the property. The Authen::SASL::XS API, though, is trying to return the actual underlying value, and therefore should return whatever the pointer points to, coerced to the appropriate type. This looks correct for the string properties, but for the SASL_SSF and SASL_MAXOUTBUF integer properties, I think it's returning the value of the pointer instead and it needs another layer of dereferencing. The property method is undocumented and doesn't seem to be called internally, which is probably why no one ever noticed this. > I don't see any reverse dependencies, so removal is also an option. > Particularly as this seems security sensitive and abandoned upstream... The lack of dependencies is somewhat deceptive because this module is transparently used by Authen::SASL (which is, somewhat surprisingly, missing any relevant dependency, even at the Suggests level; that's probably a different bug). I believe it prefers Authen::SASL::XS if it is installed. The Perl implementation for Authen::SASL works fine for clients, but if you want to write a server, you need Authen::SASL::XS if you're using any mechanism other than the simple password ones. See Authen::SASL::Perl: As for server support, only *PLAIN*, *LOGIN* and *DIGEST-MD5* are supported at the time of this writing. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1077764: Ruling request on os-release specification implementation
Luca Boccassi writes: > A trixie image is now in development, will become stable at some point > next year, will gain security support where it now has none, then it > will pass to the LTS team, then it will go EOL and any installation will > have to move to trixie + 1 which will be forky. The same happened to > bookworm, the same will happen to forky. It is not a rolling release, > because it has a limited lifetime, that begins, develops and ends. This is not true of a testing image, which is indeed a rolling release (with a somewhat odd variation in the frequency with which new packages are rolled into the release) that never gains security support, never passes to the LTS team, and never goes EOL. So whether this is true of an image installed from the current testing repository depends on the apt configuration in a way that is not captured by os-release under your proposal, namely whether it is configured to point to testing or to trixie. It's the exact same package set, but a completely different lifecycle. This is somewhat similarly true of stable vs. bookworm, but pointing to stable rather than bookworm is generally not encouraged because the sudden upgrade behavior when we release a new stable can be surprising in a way that is generally the opposite of what one wants from using stable. With testing, however, this is a standard configuration that is often preferable to using the codename, depending on what goals one has for running a testing image. For example, every testing image that I have points to testing, not to trixie. > The purpose of os-release is to identify images that have such > differences, and give them metadata accurately describing their > differing lifecycles, which are different and distinct, have different > characteristics, reflecting in different fields being set, such as > SUPPORT_END. I think there is no way to fully satisfy that purpose in Debian without doing something dynamic based on the apt configuration. Your proposal provides a different approximation that better captures one aspect of the lifecycle, but still does not achieve the semantics you're arguing for in the abstract. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1077764: Ruling request on os-release specification implementation
Simon McVittie writes: > On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote: >> Luca Boccassi writes: >>> It is correct as-is. VERSION_ID is meant to identify a release, not >>> updates or point releases. A release as in, Debian Bookworm, or Fedora >>> 40, or Ubuntu Noble, and so on. >> Why would you not want to identify point releases? This really >> surprises me. > I think the idea is that two releases have a different VERSION_ID if and > only if they can both be fully up to date, but still remain > different. If we make the analogy of git, VERSION_ID labels a branch, > not a tag. Oh, thank you, this was not at all obvious to me. If this is indeed the case, that would be a useful clarification to add to the specification. This also explains the desire to identify testing as trixie, but not identify unstable as trixie. If one configures a testing system to point to trixie, then fully updating it will move it into the stable release when the stable release comes out. However, if one points a system at unstable, that system will never become a trixie system and will always continue to point to a different release. This is not an entirely clean analogy, since it's also possible to point a system at the testing suite directly, rather than using the code name, in which case that system will also never become trixie. So in that sense testing is simultaneously both trixie and not trixie depending on exactly how you configure apt. This sort of ambiguity is, I think, part of why this proposal generates so much discussion. Debian simply doesn't currently have clean semantics for testing. It exists in a sort of quantum superposition where it is multiple things simultaneously for different people, and this proposal is trying to label it in a way that collapses that state to match the mental model of one group of people, invalidating the mental model of a different group of people. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1077764: Ruling request on os-release specification implementation
Luca Boccassi writes: > That's yet another Debian-specific workaround. The point of this is, > again, answering the question "what is this vendor tree" _without_ > distro specific kludges. That's the entire reason for os-release to > exist. If the answer at any point is "check os-release AND THEN run this > distro specific set of scripts or binaries", then the answer is wrong, > and the implementation of the spec is buggy. Again, one might say "I am > ok with this being buggy because we gain X Y and Z in exchange", but > buggy it is and buggy it will remain. This talk about "buggy" and "workarounds" didn't help me understand what you meant, but I think what you're saying is that I'm right, you *do* only care about the apt configuration, BUT apt is Debian-specific and figuring out how it is configured is not something that can be done portably, so you do want to use os-release as a proxy for that information because it's a cross-distro tool. That makes sense to me. It's a fallible proxy and it will get a bunch of edge cases wrong, but it's probably not possible to do better with an equivalently simple tool. Fundamentally, you want to change Debian's policy about testing to complete the separation from unstable and treat it as a first-class release in its own right in our metadata. Debian has historically not done this and generally discouraged people from doing this (this is *not* just Santiago's position; Santiago is correctly reflecting the previous consensus of the project), but there's always been a fair bit of controversy over that point, and I personally tend towards the side that thinks testing can be usefully treated as a rolling release with very substantial caveats and limitations. I do agree that it's often useful to be able to quickly determine if an image is pointing to testing or to unstable. > On Fri, 2 Aug 2024 at 04:00, Russ Allbery wrote: >> Well, it's related to your example of the zoom package basing decisions >> on the version number. If they had done that based on a version number >> of testing, there's a fairly high chance that whatever decisions they >> made would be wrong by the time the stable release happens, >> particularly if they do that early in a release cycle. >> That said, I would expect most third-party non-free packages like that >> to not care at all about anything in Debian until it reached stable, so >> the chances of them doing that may be low. > Uh, I did not provide an example regarding zoom? Where's that from? Ugh, I'm sorry, I was reading a lot of bug history and completely misattributed that message (and, for that matter, when it was sent). I was thinking of: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008735#91 which was from Kipp Cannon. My apologies for the confusion. >> I am surprised that point releases don't change VERSION_ID, and now I'm >> curious why that's the case. I was assuming, having not previously >> looked at it, that VERSION_ID would match /etc/debian_release, but I >> see that it doesn't and has only the major version. > It is correct as-is. VERSION_ID is meant to identify a release, not > updates or point releases. A release as in, Debian Bookworm, or Fedora > 40, or Ubuntu Noble, and so on. Why would you not want to identify point releases? This really surprises me. >> Regardless, security uploads do potentially create this problem, but we >> also try pretty hard to not change major functionality in security >> uploads in ways that may prompt someone to want to change behavior >> based on that version. There is a window of possibility there, I think >> it's sufficiently narrow to not worry that much about. It's at least a >> much narrower problem than version numbers in testing. > See other mail. It is really not narrow at all, because of kernel > upstream LTS updates. The upstream kernel quality of these branches is > really, really low, and massive regressions sneak in at all times. The > difference of behaviour between point releases is huge. I believe kernels are usually (not always, but usually) updated as part of point releases, which is yet another reason why I am so baffled as to why the VERSION_ID would not track point releases. > Debian stable updates do not, and pretty much never have, include only > security fixes. Exactly, which is why they should result in a VERSION_ID bump. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1077764: Ruling request on os-release specification implementation
an version numbers, in fact), so we already have this problem since, as you pointed out when opening this bug, the current base-files os-release file declares unstable and testing to be trixie. To be clear, although I understand why Santiago made that change, I have a similar worry about that decision. Anyway, I don't know how much we should care about this, particularly given the RELEASE_TYPE addition. That's why I said it was a worry, not a blocking objection. The most mistake-resistant approach would be to give testing some *other* code name that isn't trixie, and only give the code name of trixie at the time of release, but that's also weirdly different from how we use codenames in the archive structure and I am probably overthinking this. > What do you mean?!! It's right there! > https://www.freedesktop.org/software/systemd/man/devel/os-release.html#RELEASE_TYPE= > ...ok, ok, it's there now because I just merged it and regenerated the > docs :-P Thanks! This looks good to me. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1077764: Ruling request on os-release specification implementation
ar more enjoyable project to work on if you would recalibrate your understanding of what is an insult. Right now, it requires substantial effort to read any thread that you have replied to because I have to brace myself for judgmental, emotionally loaded, and hostile-sounding language that gets in the way of understanding the root disagreement and having a cordial and constructive collaboration. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1077764: Ruling request on os-release specification implementation
Luca Boccassi writes: > There are several different ways of having different content in sid vs > testing, and some have been proposed in the latest bug linked above, I > would be happy to discuss those details too if required. Generally the technical committee works best if it can consider a concrete technical proposal for a fix alongside the problem statement. I'm not a member, but as an interested bystander, I would like to see the details of precisely how you would implement your desired functionality. That could be several options if you'd like the committee to choose between them. I'd also like to see an elaboration of how you propose to distinguish sid from testing. This would be an ill-defined concept on the systems that I personally install testing packages on, and the specific criteria that you would use is not obvious to me from the bug discussion. I did review the discussion #1021663 in the hope that I would find a detailed technical proposal there, but your messages to that bug seemed to focus on criticisms of the current behavior mixed with insults. I wasn't able to find a proposal, but it's entirely possible I missed it. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1076346: Perl modules installed read-only (mode 0444)
Package: dh-debputy Version: 0.1.43 Severity: normal X-Debbugs-Cc: r...@debian.org Module::Build, one of the common build systems for Perl modules, defaults to installing Perl modules under /usr/share/perl5 read-only (mode 0444). With debhelper, this could be ignored for Debian packaging, since dh_fixperms (I believe) would repair the permissions to match the 0644 required by Debian Policy. With debputy, this appears to not happen (at least by default). Adding an explicit transformation to the manifest works around this: packages: docknot: transformations: - path-metadata: path: "usr/share/perl5" mode: "u+w" recursive: true It would be nice to not have to think about this, though. -- 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.9.8-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 dh-debputy depends on: ii debhelper 13.16 ii dwz 0.15-1+b1 ii man-db2.12.1-2 ii perl 5.38.2-5 ii python3 3.12.3-1 ii python3-colored 2.2.3-1 ii python3-colorlog 6.8.2-1 ii python3-debian0.1.49 ii python3-ruyaml0.91.0-3 ii strip-nondeterminism 1.14.0-1 Versions of packages dh-debputy recommends: ii debhelper13.16 ii python3-argcomplete 3.4.0-1 Versions of packages dh-debputy suggests: pn hunspell-en-us pn python3-hunspell pn python3-junit.xml pn python3-levenshtein ii python3-lsprotocol 2023.0.0-1 pn python3-pygls -- no debconf information
Bug#858970:
Andreas Hasenack writes:
> Heimdal's ktb5.conf manpage (with the patches applied):
>Files and directories may be included by absolute path.
> Including a directory causes all files in the directory to be included
> as if each file had been included sep‐
>arately, but only files whose names consist of alphanumeric,
> hyphen, and underscore are included, though they may also end in
> '.conf'.
> Heimdal doesn't mention ordering, so it's readdir() ordering, whatever that
> is:
> +if ((d = opendir(dname)) == NULL)
> +return errno;
> +
> +while ((entry = readdir(d)) != NULL) {
> (...)
readdir ordering is probably bad. I think that's essentially random on a
lot of file systems, and I'm not sure it's even guaranteed to be stable.
Is there any chance we could get that fixed in Heimdal before we start to
rely on it?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#858970: please add /etc/krb5.conf.d
Andreas Hasenack writes: > Presumably yes, but we have to indeed think about it. Normal dpkg conf > prompts will apply here, unless we do something (smart?) in postinst. > update: just saw the krb5-config postinst, it indeed tries to handle > many cases, and this would be another one. Yeah, krb5-config is quite complicated and doesn't treat /etc/krb5.conf as a typical Debian configuration file. It would be really nice to find a way to get more typical configuration semantics for /etc/krb5.conf, since the level of complexity makes krb5-config changes fragile and hard to test, but I don't have any great ideas for how to do that. > There are two breakage possibliities here: > a) It's quite possible some users already have a > /etc/krb5.conf.d/foo.conf file that has been ignored so far, and will > now be included. That could lead to unexpected behavior, yes. I think this we can probably say is okay to handle via NEWS.Debian. > We could grep for include/includedir in krb5.conf, be it a symlink or > not? What is the scenario where /etc/krb5.conf is a symlink, are some > sites doing that? I suspect there's at least one site somewhere that makes /etc/krb5.conf a symlink to some file in AFS, but I have no idea how common this sort of thing is. Given that the local administrator can just replace the file with one that doesn't have the includedir, I suppose that at some level it's just another case of "the local administrator can break their own system" and we mostly need to try to make people aware of it during upgrades. > I see, so for example you will want to create a configuration snippet to > address #756880, but aren't sure if that file will even be included > because krb5.conf might not have the includedir directive. Yes, exactly. > Note we can now also include specific files, without it having to be a > whole directory, if this helps. I don't think that it does. The file may or may not be there (lots of people use Kerberos without using libpam-krb5), and there's still the basic problem that we can't guarantee that the include directive is present. > I was thinking about a breaks, as in, new krb5-config would break old > heimdal. Ah, yes, that makes sense. And then packages that need configuration snippets can depend on the new version of krb5-config and that probably makes all the right things happen. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#858970: please add /etc/krb5.conf.d
Sam Hartman writes: >>>>>> "Andreas" == Andreas Hasenack writes: > >> And what dependency should a package that wants to use included > >> fragments have to ensure that those included fragments are > >> loaded? > I don't think you can. > An administrator might remove the includedir. > krb5.conf might be a symlink. > I think the strongest hint you can make is breaks krb5-config << > version. I'm not sure what that means for https://bugs.debian.org/756880 then. I want to move the minimum_uid setting into a configuration fragment so that people can easily change it as a conffile instead of having to stop using pam-auth-update if they need to change it. But if that setting is not applied somehow, this may allow local root compromise in pathological cases of Kerberos realms where people have unexpected principal names. I guess I can yell really loud in NEWS.Debian and call that good enough. Or add some postinst probe to make sure that the include is present, although I hate doing that because it means debconf, translations, and all of that machinery. Of course, this work is not required to solve my problem in a separate package. :) I was just hoping that it would. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#858970:
Andreas Hasenack writes: > If I include it via this krb5.conf: > [libdefaults] > includedir /etc/krb5.conf.d > default_realm = LOWTECH > default realm is LXD. > If I include it like this: > [libdefaults] > default_realm = LOWTECH > includedir /etc/krb5.conf.d > Then default realm is LOWTECH. Do both MIT and Heimdal use the same order (first seen wins)? I hope so, otherwise this is going to be tricky. > I think it's best to have the includedir at the very top, outside any > section. Seems to be the least surprising. I think that's right. That means that fragments will override anything in the base /etc/krb5.conf, which feels correct to me. We should add a prominent comment to the top of the default /etc/krb5.conf that explains this, as well as a NEWS.Debian entry. Do both MIT and Heimdal sort the fragments alphabetically before including them, so that there's some predictable order for which fragments override each other? We'll want to document the ordering. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#858970: please add /etc/krb5.conf.d
Andreas Hasenack writes: > I opened #1074775[1] to backport the heimdal patches that add include > and includedir support, filed a couple of salsa PRs[2][3] with tests, > and they were merged. Once there is a new upload of heimdal, we can > consider making this change in kerberos-configs then. What do you think? I am in favor of making this change. Thank you very much for clearing the blocker in Heimdal. This will, among other things, let me finally address #756880[1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756880 The change is not entirely trivial, however. Here are some things that come to mind that we probably need a plan for how to handle: 1. For already-configured systems, should we add the include directive to the existing krb5.conf file? Presumably the answer is yes, or the migration is going to be rather difficult. Is there a correct place in the krb5.conf file to add the include so that we get the correct semantics for whether fragments override the main file or vice versa? Are we going to break anyone's system by suddenly including the fragments? We'll at least need a NEWS.Debian entry; maybe we also need a debconf warning in some situations? 2. With the current logic, it's not possible to guarantee that the include directive has been added, since krb5-config by design doesn't touch a krb5.conf file that's a symlink. That means it's possible to have the latest version of everything installed and still not respect the configuration fragments. Do we just live with this? I'm nervous about moving critical configuration into a fragment when we can't guarantee that the fragment is loaded. In the libpam-krb5 case, this can lead to a security vulnerability. 3. How do dependencies work? This change to krb5-config will require a particular version of Heimdal, since earlier versions don't support include (and will this break Kerberos entirely if the include is present?). But krb5-config can't depend on any specific Kerberos implementation, so I don't know how to represent this as a dependency. And what dependency should a package that wants to use included fragments have to ensure that those included fragments are loaded? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1075905: ITP: python-fraction -- Fraction carries out all the fraction operations including addition, subtraction, multiplication, division, reciprocation
Yogeswaran Umasankar writes: > As I look further, it appears that standard Python libs such as float or > decimal.Decimal do not provide exact representation of rational numbers > (fractions) without potential loss of precision. Seems ‘fraction’ > package yield exact results because those functions directly work on > fractions (to my limited understanding). > decimal.Decimal is better than float, but it only extends to arbitrary > precision decimal arithmetic, not exact representation of rational > numbers. Given that these libraries could potentially serve as > dependencies for tensor-related packages and beyond, should we consider > bringing 'fraction' or restrict ourselves to float (which is a fallback > in moarchiving if fraction unavailable)? I think the suggestion is to use the Python standard library package "fractions" specifically: https://docs.python.org/3/library/fractions.html -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1074014: encode mandatory merged-/usr into policy
Helmut Grohne writes: > Portability is one angle and certainly an important one. Spending > collective project resources is another one. I argue that changing these > paths beyond what is technically necessary is not a good use of our > time. So how about having policy recommend not changing path references > compared to upstream? I don't think this should be a policy requirement > as there may be good reasons to deviate and we can rationalize this > recommendation with the portability and the effort arguments. Oh, that's an interesting idea. How about something like: Since paths either with or without /usr are supported on Debian systems, maintainers of non-native packages are encouraged to follow the same conventions as the upstream package when referencing absolute paths. There is no need to change upstream code from, for example, /bin to /usr/bin (or from /usr/bin to /bin) when packaging for Debian. There is a drawback, though: because dpkg only knows about the usr/bin (etc.) paths, at least as I understand the current state of things, one cannot find non-/usr paths with dpkg -S. Changing all the paths to include usr/ therefore does solve a usability issue in some cases, so this trade off is not entirely obvious. I have lost track of the work on this. Are there any prospects for dpkg to know, on Debian systems, that bin/sh and usr/bin/sh are the same thing? > I have another question. Thorsten Glaser was unhappy about my mksh > report as he believes that it should be /bin/mksh and not /usr/bin/mksh. > I argued that the biggest concern is the symlink vs directory conflict > and he came up with a crazy solution where mksh's data.tar contains > ./bin/mksh but not ./bin on the grounds that ./bin is provided by an > essential package in all Debian releases. I think this approach > practically solves a significant chunk of the problems listed by DEP17, > but it still confuses QA tools and e.g. dpkg -S (maybe more). My > proposal here would make mksh's approach violate policy. Should policy > allow Thorsten's approach? It certainly is something that needs to be > forbidden for any transitively essential package or bootstrapping tools > fail. My inclination is to say no, we shouldn't allow it in Policy. The release team can decide whether they care in the case of mksh, and I personally have a hard time getting that upset about Thorsten carrying that policy violation in his package when it matters a lot to him and he accepts the resulting breakage. But I'm fine with calling it a policy violation: it breaks other tools, making it work is a level of complexity that we don't need, and it doesn't, so far as I know, have a strong technical justification. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1074014: encode mandatory merged-/usr into policy
Sam Hartman writes: >>>>>> "Helmut" == Helmut Grohne writes: > Helmut> 5. Given earlier disagreement on this > Helmut> matter, should we discuss this matter in a wider setting > Helmut> such as d-devel? > No, please no! > If there ends up being disagreement, the TC should use its policy making > powers and put this to bed. I forgot about the TC involvement. This is a better answer than mine. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1074014: encode mandatory merged-/usr into policy
Helmut Grohne writes: > given the progress we have made with /usr-move and DEP17, I think it is > time to consider encoding the changes into policy. As of this writing, > there are 216 source packages in unstable that still install into > aliased locations and their number has been dropping since a while. All > but very few packages have bug reports of important severity and will > have their severity upgraded to serious on August 6th. Thank you again for all the work that you have done on this. I agree that we have reached the point in the transition where we should update Policy to reflect the new requirements of the archive. > For these reasons, I propose changing section 10.1 and encoding the > avoidance of symlink vs directory conflicts into policy. To get a > discussion going, I suggest the following update. > - To support merged-/usr systems, packages must not install files in both > - /path and /usr/path. For example, a package must not install both > - /bin/example and /usr/bin/example. > + Since base-files implements mandatory merged-/usr by installing the > + aliasing symbolic links, other packages must not install files into > + aliased paths such as /bin, /lib, /lib* or /sbin. The package manager is > + not prepared to deal with such aliasing and in prohibiting the > + installation into aliased locations, we avoid triggering undefined > + behaviour. Conversely, packages may assume that /bin, /lib and /sbin are > + symlinks at all times and that their files below /usr/bin, /usr/lib and > + /usr/sbin are also accessible via their aliased locations. I spent some time thinking about this, since I personally still wish people wouldn't write /usr/bin/sh when they mean /bin/sh. I don't think Policy should prohibit this since, among other reasons, we have no effective enforcement mechanism and the package will clearly work fine on Debian systems. But it would be nice if people didn't gratuitously break portability, admittedly mostly to non-Linux systems at this point. That said, I think I convinced myself that this is just not something Policy can reasonably address. We should state the assumption as you stated it since that's required for packages to use /bin/sh at all, and this probably is not the place to give people portability advice, particularly since it only applies to things that might be copied from Debian to a non-Debian system and most of those aren't under our control and will never be written to Policy anyway. > Questions: > 1. Do you agree that policy should be changed? Yes. > If yes: > 2. Do you agree that policy should prohibit installing into aliased > paths? Yes. > 3. Do you agree that the current progress is sufficient for changing > policy? If not, when can we change policy? Yes. > 4. Do you agree with the proposed wording? Can you suggest > improvements? Yes. > 5. Given earlier disagreement on this matter, should we discuss this > matter in a wider setting such as d-devel? You certainly can, but at this late stage I don't think it would change anything. We're already into mass-bug-filing territory and it's going to be an RC bug, so it's already de facto policy and I don't see a justification for not making it de jure policy. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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 > specificati
Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete
where toolchain maintainers are relatively 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
at persuasion and doesn't get us closer to making a real decision. In other words, this is advice that I constantly give myself because I am 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
harmful. Yeah, it sounds like you're thinking of exactly the case I was thinking of. > So I want 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/c
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 informat
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
re's a lot of appeal of having a thorough specification for what debhelper is supposed to 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 an
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 o
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 na
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/>
