Bug#1079635: bookworm-pu: package systemd/252.30-1~deb12u2
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org, a...@adam-barratt.org.uk Dear Release Team, This upload backports one patch to revert adding a new comment that was added in 252.30-1~deb12u1 to a conffile as indicated in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079086#25 Debdiff attached. -- Kind regards, Luca Boccassi diff -Nru systemd-252.30/debian/changelog systemd-252.30/debian/changelog --- systemd-252.30/debian/changelog 2024-08-19 21:32:22.0 +0100 +++ systemd-252.30/debian/changelog 2024-08-25 18:35:39.0 +0100 @@ -1,3 +1,10 @@ +systemd (252.30-1~deb12u2) bookworm; urgency=medium + + * Backport patch to revert new comment in /etc/systemd/journald.conf. +Avoid dpkg prompt on upgrade + + -- Luca Boccassi Sun, 25 Aug 2024 18:35:39 +0100 + systemd (252.30-1~deb12u1) bookworm; urgency=medium * New upstream version 252.30 diff -Nru systemd-252.30/debian/patches/Revert-journal-comment-the-default-value-in-journald.conf.patch systemd-252.30/debian/patches/Revert-journal-comment-the-default-value-in-journald.conf.patch --- systemd-252.30/debian/patches/Revert-journal-comment-the-default-value-in-journald.conf.patch 1970-01-01 01:00:00.0 +0100 +++ systemd-252.30/debian/patches/Revert-journal-comment-the-default-value-in-journald.conf.patch 2024-08-25 18:34:31.0 +0100 @@ -0,0 +1,17 @@ +Author: Luca Boccassi +Bug-Debian: http://bugs.debian.org/1079086 +Description: Revert "journal: comment the default value in journald.conf" + Because of how dpkg handles config files, this will cause a prompt to + users on upgrade, which is undesirable for stable updates, so revert it + in v252-stable. +--- a/src/journal/journald.conf b/src/journal/journald.conf +@@ -30,7 +30,7 @@ + #RuntimeKeepFree= + #RuntimeMaxFileSize= + #RuntimeMaxFiles=100 +-#MaxRetentionSec=0 ++#MaxRetentionSec= + #MaxFileSec=1month + #ForwardToSyslog=yes + #ForwardToKMsg=no diff -Nru systemd-252.30/debian/patches/series systemd-252.30/debian/patches/series --- systemd-252.30/debian/patches/series 2024-08-19 21:32:22.0 +0100 +++ systemd-252.30/debian/patches/series 2024-08-25 18:32:58.0 +0100 @@ -18,3 +18,4 @@ debian/systemctl-do-not-shutdown-immediately-on-scheduled-shutdo.patch debian/Downgrade-a-couple-of-warnings-to-debug.patch debian/Skip-flaky-test_resolved_domain_restricted_dns-in-network.patch +Revert-journal-comment-the-default-value-in-journald.conf.patch signature.asc Description: This is a digitally signed message part
Bug#1079086: bookworm-pu: package systemd/252.30-1~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org Dear Release Team, We would like to upload the latest stable point release of systemd 252 to bookworm-p-u. Stable release branches are maintained upstream with the intention of providing bug fixes only and no compatibility breakages, and with automated non-trivial CI jobs that also cover Debian and Ubuntu. I have already uploaded to p-u. The only packaging changes are refreshing one patch to remove new fuzz. Debdiff attached. The list of commits included can be seen at: https://github.com/systemd/systemd-stable/compare/v252.29...v252.30 -- Kind regards, Luca Boccassi diff -Nru systemd-252.29/debian/changelog systemd-252.30/debian/changelog --- systemd-252.29/debian/changelog 2024-07-25 13:49:17.0 +0100 +++ systemd-252.30/debian/changelog 2024-08-19 21:32:22.0 +0100 @@ -1,3 +1,10 @@ +systemd (252.30-1~deb12u1) bookworm; urgency=medium + + * New upstream version 252.30 + * Refresh patches to remove fuzz from 252.30 + + -- Luca Boccassi Mon, 19 Aug 2024 21:32:22 +0100 + systemd (252.29-1~deb12u1) bookworm; urgency=medium * New upstream version 252.29 (Closes: #1074789) diff -Nru systemd-252.29/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch systemd-252.30/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch --- systemd-252.29/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch 2024-07-25 13:47:26.0 +0100 +++ systemd-252.30/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch 2024-08-19 21:32:22.0 +0100 @@ -47,7 +47,7 @@ +++ b/src/journal/journald.conf @@ -32,7 +32,7 @@ #RuntimeMaxFiles=100 - #MaxRetentionSec= + #MaxRetentionSec=0 #MaxFileSec=1month -#ForwardToSyslog=no +#ForwardToSyslog=yes diff -Nru systemd-252.29/docs/CONTAINER_INTERFACE.md systemd-252.30/docs/CONTAINER_INTERFACE.md --- systemd-252.29/docs/CONTAINER_INTERFACE.md 2024-07-25 13:45:32.0 +0100 +++ systemd-252.30/docs/CONTAINER_INTERFACE.md 2024-08-19 21:25:31.0 +0100 @@ -230,7 +230,9 @@ directory: it's used by code outside the container to insert mounts inside it only, and is mostly an internal vehicle to achieve this. Other container managers that want to implement similar functionality might consider using - the same directory. + the same directory. Alternatively, the new mount API may be used by the + container manager to establish new mounts in the container without the need + for the `/run/host/incoming/` directory. 2. The `/run/host/inaccessible/` directory may be set up by the container manager to include six file nodes: `reg`, `dir`, `fifo`, `sock`, `chr`, diff -Nru systemd-252.29/man/repart.d.xml systemd-252.30/man/repart.d.xml --- systemd-252.29/man/repart.d.xml 2024-07-25 13:45:32.0 +0100 +++ systemd-252.30/man/repart.d.xml 2024-08-19 21:25:31.0 +0100 @@ -562,7 +562,7 @@ fstab5. -If both bit 50 and 59 are set for a partition (i.e. the partition is marked both read-only and +If both bit 60 and 59 are set for a partition (i.e. the partition is marked both read-only and marked for file system growing) the latter is typically without effect: the read-only flag takes precedence in most tools reading these flags, and since growing the file system involves writing to the partition it is consequently ignored. diff -Nru systemd-252.29/man/systemd-path.xml systemd-252.30/man/systemd-path.xml --- systemd-252.29/man/systemd-path.xml 2024-07-25 13:45:32.0 +0100 +++ systemd-252.30/man/systemd-path.xml 2024-08-19 21:25:31.0 +0100 @@ -43,6 +43,12 @@ The variables whose name begins with search- do not refer to individual paths, but instead to a list of colon-separated search paths, in their order of precedence. + +Note that paths which depend on environment variables are +computed with systemd-path's invoked +environment, and not the system or user manager's environment. As +such, the output of systemd-path may not +reflect the behavior of manager processes. diff -Nru systemd-252.29/man/systemd-system.conf.xml systemd-252.30/man/systemd-system.conf.xml --- systemd-252.29/man/systemd-system.conf.xml 2024-07-25 13:45:32.0 +0100 +++ systemd-252.30/man/systemd-system.conf.xml 2024-08-19 21:25:31.0 +0100 @@ -421,10 +421,12 @@ ManagerEnvironment= Takes the same arguments as DefaultEnvironment=, see above. Sets -environment variables just for the manager process itself. In contrast to user managers, these variables -are not inherited by processes spawned by the system manager, use DefaultEnvironment= +environment variables for the manager process itself. These variables are inherited by processes +spawned by use
Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum
Both kernel and iproute2, backports is fine too On Mon, 19 Aug 2024 at 21:15, Роман Мещеряков wrote: > > Luca, sorry if my question is silly. Do you mean "testing or unstable" > iproute2 package, Debian kernel or complete fresh Debian installation? > -- > Kind regards, Roman Mescheryakov > > > 19.08.2024, 17:48, "Luca Boccassi" : > > Control: tags -1 moreinfo > > On Sun, 18 Aug 2024 21:07:10 +0300 =?utf- > 8?B?0KDQvtC80LDQvSDQnNC10YnQtdGA0Y/QutC+0LI=?= > wrote: > > Package: iproute2 > Version: 6.1.0-3 > > > Hi, > > Can you reproduce the same issue on testing or unstable? > > > -- > Kind regards, > Luca Boccassi
Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum
Control: tags -1 moreinfo On Sun, 18 Aug 2024 21:07:10 +0300 =?utf- 8?B?0KDQvtC80LDQvSDQnNC10YnQtdGA0Y/QutC+0LI=?= wrote: > Package: iproute2 > Version: 6.1.0-3 Hi, Can you reproduce the same issue on testing or unstable? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1078745: generator-scripting-language: Remove vendored pcre
On Thu, 15 Aug 2024 10:40:00 +0200 Bastian Germann wrote: > Source: generator-scripting-language > Version: 4.1.5-4 > Severity: important > Control: forwarded -1 https://github.com/zeromq/gsl/pull/52 > > Please get rid of the vendored debian/pcre3. > There is an upstream pull request that can be of help with this by building with pcre2. Unfortunately the upstream PR is not ready, as mentioned there it needs extensive regression testing on multiple platforms, including various version of Windows and OSX, and so far nobody has stepped up to do that. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1078688: Please use filecaps for /usr/sbin/unix_chkpwd instead of setgid shadow
On Wed, 14 Aug 2024 14:54:20 -0600 Sam Hartman wrote: > >>>>> "Daan" == Daan De Meyer writes: > > Daan> Dear Maintainer, As described in > Daan> https://github.com/linux-pam/linux-pam/pull/373, unix_chkpwd > Daan> does not need to be setuid or setgid anymore if it is given > Daan> cap_dac_override via filecaps instead. I would like debian to > Daan> use filecaps instead of setgid shadow for > Daan> /usr/sbin/unix_chkpwd so that the file itself can be owned by > Daan> root:root and the setgid bit can be removed from the > Daan> file. Having all files in /usr owned by root:root is useful > Daan> for image builders as it allows building debian images in a > Daan> stripped down user namespace with only the root user and > Daan> nothing else available. > > My inclination is to mark this bug wontfix. > The principle of least privilege says that we should not give a > executable more privilege than it needs. > DAC_OVERRIDE is significant privilege--almost certainly enough privilege > to compromise the system entirely. > In contrast, sgid shadow is significantly less privilege. > > I'd like to find a way to support the image building use case, but not > at the expense of security for the rest of the world. > Do you have any suggestions for how we can meet both of our needs? The setgid is inherited by any eventual child process. On the other hand, capabilities can be limited to the individual process, and stopped from being inherited. IMHO that already makes it more attractive, as the most common avenue for exploit is to trick it into executing something else. It seems unlikely to have ROP gadgets or suchlike readily available in this. On top of that, this is only needed for reading, right? If that's the case, then CAP_DAC_READ_SEARCH can be used, which gives read-only privileges. That is a very lightweight cap, especially as, most likely, the most dangerous thing you can read is the root password, and this is anyway designed to allow the caller to do exactly that. So it seems to me, being able to set cap_dac_read_search=ep would be strictly better than setgid under common circumstances? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts
Control: reassign -1 vlan 2.0.5+nmu2 Control: tags -1 patch On Wed, 14 Aug 2024 15:35:56 -0400 Michael Stone wrote: > Package: iproute2 > Version: 6.10.0-1 > Severity: critical > Justification: breaks the whole system > > The first time I rebooted after iproute2 removed the /sbin/ip link, my system > failed to boot. I eventually discovered this was because /sbin/vconfig (from > the "vlan" package) calls /sbin/ip and when that failed the network was not > configured. This meant having to boot into single user mode for diagnostics > because systemd hung forever waiting for the network. This change was noted in NEWS. I would suggest hooking your config into something that uses the network-online.target target, with a timeout like network-manager and networkd do, so that the boot process doesn't hang. If it's a simple unit, it's enough to add RuntimeMaxSec= to it, so that it's killed if it doesn't work within the configured timeout. Patch for vlan sent at: https://salsa.debian.org/debian/vlan/-/merge_requests/3 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1078607: Feature Request: Add `auto` option for VRF table id management
Control: tags -1 upstream Control: close -1 On Tue, 13 Aug 2024 13:41:32 -0400 Mike Waterman wrote: > Package: iproute2 > Version: 5.10.0-4 > Severity: wishlist > > I'm requesting the addition of an `auto` option for VRF table ID management > in the iproute2 package on Debian. (Apologies if the package is incorrect.) > Currently, managing VRF table IDs manually can be cumbersome and > error-prone. In Cumulus Linux, the `auto` option allows the OS to handle > allocating and releasing VRF table IDs automatically, which greatly > simplifies network configuration and management. Having a similar feature > in Debian would be highly beneficial for users who manage complex > networking setups. > > For example, instead of this: > > ``` > auto vrfexample > iface vrfexample > vrf-table 1001 > > auto vrfexample2 > iface vrfexample2 > vrf-table 1002 > ``` > > Or this: > > ``` > ip link add vrfexample type vrf table 1001 > ip link add vrfexample2 type vrf table 1002 > ``` > > It'd be great to do this: > > ``` > auto vrfexample > iface vrfexample > vrf-table auto > > auto vrfexample2 > iface vrfexample2 > vrf-table auto > ``` > > Or this: > > ``` > ip link add vrfexample type vrf table auto > ip link add vrfexample2 type vrf table auto > ``` > > We’d like to request this be backported to Bullseye for compatibility > reasons. Please submit such feature requests upstream. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1060384: RM: maybe this package should be removed
Control: tags -1 moreinfo upstream On Wed, 10 Jan 2024 14:35:16 +0100 Alexandre Detiste wrote: > Source: python-azure-devtools > Severity: normal > X-Debbugs-Cc: Luca Boccassi > > Hi Luca, > > Can you check if azure-devops-cli-extension > still needs python-azure-devtools ? > > It is the only reverse dependency. > > https://github.com/Azure/azure-python-devtools > > > This repository has been archived by the owner on Oct 12, 2023. It is now read-only. > > Disclaimer: The package "azure-devtools" is no longer maintened > > nor used in any Microsoft projects anymore. Hi, Unfortunately it looks like it is still needed in azure-devops-cli- extension, albeit only for unit tests. We could disable them I guess, but I figure it's better to wait for upstream to drop this a provide a replacement? $ git grep -r azure_devtools tests/test_adminBannerTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_boardsAreaTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_boardsIterationTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_boardsQueryTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_boardsRelationTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_boardsWorkItemTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_devopsProjectTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_devopsSecurityGroupTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_devopsSecurityPermissionTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_devopsTeamTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_devopsUserTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_extensionSearch.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_invoke.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_pipelineAgentPoolQueueTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_pipelineFoldersTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_pipelinesBuildCancelTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_pipelinesBuildDefinitionsTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_pipelinesBuildTagTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_pipelinesBuildTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_pipelinesCreateAndVariablesTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_reposImportTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_reposPoliciesTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_reposPrCommandsReviewersTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_reposPrPoliciesWorkItemsTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_reposRefDeleteFlowTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_reposRefTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_reposRepoTest.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_variableGroup.py:from azure_devtools.scenario_tests import AllowLargeResponse tests/test_wikiAndPagesTest.py:from azure_devtools.scenario_tests import AllowLargeResponse _ ERROR collecting tests/test_adminBannerTest.py __ ImportError while importing test module '/tmp/a/.pybuild/cpython3_3.12/build/tests/test_adminBannerTest.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: /usr/lib/python3.12/importlib/__init__.py:90: in import_module return _bootstrap._gcd_import(name[level:], package, level) tests/test_adminBannerTest.py:10: in from azure_devtools.scenario_tests import AllowLargeResponse E ModuleNotFoundError: No module named 'azure_devtools' __ ERROR collecting tests/test_boardsAreaTest.py __ ImportError while importing test module '/tmp/a/.pybuild/cpython3_3.12/build/tests/test_boardsAreaTest.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: /usr/lib/python3.12/importlib/__init__.py:90: in import_module return _bootstrap._gcd_import(name[level:], package, level) tests/test_boardsAreaTest.py:9: in from azure_devt
Bug#1064408: [PATCH] duplicate aliased diversions for DEP17
Control: tags -1 pending
On Wed, 21 Feb 2024 18:04:17 +0100 Helmut Grohne
wrote:
> Package: live-build
> Versrion: 1:20230502
> User: helm...@debian.org
> Usertags: dep17p3
> Tags: patch
>
> /bin/hostname and /sbin/start-stop-daemon are being moved from / to
/usr
> in trixie. Hence, these diversions become ineffective. Temporarily
add
> both diversions to handle both variants.
> ---
> scripts/build/chroot_dpkg | 15 ---
> scripts/build/chroot_hostname | 17 +
> 2 files changed, 25 insertions(+), 7 deletions(-)
>
> I note that while live-build has MRs on salsa, I cannot seem to create
> one. Hence sending a patch via bugs.d.o.
>
> diff --git a/scripts/build/chroot_dpkg b/scripts/build/chroot_dpkg
> index c43c0eb01..d64820f72 100755
> --- a/scripts/build/chroot_dpkg
> +++ b/scripts/build/chroot_dpkg
> @@ -38,8 +38,14 @@ case "${_ACTION}" in
> Acquire_lockfile
>
> # Create custom start-stop-daemon program
> - Chroot chroot dpkg-divert --rename --quiet --add
> /sbin/start-stop-daemon
> - ln -fs /bin/true chroot/sbin/start-stop-daemon
> + Chroot chroot dpkg-divert --rename --quiet --add
> /usr/sbin/start-stop-daemon
> + # begin-remove-after: released:trixie
> + # In the bookworm to trixie upgrade, dpkg moves
> + # start-stop-daemon from /sbin to /usr/sbin. Duplicate the
> + # diversion to cover both. DEP17 P3 M18
> + Chroot chroot dpkg-divert --rename --quiet --add --divert
> /sbin/start-stop-daemon.distrib.usr-is-merged
This is missing the second positional parameter (/sbin/start-stop-
daemon), but after fixing that it seems to work, so I'll upload a fixed
version shortly
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#1078331: systemd: All non-default Journal Namespaces read from /dev/kmem
Control: tags -1 -moreinfo Control: tags -1 upstream Control: close -1 On Fri, 9 Aug 2024 17:36:48 +0200 "F. Stoyan" wrote: > On 9.08.24 14:51, Luca Boccassi wrote: > > Control: tags -1 moreinfo > > > > > > Can you reproduce this on testing or unstable? > > > > Package: systemd > Version: 256.4-2 > Severity: normal > > Dear Maintainer, > > Exactly the same behavior with trixie: Ok, then please open an issue upstream via https://github.com/systemd/systemd/issues/new?assignees=&labels=bug+%F0%9F%90%9B&projects=&template=bug_report.yml and reproduce it with debug log level enabled, and attach the full logs and the reproducer. There are no downstream patches or configurations that would affect that. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1078331: systemd: All non-default Journal Namespaces read from /dev/kmem
Control: tags -1 moreinfo On Fri, 09 Aug 2024 15:32:56 +0200 "F. Stoyan" wrote: > Package: systemd > Version: 252.29-1~deb12u1 > Severity: normal > > Dear Maintainer, > > the manual page journald.conf(5) states very clearly: > > ReadKMsg= > Takes a boolean value. If enabled systemd-journal processes /dev/kmsg > messages generated by the kernel. In the default journal namespace > this option is enabled by default, it is disabled in all others. > > But, every time a non default journal namespace is spawnd, it > complains very loudly: > > Aug 07 16:30:55 systemd[1]: Starting systemd-journald@bulk.service - Journal Service for Namespace bulk... > Aug 07 16:30:55 systemd-journald[2081]: Failed to open /dev/kmsg, ignoring: Operation not permitted > Aug 07 16:30:55 systemd[1]: Started systemd-journald@bulk.service - Journal Service for Namespace bulk. > Aug 07 16:31:25 systemd[1]: systemd-journald@bulk.service: Deactivated successfully. > > The namespace configuration is at follows: > > $ systemd-analyze cat-config systemd/journ...@bulk.conf > # /etc/systemd/journ...@bulk.conf > # Use 'systemd-analyze cat-config systemd/journ...@bulk.conf' to display the full config. > # See journald.conf(5) for details. > > [Journal] > Storage=volatile > RuntimeMaxUse=16M > ReadKMsg=no > > It does not matter whether "ReadKMsg=no" is configured or not, > it does not change the behavior. Can you reproduce this on testing or unstable? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1078205: systemd: can't start polkitd in a podman container without CAP_SYS_ADMIN
On Thu, 8 Aug 2024 09:20:34 +0100 Simon McVittie wrote: > Package: systemd > Version: 256.4-2 > Severity: normal > Forwarded: https://github.com/systemd/systemd/issues/29860 The linked issue already says it all, this is an issue in podman. Do you want to reassign this, or should I just close it? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1077764: Call for votes: don't issue any ruling
On Wed, 7 Aug 2024 at 16:57, Christoph Berg wrote: > > Re: Luca Boccassi > > > BEGIN BALLOT > > > > > > The Technical Committee declines to overrule the maintainer of > > > base-files, or issue any advice on issues concerning /etc/os-release. > > > > > > We do not think there is a clear proposal on the table for us to assess, > > > and we do not think it is appropriate to issue any general statements on > > > the issues concerning /etc/os-release. > > > > Seriously? In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#368 > > you say that you could rule on the general statement rather than a > > specific implementation, then I answer "I'd prefer that if it was > > possible", and this is how you respond? I've asked multiple times > > exactly what it is that you need in order to make a decision, and all > > I get in response are first cryptic and contradicting statements, and > > then this abrupt dismissal. This seriously feels like something out of > > Kafka novel. > > I vote A > N. > > Luca: people would be much more likely to act positively on your > requests if you wouldn't call them Kafkaesque. I described the experience of this process as kafkaesque as a response to the dismissal, not before it, so unless it went through a mail relay in Winden that seems unlikely, among other things because of the principle of causality. And I think describing as kafkaesque the experience of being told "Yeah we can do X" ---> "You will now be punished for asking to do X" seems quite charitable to me as a description. Ironically, telling me the dismissal is because of this even though it happened before makes it feel even _more_ kafkaesque. I still haven't got the faintest clue what exactly is that you need in a proposal to consider it. I even thought about providing references and documentation for how other distributions with similar bodies provide a much more well defined engineering process for such proposals, so that even mere mortals like myself can actually understand it and use it productively, as a possible source of inspiration for constructive feedback, but what's the point? It's just going to go into /dev/null anyway. My takeway from this whole thing is that it's a waste of time to reach out to the TC, and it's best to just ignore it. Live and learn, I suppose.
Bug#1078157: systemd: Backport pid1: only add a Wants= type dependency on /tmp when PrivateTmp=yes
Control: tags -1 wontfix Control: close -1 On Wed, 07 Aug 2024 13:11:42 + Bastien =?ISO-8859-1?Q?Roucari=E8s?= wrote: > Package: systemd > Version: 247.3-7+deb11u5 > Severity: important > Tags: patch upstream jessie stretch buster bullseye > Forwarded: https://github.com/systemd/systemd/commit/b2c7d1bbc2 > > Dear Maintainer, > > Without this commit autopkgtest on salsa are broken. > > See for instance > https://salsa.debian.org/apache-team/apache2/-/jobs/5960590 > > Can you consider to release a PU release this patch ? > > I can do the work. > > It breaks your testing infrastructure, particularly for testing daemon, particularly security update testing. As mentioned on IRC, I am not very comfortable with shipping code changes in oldstable at this point in time for a specific corner case that only happens due to a particular setup in a particular container environment. Also as mentioned, this is only a problem for units that set PrivateTmp=yes, so what the autopkgtest branch for that affected package can do is add a drop-in in /run/systemd/system/foo.service.d/disabletmp.conf with: [Service] PrivateTmp=yes and do a daemon-reload at the beginning of the test case, and the problem should be bypassed. If the unit really needs an individual tmpdir, you can also add: TemporaryFileSystem=/tmp Which is very similar but doesn't add a dependency on the host's tmp.mount Hence I am closing for now. If it turns out that there are hundreds of packages affected that need to run tests on bullseye in salsa-ci and are also using PrivateTmp and it's impractical to add workarounds everywhere we can reconsider, but if it's just a handful and the workaround works, please use that instead, so that we can minimize risk. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1078115: azure-cli - fails to get access token: User 'X' does not exist in MSAL token cache
Control: severity -1 minor Control: reassign -1 microsoft-authentication-extensions-for-python On Wed, 7 Aug 2024 10:18:59 +0200 Bastian Blank wrote: > Control: severity -1 serious > > On Wed, Aug 07, 2024 at 09:59:06AM +0200, Bastian Blank wrote: > > With a brand new config and after using "az login" to login with exactly > > the mentioned user, this now fails with: > > | % az account get-access-token > > | User 'wa...@spi-inc.org' does not exist in MSAL token cache. Run `az login`. > > | % grep waldi@spi ~/.azure/msal_token_cache.json > > | "username": "wa...@spi-inc.org", > > Okay, this problem is fixed in > https://github.com/AzureAD/microsoft-authentication-extensions-for-python/commit/6fd4920f20ab36263a55ad228c432265f8d2f2eb > and released with python-msal-extensions 1.2.0. What a shitshow. > > In a nut shell: the token cache changed function namens from find to > search. msal_extensions 1.1.0 wraps "find" to actually read the token > cache, but azure-cli uses "search". Sigh they tag their betas as "1.2.0b1" so uscan on ddpo doesn't show that 1.2.0 was actually released and it looked like it was still in beta -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1077764: Ruling request on os-release specification implementation
On Wed, 7 Aug 2024 at 07:54, Sean Whitton wrote: > > Hello, > > On Tue 06 Aug 2024 at 11:45pm +01, Luca Boccassi wrote: > > > It's just a bunch of emails. I have no idea where that is coming from, > > because it's certainly not the intention. Your guess about languages > > is probably accurate. > > Your use of English suggests to me you have native or near-native > fluency, and you said upthread that you live in an English-speaking > country and see yourself as culturally fitting-in. > Therefore, I would ask you to think carefully about whether the problem > may be more subtle than just misunderstandings of English tone. And I would ask you to understand that your statements about processes have misled me into changing this proposal in a way that was against my interest as petitioner. An unfortunate and unintentional misunderstanding with no ill intent behind it I'm sure, but it still happened. Naively, this would appear much more problematic to me than some perceived misunderstandings about unspecified and nebulous "English tone" (?) in a bunch of emails, but most likely being the aggrieved party has something to do with it. A brief summary: Here you said that you could rule on general principles: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#368 Here I reply asking you to please do so if it is possible, changing the proposal to be on general principles: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#388 Here you respond to my request by calling a vote to dismiss the proposal because you don't rule on general principles: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#433
Bug#1077045: systemd 252.29-1~deb12u1 flagged for acceptance
On Wed, 7 Aug 2024 at 06:24, Adam D Barratt wrote: > > package release.debian.org > tags 1077045 = bookworm pending > thanks > > Hi, > > The upload referenced by this bug report has been flagged for acceptance into > the proposed-updates queue for Debian bookworm. > > Thanks for your contribution! > > Upload details > == > > Package: systemd > Version: 252.29-1~deb12u1 > > Explanation: Thanks for processing these - for future cases, do you prefer a single bug that gets renamed as a new version is uploaded, or the same with one separate bug for each separate upload to p-u?
Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 20:53, Marc Haber wrote: > > Hi, > > I am in favor of your request. > > On Tue, Aug 06, 2024 at 05:28:57PM +0100, Luca Boccassi wrote: > > On Tue, 6 Aug 2024 at 16:43, Helmut Grohne wrote: > > > I kindly ask you to stop posting to this bug and mailing list for at > > > least 24h from now. Multiple participants have asked you to improve the > > > way you interact. I am not seeing such improvement and remind you of the > > > Debian Code of Conduct available at > > > https://www.debian.org/code_of_conduct. The way you replied to Wouter is > > > not respectful and it is not appropriate here. Please distance yourself > > > from this matter for a day and reflect. > > > > Please stop trying to conflate highlighting factual inaccuracies with > > "disrespect". There is nothing inappropriate in replying "B is > > happening" to "A is happening", when it's B and not A that is > > happening. > > The problem is not WHAT you are saying, it is HOW you are saying it. In > those discussions (and you are part of a lot of such discussions) you > sound to the casual reader as if you're talking down to somebody you > consider a moron, unable to pull up their own pants in the morning. This > might be a cultural or language issue because English is a foreign > language for both of us, so I am just trying to say how your messages > sound for me. It's just a bunch of emails. I have no idea where that is coming from, because it's certainly not the intention. Your guess about languages is probably accurate.
Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 16:55, Wouter Verhelst wrote: > > On Tue, Aug 06, 2024 at 03:16:49PM +0100, Luca Boccassi wrote: > > On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst wrote: > > > The question is: > > > > > > what is, exactly, the problem that the os-release specification is > > > supposed to solve? And how does unstable and testing being > > > undistinguishable from each other not solve that problem? > > > > > > I have not seen an answer to that question, and it is, I think the > > > central question that we need to see answered. Because that would show > > > what the *benefit* of the os-release specification is, and that would > > > allow the ctte to do a proper cost-benefit analysis of the proposed > > > solutions. > > > > > > While I don't think this is the case, it is of course not entirely > > > impossible that I have missed or overlooked the reply to the question I > > > state above, in which case I apologise and would kindly ask that you > > > point to it. > > > > Yes, I'm afraid you did miss it, as it has been answered multiple > > times. Please re-read replies from myself, Gioele and Marc. > > - Gioele's message is about reimplementing lsb_release in terms of > os-release. As it wants to do largely the same thing as os-release, it > stands to reason that it would have the same problems, but that does > not actually answer the question as to what the problem is you're > trying to solve. Surely the reason that os-release exists is not "so > we have a way to implement the lsb_release script". In fact, if that > were the only reason, then we could do away with os-release entirely, > implement lsb_release for Debian in terms of parsing apt > configuration, and we wouldn't even be having this discussion. It's not, though, because it's the same issue. Quoting verbatim: "My opinion is that by deciding to not ship enough information in /usr/lib/os-release to distinguish between testing and unstable the CTTE is just pushing that same issue into a myriad of other packages." https://lists.debian.org/debian-ctte/2024/08/msg00057.html > - Marc's answer is an example involving managing the life cycle, using > ansible, of various hosts. While that is indeed a real-life example > where something like os-release could be useful, it is not an answer > to the question of what it is, exactly, that os-release is trying to > do. You do not answer a question "what is the problem that X is trying > to solve" by way of "here is one example of things that are easier", > because it is always possible to give a counter-example of things that > would decidedly *not* be easier -- such as managing quality in Debian > in light of packages that change their behavior if they detect that > they're on a different distribution. Yes, the reason for pointing to that response was exactly to answer your question about "benefits", which is something you were looking for. What os-release is for is answered elsewhere, for starters in the very first mail, 4th paragraph: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5 And other responses such as: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#208 Again, I've explained it many times through the thread, please skim it again, as I do not really want to re-write the same things again. > - You gave multiple instances of "people want to do this" without going > into detail as to why. I have written literally walls upon walls of text, among the many things one might say, "not enough details" is really one that I wouldn't have expected > This question matters, because understanding the need is the first step > in understanding why the current situation is suboptimal. > > From my point of view, the need has always been the ability to identify, > with limited detail, what a particular installation contains. I say > "with limited detail", because it can never be complete by way of a > single file; there will always be more details that such a file format > cannot express. But this is sufficient for things like labelling other > installations on the same hardware in a boot menu, remembering what you > were trying to do with that image on the disk somewhere, or various > other cases where a hint as to what an image is could help. And yet because of this bug you can't even do that right now. Am I going to boot trixie or sid in that boot menu? No idea, they have the same label > It can never be more than a hint, however; there is always more detail > to be found. For instance, in the case of Debian stable, os-rele
Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 16:43, Helmut Grohne wrote: > > Hi Luca, > > I kindly ask you to stop posting to this bug and mailing list for at > least 24h from now. Multiple participants have asked you to improve the > way you interact. I am not seeing such improvement and remind you of the > Debian Code of Conduct available at > https://www.debian.org/code_of_conduct. The way you replied to Wouter is > not respectful and it is not appropriate here. Please distance yourself > from this matter for a day and reflect. Please stop trying to conflate highlighting factual inaccuracies with "disrespect". There is nothing inappropriate in replying "B is happening" to "A is happening", when it's B and not A that is happening.
Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst wrote: > > On Tue, Aug 06, 2024 at 10:11:05AM +0100, Luca Boccassi wrote: > > On Tue, 6 Aug 2024 at 09:03, Wouter Verhelst wrote: > > > On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote: > > > > That would make it contradictory with itself and everything else that > > > > uses it, so it's not a change that would be acceptable. > > > > > > Why not? > > > > Because A is A, not B. > > > > > You seem to hold the opinion in this discussion that the os-release > > > specification is perfect and that Debian's implementation of it is > > > wrong and should be corrected and there is no discussion. > > > > > > I'm not saying that's not true, but it does make it more difficult to > > > understand the reasoning. > > > > Nobody said anything is perfect. > > And yet: > > [...] > > You cannot argue that the math book is wrong and Debian is right to > > say that 2+2=5. > > The os-release specification is not a math book. It is an > English-language specification. Specifications like that are not math. In this case it's very much like math. It's a simple assignment, key=value, and it's set wrongly. The fact that it's wrong is not in question. Whether it's acceptable or not for it to be wrong is in question. > It is perfectly viable to accept that certain things are difficult to do > for one distribution, perhaps even too difficult to do, and that > therefore it is not worth doing. But in order to make that call, it is > necessary to know more. Certain things may be, but this isn't one of them. This isn't difficult, it's trivial to do, if one wanted to do it. > > > You want to update the implementation in Debian to more closely match > > > the specification. I and others have asked you what the benefit of this > > > would be, but TTBOMK the answers you have given all essentially boiled > > > down to "because that is what the standard requires", and/or "because > > > people might want to know the difference between the two", without going > > > into detail or providing real-world examples as to why this would be the > > > case. I myself have even given a real-world example, but then it turned > > > out that this was not even a good idea and Helmut Grohne showed me a > > > better way to implement what I needed to do. > > > > Please see (plenty) of other mails. I know there's a lot of noise and > > it takes time to sift through the walls of texts, but that's why I do > > not want to add even more. > > Please do not mistake my disagreement for misunderstanding. > > I have read every mail in this thread. I have perhaps skipped over some > parts of some emails which were going off on a tangent, but I have > definitely read every one of *your* words in this thread. I have also > opened the links to various other sites and bug reports that you have > posted. In short, I *have* done my homework, thank you very much. > > > I added multiple examples, > > I have seen vague handwavy statements of "people might want to do this". > I have seen examples where you explain how a set of commands does not > result in the os-release file having the "correct" contents. Then this homework would get a D- ;-) We _do_ this, already, all the time. There's no "might", I've linked multiple cases where image builders need to do this stuff, and Debian is uniquely a pain. > What I have not seen is *why this matters*, despite asking multiple > times. "Because that is what the os-release spec says" is a circular > non-answer. This has been answered multiple times, by multiple people even. > The question is: > > what is, exactly, the problem that the os-release specification is > supposed to solve? And how does unstable and testing being > undistinguishable from each other not solve that problem? > > I have not seen an answer to that question, and it is, I think the > central question that we need to see answered. Because that would show > what the *benefit* of the os-release specification is, and that would > allow the ctte to do a proper cost-benefit analysis of the proposed > solutions. > > While I don't think this is the case, it is of course not entirely > impossible that I have missed or overlooked the reply to the question I > state above, in which case I apologise and would kindly ask that you > point to it. Yes, I'm afraid you did miss it, as it has been answered multiple times. Please re-read replies from myself, Gioele and Marc. >
Bug#1077764: Call for votes: don't issue any ruling
On Tue, 6 Aug 2024 at 13:36, Sean Whitton wrote: > > Hello, > > I call for votes on the following: > > = > BEGIN BALLOT > > The Technical Committee declines to overrule the maintainer of > base-files, or issue any advice on issues concerning /etc/os-release. > > We do not think there is a clear proposal on the table for us to assess, > and we do not think it is appropriate to issue any general statements on > the issues concerning /etc/os-release. Seriously? In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#368 you say that you could rule on the general statement rather than a specific implementation, then I answer "I'd prefer that if it was possible", and this is how you respond? I've asked multiple times exactly what it is that you need in order to make a decision, and all I get in response are first cryptic and contradicting statements, and then this abrupt dismissal. This seriously feels like something out of Kafka novel.
Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 11:40, Matthew Vernon wrote: > > On 06/08/2024 11:22, Luca Boccassi wrote: > > On Tue, 6 Aug 2024 at 11:10, Matthew Vernon wrote: > >> > >> Hi, > >> > >> On 06/08/2024 10:42, Luca Boccassi wrote: > >> > >>> This is not a hard technical problem with no known solution that we > >>> are asking for design guidance on. This is a trivial technical > >>> problem with a hard social conflict at its core. What we are really > >>> blocked on is that the current owner of os-release refuses to let us > >>> fix it. > >> This is an unfair and inaccurate summary. The policy question of "should > >> testing and unstable be differentiated by os-release" isn't > >> straightforward, and there isn't consensus that the answer should be > >> "yes", as you would like it to be. > > > > But in what way is it inaccurate? > > Your text says (at least as I read it) "the technical problem is easy, > but the os-release maintainer is preventing us from implementing the > otherwise-agreed solution". This is an accusation of poor conduct aimed > at the os-release maintainer. It is not? It means what it says: the technical side is trivial, but there is a social disagreement on what the policy should be, hence the involvement of the CTTE to solve this conflict. If there was agreement then I wouldn't be here, no? Recognizing and expressing that there is a policy disagreement, resulting in a change being blocked, is not an accusation of any kind. > > And same question as I asked Sean earlier - by "consensus" here, do > > you mean that you want to see more people outside of TC members > > chiming in on the policy question? > > No. TC bugs are not popularity contests. My point is that your paragraph > I objected to was claiming that the os-release maintainer was stopping > "us" [presumably meaning Debian] from fixing the bug that os-release > does not differentiate between testing and unstable. No, I did not mean "Debian", I meant people who want to implement this change.
Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 11:37, Helmut Grohne wrote: > > Hi Luca, > > On Tue, Aug 06, 2024 at 10:42:28AM +0100, Luca Boccassi wrote: > > that matters. This is not a hard technical problem with no known > > solution that we are asking for design guidance on. This is a trivial > > technical problem with a hard social conflict at its core. What we are > > That's actually great news. Many of us have perceived this as difficult > to solve on a technical level. Would you mind attaching your > implementation to a mail? For instance you may attach your new source > package (possibly multiple times for different suites) as well as > debdiffs for other related packages (if needed). I was assuming that > asking for this was too much prior to making a decision, but as you say > it is trivial, it is much easier to reason about that code than reason > about what we have now. Yes, I do mind, as explained here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#388
Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 11:26, Matthew Vernon wrote: > > On 06/08/2024 11:22, Luca Boccassi wrote: > > On Tue, 6 Aug 2024 at 11:10, Matthew Vernon > > wrote: > > >> The policy question of "should testing and unstable be > >> differentiated by os-release" isn't straightforward, and there > >> isn't consensus that the answer should be "yes", as you would like > >> it to be. > > >> Debian's current (and long-standing) answer to that question is > >> "no", and my view is that you have not advanced a sufficiently > >> compelling case that this answer should be changed. > > > > Sorry, I don't follow. How is that related to the implementation > > details of how to solve it? > > Well, because if the answer to the question is "no, testing and unstable > should not be differentiated by os-release", then there is no need to > come up with a system whereby they are differentiated. Yes, I agree, that's what I was trying to convey, I guess I wrote it in a confusing way
Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 11:10, Matthew Vernon wrote: > > Hi, > > On 06/08/2024 10:42, Luca Boccassi wrote: > > > This is not a hard technical problem with no known solution that we > > are asking for design guidance on. This is a trivial technical > > problem with a hard social conflict at its core. What we are really > > blocked on is that the current owner of os-release refuses to let us > > fix it. > This is an unfair and inaccurate summary. The policy question of "should > testing and unstable be differentiated by os-release" isn't > straightforward, and there isn't consensus that the answer should be > "yes", as you would like it to be. But in what way is it inaccurate? Are you saying there _is_ a hard technical problem with no known solution somewhere? My point is that I don't think there is one. I understand that the policy question is not straightforward, but that's exactly the point I was trying to convey: nitpicking over how a specific solution looks like is a distraction from the policy question, which is the important part of all of this, and the part that really needs clarification. And same question as I asked Sean earlier - by "consensus" here, do you mean that you want to see more people outside of TC members chiming in on the policy question? Again, I have not publicised this anywhere. I can do that and get more people to chime in, if that's the request. > Debian's current (and long-standing) answer to that question is "no", > and my view is that you have not advanced a sufficiently compelling case > that this answer should be changed. Sorry, I don't follow. How is that related to the implementation details of how to solve it?
Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 04:12, Sean Whitton wrote: > > Hello Gioele, > > On Mon 05 Aug 2024 at 08:34am +02, Gioele Barabucci wrote: > > Couldn't the CTTE just rule on the question: > > > > * should Debian provide a way to distinguish between the two > > similar-but-not-identical, rolling, ephemeral releases called "testing" > > and "staging" via /etc/os-release? > > > > and leave the details of how to implement that decision (dependencies, > > Essential:ye, uploads, releases, etc...) to the involved parties? > > We could. Generally, however, the ctte is designed to break ties > between proposed solutions. If the next thing to be done is design work > to come up with a solution, then it is probably preferable for it to > come back to ctte only after that work has been done. If you _can_ then I'd ask to please do so, so that we can stop getting mired in endless nitpicking about implementation details. The technical side is beyond trivial, it's one line of text to fix, and there's millions of ways to achieve that, some good and easy, some horrible and complex, and all the spectrum in between, some of which were mentioned in this long thread and some that weren't, but none of that matters. This is not a hard technical problem with no known solution that we are asking for design guidance on. This is a trivial technical problem with a hard social conflict at its core. What we are really blocked on is that the current owner of os-release refuses to let us fix it. If you rule on what Gioele said, and the decision is to overrule the block, transferring ownership of os-release if needed, then the people interested in fixing this can actually be empowered to find a way that works in practice to do so and implement it, without the distraction of trying to concoct a solution that feels good and aesthetically appealing in the aseptic, abstract context of an email thread to convince you to vote one way or the other. > And in the meantime, it might be that all parties like the proposed > solution and are happy to have it in the archive, such that ctte > involvement is not required after all. This is not going to happen, as already mentioned various people have tried for at least 12 years to get os-release fixed, one more month or one more year or one more decade is not going to change anything.
Bug#1077764: Ruling request on os-release specification implementation
On Tue, 6 Aug 2024 at 09:03, Wouter Verhelst wrote: > > On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote: > > On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst wrote: > > > > > > On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote: > > > > On Fri, 2 Aug 2024 at 21:29, Helmut Grohne wrote: > > > > > > 2) Testing and unstable can continue to remain indistinguishable, > > > > > > and > > > > > > both be erroneously identified as trixie > > > > > > > > > > Isn't there the third option of adhering to the os-release > > > > > specification > > > > > without making testing and unstable distinguishable? I did not see > > > > > this > > > > > ranked in your preference. Do you see it as even worse than the status > > > > > quo? > > > > > > > > There isn't such option. Adhering to the specification means > > > > identifying them separately, given they can be built separately, ran > > > > separately, managed separately. So the option you are referring to is > > > > for the opposite: _not_ adhering to the specification, and yes, that > > > > is an option. > > > > > > For completion's sake: > > > > > > There is a third option of updating the os-release specification to > > > declare that there is no relevant difference between distributions such > > > as Debian's testing and unstable (for some definition of a class of > > > distributions that would encompass the two) and that it is not necessary > > > for os-release files to distinguish between them. > > > > > > I make no statement as to whether this is a good idea or not, but it is > > > definitely a possibility. > > > > That would make it contradictory with itself and everything else that > > uses it, so it's not a change that would be acceptable. > > Why not? Because A is A, not B. > You seem to hold the opinion in this discussion that the os-release > specification is perfect and that Debian's implementation of it is > wrong and should be corrected and there is no discussion. > > I'm not saying that's not true, but it does make it more difficult to > understand the reasoning. Nobody said anything is perfect. You can check the git history and see that it gets updated from time to time, proving the opposite. However, this doesn't mean that _any_ request is reasonable. This one is not. Debian's implementation in sid is buggy, end of - it says sid is trixie, instead of saying that sid is sid. Again, you can argue that it's fine to leave it buggy - that's ok. You cannot argue that the math book is wrong and Debian is right to say that 2+2=5. > You want to update the implementation in Debian to more closely match > the specification. I and others have asked you what the benefit of this > would be, but TTBOMK the answers you have given all essentially boiled > down to "because that is what the standard requires", and/or "because > people might want to know the difference between the two", without going > into detail or providing real-world examples as to why this would be the > case. I myself have even given a real-world example, but then it turned > out that this was not even a good idea and Helmut Grohne showed me a > better way to implement what I needed to do. Please see (plenty) of other mails. I know there's a lot of noise and it takes time to sift through the walls of texts, but that's why I do not want to add even more. I added multiple examples, others added theirs, there's no point in piling up even more, there's plenty already for the undecided, and those whose minds were already made before even reading the subject line won't bulge anyway. > Given the what we know so far, in my opinion (for as much as that one > holds merit), Debian should declare that we implement the os-release > specification only from the time of the release of our distribution > suites, and that the data in the os-release file before that (i.e., in > our development suites) could be right or could be wrong but that we do > not warrant that it is either way. That's not what happens right now though - the file is there, so it is implemented.
Bug#1077764: Ruling request on os-release specification implementation
On Mon, 5 Aug 2024 at 13:04, Luca Boccassi wrote: > > On Mon, 5 Aug 2024 at 08:42, Helmut Grohne wrote: > > > > Hi Gioele, > > > > On Mon, Aug 05, 2024 at 08:34:41AM +0200, Gioele Barabucci wrote: > > > as the maintainer (and upstream author) of the current lsb_release > > > implementation used in Debian and derivatives (src:lsb-release-minimal), > > > I'd > > > like to voice my support in favor of having enough information in > > > /usr/lib/os-release to be able to tell "testing" and "unstable" apart. > > > > thanks for speaking up. > > > > > Couldn't the CTTE just rule on the question: > > > > > > * should Debian provide a way to distinguish between the two > > > similar-but-not-identical, rolling, ephemeral releases called "testing" > > > and "staging" via /etc/os-release? > > > > > > and leave the details of how to implement that decision (dependencies, > > > Essential:ye, uploads, releases, etc...) to the involved parties? > > > > My understanding of the constitution is that this is not something we > > can rule. Consider 6.3.5: > > > > | The Technical Committee restricts itself to choosing from or adopting > > compromises between solutions and decisions which have been proposed and > > reasonably thoroughly discussed elsewhere. > > > > Leaving these details out of scope of the decision would further > > entrench the conflict as it would be unclear how the responsibility of > > the os-release metadata would be transitioned and I would expect further > > disagreement on that aspect. > > > > The primary method proposed by Luca intends to leverage t-p-u, which has > > been nacked by two release team members. As such selecting that option > > would imply overruling DPL delegates, which also is not a power of the > > CTTE. > > Maybe I'm too optimistic, but again in my reading I do not see vetoes, > I see valid concerns that I believe I responded to. I believe Gioele's > proposal that I adopted meets these criterias: > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u > > Again, if those criterias are incomplete, then I'd ask that > documentation be brought up to date, as this is a generic mechanism, > and having everything needed to use it documented is beneficial for > the project at large, outside of this one instance. And to be clear, of course if RT now replies with something along the lines of "this is an official veto to the use of t-p-u from RT", then I'll pick one of the alternatives that do not involve t-p-u
Bug#1077764: Ruling request on os-release specification implementation
On Mon, 5 Aug 2024 at 08:42, Helmut Grohne wrote: > > Hi Gioele, > > On Mon, Aug 05, 2024 at 08:34:41AM +0200, Gioele Barabucci wrote: > > as the maintainer (and upstream author) of the current lsb_release > > implementation used in Debian and derivatives (src:lsb-release-minimal), I'd > > like to voice my support in favor of having enough information in > > /usr/lib/os-release to be able to tell "testing" and "unstable" apart. > > thanks for speaking up. > > > Couldn't the CTTE just rule on the question: > > > > * should Debian provide a way to distinguish between the two > > similar-but-not-identical, rolling, ephemeral releases called "testing" > > and "staging" via /etc/os-release? > > > > and leave the details of how to implement that decision (dependencies, > > Essential:ye, uploads, releases, etc...) to the involved parties? > > My understanding of the constitution is that this is not something we > can rule. Consider 6.3.5: > > | The Technical Committee restricts itself to choosing from or adopting > compromises between solutions and decisions which have been proposed and > reasonably thoroughly discussed elsewhere. > > Leaving these details out of scope of the decision would further > entrench the conflict as it would be unclear how the responsibility of > the os-release metadata would be transitioned and I would expect further > disagreement on that aspect. > > The primary method proposed by Luca intends to leverage t-p-u, which has > been nacked by two release team members. As such selecting that option > would imply overruling DPL delegates, which also is not a power of the > CTTE. Maybe I'm too optimistic, but again in my reading I do not see vetoes, I see valid concerns that I believe I responded to. I believe Gioele's proposal that I adopted meets these criterias: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u Again, if those criterias are incomplete, then I'd ask that documentation be brought up to date, as this is a generic mechanism, and having everything needed to use it documented is beneficial for the project at large, outside of this one instance. > As I see it, we need a detailed proposal on how you would see this > implemented in order to positively rule on this matter. The level of > detail is debatable, but due to how it affects the essential system I > recommend doing a PoC-level at least. > > Beyond all of this, more recent posts to this thread have made it more > clear to me that the state of /etc/os-release maybe should not only > depend on the suite you pass to debootstrap, but represent an > administrative choice (with a useful default). For instance, I tend to > install laptops as unstable (in order to pick up reasonable hardware > support) and eventually transition them to oldstable (when I plan to > decommission the system after oldstable ends support). It would not be > useful to have these labeled as unstable for the entirety of their use. Such laptop's os-release would say sid when it's running sid and then say when it runs oldstable, so I don't see a problem there? > In order to move this request forward, I see two questions that would > benefit from answers: > * What kind of code behaves differently for testing and unstable beyond >presenting a different string to a user? That's very hard to answer. Right now anybody who looks at testing vs unstable will necessarily ignore os-release, as it doesn't help, and on top of that the addition of VERSION_CODENAME to sid is relatively recent, so in theory nothing should change? But not sure how one could answer that question authoritatively, short of actually uploading and see what happens.
Bug#1077764: Ruling request on os-release specification implementation
On Mon, 5 Aug 2024 at 08:39, Helmut Grohne wrote: > > Hi Luca, > > On Fri, Aug 02, 2024 at 04:17:43PM +0100, Luca Boccassi wrote: > > Validating is of course necessary. If the worry is around changing the > > dependencies of base-files, I would be happy to carry the dependency on > > a new os-release binary package in init-system-helpers, which is > > already Essential: yes. I already did something similar in Bookworm to > > force all installations to become usrmerged, and I do not recall issues > > with the bootstrapping order. This would be even easier in practice as > > the new package would have a single file, no maintainer scripts, no > > dependencies and no build dependencies. Would that solve your concerns? > > No. You need to decide whether /etc/os-release is to be essential or > not. > > If it is, then your proposed dependency in init-system-helpers does not > cut it, because I can simply upgrade base-files before > init-system-helpers and then my /etc/os-release is gone violating Debian > policy. A more reliable mechanism for transitioning essential files is > required. Sure, but violating debian policy is something that happens when it's needed or worth doing, and then it's dealt with if it actually becomes a problem. In _practice_ I doubt that would create actual issues, given it requires manually hold back the update of one but not the other. In practice, a synchronized upload should be more than enough to avoid real issues. This is something that could be established with QA effort once it's implemented as POC.
Bug#1077764: Ruling request on os-release specification implementation
On Mon, 5 Aug 2024 at 09:39, Marc Haber wrote: > > On Mon, Aug 05, 2024 at 09:25:31AM +0100, Simon McVittie wrote: > > * Some package, let's call it foobar, reads os-release and changes its > > behaviour according to whether it sees trixie/testing or unstable > > > > * foobar_1.2-3 is in unstable and works correctly there > > > > * The testing migration scripts let it migrate > > > > * trixie's os-release is different from unstable's (this is the essence > > of what Luca is asking for) > > > > * Unfortunately, when it sees trixie's os-release, foobar_1.2-3 behaves > > incorrectly > > > > * Now our mechanisms to avoid regressions in testing have failed to > > prevent a regression, because the regression was never visible to users > > of unstable, and in fact didn't exist until foobar migrated > > That can happen the same way when a package trips over VERSION and > VERSION_ID suddenly appearing. > > While you have a point here, I think that the current state is an > expression of us valueing our toolchain and processes higher than the > needs of users of testing. By having our development repositories out in > the open we are literally inviting people to use it. In fact, that's an > important part of our QA. We should not make life harder for those > people. That, and also this objection assumes it's impossible to tell them apart right now. It's not, as already shown many times, it just requires to open code annoying Debian-specific workarounds. But if anybody wants, they can do it. I know, because I do it in many places already.
Bug#1077764: Ruling request on os-release specification implementation
On Mon, 5 Aug 2024 at 12:21, Luca Boccassi wrote: > > On Mon, 5 Aug 2024 at 03:15, Sean Whitton wrote: > > > > Hello, > > > > So far, although many people are sympathetic to the frustration at > > distinguishing testing from unstable in practice, I don't believe anyone > > has spoken in favour of overriding Santiago, besides Luca. > > To clarify, do you mean "TC members" here instead of the more generic > "people"? Because there have been a few people speaking in favour, > with varying degrees of enthusiasm. But please note that I have not > publicized this anywhere, so only somebody who follows CTTE's bugs > would have noticed. If you are looking for more people (outside of TC > members) to chime in, I can try and make that happen, but I wasn't > aware this was a requirement. > > > Also, the Release Team aren't happy with Luca's plan, so even if the TC > > were to override Santiago, it might be moot, because the TC can't > > override delegate decisions. > > That is not how I read those messages though? I do not see vetoes. > There were legitimate concerns raised about QA efforts, and manual > efforts, which I think I have answered - at least there hasn't been > any comeback on those answers. > > As far as I can tell, testing-proposed-updates is a fully supported > mechanism, our dev ref even mentions it: > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u > > I believe the change being talked about respects all the points and > requirements listed on that page. If there are more that are not > present there, I would ask that they be documented in the same place - > this would generally be useful, not just for this instance. Also, using t-p-u is only one mechanism, there are more mentioned in another mail. I'd rather not do extra work if a better mechanism is there, but if that cannot be used for any reason, then I would do such extra work and avoid t-p-u. As mentioned before, I am not asking to modify testing/trixie in any way. I am asking to modify sid. If what I propose was implemented right now, trixie would be exactly as it is now. It's sid that would change from VERSION_CODENAME=trixie to VERSION_CODENAME=sid.
Bug#1077764: Ruling request on os-release specification implementation
On Mon, 5 Aug 2024 at 03:15, Sean Whitton wrote: > > Hello, > > So far, although many people are sympathetic to the frustration at > distinguishing testing from unstable in practice, I don't believe anyone > has spoken in favour of overriding Santiago, besides Luca. To clarify, do you mean "TC members" here instead of the more generic "people"? Because there have been a few people speaking in favour, with varying degrees of enthusiasm. But please note that I have not publicized this anywhere, so only somebody who follows CTTE's bugs would have noticed. If you are looking for more people (outside of TC members) to chime in, I can try and make that happen, but I wasn't aware this was a requirement. > Also, the Release Team aren't happy with Luca's plan, so even if the TC > were to override Santiago, it might be moot, because the TC can't > override delegate decisions. That is not how I read those messages though? I do not see vetoes. There were legitimate concerns raised about QA efforts, and manual efforts, which I think I have answered - at least there hasn't been any comeback on those answers. As far as I can tell, testing-proposed-updates is a fully supported mechanism, our dev ref even mentions it: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u I believe the change being talked about respects all the points and requirements listed on that page. If there are more that are not present there, I would ask that they be documented in the same place - this would generally be useful, not just for this instance.
Bug#1077764: Ruling request on os-release specification implementation
On Mon, 5 Aug 2024 at 01:07, Timo Röhling wrote: > > Hi, > > * Luca Boccassi [2024-08-03 16:15]: > >The only question is whether they do that and then say "it's nice > >that we have a common, standard, agnostic way of figuring this out > >and it just works (TM) on Debian too", or, "man this Debian thing > >sure is a gigantic pile of rubbish, it's so painful to deal with it > >as opposed to literally everything else, why do I even bother with > >it". > >[...] > >The only thing you can do as a TC member is decide whether users > >should continue to curse Debian while they do have to open-code bad > >workarounds exclusively for it > Can we please dial down on the hyperbole? This is not some teenage > drama about the Cool Kids stopping to like us if we don't do This > Random Thing, so let's keep it about the technical implications. I assure you this was no hyperbole, but a real-life example. There was lots and lots of cursing involved. > >I just showed you - I have two images, with radically different > >lifecycles, and I cannot tell them apart. I can tell apart any other > >version of any other distribution, not this one. That's a negative > >consequence for me. If you meant to say it's ok for you that there is > >such a negative consequence for me, well, ok, that's not great, but > >fine I guess. But it should be pretty obvious that it is negative for > >me: I am telling you it is. > Can you be a bit more specific about the negative consequences? You > seem to imply that distinguishing testing and unstable images is > desirable just for the sake of it. Yet I cannot (painlessly) > distinguish a Debian image that has been created with debootstrap > from one that has been created with mmdebstrap either, and I'm not > losing sleep about it. The image tool used to build an image doesn't change which release is built. Stamping the image with the origin wouldn't be a bad idea, though - perhaps we should teach our image building tools to take /usr/lib/os-release, and create /etc/os-release (replace the symllink) with it as a base, adding metadata about the image created such as what you suggest. The negative consequences I think were already shown through the thread - not being able to distinguish between a bookworm image and a bullseye image would be a problem, and this is the same. The entire reason os-release exists is to tell you such things, and right now sid is buggy, as it says it's trixie, but it's not. > >If trixie was identified as trixie, and sid was identified as > >unstable, what compromise would be, er, compromised, precisely? > Unstable would become less useful at weeding out bugs in packages > before they reach testing, which is pretty much the main reason for > unstable to exist in the first place. > > Of course, this is not an absolute. Maybe following your proposal > has such a big advantage for Debian and its users that we should > accept this drawback. I just have not seen that argument yet. I'm not sure I follow. Why would that be the case? Why would fixing a line in a text file cause more bugs? Are you assuming it's impossible right now to distinguish testing vs unstable? Because that is most definitely not the case. It is possible, just horrible to do, and requires Debian-specific kludges. But it can, and it routinely is done, with much pain involved. > >The lifecycle is what matters for os-release. This is an extremely > >important distinction and it is crucial here, because this is what > >os-release is about, and this bug is about os-release and its > >implementation, not about generic ideas. > I understand why this distinction is important for the os-release > spec, but that does not automatically make it important for Debian > users as well. Let me concede that people tend to use testing and > unstable as if they were official Debian releases. So what would be > a workflow that is hampered by the current situation? What do people > *actually* do that makes your proposed change useful to them? I showed some commands and tools that I personally use to identify what is this image that I have lying around, in a cross-distro and agnostic way, which doesn't work exclusively for Debian, and works everywhere else. I build a lot of images, and I maintain a fair few image building tools, so this matters to me, and to anybody else doing similar things, and probably much more. The first time this bug was raised was 12 years ago (linked in the first mail), so it's definitely not just me.
Bug#1077937: avahi-daemon: WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended.
On Mon, 5 Aug 2024 at 10:31, Laurent Bigonville wrote: > > On Mon, 05 Aug 2024 00:15:00 +0100 Luca Boccassi wrote: > > > I'm not sure what could be done here, and I don't think anything should > > even if it could. Either don't install/enable both at the same time, or > > disable mDNS in resolved (it's optional). > > The avahi-daemon is pulled by some packages and disabling it completely > will break stuff. > > It seems that Fedora has gone the "disable mDNS support by default in > systemd-resolved" route: > https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_793 > > An other option could be to let avahi-daemon puts a snippet to disable > systemd-resolved mDNS support in /etc/systemd/resolved.conf.d/ > > So what's your preferred way here? I do not want to disable it globally as it's possible to just disable avahi, but if Michael wants to ship a drop-in for resolved in avahi that's fine by me, as the drop-in can be masked locally too
Bug#1077937: avahi-daemon: WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended.
Control: reassign -1 avahi-daemon On Sun, 04 Aug 2024 21:47:25 +0200 Laurent Bigonville wrote: > Package: avahi-daemon > Version: 0.8-13+b2 > Severity: important > X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org > > Hello, > > In the logs I see the following: > *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. *** > > And > > Host name conflict, retrying with -XXX > > I think this is caused by systemd-resolved? > > That should be addressed I guess? I'm not sure what could be done here, and I don't think anything should even if it could. Either don't install/enable both at the same time, or disable mDNS in resolved (it's optional). -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1077764: Ruling request on os-release specification implementation
On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst wrote: > > On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote: > > On Fri, 2 Aug 2024 at 21:29, Helmut Grohne wrote: > > > > 2) Testing and unstable can continue to remain indistinguishable, and > > > > both be erroneously identified as trixie > > > > > > Isn't there the third option of adhering to the os-release specification > > > without making testing and unstable distinguishable? I did not see this > > > ranked in your preference. Do you see it as even worse than the status > > > quo? > > > > There isn't such option. Adhering to the specification means > > identifying them separately, given they can be built separately, ran > > separately, managed separately. So the option you are referring to is > > for the opposite: _not_ adhering to the specification, and yes, that > > is an option. > > For completion's sake: > > There is a third option of updating the os-release specification to > declare that there is no relevant difference between distributions such > as Debian's testing and unstable (for some definition of a class of > distributions that would encompass the two) and that it is not necessary > for os-release files to distinguish between them. > > I make no statement as to whether this is a good idea or not, but it is > definitely a possibility. That would make it contradictory with itself and everything else that uses it, so it's not a change that would be acceptable.
Bug#1077764: Ruling request on os-release specification implementation
On Sun, 4 Aug 2024 at 00:25, Russ Allbery wrote: > > 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. I do have 'stable' in my configuration on this machine, intentionally. It doesn't suddenly become incorrect that os-release says VERSION_ID=12 VERSION_CODENAME=bookworm, because it _is_ bookworm right now. Once the next stable is out, it will be upgraded, os-release included and it will say VERSION_ID=13 and it will still be correct. Same for testing. This is not incompatible at all with os-release, and in fact it works very nicely - it just means "when this reaches the point of flipping to a different stage in the lifecycle, upgrade me to the next version automatically when such process runs next". If you build an image, _of course_ the metadata will be correct at the point in time that image was created, if you don't touch it, it cannot magically change, that's ok, and in no way contradicts anything I've said or anything in the os-release spec, and I don't see how it could - it would be useless if it broke 5 minutes after an image was created. None of this means that bookworm or trixie are rolling releases - they are not, they will both be EOL and need replacements. If you build a testing image or a stable image or an oldstable image you are just taking advantage of aliases to automatically move between different releases when they reach certain points in their lifecycles - we call these 'aliases', correctly, which reflects this fact. If you run an upgrade workflow, however that might look like, the content will change - that's ok! It's the point of doing upgrades. If it's configured to do so, it will be a different release after the upgrade, and its new metadata will reflect that. What it could use to make it even more useful, is adding SUPPORT_END= and RELEASE_TYPE= so that I can get extra information out of it - however, these are cherries on top. And I don't _think_ we have fixed EOL dates that can be set pre-emptively, while other distros do, so it would have to be added on EOL date which is less useful, but perhaps worth considering nonetheless. Again, not a deal breaker. > > 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. Already explained above how this can and does work.
Bug#1077764: Ruling request on os-release specification implementation
On Sat, 3 Aug 2024 at 19:28, Wouter Verhelst wrote: > > On Fri, Aug 02, 2024 at 11:35:54AM +0100, Luca Boccassi wrote: > > Testing and unstable have completely separate and independent > > archives, you can point an image builder to one OR the other, in > > isolation, and it will produce a fully complete and runnable and > > bootable OS tree. The fact that they might have some or even all > > content in common at particular points in time is orthogonal and > > unrelated to what the purpose of os-release is. > > I suspect this is the crux of your problem. Perhaps it might be useful > to explain what "the purpose of os-release" is, exactly? I suspect that > most people here see testing as more similar to unstable than not, and > in order for us to find common ground, understanding *why* this matters > for os-release might be useful. I mentioned this a few times through the thread, but there now are walls upon walls of text, so it's worth repeating as it's very likely that it's lost in this miasma of words. 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. A sid image will never become stable, will never gain security support, will never pass to the LTS team, will never go EOL, such installation was always sid, continues to be sid now, will always be sid. It is a rolling release, because it has no beginning and no end, and an installed image simply carries on. Thus the lifecycles of a sid image and a trixie image are radically distinct and separate. They can be created individually and separately, they can be used individually and separately. They take different paths through time. 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. The fact that content might be similar at some point in time is irrelevant for os-release, oldstable and stable also have some packages that are identical bit-by-bit and it doesn't matter at all: lifecycles are what matters, content does not.
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 21:29, Helmut Grohne wrote: > > Hi Luca, > > On Fri, Aug 02, 2024 at 01:43:04AM +0100, Luca Boccassi wrote: > > 1) The os-release specification must be adhered to, and it must be > > possible to tell the difference between testing vs unstable, and each > > must be correctly identified by the respective metadata > > Given the state of discussion, I think it is fairly evident that we do > not have consensus for the need to distinguish testing and unstable. We > have people arguing in favour and we have people arguing against that. > This is a point of disagreement. I'm not sure "consensus for the need" is the right term here? People obviously _do_ what I am speaking of. There might not be consensus that's it's a good idea to do it, but it still happens, and it will continue to happen, regardless of what is decided here. People do need to distinguish it, whether the TC rules that it should be easy to do so like in any other distro, or whether it rules that it will continue to require annoying Debian-specific kludges, won't change this fact. > > 2) Testing and unstable can continue to remain indistinguishable, and > > both be erroneously identified as trixie > > Isn't there the third option of adhering to the os-release specification > without making testing and unstable distinguishable? I did not see this > ranked in your preference. Do you see it as even worse than the status > quo? There isn't such option. Adhering to the specification means identifying them separately, given they can be built separately, ran separately, managed separately. So the option you are referring to is for the opposite: _not_ adhering to the specification, and yes, that is an option. Well, I guess there could be yet another option: stop making it possible to create either testing or unstable images separately in the first place, just like you cannot create a stable-proposed image. > > Sorry but I do not think that is an accurate representation. First of > > all, the implementation of the spec is bugged, period - it's not about > > being pedantic about it, it's about being completely incompatible: sid > > is identified as trixie, and that is just plain wrong, and there's no > > room for interpretation, no matter how one might try to bend it. You > > might say that you don't _care_ that the implementation is buggy, you > > might even say that it is worth, nay _good_ it to leave it buggy - but > > buggy it is, if I create a sid image, it will never in a million years > > be trixie, and yet it says it's trixie. > > I think it has become abundantly clear that your view on this does not > represent consensus of discussion participants. It is not as black and > white as you paint it. Simon compared unstable to Ubuntu's proposed > pocket. It also happens that testing and unstable share the same pool > hierarchy and the vast majority of packages. On the other hand, Devuan > operates as an overlay repository to be added on top of a Debian > repository. I don't think it matters that Ubuntu's proposed is > implemented as a partial distribution overlaid onto another as that's > what other derivatives (that do update their os-release file) do as > well. Sure, there's no consensus on the solution, that's obvious otherwise I would not have needed to open this in the first place, right? There are some things that require opinions to converge - should this bug be fixed? - and there are some things that just are - people create and manage and run sid and trixie images independently, the implementation of the spec in sid is buggy. These last two statements do not need consensus, they are facts. Deciding what to do based on those facts requires consensus on the solution to adopt, if any. The example of Ubuntu's proposed pocket is wrong as already mentioned, from the point of view of the os-release specification, which is what matters here. You cannot create an ubuntu-proposed image without the full release, so os-release is not concerned with it, and doesn't mandate anything in particular. os-release concerns images that have a lifecycle and their identification. Trixie has a lifecycle: it started as a development release, it will be declared stable and start receiving security support, it will move to ELTS, it will go EOL. sid will not do any of these things, its lifecycle is entirely and completely separate, it will always be sid, it will never be security supported, it will never go EOL, and it is a rolling release. Once more for those at the back: the _content_ is irrelevant, it can be fixed, it can change a lot, it can be the same as different releases, it can be partially the same, it can be completely different, it doesn't matter one bit. The lifecycl
Bug#1077764: Ruling request on os-release specification implementation
On Sat, 3 Aug 2024 at 12:39, Sebastian Ramacher wrote: > > On 2024-08-03 12:20:09 +0200, Paul Gevers wrote: > > Hi > > > > On 03-08-2024 11:58, Luca Boccassi wrote: > > > > On the use of tpu: > > > > Personally, until now I fail to see enough value of being able to > > > > distinguish unstable and testing to give the package carrying > > > > /etc/os-release a permanent exception via tpu. > > > > > > Thanks for chiming in - assuming for a moment that it is decided that > > > the change will be implemented, do you see any technical obstacles in > > > using t-p-u as proposed? > > > > The biggest reason I know against using tpu is that it currently isn't > > receiving the same amount of testing (be it automatic (autopkgtest, > > piuparts, in the future reproducibility) or human) as unstable-to-testing > > migrations receive. For the automatic part, that's obviously a solvable > > problem (and already on my todo list for YEARS), but currently not the case. > > It also *always* requires human intervention by the Release Team. Another > > issue issue with tpu is that binNMU'ing is more difficult (I assume that's > > probably not very often relevant in the current case). I recall there are > > more issues with tpu, but I have forgotten them. When I find them, I'll add > > them. > > To add to that: tpu is used for exceptional cases only. Cases where we > deem the result of the upload more important than the additional > work required of a release team member. Cases where we deem RC bugs > potentially introduced by missing QA for tpu uploads less severe than > the issue we are trying to fix in testing. Essentially, if it is not a > critical bug (think xz incident critical), going through tpu during non-freeze > time never happens. > > For a package that is part of the essential set, having all the QA tools > checking the consequences of the inclusion of this a package is really > essential. Skipping out on QA checks for an essential packages that > would normally run for typical unstable to testing migration puts even > more pressure on the release team to make sure that accepting the > package from tpu does not severly break testing. > > (As side note: in essentially all cases where I handled tpu uploads > (that I remember) during non-freeze time, it was more effort to untangle > unstable so I have asked maintainers explicitly to perform tpu uploads.) In the generic case, sure, I see all of that making perfect sense. This though is about one very specific and narrow case: an arch: all package with a single, fixed and inert text file, that differs by one line. No maintainer scripts that run on install/upgrades and could fail, no programs that run on install, no dependencies that might not be available or installable, one reverse dependency for one cycle to ensure installation in existing images and then it will be removed. And it's one upload at the beginning of a cycle, and then it stays as-is for 2 years until the next, so there is no continued effort nor need to watch it. At each cycle there is a lot of work to do to prepare the next testing pocket I imagine - creating new aliases and whatnot, so in the context of that and compared to the size of that work, this appears to me as a minor addition, no? Which is not to say it's nil or doesn't require any effort ofc. The QA effort I see is: diffoscope old.deb new.deb and verify the difference is only in the changelog entry and the VERSION_CODENAME= field. For this specific and precise use case, do you see the requirement for any other QA effort on top of this, and if so could you please clarify what it would entail? > Also, we have been pushing to keep testing and unstable as close as > possible. Packages not migrating for some time are considered RC buggy > to reduce the difference and where Paaul is thankfully filing the > corresponding bugs. Going through tpu would essentially introduce a > package that is auto-RC buggy in the essential set with consequences: it > causes even more divergence for autopkgtests in testing (reference > tests), in testing + pinned packages from unstable for migration checks > and in unstable. That would cause potentially even more work (for the RT > and maintainers) to figure out why some test is failing in one > configuration and not the other. I deal with fairly complex autopkgtest in debci all the time, for systemd and related packages. The differences between testing and unstable at any given time are so massive due to things like the kernel having a fast development and upload cycle with lots of point releases, a one line difference in one text file seems extremely minor compared to the mountain of other things that are ongoing
Bug#1077764: Ruling request on os-release specification implementation
On Sat, 3 Aug 2024 at 11:20, Paul Gevers wrote: > > Hi > > On 03-08-2024 11:58, Luca Boccassi wrote: > >> On the use of tpu: > >> Personally, until now I fail to see enough value of being able to > >> distinguish unstable and testing to give the package carrying > >> /etc/os-release a permanent exception via tpu. > > > > Thanks for chiming in - assuming for a moment that it is decided that > > the change will be implemented, do you see any technical obstacles in > > using t-p-u as proposed? > > The biggest reason I know against using tpu is that it currently isn't > receiving the same amount of testing (be it automatic (autopkgtest, > piuparts, in the future reproducibility) or human) as > unstable-to-testing migrations receive. For the automatic part, that's > obviously a solvable problem (and already on my todo list for YEARS), > but currently not the case. It also *always* requires human intervention > by the Release Team. Another issue issue with tpu is that binNMU'ing is > more difficult (I assume that's probably not very often relevant in the > current case). I recall there are more issues with tpu, but I have > forgotten them. When I find them, I'll add them. Thank you. For this particular case: there would be 2 uploads for every cycle, one at the end to add version numbers (this already happens, no?), one at the beginning to change the VERSION_CODENAME. I think from the point of view of requiring manual labour it should be pretty lightweight compared to the current workload of managing stable-p-u, at 2 uploads to review once every ~2 years, right? For the binNMU side, this would be an Architecture: all package, so it doesn't apply I think, right? It wouldn't be subject to any binary transition for library bumps or things like that. In the current proposal I am putting forward it's a binary arch: all with a single fixed arch-independent text file in /usr/lib/ and a single fixed symlink in /etc/ to the file in /usr/lib, no maintainer scripts whatsoever, no dependencies.
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 21:06, Sam Hartman wrote: > > >>>>> "Luca" == Luca Boccassi writes: > > Luca> On Fri, 2 Aug 2024 at 13:00, Simon McVittie wrote: > >> > >> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote: > >> > To further clarify why the status quo with > >> VERSION_CODENAME=trixie in > sid is really bad: it used to be > >> that if you had "debian" mentioned in > os-release but no other > >> version identifying fields, you knew you were > on testing OR > >> unstable and you'd have to deploy horrendous hacks to > attempt > >> and figure out which of the two it was really. > >> > >> OK, I think this is progress: > >> > >> What is the scenario / use-case in which it becomes necessary to > >> distinguish between those two suites? > >> > >> To put that another way, what external piece of software needs to > >> change its behaviour, dependent on whether you are running > >> testing (of an unspecified datestamp) or unstable (of an > >> unspecified datestamp)? > >> > >> Or perhaps you are thinking of a scenario in which a *person* > >> needs to change their behaviour, dependent on whether they are > >> running testing or unstable? > > Luca> Are the examples I provided at: > > Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43 > Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5 > > Not to me. > I read what I think is the examples you linked from both bug reports. > I didn't dig too far into the github links you provided though. > What I see from your mail is that people want to distinguish unstable > from testing and have created various hacks to do so. > > What I do not see is a compelling explanation of why Debian as a project > wants to encourage that distinction. > I agree that people doing a thing is evidence that it has value to those > people. > But I do not think you provided an explanation of what that value is. > > If it were easy to distinguish testing from unstable, why would I want > to do that? I don't see any of this being about "encouraging", because, as mentioned in a previous mail, this is already how things work, and it doesn't need any encouraging. It's about simply recognizing that this is how everything already works, and changing 5 characters in a text file that will have no repercussion on how these are used. Because once again, I can do: debootstrap trixie foo debootstrap sid bar foo and bar are different images, with different policies and different lifecycles. foo is currently in development, will freeze and then become stable and security supported, and then move to LTS, and then be EOL. It is a development-to-stable-to-eol image. bar will continue being a development image, will never freeze, will never become security supported, will never become LTS, will never be EOL. It is a rolling image. These details are what os-release is about, if you read the spec, there are tons of fields about lifecycle management of an image, with support and so on. I am not describing a proposal here, I am describing how things work and have always worked. If you are asking me _why_ other people use the above how they use them, well, I don't know? Unfortunately I left my Cerebro helmet in my other coat. What I can do is show that it happens, it's always happened, and it will very likely continue to happen. And what I am highlighting is that we are the only distro that makes it hard to do it, and I am highlighting that a specification (that I am one of the owners of) is implemented incorrectly since it says A is B. And I am asking to fix it so that A says it's A instead, and B continues to say it's B as it does today. I can say why _I_ do it though: because I regularly build and manage multiple images, and I can correctly identify all of them based on standard distro-agnostic tooling, but not Debian unstable, which is the _only_ exception that requires annoying kludges to be used.
Bug#1077764: Ruling request on os-release specification implementation
On Sat, 3 Aug 2024 at 10:51, Paul Gevers wrote: > > Hi, > > [Release Team member hat on, but I only voice my opinion as a member]. > > On the use of tpu: > Personally, until now I fail to see enough value of being able to > distinguish unstable and testing to give the package carrying > /etc/os-release a permanent exception via tpu. Thanks for chiming in - assuming for a moment that it is decided that the change will be implemented, do you see any technical obstacles in using t-p-u as proposed? > On Debian version numbers: > I my view we only assign version numbers the moment we release. You can > see that reflected in the symlink layout of debian/dists and in the > trixie/Release file. Understood, thanks for providing that additional information - then as mentioned in another reply, I am changing the request from what it was originally stated in the initial email that opened the bug, and I do not request that version numbers be added to testing. The implementation I am then requesting to rule on is defined in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43 and, in practice, results only in a change to unstable, testing's content will remain as it currently is, with no change at all.
Bug#1077764: Ruling request on os-release specification implementation
On Sat, 3 Aug 2024 at 05:23, Sean Whitton wrote: > > Hello, > > Luca is the upstream maintainer of the specification, but whether and > how the specification as published applies to Debian is not simply up to > his assertion. To be really really precise, what I asserted is that the implementation is currently buggy in unstable, which is technically correct. I then _ask_ for a ruling to change the implementation. As already mentioned many times in other mails, one is perfectly allowed to say "this bug should not be fixed", "this bug's severity is nil", but not to say "this bug does not exist". To repeat the same example, if os-release was a program asserting on the state, it would run correctly on testing, and it would crash when run in unstable. One can say it's wrong that it crashes and one wants the state to remain as-is, but one can't say it doesn't crash, because it is a fact that it does, not an opinion. Both of these things can happen at the same time and be both true: the TC rules that the os-release file in unstable will remain as-is, and os-release implementation in Debian is buggy. A bug report can be closed by an upload that changes something, or by a close+wontfix. > The TC is being asked to override how Santiago has determined the > specification applies to Debian. > The Release Team's opinion is as relevant as Santiago's, I think. Everybody is welcomed to chime in at any time, and I have already said so on RT's IRC channel the other day just after opening this bug. On the matter of formal ownership however, I want to highlight that, as you can see in various replies detailing the precise technical solution that could possibly be implemented, there are _no changes to testing_ being proposed here, in case what you are worried about here is ownership of testing and changes to it. The only change would be in unstable, and as far as I understand (I might be wrong, please correct me) RT owns testing and [old]stable, not unstable. If you want to ensure the owner of the relevant area is directly involved, then perhaps it's the FTP team that should be, since as far as I understand they are the owners of unstable (might be wrong here too)? Again, everyone's welcome to chime in at any time, just trying to clarify who's responsible for what here. > Here is how it seems to me: > > - the specification applies cleanly to our stable releases, and we > want to support it, so we ship the appropriate metadata > > - it applies to testing during the later stages of the freeze, and > indeed we ship correct metadata at that time > > - it does not apply to testing the rest of the time, and it never > applies to unstable. We ship metadata, but only as a side-effect of > our process for preparing stable releases. > > If this is right, then the goal should not be to ship correct metadata > in testing and unstable, because that's impossible. > The goal should simply be to make whatever we ship in testing and > unstable relatively unobtrusive to users. If I understand correctly what you mean by "apply" here, and you mean in terms of the specification and what it is meant for, then as one of the owners of the spec I can say with certainty that the spec applies to testing and unstable, at any time. There is nothing incompatible with the way testing and unstable exist, are created, handled, maintained, used or anything else, and they are nothing "special" compared to other distributions, other than in the fact that the spec is not implemented correctly in unstable. There should not be any doubt on any of this, solely from the point of view of what the specification is for and what its goals are. One can of course disagree on whether it should be implemented as such and where, which is what is happening right now. If you mean it in terms of what is currently implemented in Debian, then that's also inaccurate: the spec is currently correctly implemented in testing, where it says VERSION_CODENAME=trixie at all times. It is incorrectly implemented in unstable, since also there it says VERSION_CODENAME=trixie, which makes it buggy, as sid is obviously not trixie, and that's the main change I am asking to implement. I'll note again that it is perfectly ok to omit VERSION_ID until release time, and in one of the replies I am clarifying that, if there are reasons to leave it out, it is ok to do so, and I am not asking the CTTE to overrule that. Also, speaking as someone who has worked on image building tools for many years, the current state is extremely intrusive for users, and that's why I am trying to fix it. > Possibly it's less obtrusive to always ship "trixie" in both testing and > unstable, rather than the special "trixie/sid" value. Or maybe not. > Santiago doesn't think so; it would be good to hear why, in this bug. > > I'd also like to note, in response to Luca, that it's misleading to say > that it's a frankendebian to have packages from sid installed on a > testing system, because that's
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 18:01, Russ Allbery wrote: > > 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. If you instantiate it as 'testing', using that keyword through your configuration, including apt, then it will be updated to the next version when that is created in the archive. So it is still trixie today, and tomorrow it will be forky, and everything, including the os-release file, will be updated accordingly with my proposal. >From the point of view of the os-release specification, this is exactly the same as using 'stable' to build and manage an image. Today that is bookworm, yesterday it was buster, tomorrow it will be trixie. It is still correct that today os-release says it's bookworm. Once it is upgraded, the os-release will be upgraded too and say 'trixie' because that's released and that's what the 'stable' alias points to. It's the same installation, and it gets upgraded to a new release - that's entirely supported by the os-release spec. That's the same if you are tracking 'testing'. And that is why in my very first mail at the top of this bug, I said that testing is _not_ a rolling release, because there's a -1 and a +1 and it has a limited lifespan. Support status is different than stable, but there are other fields to indicate that, and again it applies just as well to oldoldoldstable. So again, while I see why there could be different points of views and some confusion around what means what, my view is that this proposal doesn't really introduce anything new, and doesn't change anything that happens today in any fundamental way. As already mentioned, I do not see anything fundamentally incompatible between the os-release concept and the unstable or testing concepts as they are today, whether they are considered with their codenames or the aliases.
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 17:07, Russ Allbery wrote: > > 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. Right, but one important correction though - it's not _only_ apt, it's _also_ apt. Apt is one of the common issues, yes, but it's not the only one. It is entirely valid to create an OS vendor tree without apt or its configuration, for a minimal read-only image deployment for a VM or a container, that you update with an image-based tool with A/B style partitioning, for example. How do you identify such a vendor tree? There's no apt. The answer on every other distro is: read usr/lib/os-release. In Debian it's: read os-release and pray the old gods and the new that it returns something identifiable, and otherwise just despair and take a wild guess. > 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. I see what you are saying, but I have to say that expressing it like that makes it sound like I am asking to flip the thing on its head completely, and do something new and unprecedented, but I'm really not? I am asking to add one line to a text file. I'm not asking to change a policy. Nothing else will change - all workflows, all usages, all intentions, all procedures, all tools, everything will be exactly the same before and after. Because you can already, today, build and install a testing image, run it, update it, manage it, use it for workloads, and never, ever get even a hint that something called "unstable" even exists. We know this happens, and it always has happened, and it will continue to happen. And the same is true for unstable. They each have their own section of the archive, which are independent from each other and fully complete on their own (as opposed to other things already mentioned like ubuntu-proposed or experimental or stable-proposed-updates). You can do 'debootstrap unstable' build an image and run it, you can do 'debootstrap trixie' build an image and run it, and you were always able to do so. So, I don't know, it seems excessive and scary to say it's a change in policy? No policy changes here, no? > > 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 s
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 08:22:55 +0200 Helmut Grohne wrote: > Hi Russ, > > Let me adress the essential/bootstrap aspects of this sub-discussion > only. > > On Thu, Aug 01, 2024 at 08:00:40PM -0700, Russ Allbery wrote: > > Given that it's included in base-files now and base-files is essential, I > > believe it has to continue to be provided by an essential package, unless > > we want to try to do the work of figuring out if os-release can be removed > > from essential (and I would not be eager to do that). > > I concur. > > > Since it is part of the essential set, though, I'm not sure the dependency > > from base-files is actually needed (but also it may not really matter). I > > think dependencies between essential packages are only really used during > > the bootstrapping phase, and presumably os-release is not needed by > > bootstrapping. > > It actually is the other way round. debootstrap-like tools will > automatically pick up all packages marked with "Essential: yes". > Bootstrapped systems will not magically install newly essential packages > though. So doing an upload of base-files that releases /etc/os- release > will not magically cause a newly essential os-release package to be > installed and thus our essential promise of /etc/os-release may be > temporarily broken. (There is no implication of how bad breaking this > promise is.) So whenever we want to add a new package to the essential > set, we need some existing essential package to declare a dependency on > that new package for the duration of one release cycle (as we do not > support skip upgrades). > > The obvious candidate to express such a dependency would be base- files > here and that brings us back to the aspects you (Russ) mentioned earlier > regarding the fragility of the bootstrap order related to base-files. > Admittedly, bootstrapping is more empirically solved in Debian than > well-defined. As I attempted clarifying this in Debian policy earlier, > the outcome was to explicitly leave it undefined. If I remember > correctly, randomly ordering the maintainer scripts executed during > filesystem bootstrap makes things fail every now and then and the order > that most tools produce works well enough currently. Any new dependency > inside the essential set poses a risk of perturbing this order that > happens to work by chance. Hence my request to validate the proposed > changes. With luck, things just work, but we better figure out before > we upload to unstable. > > This is not pretty, but it is what we have. And then I see this mostly > as a work item rather than a blocking issue once we agree on the other > matters. Validating is of course necessary. If the worry is around changing the dependencies of base-files, I would be happy to carry the dependency on a new os-release binary package in init-system-helpers, which is already Essential: yes. I already did something similar in Bookworm to force all installations to become usrmerged, and I do not recall issues with the bootstrapping order. This would be even easier in practice as the new package would have a single file, no maintainer scripts, no dependencies and no build dependencies. Would that solve your concerns? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#833256: util-linux: Please use login/passwd implementations provided by util-linux
On Fri, 2 Aug 2024 at 14:51, Chris Hofstaedtler wrote: > > Control: block -1 by 1074394 > > Hi Luca, > > * Luca Boccassi [240802 15:09]: > > What's the state on this? > > Package: login currently provides these separate interfaces: > > * /usr/bin/login > * /usr/bin/newgrp > * /usr/bin/sg > * /usr/sbin/nologin > > For these 4, I need to reread this bug and see if util-linux has > direct replacements. > > * /etc/login.defs > > Getting this out of Package: login is #1074394, added a block. > > > Any chance we can get util-linux's login in > > for trixie? > > Unsure. Lets see if time permits it. > > > Some folks have done a _ton_ of work to make util-linux's > > login work nicely with autologin for containers and VMs with zero guest > > configuration, using systemd credentials over smbios and such things. > > It would be great if we could reap the benefits of this in trixie. > > Is this all already part of Debian's util-linux or will it become > part of a newer release or sth else? It's all part of the latest releases of util-linux and systemd
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 13:00, Simon McVittie wrote: > > On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote: > > To further clarify why the status quo with VERSION_CODENAME=trixie in > > sid is really bad: it used to be that if you had "debian" mentioned in > > os-release but no other version identifying fields, you knew you were > > on testing OR unstable and you'd have to deploy horrendous hacks to > > attempt and figure out which of the two it was really. > > OK, I think this is progress: > > What is the scenario / use-case in which it becomes necessary to > distinguish between those two suites? > > To put that another way, what external piece of software needs to > change its behaviour, dependent on whether you are running testing > (of an unspecified datestamp) or unstable (of an unspecified datestamp)? > > Or perhaps you are thinking of a scenario in which a *person* needs to > change their behaviour, dependent on whether they are running testing > or unstable? Are the examples I provided at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5 enough to answer this question? (I'm trying to avoid copy/pasting the same stuff multiple times in an already long and probably-going-to-be-even-longer thread) > > Sorry, but there's no other way to define this than a bug. > > I would personally characterize it as a potential root cause for bugs, > more than as a bug itself. To me, an example of one of those bugs might > look more like "I run ansible/Puppet/etc. against my test VM, and I > expect it to do a useful thing, but actually it..." (with the buggy result > perhaps being to crash, or to install the wrong package, or something). It's not running code, but we consider mistakes in documentation bugs too, and treat them as such in our tools and processes. A wrong implementation of a specification, that results in wrong text being published, should still qualify as a bug given precedents, even if it's not in itself running code. It might or might not cause other bugs/bad behaviour, but that should be orthogonal.
Bug#833256: util-linux: Please use login/passwd implementations provided by util-linux
On Sun, 3 May 2020 21:19:41 +0200 Chris Hofstaedtler wrote: > Hi Bálint, > > * Bálint Réczey [200503 19:18]: > > I'm now a bit less convinced that the switch its worth the pain of > > getting through the transition, but I'm still not strongly against it. > > > > To move forward I have created a branch where MRs are welcome: > > https://salsa.debian.org/debian/shadow/commits/move-login-to-util-linux . > > Thanks for working on this. I'll try to see what we need to do on > the util-linux side soon. > > > I' have also converted the shadow the package to dh and cleaned up it > > a bit. /etc/securetty is dropped, so we don't have to drop it if the > > move to util-linux finally happens. > > Awesome. Hi Chris, What's the state on this? Any chance we can get util-linux's login in for trixie? Some folks have done a _ton_ of work to make util-linux's login work nicely with autologin for containers and VMs with zero guest configuration, using systemd credentials over smbios and such things. It would be great if we could reap the benefits of this in trixie. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 12:48, Simon McVittie wrote: > > On Fri, 02 Aug 2024 at 11:35:54 +0100, Luca Boccassi wrote: > > VERSION_CODENAME=trixie was added, and the problem as explained is > > that it's present in sid too. So the only identifier we have in sid, > > identifies it as trixie, which is categorically and unequivocally > > wrong. > > When involved in a disagreement, please could you try to make an effort > to understand the point of view of the other side, rather than declaring > them to be categorically and unequivocally wrong? I think that would > lead to fewer people feeling that they're being shouted at and refusing > to engage with you, which is likely to result in more of the changes > you want to see actually being adopted. Some things are viewpoints, and then there are such things as facts. As mentioned in another mail, one is of course allowed to say "it is fine if the os-release implementation in debian is buggy". One can say "the severity of this bug is nil". One can say "it is better if the bug is not solved". One doesn't even have to state a reason for such a belief, and it's perfectly valid nonetheless. That's a viewpoint. It is not a "viewpoint" to say "the os-release implementation in debian is not buggy", because it's not a competing opinion or design choice, it's denying a fact that exists independently of opinions, for reasons already explained at length, that I am not going to repeat yet again. One can disagree on the severity of the bug and think it is nil, one can disagree on whether it should be fixed or how. It is still a bug. Why is it a problem to define it as such? Why is saying "the spec says A, this does B, therefore it's a bug" equivalent to "shouting" or "insulting"? If this was a running program and it checked the state according to the spec and assert on it, it would crash. Whether one holds the view that it would be right or wrong to crash, it would still crash, and there's no point in denying it would, and I don't see how it helps with resolving anything or making any progress. > In this case, I think the two design principles might be: > > - you think of sid as an independent rolling-release distribution in > its own right, an alternative to e.g. Arch Linux, and so you want to > label sid images/containers/chroots/etc. in a way that is consistent > with that point of view; I don't think that's accurate. It's not an opinion that one can run "debootstrap sid", install it, run it, and never ever reach any point in time where that is a stable, security supported os vendor tree that will go EOL and have a version+1. This is a fact. We know for a fact that this happens, today, yesterday and tomorrow, in the real world. It is also a fact that due to this, the os-release specification mandates certain things to be defined in its metadata, that are currently not done today, and that some that are done, shouldn't. It is an opinion that I think this should be fixed, and it is also an opinion that fixing it is more important than other competing concerns. It is an opinion to say that it is better to leave it as-is. > - Santiago thinks of sid as a tool to be used as part of the process of > making our next stable release, an alternative to e.g. Fedora Rawhide, > and wants to label sid images/etc. in a way that is consistent with > *that* point of view That's not an opinion either. It is a fact that sid is a tool used to develop the next stable release. I recognize that fact, and I do not want to change it. My understanding is that Santiago's opinion is that fact is a reason enough to avoid fixing the above issue, because labeling is incompatible with , and because sid and trixie must remain undistinguishable because they are the same thing. It is my opinion that labeling does not impede on the goal of sid being a tool to develop the next stable release, and it is a fact that the os-release specification is not incompatible with this situation, and it is my opinion that we should change this implementation, and it is my opinion that it would not negatively affect sid's purpose and role in our development model, and it is my opinion that trixie and sid should be distinguishable, and it is a fact that trixie and sid being distinguishable would fix a bug in the os-release implementation. > I think that, as a project, we need a lot more willingness to frame > disagreements in terms of "I see your point, but I think my point is > more important", and a lot less "you're just wrong". All of us are > doing our best to make Debian the best possible Free operating system, > even if we don't always agree on precisely what that means. I don't see saying "
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 11:35, Luca Boccassi wrote: > > On Fri, 2 Aug 2024 at 10:15, Simon McVittie wrote: > > So I think Luca really has two distinct change requests here, not just one: > > > > 1. Label testing as Debian 13 starting from the beginning of the trixie > >cycle, and the equivalent for each future cycle > > 2. Label unstable as something that differs from testing > > > > and it would be technically possible to have both, or neither, or accept > > (1.) but reject (2.). > > > > I personally have a lot of sympathy for wanting (1.) - as I said, when > > I'm communicating with developers outside the Debian bubble who don't > > know our processes, I tend to refer to both testing and unstable as some > > sort of prerelease, alpha or preview of Debian 13, because that's close > > enough to true. I am much more hesitant about (2.), because testing and > > unstable are more similar than they are different, and more similar to > > each other than they are to their state 6 months ago. > > 1 is already the case, and actually I am asking to revert that. > VERSION_CODENAME=trixie was added, and the problem as explained is > that it's present in sid too. So the only identifier we have in sid, > identifies it as trixie, which is categorically and unequivocally > wrong. To further clarify why the status quo with VERSION_CODENAME=trixie in sid is really bad: it used to be that if you had "debian" mentioned in os-release but no other version identifying fields, you knew you were on testing OR unstable and you'd have to deploy horrendous hacks to attempt and figure out which of the two it was really. But if you had VERSION_CODENAME, you could just use that, full stop, and everything was sane. Now all these hacks have to be further hacked, and you have to check if you are on Debian, and if you have VERSION_CODENAME, and if you do _not_ have VERSION_ID _then_ you have to discard VERSION_CODENAME, completely ignore it, and then run the previous hacks. Sorry, but there's no other way to define this than a bug. Well, there are many more I could mention, but then Russ would whip out the cane ;-)
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 11:39, Matthew Vernon wrote: > > Hi, > > With my jaunty TC member hat on, I would prefer if issue came to us with > a description of both sides' perspective on the discussion that they > would view as fair. In any case, I hope that Santiago will feel able to > chime in with their perspective. In case that doesn't happen, for reference, his position is articulated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021663#55 and the other linked bugs. > My initial thought is that this is really about whether the base-files > maintainer is correct to have decided that os-release for testing and > unstable should not provide VERSION nor VERSION_ID; that seems to me the > technical policy question, and whether os-release moves into a new > package or not is an implementation detail that flows from that decision? Almost, but not quite - as mentioned in other emails it's actually fine to omit VERSION/VERSION_ID until release time. The main vector to do this distinction is VERSION_CODENAME which is currently set to 'trixie' in both trixie and sid. I am asking the CTTE to rule that testing and unstable must have different VERSION_CODENAME fields in their respective os-release files, that is to say "trixie" and "sid" respectively. It is correct to say that "sid does not have a version", just like Arch or Tumbleweed, so that is not a contentious point. It is acceptable to me to say "trixie does not have a version until release day", although I would prefer it did, because it is sufficient to have VERSION_CODENAME being different for the purpose of this ticket. Please note that older bugs against base-files mention version numbers because VERSION_CODENAME is a later addition to the spec, it appeared in 2016, so VERSION_ID used to be the only way to tell the difference between releases programmatically, so naturally users reporting bugs about being impossible to distinguish testing vs unstable asked for that to be added. It's no longer the case today, so this request is _not_ about overriding the decision to omit VERSION_ID until release date. > I think the submitter's contention against that is that in fact people > do want to be able to differentiate between testing and unstable. I > think they would go further and say that people want to be able to do > this without doing anything more involved than inspecting > /etc/os-release and that Debian should support them in so doing. Yes, this is correct, minus the part about the specific field numeric versions, which is more of a "nice to have" but can still be omitted if, e.g., RT prefers doing so.
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 10:15, Simon McVittie wrote: > The closest equivalent of what Fedora and Ubuntu do would be to label > both testing and unstable as though they were some sort of Debian 13 > prerelease, but not distinguish between the two. But Luca is asking for > unstable images/chroots/installations to be machine-readably different, > even if they happen to contain all of the same packages at the same > versions (other than base-files), and I think that's because unstable > has more users than Ubuntu proposed, and is typically further away from > testing than the gap between Ubuntu proposed and devel. As far as I understand Ubuntu proposed is a partial pocket, like stable-proposed-updates. It doesn't have full content at all times. You cannot debootstrap and install oracular-proposed, you _have_ to include oracular. So it's correctly not identified separately and independently in its os-release, as it doesn't make sense to do so, from the point of view of the os-release specification and its purpose and intent. oracular-proposed will always be oracular, if you clone it now and update it a year on it will still fetch oracular 24.10 content, not 25.04 . Debian sid will remain debian sid forever, if you clone sid today and update it in 2 years time you will not get trixie 13.x. If you clone testing today and update it in 2 years time, you will get trixie 13.x. If you enable bookworm-proposed-updates on bookworm, it's still bookworm. If you enable experimental on sid, it's still sid. Testing and unstable have completely separate and independent archives, you can point an image builder to one OR the other, in isolation, and it will produce a fully complete and runnable and bootable OS tree. The fact that they might have some or even all content in common at particular points in time is orthogonal and unrelated to what the purpose of os-release is. > So I think Luca really has two distinct change requests here, not just one: > > 1. Label testing as Debian 13 starting from the beginning of the trixie >cycle, and the equivalent for each future cycle > 2. Label unstable as something that differs from testing > > and it would be technically possible to have both, or neither, or accept > (1.) but reject (2.). > > I personally have a lot of sympathy for wanting (1.) - as I said, when > I'm communicating with developers outside the Debian bubble who don't > know our processes, I tend to refer to both testing and unstable as some > sort of prerelease, alpha or preview of Debian 13, because that's close > enough to true. I am much more hesitant about (2.), because testing and > unstable are more similar than they are different, and more similar to > each other than they are to their state 6 months ago. 1 is already the case, and actually I am asking to revert that. VERSION_CODENAME=trixie was added, and the problem as explained is that it's present in sid too. So the only identifier we have in sid, identifies it as trixie, which is categorically and unequivocally wrong.
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 10:09, Simon McVittie wrote: > > On Thu, 01 Aug 2024 at 16:54:20 +0100, Luca Boccassi wrote: > > The second [objection from the base-files maintainer] is pushing forward a > > philosophical explanation according to which testing and unstable are > > not actually different images, but they are one and the same (two sides > > of the same coin is the expression used). While that might be true in a > > philosophical sense, this is a practical matter, and it concerns only > > the os-release specification and its implementation. In such context, > > testing and unstable are different and independent images, built from > > different and independent archives of packages. For example, at any > > point in time you can do: > > > > deboostrap testing /tmp/a > > deboostrap unstable /tmp/b > > > > and if your shell history is lost, you have no reliable, stable, > > distro-agnostic way to identify what exactly /tmp/a and /tmp/b are. > > But, let's continue your example: suppose you ran those commands back in > January. Now, 6 months later, run similar commands again: > > debootstrap testing /tmp/c > debootstrap unstable /tmp/d > > With your proposed labelling of testing and unstable as being fundamentally > different, you would have: > > /tmp/a: testing from January, labelled as testing (or trixie or Debian 13) > /tmp/b: unstable from January, labelled as unstable > /tmp/c: testing from July, labelled as testing (or trixie or Debian 13) > /tmp/d: unstable from July, labelled as unstable > > But, contrary to that, the differences between a and b will be relatively > small, and so will the differences between c and d; whereas the differences > between a and c will be large (even though they're both labelled as > testing) and so will the differences between b and d. > > For example, a and b will have glibc 2.37, but c and d will have 2.39, > with whatever behaviour changes have happened in the last 6 months. > Similarly, neither a nor b has been through the t64 transition, but > both c and d have. > > I think the most important fact about all of these chroots is > "it's strictly newer than Debian 12, so expect some behaviour > changes". Precisely how much newer, and precisely which behaviour changes, > is not such a simple question to answer: it depends which package's > behaviour you're interested in, and if you want to answer that question, > the only way is to look at individual packages, so that you can tell > whether they were last updated in January or whether they have been > updated to July's version. If you chroot into /tmp/b after you create /tmp/d, and you update it, you will get content that matches /tmp/d, not /tmp/c (yes yes if you touched /tmp/b in some ways there will be subtle differences, and weird breakages might happen from time to time, but you know what I mean). sid remains sid, it will never be trixie, it will never become released with security support, then move to ELTS, and then go EOL. A particular instance might have some out of date content, but that's true of every OS tree in the universe, but it fundamentally doesn't change its identification from the point of view of os-release. The fact that some content might match the content of other releases doesn't change anything in the specific context of os-release - again it's fine to have a philosophical discussion on what actually constitutes a pipe, but this is not the purpose of this ticket - in fact, we have many many packages that never get rebuilt, and that are bit-by-bit identical from oldoldstable to oldstable to stable to testing to unstable. Does it mean that os-release in bullseye is wrong to identify it as bullseye and should say 'sid' instead, because some packages are identical and indistinguishable between the two? This is trying to ascribe a meaning to os-release that it really doesn't have, and nobody I know of uses it for. Because it doesn't tell you "yes this is exactly up to date at the time you are reading it". It tells you, "this is what this vendor tree was, at the time it was last updated or created", and yes, this is useful and needed information to convey. If you create an Archlinux or a SUSE Tumbleweed vendor tree now, and another one next year, they will be massively different. os-release will still, correctly, say the same thing. Because it is not a statement about updated-ness, it's a statement that captures the identity of a vendor tree at the point in time it was touched. As mentioned already in a separate mail, we actually have optional fields like BUILD_ID where timestamps can be added, if that needs to be tracked. A VERSION_CODENAME doesn't mean content will always be the same - it
Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 04:00, Russ Allbery wrote: > > Luca Boccassi writes: > > > It could be a dependency of something else, or it could be marked as > > essential itself, given the content is a 5 lines text file and a symlink > > it shouldn't be too hard to figure out an acceptable way to ensure it > > ships everywhere. It doesn't have to be related to base-files at all, it > > was just the first thing that came to mind. > > Given that it's included in base-files now and base-files is essential, I > believe it has to continue to be provided by an essential package, unless > we want to try to do the work of figuring out if os-release can be removed > from essential (and I would not be eager to do that). > > Since it is part of the essential set, though, I'm not sure the dependency > from base-files is actually needed (but also it may not really matter). I > think dependencies between essential packages are only really used during > the bootstrapping phase, and presumably os-release is not needed by > bootstrapping. > > Anyway, I haven't done any work in this area of Debian so I'll leave this > for other people with more relevant expertise to comment on. Yeah it really has to be part of the essential set, it's just expected to be there in the minimalest of barest vendor trees. Priority: essential is probably the easiest. > [version numbers] > > The really important part is adding different and separate codenames, so > > that a testing image can be reliably and univocally distinguished from a > > sid image, and VERSION_CODENAME is enough for that, the version number > > is cherry on top. > > Like Santiago, I admit to not finding this use case compelling. Most of > the reasons why I might imagine someone would want to do this sound like > misunderstandings of how Debian works, given that in many cases, excluding > the apt configuration, today's unstable image is next week's testing image > without changing a single byte on disk. In other words, in the cases > where this does make sense, I feel like this desire is usually a proxy for > "what package pool will *new* packages for this image be drawn from," and > using os-release to guess at that information seems at least a bit > questionable. If what someone cares about is apt configuration, it seems > better to get that information from apt directly, not via a fallible proxy > (and maybe we need a better way to do that). 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. apt might not even be installed or configured in an otherwise correct and minimal read-only OS tree. It's not just about your laptop or your server, it's about building, running, stacking and identifying many types of images - bare metal, virtual, container, chroot, you name it. Please see examples in my other email to Helmut. > However, it doesn't seem obviously *bad* to do this either, and I trust > that you have reasons why you think this is important. > > > But this example seems a bit too tortured to me. > > 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? > > And secondly, that same strawman > > straw man (noun) > > 1: a weak or imaginary opposition (such as an argument or adversary) >set up only to be easily confuted > > This is the sort of thing I was talking about when I said insults. I'm > not sure if you're using this term with some non-standard definition > (believable, since I was using this argument in the opposite way from how > one would use a straw man), but the normal implication of calling my > argument a straw man is that I was arguing in bad faith. This comes > across as weird
Bug#1077764: Ruling request on os-release specification implementation
On Thu, 1 Aug 2024 at 22:52, Helmut Grohne wrote: > > Hi Luca, > > On Thu, Aug 01, 2024 at 04:54:20PM +0100, Luca Boccassi wrote: > > This is an escalation requesting a ruling on the matter of several > > base-files bugs around its buggy implementation of the os-release > > specification, the most recent example being #1021663 and other > > instances that I could find with a cursory look being #1008735 and > > #675731. > > I observe that Santiago has replied to each of them with patience and > that he has presented relatable reasons for his choices. > > As you detail later, it seems that the corner stone of your complaint is > that an unstable installation should have VERSION_CODENAME=sid rather > than VERSION_CODENAME=trixie. Do you agree with this characterization? Yes, _and_ testing should have VERSION_CODENAME=trixie at the same time, to be precise. I.e., the very core of the conflict is about whether being able to tell the difference between testing and unstable should be possible following the distro-agnostic os-release specification. > > The TL;DR is a request to override the base-files maintainer, and > > enable moving os-release into a new, independent and separate source > > package, so that these bugs may finally be fixed, and Debian's os- > > release may finally be made compliant with the specification. > > On a process level, the CTTE can only decide among available options. In > this context available roughly equates the existence of a patch (or > source package). Reading multiple bugs, I found disagreement on this > approach, but no code that could be characterized as a reviewable > solution. Well you know this better than me of course, but isn't this also something you can do? Decide between: 1) The os-release specification must be adhered to, and it must be possible to tell the difference between testing vs unstable, and each must be correctly identified by the respective metadata or 2) Testing and unstable can continue to remain indistinguishable, and both be erroneously identified as trixie Again you'll know better than me, but it seems to me rulings were made in the past that were along similar lines (eg: usrmerge) - there wasn't reviewable code there, no? > Another plausible way to interpret your mail is that you really ask the > CTTE to override the base-files maintainer in claiming ownership of > /etc/os-release in the base-files package request releasing the file to > another package. Given that said file has become part of the essential > interface, releasing it is subtle and warrants a more detailed look at > how the take-over is supposed to happen. To me that process is too > sketchy to consider at this time. > > > Numerous attempts were independently made by many different people to > > try and convince the base-files maintainer to fix this issue, the > > oldest one linked above being 12 years ago, and they have all been > > rejected, as recently as today. The only course of action left is > > therefore asking for a CTTE intervention in the matter, as all attempts > > at mediation and negotiation over the years have failed. > > Evidently, there are multiple conflicting requirements that various > parties would like to see implemented. The base-files maintainer has > made a compromise and argued in favour of his position. Said compromise > encompasses an interpretation of the os-release specification that does > not follow it to the letter. Sorry but I do not think that is an accurate representation. First of all, the implementation of the spec is bugged, period - it's not about being pedantic about it, it's about being completely incompatible: sid is identified as trixie, and that is just plain wrong, and there's no room for interpretation, no matter how one might try to bend it. You might say that you don't _care_ that the implementation is buggy, you might even say that it is worth, nay _good_ it to leave it buggy - but buggy it is, if I create a sid image, it will never in a million years be trixie, and yet it says it's trixie. Secondly, I am not even sure what these conflicting requirements actually are? Could you please spell them out? If trixie was identified as trixie, and sid was identified as unstable, what compromise would be, er, compromised, precisely? Because the only practical objections I could find were based on the idea that implementations would be ugly or hard to maintain or so - as already mentioned, I am happy to relieve anybody else and take that hard and ugly maintenance burden for myself. What other actual problem would suddenly appear? What feature or advantage do we leave behind? How are things made worse for our users? > > The os-release specification, of which I am an upstream author and > > maintainer
Bug#1077764: Ruling request on os-release specification implementation
On Thu, 1 Aug 2024 at 20:06, Russ Allbery wrote: > > Luca Boccassi writes: > > > I was about to say that the proposal is in the linked bug, but it has > > disappeared - it could be due to the bugs getting unlinked. Anyway, my > > variant is here: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675731#54 > > Ah, thank you. I think that answers my questions. > > To summarize briefly to ensure that I understand, your proposal is to > separate only this content into a second package, make base-files depend > on it, and then maintain different versions of that package in unstable > and testing. > > There are two technical aspects of this proposal that worry me. > > The first is adding a dependency to base-files. I know people have put a > whole lot of work into pure dependency-based bootstrapping for Debian, but > historically base-files has been very special and posed lots of > interesting complications that are separately handled in lots of different > tools. It could be a dependency of something else, or it could be marked as essential itself, given the content is a 5 lines text file and a symlink it shouldn't be too hard to figure out an acceptable way to ensure it ships everywhere. It doesn't have to be related to base-files at all, it was just the first thing that came to mind. > I do agree with Santiago's desire to maintain base-files as a "normal" > Debian package that gets tested in unstable and propagates to testing, so > if we go down this route, splitting out this data does seem better to me > than maintaining multiple lines of development for base-files itself. > > The second thing that I'm not fond of is giving testing the version number > 13 when we plan on using 13 as the version number for the trixie release. > I fear that if we do that, someone (probably a third-party package > provider) will add some workaround or behavior change for a package based > on that version number for a problem that only ever existed in testing and > that was not in the actual 13 release. I would instead expect testing to > use some version number that is between stable and the version number that > will be assigned to the next release, to reflect that it is likely to > change substantially before Debian makes an actual release 13. The version number is the least important part of the changes - so for example, it could still be omitted until the actual release like it is now. The really important part is adding different and separate codenames, so that a testing image can be reliably and univocally distinguished from a sid image, and VERSION_CODENAME is enough for that, the version number is cherry on top. I still think that trixie is 13 and 13 is trixie, so there's no point in delaying, as that piece of metadata is not going to change, and I think it would be better if "debootstrap trixie" always gave the same identification metadata (barring the release type as per below perhaps) but it's not a crucial matter and it's fine either way, in the end. But this example seems a bit too tortured to me. First, if you add a workaround like that, you would normally do it based on the package version you are working around, or at least that's how I usually do it and see it done. And secondly, that same strawman can be applied to stable, as we do point releases and security uploads. One could see a bug in bookworm and decide to check for VERSION_ID=12 to work around it, even if that bug is later solved in a point release or security update. It is still correct to mark stable as VERSION=12 (without the point release). > (If I were designing this from scratch, I'd give serious thought to using > even version numbers for releases and odd version numbers for testing, > similar to how Perl releases are versioned for very similar reasons. But > that's probably too big of a change for the level of benefit.) > > Presumably the RELEASE_TYPE setting of pre-release is supposed to help > with that, but (a) that variable doesn't seem to be documented in > os-release(5); 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 > (b) the sorts of packagers that I'm worried about are quite > likely to not make subtle distinctions like that, so the version is still > there as a potential foot-gun for people who aren't paying close > attention; and (c) I would argue that calling testing a "pre-release" is > not very accurate, since that applies that the contents are very similar > to the eventual release and are in a relatively late stage of testing. As above, if someone wants to abuse the version to pin thing
Bug#1077764: Ruling request on os-release specification implementation
On Thu, 1 Aug 2024 at 18:33, Russ Allbery wrote: > > 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 was about to say that the proposal is in the linked bug, but it has disappeared - it could be due to the bugs getting unlinked. Anyway, my variant is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675731#54 There was also a slight variant by Gioele, that again I fail to find now and it might be because of the bugs being rearranged, where testing-proposed-updates is used to upload testing-specific content. The TL;DR: ensure that the version of the 'os-release' package with the content for unstable stays in unstable and never migrates, and the version of the 'os-release' package with the content for testing goes to testing either via a quick migration or via testing-proposed-updates. And the exact details on _how_ to manage it are all up for discussion of course, if there are better ideas I'm happy to implement them. The reason for escalating to the CTTE is not the implementation details however, it's a core conflict about the basic concept of os-release itself. > 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. If you 'debootstrap unstable /tmp/a' and then 'cat /tmp/a/usr/lib/os-release' you will see: PRETTY_NAME="Debian GNU/Linux sid" NAME="Debian GNU/Linux" VERSION_CODENAME=sid ID=debian If you instead 'debootstrap testing /tmp/b' and then 'cat /tmt/b/lusr/lib/os-release' you will see: PRETTY_NAME="Debian GNU/Linux 13 (trixie)" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie RELEASE_TYPE=pre-release ID=debian That's it. Of course if what you are saying is that you mix and match a selection of packages from testing and unstable, well that's a frankendebian - you can do that on any release (I have some testing packages pulled in my debian stable laptop right now). So the identification will be as it is right now, it will depend on the version of the package providing the os-release file, which like any other package can be manually overridden, upgraded, downgraded if one really wishes to do so. I could echo "ID=windows 3.1" into my local /etc/os-release and nothing would stop me or fix it until the next stable release. But this doesn't really change the purpose or meaning of the os-release specification and its implementation and purpose. > 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. There are for sure a lot of criticisms of the bugs in base-files, but there are no insults.
Bug#1008735: base-files: os-release and debian_version make testing and unstable indistinguishable
These bugs have now been escalated to the CTTE: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764
Bug#1077764: Ruling request on os-release specification implementation
On Thu, 1 Aug 2024 at 17:32, Christoph Berg wrote: > > Re: Luca Boccassi > > The TL;DR is a request to override the base-files maintainer, and > > enable moving os-release into a new, independent and separate source > > package, so that these bugs may finally be fixed, and Debian's os- > > release may finally be made compliant with the specification. > > If we are fixing that, we should also fix /etc/debian_version in the > same way. I've always been wondering why we don't put better content > into these files. > > (Though I'm not sure the ruling should include the "move to new source > package" part. It could also be fixed inside base-files.) I left that out intentionally, as that is by definition a Debian-specific file and the main goal here is fixing the distro-agnostic metadata issues, and also changing that might affect backward compatibility of existing consumers (not an issue in os-release, as the relevant metadata is either absent or the wrong one is very new). However, I personally do not have a strong opinion one way or the other, and I am happy to do extra work if required.
Bug#1077764: Ruling request on os-release specification implementation
ill be a trixie+1 (forky). The fact that trixie gets a lot of changes in this 2 years development period is orthogonal and independent, and does not qualify it as a rolling distribution, in the context of the os-release specification. In fact, there is a proposal to add an independent os- release field that qualifies a version as "stable", "lts" or in "development", that would be suited to mark testing as such. So it would be entirely appropriate to set VERSION_ID=13 in trixie's os- release right now. It is not appropriate to set VERSION_ID=13 in sid's os-release, now or ever. These issues are not just theoretical, and do not concern mere personal preferences or cleanliness or code quality or ugliness. They cause very real, very actual and very painful grief for Debian users, as evidenced by the multiple independent bugs with multiple independent reporters chiming in, and the multiple ugly hacks that have to be implemented as Debian-specific workarounds (the latest instance of which can be found at https://sources.debian.org/src/systemd/256.4-2/debian/tests/upstream/#L15 ). The base-files maintainer repeatedly, over numerous years, refused to fix these incompatibilities with the specification, citing personal preferences and interpretations, and the latest suggestion as per #1021663 is to override the lsb_releae maintainer and ship again buggy and deprecated lsb_release python scripts to try again to solve the problem in a Debian-specific way, parsing apt's sources.list. The point of a cross-distro specification is to perform its function reliably so that users do not have to employ distro-specific workarounds, so we are currently doing our users a disservice by shipping a buggy implementation, and require them to use deprecated and buggy scripts as workarounds. It would in fact be much better to simply not ship an implementation of os-release at all, rather than implement it wrongly based on reinterpretations. A concrete proposal that I can put forward is to move os-release away from base-files, into a new source+binary package, that can be managed independently, and can be updated to respect the specification it is supposed to follow. base-files ships code in maintainer scripts so requires changes and updates, and using a separate package allows to do only one upload per cycle to set the new metadata. base-files can then depend on this new binary package, which will ship only /usr/lib/os- release, its /etc/os-release symlink and no maintainer script. This package should be team-maintained on Salsa (as opposed as base-files that is individually maintained with no VCS). The os-release installed in sid's images would then be something along those lines: PRETTY_NAME="Debian GNU/Linux sid" NAME="Debian GNU/Linux" VERSION_CODENAME=sid ID=debian And trixie's would be something along those lines: PRETTY_NAME="Debian GNU/Linux 13 (trixie)" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie RELEASE_TYPE=pre-release ID=debian With RELEASE_TYPE= changing to 'lts' immediately before release day. 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. I volunteer to do the work to create and team-maintain the new package, and provide a patch to do the move from base-files. If requested, I am happy to do such work in advance so that you can judge based on something concrete. Thank you for your consideration. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1008735: base-files: os-release and debian_version make testing and unstable indistinguishable
On Thu, 1 Aug 2024 at 14:29, Santiago Vila wrote: > El 21/7/24 a las 11:36, Luca Boccassi escribió: > > There have been many bugs over the years, > > Well, my feeling is quite the opposite: I think there really > have not been so many bugs over the years. The 3 CC'ed ones are the first ones I could find with a cursory look. The sheer amount of Debian-specific ugly hacks that are around because of this bug in base-files speaks volumes. > There is a paragraph in /usr/share/doc/base-files/FAQ saying > testing and unstable are sides of the same coin. Most people > read it and realize that differentiating between testing > and unstable is not such an important issue. In some cases > (read below) it may be even counter-productive and harmful. That FAQ is wrong, at the very least from the point of view of the os-release specification. Once again, you can do: debootstrap unstable a/ debootstrap testing b/ and then you have two different and independent images, running two different and independent sets of packages, from two different and independent archives, and no sensible way to distinguish them. It doesn't matter what you write down in your own FAQ, the specification is what matters. If you want to write a competing specification, with different semantics and contents, and convince other distros to adopt it instead of os-release, feel free to do so. But what base-files ships is not a spec-compliant os-release metadata file, and that's a bug in base-files. > Moreover, for some time, we had a smart "lsb_release" command > which actually looked at the sources.list file (the recommended > approach). That is not the recommended approach, that's a Debian-specific horrendous and fragile hack (hint: you can have _both_ unstable and testing lines in sources.list, with unstable apt-pinned at 1 or so, and then your recommendation falls apart). LSB is dead, and good riddance. We want to reduce these pointless and painful debianism, not make them proliferate. We should promote Debian based on what it's good at, not based on how much of a pain it is to use. > > and this issue keep biting. > > Just fell into it yet again. > > Well, that's vague and imprecise. When reporting bugs, one usually > tells what one did, what one expected, and what one got. > > I guess you simply expected VERSION_CODENAME to be "sid" on a system > running sid, but there are reasons why that's not reasonable or useful > and the FAQ attempts at explaining that. No, I expected to be able to tell if an image I am managing is trixie or sid, and it is impossible to do so reliably. It is a problem that exists only in Debian. > > os-release is the Linux > > standard for identifying images, and we need to make it useful for our > > users for testing and unstable too, not just for stable. > > This is unaccurate in several ways. You say that it's not useful for > testing, but that's not true. Also, you say that we need to make it useful > for unstable. Well, unstable is not a supported distribution, so that > would be at least subject to debate. As an upstream author and maintainer of the os-release specification, I can tell you with absolute certainty that it is in fact accurate. The way base-files generates os-release currently in Debian is bugged, and as per multiple bug reports has always been bugged. The wrong metadata is conveyed to users. This is not a matter of opinions, the spec is very clear. > > Currently in unstable/testing os-release contains: > > > > PRETTY_NAME="Debian GNU/Linux trixie/sid" > > VERSION_CODENAME=trixie > > > > And debian_version contains: > > > > trixie/sid > > > > This is confusing and breaks all the software out there that needs to > > distinguish between releases. > > Well, one might wonder what kind of software needs to differentiate > between testing and unstable. It may be the case that such software > is already broken to begin with. Any software that deals with images, root directories, and whatnot. And the only broken software here is base-files. > If you find the above confusing, there is a very simple explanation: > some fields are to be read by humans, and others are to be read by scripts > and the like. The file debian_version historically reads as trixie/sid > because its contents end up being shown to the end user on login screens, > while the more recent VERSION_CODENAME has the value "trixie", as it's > to be read by scripts which are meant to work in a system running trixie. And it's broken: an unstable image will be identified as "trixie", which is not unstable, it's something different. > [ At this point, I'll omit your split-os-release proposal from this quote, > it was a
Bug#1008735: Bug#675731: base-files: Please add VERSION entry to /etc/os-release for unstable/testing too
On Thu, 1 Aug 2024 at 13:15, Santiago Vila wrote: > > Hello Luca. > > I'm not happy at all that you decided to reopen three different bugs for this, > including this one which was 12 years old (!). > > Sure, the three bugs are "related" but only to a certain point, as they ask > for different things, and I consider them to be different bugs, so please > respect that. > > Bug #1021663, based on its original subject, is the one that best matches > the things you mention now, so that will be where I will address your > concerns. They *ask* for different things, as in, different solutions are brainstormed and proposed. But the underlying problem is the same across all those (and more, actually), which is the title I picked: it is not possible to distinguish a testing image from an unstable image. That's the reason I merged and retitled - while submitters often propose solutions, the thing that matters most is the problem being addressed, and in my view it doesn't make sense to consider the same problem multiple times independently and in isolation. Of course you are entitled to rearrange bugs for your packages as you see fit, so I will not change them any further. > (Please do *not* post the same message again in the other bug, > I will quote if/as needed). Just as you are entitled to rearrange bugs of your packages as you see fit, I am entitled to reply where and how I see fit. If I think some information is worth being associated with multiple issues, I will CC multiple issues. You are free to drop any CC from your own mails of course. > Follows an explanation for bugs #675731 and #1008735. > > This report (#675731) is a request for VERSION and VERSION_ID to be added > for testing and unstable. This is a wontfix because testing and unstable > do not have a version at all, they only have codenames. That has been the > case for at least 25 years, and the Release Managers have always supported > that view. This bug was closed for a good reason. Please do not reopen it > again. And once again, the root cause is not being able to distinguish between the two. The particular fields are one specific suggestion on how to potentially fix that issue, and one that is not correct as you already noted. The underlying problem is still the same though. > Bug #1008735 asks for VERSION, VERSION_ID and VERSION_CODENAME to be added. > Only VERSION_CODENAME may be added from those (see above to see why) and it > was done in version 12.3, so the bug was closed for a good reason. As noted > before, differentiating stable from testing/unstable is a thing and > differentiating testing from unstable is another different thing. Please > do not reopen this bug again. Same as above. Adding VERSION_CODENAME did not solve that problem at all, as it is present in unstable too - in fact, by adding VERSION_CODENAME=trixie to unstable, it made things _worse_, not _better_, as now there is yet another piece of wrong metadata being associated with sid images, that users have to know about and work around manually.
Bug#1076432: systemd: [networkd] incorrect IPv6 address generation
Control: retitle -1 networkd: no option to use lower 64 bits of IPv6-LL address for global addr Control: tags -1 -moreinfo Control: notfound -1 systemd/252.26-1~deb12u2 Control: severity -1 wishlist Control: close -1 As per the upstream ticket, there is nothing incorrect about address generation, simply different expectations. The ticket has been converted in an RFE to implement the missing mode, so closing here as new features are tracked upstream only. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1076432: systemd: [networkd] incorrect IPv6 address generation
On Mon, 29 Jul 2024 at 19:02, Martin-Éric Racine wrote: > > On Tue, 23 Jul 2024 18:15:48 +0100 Luca Boccassi wrote: > > Control: tags -1 upstream > > > > On Tue, 23 Jul 2024 19:45:33 +0300 =?UTF- > > 8?Q?Martin=2D=C3=89ric_Racine?= wrote: > > > Please note that if you only reply to the bug itself, the reporter > > > will never know that you requested more information. > > > > > > On Tue, 16 Jul 2024 11:37:43 +0100 Luca Boccassi > > wrote: > > > > Control: tags -1 moreinfo > > > > > > > > On Tue, 16 Jul 2024 13:29:36 +0300 =?utf-8?q?Martin- > > =C3=89ric_Racine?= > > > > wrote: > > > > > Package: systemd > > > > > Version: 252.26-1~deb12u2 > > > > > Severity: important > > > > > Tags: ipv6 > > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > Hash: SHA256 > > > > > > > > > > I have enabled networkd and created the following > > > > /etc/systemd/network/dhcp.network: > > > > > > > > > > [Match] > > > > > Name=en* wl* > > > > > > > > > > [Network] > > > > > DHCP=yes > > > > > IPv6PrivacyExtensions=yes > > > > > IPv6LinkLocalAddressGenerationMode=stable-privacy > > > > > > > > > > Two issues: > > > > > > > > > > 1) networkd creates a new link address with the stable-privacy > > flag, > > > > in addition to the existing one created by the kernel on bootup. > > > > > 2) Regardless, the stable-privacy flag is not inherited by the > > > > mngtmpaddr address. It steadfastly uses an EUI64 address. > > > > > > > > Can you reproduce in testing/unstable? > > > > > > Yes. It still ignores the fe80 created by the kernel at boottime with > > > the stable-privacy flag, it still creates an additional one, and it > > > still creates a public address with EUI64 instead of stable-privacy. > > > > Ok, then please open an issue upstream, after gathering debug level > > logs (SYSTEMD_LOG_LEVEL=debug env var in networkd) and attach them too, > > and also attach the "ip addr" output > > I have no idea of where to enable debug only for networkd. First result on Google for "how to enable debug logs in systemd-networkd": https://superuser.com/questions/1187633/how-to-debug-systemd-networkd Both methods listed there are correct
Bug#1077204: systemd fails to boot on a 5.4 kernel
On Sun, 28 Jul 2024 at 12:04, Kornilios Kourtis wrote: > > On Sun, Jul 28, 2024 at 11:16:33AM +0100, Luca Boccassi wrote: > > > Booting the kernel. > > > [0.00] Linux version 5.4.280 (root@buildkitsandbox) (gcc > > version 13.2.0 (Ubuntu 13.2.0-23ubuntu4)) #1 SMP Fri Jul 26 13:40:53 > > UTC 2024 > > > > You are running an Ubuntu kernel on Debian? That doesn't make sense and > > it's not supported. You are probably hitting some apparmor denials that > > are blocking some setup step from working: > > > > dev-hugepages.mount: Failed to spawn executor: Argument list too long > > > > Use the Debian kernel from the Debian version you are running, or if > > you want to use an Ubuntu kernel, install Ubuntu instead. > > This is not an ubuntu kernel. It is a custom kernel that we build on our > own (we just happen to build the kernels in ubuntu) and we use them in > our testing pipeline with a debian rootfs. FWIW, 5.4 kernels booted fine > with previous versions of systemd. > > My expectation would be that debian's systemd would be able to boot the > machine even with a custom kernel. Please do not open bugs for issues happening on custom kernels. Only Debian kernels are supported, for anything else you'll have to either figure it out yourself, or pay a contractor to do so.
Bug#1077204: systemd fails to boot on a 5.4 kernel
Control: tags -1 -moreinfo Control: tags -1 wontfix Control: close -1 On Sun, 28 Jul 2024 09:11:34 +0200 Kornilios Kourtis wrote: > On Sat, Jul 27, 2024 at 11:06:08AM +0100, Luca Boccassi wrote: > > On Fri, 26 Jul 2024 22:39:15 +0200 Kornilios Kourtis > > wrote: > > > On Fri, Jul 26, 2024 at 07:09:03PM +0100, Luca Boccassi wrote: > > > > Please set systemd.log_level=debug on the kernel command line and > > > > attach the full debug log output > > > > > > Decompressing Linux... Parsing ELF... Performing relocations... done. > > > Booting the kernel. > > > > You did not enable debug level output > > I've set "debug systemd.log_level=debug systemd.log_target=console" in > the kernel command line, and now I'm seeing more messages. Adding output > below. Please let me know if there is more information I can provide. > > Booting the kernel. > [ 0.00] Linux version 5.4.280 (root@buildkitsandbox) (gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4)) #1 SMP Fri Jul 26 13:40:53 UTC 2024 You are running an Ubuntu kernel on Debian? That doesn't make sense and it's not supported. You are probably hitting some apparmor denials that are blocking some setup step from working: dev-hugepages.mount: Failed to spawn executor: Argument list too long Use the Debian kernel from the Debian version you are running, or if you want to use an Ubuntu kernel, install Ubuntu instead. -- Kind regards, Luca Boccassi
Bug#1077271: systemd broken after 256.4-2 upgrade
Control: severity -1 minor Control: tags -1 unreproducible moreinfo On Sat, 27 Jul 2024 18:16:36 + Richard B wrote: > Jul 27 11:41:44 fw13 systemd[1]: Failed to fork off sandboxing environment > for executing generators: Protocol error > Jul 27 11:41:45 fw13 systemd[1]: Freezing execution. Something on your system is blocking namespaces, you will need to figure out what it is and why -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1051785: workaround
On Fri, 21 Jun 2024 14:55:13 +0100 Simon McVittie wrote: > The intended way to change the settings of the Debian-gdm user is to edit > /etc/gdm3/greeter.dconf-defaults. In this case I think the equivalent would > be to locate the line "[org/gnome/login-screen]" and fill in > "enable-smartcard-authentication=false" below it, so it looks > something like this: > > ... > [org/gnome/login-screen] > enable-smartcard-authentication=false > logo='/usr/share/images/vendor-logos/logo-text-version-64.png' > ... > > And then restart gdm (the easiest/most reliable way is to reboot). I can confirm this works (I too have a yubikey with a cert for unrelated purposes). Previously this was a mere annoyance as it just meant having to type the username manually, which is no big deal. However, since gnome 46 migrated to testing, this actually breaks login completely - after typing the password, the greeter is just stuck there. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1072930: libpam-wtmpdb: sessions not closed after systemd-run --user --machine …@.host
On Sat, 27 Jul 2024 16:50:55 +0200 Chris Hofstaedtler wrote: > Control: reassign -1 src:systemd > Control: affects -1 libpam-wtmpdb > > Luca, > > On Mon, Jun 10, 2024 at 03:26:24PM +0100, Tomas Janousek wrote: > > If I do the following: > > > > $ sudo systemd-run --user -M "$USER"@.host --quiet --wait -- collect --pipe echo foo > > > > then I get an error in the journal: > > > > Jun 10 14:15:08 deb1-wtmpdb systemd[657]: Started run- u7.service - echo foo. > > Jun 10 14:15:08 deb1-wtmpdb (sd-pam)[1297]: pam_unix(login:session): session closed for user debian > > Jun 10 14:15:08 deb1-wtmpdb (sd-pam)[1297]: pam_wtmpdb(login:session): update_logout: Updating logout time did not return SQLITE_DONE: 8 > > > > and the session stays open: > > > > $ last > > debian Mon Jun 10 14:15 - still logged in > > > I'll need your help/insight here. ISTM systemd is restricting what > PAM is allowed to do, but the libpam-wtmpdb cannot really function > without writing to its file. > > How is this supposed to work? > Was there a discussion with wtmpdb upstream? Sorry I am completely clueless about pam, please ask upstream on the mailing list or on a ticket -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1077204: systemd fails to boot on a 5.4 kernel
On Fri, 26 Jul 2024 22:39:15 +0200 Kornilios Kourtis wrote: > On Fri, Jul 26, 2024 at 07:09:03PM +0100, Luca Boccassi wrote: > > Please set systemd.log_level=debug on the kernel command line and > > attach the full debug log output > > Decompressing Linux... Parsing ELF... Performing relocations... done. > Booting the kernel. You did not enable debug level output -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1077204: systemd fails to boot on a 5.4 kernel
Control: tags -1 moreinfo On Fri, 26 Jul 2024 19:59:35 +0200 Kornilios Kourtis wrote: > Package: systemd > Version: 256.4-2 > > Hi, > > systemd fails to boot on 5.4 kernels (other kernels seem to work). The > logs below are from 5.4.280, but trying with older kernels has the same > effect. > > SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.33: No such file or directory > [ 1.136915] systemd[1]: systemd 256.4-2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CU > RL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZST > D +BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE) > [ 1.139048] systemd[1]: Detected virtualization kvm. > [ 1.139402] systemd[1]: Detected architecture x86-64. > > Welcome to Debian GNU/Linux trixie/sid! > > [ 1.140500] systemd[1]: Hostname set to . > [ 1.160170] systemd[1]: bpf-restrict-fs: BPF LSM hook not enabled in the kernel, BPF LSM not supported. > [ 1.169448] systemd-tpm2-ge (89) used greatest stack depth: 14272 bytes left > [ 1.171050] systemd-debug-g (79) used greatest stack depth: 13576 bytes left > [ OK ] Created slice system-getty.slice - Slice /system/getty. > [ OK ] Created slice system-modprobe.slice - Slice /system/modprobe. > [ OK ] Created slice system-serial\x2dget…slice - Slice /system/serial-getty. > [ OK ] Created slice user.slice - User and Session Slice. > [ OK ] Started systemd-ask-password-conso…equests to Console Directory Watch. > [ OK ] Started systemd-ask-password-wall.…d Requests to Wall Directory Watch. > [ OK ] Set up automount proc-sys-fs-binfm…ormats File System Automount Point. > Expecting device dev-ttyS0.device - /dev/ttyS0... > [ OK ] Reached target paths.target - Path Units. > [ OK ] Reached target remote-fs.target - Remote File Systems. > [ OK ] Reached target slices.target - Slice Units. > [ OK ] Reached target swap.target - Swaps. > [ OK ] Reached target timers.target - Timer Units. > [ OK ] Listening on systemd-creds.socket - Credential Encryption/Decryption. > [ OK ] Listening on systemd-initctl.socke…- initctl Compatibility Named Pipe. > [ OK ] Listening on systemd-journald-dev-…socket - Journal Socket (/dev/log). > [ OK ] Listening on systemd-journald.socket - Journal Sockets. > [ OK ] Listening on systemd-networkd.socket - Network Service Netlink Socket. > [ OK ] Listening on systemd-udevd-control.socket - udev Control Socket. > [ OK ] Listening on systemd-udevd-kernel.socket - udev Kernel Socket. > [FAILED] Failed to mount dev-hugepages.mount - Huge Pages File System. > See 'systemctl status dev-hugepages.mount' for details. > [FAILED] Failed to mount dev-mqueue.mount - POSIX Message Queue File System. > See 'systemctl status dev-mqueue.mount' for details. > [FAILED] Failed to mount run-lock.mount - Legacy Locks Directory /run/lock. > See 'systemctl status run-lock.mount' for details. > [FAILED] Failed to mount sys-kernel-debug.mount - Kernel Debug File System. > See 'systemctl status sys-kernel-debug.mount' for details. > [FAILED] Failed to mount sys-kernel-tracing.mount - Kernel Trace File System. > See 'systemctl status sys-kernel-tracing.mount' for details. > [FAILED] Failed to mount tmp.mount - Temporary Directory /tmp. > See 'systemctl status tmp.mount' for details. > [FAILED] Failed to start modprobe@configfs.…vice - Load Kernel Module configfs. > See 'systemctl status modprobe@configfs.service' for details. > ... Please set systemd.log_level=debug on the kernel command line and attach the full debug log output -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1077184: systemd: /etc/sysctl.conf is no longer read
Control: severity -1 wishlist Control: tags -1 wontfix Control: close -1 On Fri, 26 Jul 2024 15:00:17 +0200 Vincent Lefevre wrote: > Package: systemd > Version: 256.4-2 > Severity: grave > Tags: security > Justification: user security hole > X-Debbugs-Cc: Debian Security Team > > The /etc/sysctl.conf file is no longer read, while I have security > settings there. > > I suspect that the cause is > > * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships > /etc/sysctl.conf (Closes: #1076190) > > which is wrong! It is not, create the symlink yourself if you still need it, the procps package dropped it so this package dropped it as well -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1077045: bookworm-pu: package systemd/252.29-1~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org Dear Release Team, We would like to upload the latest stable point release of systemd 252 to bookworm-p-u. Stable release branches are maintained upstream with the intention of providing bug fixes only and no compatibility breakages, and with automated non-trivial CI jobs that also cover Debian and Ubuntu. I have already uploaded to p-u. There are no packaging changes. Debdiff attached. The debdiff excludes hwdb generated IDs. The list of commits included can be seen at: https://github.com/systemd/systemd-stable/compare/v252.28...v252.29 -- Kind regards, Luca Boccassi diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.28/debian/changelog systemd-252.29/debian/changelog --- systemd-252.28/debian/changelog 2024-07-07 11:56:20.0 +0100 +++ systemd-252.29/debian/changelog 2024-07-25 13:49:17.0 +0100 @@ -1,3 +1,9 @@ +systemd (252.29-1~deb12u1) bookworm; urgency=medium + + * New upstream version 252.29 (Closes: #1074789) + + -- Luca Boccassi Thu, 25 Jul 2024 13:49:17 +0100 + systemd (252.28-1~deb12u1) bookworm; urgency=medium * New upstream version 252.28 (Closes: #1074789) diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.28/hwdb.d/meson.build systemd-252.29/hwdb.d/meson.build --- systemd-252.28/hwdb.d/meson.build 2024-07-07 11:52:10.0 +0100 +++ systemd-252.29/hwdb.d/meson.build 2024-07-25 13:45:32.0 +0100 @@ -29,6 +29,7 @@ '70-analyzers.hwdb', '70-av-production.hwdb', '70-cameras.hwdb', +'70-hardware-wallets.hwdb', '70-joystick.hwdb', '70-mouse.hwdb', '70-pda.hwdb', diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.28/man/systemd.service.xml systemd-252.29/man/systemd.service.xml --- systemd-252.28/man/systemd.service.xml 2024-07-07 11:52:10.0 +0100 +++ systemd-252.29/man/systemd.service.xml 2024-07-25 13:45:32.0 +0100 @@ -707,8 +707,8 @@ Configures a maximum time for the service to run. If this is used and the service has been active for longer than the specified time it is terminated and put into a failure state. Note that this setting does not have any effect on Type=oneshot services, as they terminate immediately after -activation completed. Pass infinity (the default) to configure no runtime -limit. +activation completed (use TimeoutStartSec= to limit their activation). +Pass infinity (the default) to configure no runtime limit. If a service of Type=notify sends EXTEND_TIMEOUT_USEC=…, this may cause the runtime to be extended beyond RuntimeMaxSec=. The first receipt of this message diff -Nru --exclude pnp_id_registry.html --exclude acpi_id_registry.html --exclude parse_hwdb.py --exclude acpi_id_registry.csv --exclude pnp_id_registry.csv --exclude usb.ids --exclude pci.ids --exclude ma-large.txt --exclude ma-medium.txt --exclude ma-small.txt --exclude '*hwdb.patch' --exclude '*hwdb' systemd-252.28/man/systemd.unit.xml systemd-252.29/man/systemd.unit.xml --- systemd-252.28/man/systemd.unit.xml 2024-07-07 11:52:10.0 +0100 +++ systemd-252.29/man/systemd.unit.xml 2024-07-25 13:45:32.0 +0100 @@ -165,13 +165,13 @@ section. When the unit is enabled, symlinks will be created for those names, and removed when the unit is disabled. For example, reboot.target specifies Alias=ctrl-alt-del.target, so when enabled, the symlink -/etc/systemd/system/ctrl-alt-del.service pointing to the +/etc/systemd/system/ctrl-alt-del.target pointing to the reboot.target file will be created, and when CtrlAltDel is invoked, -systemd will look for the ctrl-alt-del.service and execute -reboot.service. systemd does not look at the [Install] section at -all during normal operation, so any directives in that section only have an effect through the symlinks -created d
Bug#1076432: systemd: [networkd] incorrect IPv6 address generation
Control: tags -1 upstream On Tue, 23 Jul 2024 19:45:33 +0300 =?UTF- 8?Q?Martin=2D=C3=89ric_Racine?= wrote: > Please note that if you only reply to the bug itself, the reporter > will never know that you requested more information. > > On Tue, 16 Jul 2024 11:37:43 +0100 Luca Boccassi wrote: > > Control: tags -1 moreinfo > > > > On Tue, 16 Jul 2024 13:29:36 +0300 =?utf-8?q?Martin- =C3=89ric_Racine?= > > wrote: > > > Package: systemd > > > Version: 252.26-1~deb12u2 > > > Severity: important > > > Tags: ipv6 > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > I have enabled networkd and created the following > > /etc/systemd/network/dhcp.network: > > > > > > [Match] > > > Name=en* wl* > > > > > > [Network] > > > DHCP=yes > > > IPv6PrivacyExtensions=yes > > > IPv6LinkLocalAddressGenerationMode=stable-privacy > > > > > > Two issues: > > > > > > 1) networkd creates a new link address with the stable-privacy flag, > > in addition to the existing one created by the kernel on bootup. > > > 2) Regardless, the stable-privacy flag is not inherited by the > > mngtmpaddr address. It steadfastly uses an EUI64 address. > > > > Can you reproduce in testing/unstable? > > Yes. It still ignores the fe80 created by the kernel at boottime with > the stable-privacy flag, it still creates an additional one, and it > still creates a public address with EUI64 instead of stable-privacy. Ok, then please open an issue upstream, after gathering debug level logs (SYSTEMD_LOG_LEVEL=debug env var in networkd) and attach them too, and also attach the "ip addr" output -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1076616: systemd-container: Bind mounts not working
Control: tags -1 -moreinfo Control: close -1 The logs are showing what the issues are: /var/lib/machines/debian-sid.nspawn:4: Unknown key 'PrivateUsersChown' in section [Exec], ignoring. Ignoring TemporaryFileSystem=, Bind= and BindReadOnly= settings, file /var/lib/machines/debian-sid.nspawn is not trusted. Ignoring network settings, file /var/lib/machines/debian-sid.nspawn is not trusted. Ignoring PrivateUsers= and PrivateUsersChown= settings, file /var/lib/machines/debian-sid.nspawn is not trusted. One setting is in the wrong section, and others are ignored because of the cmdline used. Please fix the settings and the cmdline and then update the wiki page accordingly. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#675731: base-files: os-release and debian_version make testing and unstable indistinguishable
Hi Santiago, There have been many bugs over the years, and this issue keep biting. Jut fell into it yet again. Please, let's fix this, once and for all. os-release is the Linux standard for identifying images, and we need to make it useful for our users for testing and unstable too, not just for stable. Currently in unstable/testing os-release contains: PRETTY_NAME="Debian GNU/Linux trixie/sid" VERSION_CODENAME=trixie And debian_version contains: trixie/sid This is confusing and breaks all the software out there that needs to distinguish between releases. And yes, they are different releases, as the archives are different and separate. And when we create an unstable or testing image, we choose one OR the other, not both, not either. debootstrap unstable or debootstrap testing Then after creating the image, we lose the ability to figure out which is which, and have to resort to ugly hacks like grepping in /etc/apt/sources.list, praying that it doesn't contain both repositories. This needs to be fixed. Here is a concrete proposal: Move os-release and debian_version to a separate source package, in a separate binary package, that base-files will depend on. At the beginning of a cycle, upload os-release containing, for example: VERSION_CODENAME=trixie PRETTY_NAME="Debian GNU/Linux trixie" and debian_version: trixie Give it urgency=high and let it migrate quickly. Then, upload again immediately, with: VERSION_CODENAME=sid PRETTY_NAME="Debian GNU/Linux sid" and debian_version: sid and file an RC bug on it to stop it from migrating. At the end of the cycle, repeat and add the VERSION_ID and other fields if you want to only add them on release day. With 2 uploads every ~2 years, the problem is solved, unstable can be identified as unstable, and testing can be identified as testing. For ~4 days in a 2 years period, unstable will have a wrong identifier. Compared to the current situation when it is always wrong, we can live with it I am sure. It can be reduced to 2 days and 1 upload if we immediately add the full next-release os-release content at the beginning of the cycle. If you do not have the time to work on the new package, as the upstream maintainer of the os-release spec, I volunteer to take care of it, if you wish it. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#931197: base-files: Include minor version in /etc/os-release
On Mon, 15 Apr 2024 13:19:00 +0200 Santiago Vila wrote: > severity 931197 normal > thanks > > I consider this to be a normal bug, and will try to discuss with Release Managers > to see if we can change it for trixie. As the maintainer of the os-release spec: Ansgar is right, the current setup is correct. Please do not add minor versions or patch versions to VERSION_ID. That field is supposed to identify whether you are on Bookworm or Bullseye or Trixie, not the minor patch levels in between. It would be a bug to change this, and it would break A LOT of parsers that expect just the Debian version. What you can do, is add another field. The spec is intentionally extensible and downstream can add any fields they like, just add a new one prefixed with DEBIAN_ to namespace it, and then you can add whatever you want in it. It could be DEBIAN_VERSION_FULL_ID=12.1 or DEBIAN_VERSION_MINOR_ID=1 or any other combination. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1076616: systemd-container: Bind mounts not working
Control: tags -1 unreproducible moreinfo On Sat, 20 Jul 2024 01:21:45 +0700 Josh Santos wrote: > Package: systemd-container > Version: 252.26-1~deb12u2 > Severity: normal > X-Debbugs-Cc: j...@omnidapps.com > > Dear Maintainer, > * What led up to the situation? > Running a container using nspawn with a bind mount such as is described here: https://wiki.debian.org/Packaging/Pre-Requisites/nspawn > > * What exactly did you do (or not do) that was effective (or > ineffective)? > systemctl start systemd-nspawn@debian-sid > > * What was the outcome of this action? > Launches fine, but bind mount is non-existent. > > * What outcome did you expect instead? > Expected the bind mount to be present > > * Additional context: pirate_praveen on DebConf IRC confirms this happens on their system which is running Debian Sid. This is working just fine here on stable: $ mkdir -p /tmp/foo/bar $ sudo systemd-nspawn --quiet --bind /tmp/foo --directory ~/images/noble/ ls -l /tmp/foo total 0 drwxr-xr-x 2 1000 1000 40 Jul 19 23:09 bar so you need to attach the exact command you are using, run it with SYSTEMD_LOG_LEVEL=debug and also attach the logs -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1076610: shorewall: hardcoded iproute2 binary path
Source: shorewall Severity: important With the latest iproute2 upload the legacy /sbin/ip symlink is gone. /bin/ip has been available since Buster, so please use that or better rely on $PATH. https://codesearch.debian.net/search?q=%2Fsbin%2Fip%5CW+package%3Ashorewall&literal=0 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#981799: Bug#981937: dh-sysuser: Reduce negative impact and assess overall utility
Control: tags 981799 -moreinfo Control: tags 981799 patch Control: severity 981799 serious Control: severity 981937 serious On Fri, 28 Jun 2024 00:44:01 +0200 lorenzo wrote: > > That cycle has happened. How about removing it now? > I'm open to consider further changes but the removal request > is a wontfix. > > Lorenzo We have now finished painstakingly removing dh-sysuser usage from all packages in the archive, bar runit which is maintaned by the dh-sysuer maintainer, for which a patch has been available in #981799 for 3 years now. With Trixie's cycle coming to an end soon-ish, it is now time to either apply the provided runit patch, or alternatively merge whatever remains of dh-sysuser inside runit so that it can continue to use it individually, without it being available for other packages in the archive and being mistakenly picked up again. Having competing packaging APIs is confusing and detrimental to the project. The standard interface the project has adopted for declarative user/group creation is dh_installsysusers provided by debhelper. Having a similarly named API, that is incompatible, does not actually use the sysuser.d interface despite being named after it, and does not provide the same advantages, is confusing for developers who might pick it by mistake, and leads to needless divergence and bugs. Hence I am bumping the severity of both bugs to serious, so that this does not ship in Trixie. Please apply the suggested change, or an equivalent one, in runit, and then please file an RM bug for dh- sysuser. Thank you. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1076455: ITP: partman-dps -- apply Discoverable Partitions Specification labels to GPT disks during installation
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: partman-dps Version : 0.1 Upstream Author : Luca Boccassi * URL : https://salsa.debian.org/installer-team/partman-dps * License : GPL-2.0-or-later Programming Lang: shell Description : debian-installer component to apply GPT labels following https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1076432: systemd: [networkd] incorrect IPv6 address generation
Control: tags -1 moreinfo On Tue, 16 Jul 2024 13:29:36 +0300 =?utf-8?q?Martin-=C3=89ric_Racine?= wrote: > Package: systemd > Version: 252.26-1~deb12u2 > Severity: important > Tags: ipv6 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > I have enabled networkd and created the following /etc/systemd/network/dhcp.network: > > [Match] > Name=en* wl* > > [Network] > DHCP=yes > IPv6PrivacyExtensions=yes > IPv6LinkLocalAddressGenerationMode=stable-privacy > > Two issues: > > 1) networkd creates a new link address with the stable-privacy flag, in addition to the existing one created by the kernel on bootup. > 2) Regardless, the stable-privacy flag is not inherited by the mngtmpaddr address. It steadfastly uses an EUI64 address. Can you reproduce in testing/unstable? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1069425: socket_wrapper and the time_t 64-bit is hard
On Mon, 29 Apr 2024 13:03:22 +1200 Andrew Bartlett wrote: > Just a warning that trying to brute force a fix for this is likely to > end badly. A lot of developer time was spent to get to this current > delicate situation, which relied on the narrow behaviour that is now > eliminated by the Debian time_t 64 transition rules. > > Socket-wrapper starts with: > > /* > * Make sure we do not redirect (f)open(at)() or fcntl() to their 64bit > * variants > */ > #undef _FILE_OFFSET_BITS > > This was added in > https://gitlab.com/cwrap/socket_wrapper/-/commit/bbe14cc3200ca553b13ed49357e2e88ba487eeaa > > Setting -D_FILE_OFFSET_BITS=64 will break the fcntl64 wrapper and so > break Samba's tests. > > I don't know if there is a good fix for this actually. > > Andrew Bartlett How about simply dropping armv7 support from socket-wrapper and uid- wrapper? Having architectures that are actually used being blocked by these issues is suboptimal at best -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1076127: (build-)dependency on removed python3-distutils
Control: tags -1 moreinfo upstream Control: severity -1 wishlist On Thu, 11 Jul 2024 08:08:05 +0200 Matthias Klose wrote: > Source: azure-cli > Version: 2.62.0-1 > Severity: serious > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: python3.12 > > there are (build-)dependency on the now removed python3-distutils. > please remove them It's a runtime dependency, and it is still used, so it cannot just be removed. Have you file an upstream issue, or better yet, sent a PR upstream to provide an alternative? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1075818: ubuntu-keyring: upload to bookworm-backports
Control: tags -1 pending n Fri, 05 Jul 2024 19:45:20 +0100 Luca Boccassi wrote: > Source: ubuntu-keyring > Severity: wishlist > X-Debbugs-Cc: x...@debian.org > > Hello, > > ubuntu-keyring missed the bookworm train due to some RC bugs. Now that > it is bug in testing, I'd like to have it in backports. Would you be ok > with it? > > I am happy to NMU it myself if you are busy. > > Thanks! Hi, I have NMU'ed to DELAYED/7 for bookworm-backports, debdiff is just the changelog entry. Let me know if you prefer me to cancel this. --- ubuntu-keyring-2023.11.28.1/debian/changelog2023-11-28 15:02:25.0 + +++ ubuntu-keyring-2023.11.28.1/debian/changelog2024-07-10 12:09:34.0 +0100 @@ -1,3 +1,10 @@ +ubuntu-keyring (2023.11.28.1-0.2~bpo12+1) bookworm-backports; urgency=medium + + * Non-maintainer upload. + * Rebuild for bookworm-backports. + + -- Luca Boccassi Wed, 10 Jul 2024 12:09:34 +0100 + ubuntu-keyring (2023.11.28.1-0.2) unstable; urgency=medium * Non-maintainer upload. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1076059: RM: azure-cosmos-python -- ROM; deprecated and replaced by python-azure
Package: ftp.debian.org Severity: normal Hi, azure-cosmos-python has long been deprecated, as it is replaced by a module from src:python-azure. It will be removed from testing via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052507 and the last reverse dependency, azure-cli, will drop it with version 2.62.0-1 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1075898: bookworm-pu: package systemd/252.28-1~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org
Dear Release Team,
We would like to upload the latest stable point release of systemd 252
to bookworm-p-u. Stable release branches are maintained upstream with
the intention of providing bug fixes only and no compatibility
breakages, and with automated non-trivial CI jobs that also cover
Debian and Ubuntu. I have already uploaded to p-u.
There are no packaging changes. Debdiff attached.
The list of commits included can be seen at:
https://github.com/systemd/systemd-stable/compare/v252.27...v252.28
--
Kind regards,
Luca Boccassi
diff -Nru systemd-252.27/debian/changelog systemd-252.28/debian/changelog
--- systemd-252.27/debian/changelog 2024-06-25 21:25:25.0 +0100
+++ systemd-252.28/debian/changelog 2024-07-07 11:56:20.0 +0100
@@ -1,3 +1,9 @@
+systemd (252.28-1~deb12u1) bookworm; urgency=medium
+
+ * New upstream version 252.28 (Closes: #1074789)
+
+ -- Luca Boccassi Sun, 07 Jul 2024 11:56:20 +0100
+
systemd (252.27-1~deb12u1) bookworm; urgency=medium
* New upstream version 252.27
diff -Nru systemd-252.27/docs/CODING_STYLE.md systemd-252.28/docs/CODING_STYLE.md
--- systemd-252.27/docs/CODING_STYLE.md 2024-06-25 21:13:13.0 +0100
+++ systemd-252.28/docs/CODING_STYLE.md 2024-07-07 11:52:10.0 +0100
@@ -54,6 +54,18 @@
}
```
+- Function return types should be seen/written as whole, i.e. write this:
+
+ ```c
+ const char* foo(const char *input);
+ ```
+
+ instead of this:
+
+ ```c
+ const char *foo(const char *input);
+ ```
+
- Single-line `if` blocks should not be enclosed in `{}`. Write this:
```c
@@ -163,7 +175,7 @@
```c
static int foobar_frobnicate(
- Foobar* object,/* the associated mutable object */
+ Foobar *object,/* the associated mutable object */
const char *input, /* immutable input parameter */
char **ret_frobnicated) { /* return parameter */
…
diff -Nru systemd-252.27/.github/workflows/mkosi.yml systemd-252.28/.github/workflows/mkosi.yml
--- systemd-252.27/.github/workflows/mkosi.yml 2024-06-25 21:13:13.0 +0100
+++ systemd-252.28/.github/workflows/mkosi.yml 2024-07-07 11:52:10.0 +0100
@@ -55,6 +55,11 @@
if: ${{ matrix.release == '9-stream' }}
run: sudo sed -i '/add_packages/s/systemd-boot/systemd/g' /usr/local/lib/python3.10/dist-packages/mkosi/__init__.py
+# FIXME: temporary workaround for debootstrap issue of Debian testing/sid on Jammy
+- name: Fix Debian testing/sid
+ if: ${{ matrix.distro == 'debian' && matrix.release == 'testing' }}
+ run: sudo sed -i 's/merged-usr/no-merged-usr/g' /usr/local/lib/python3.10/dist-packages/mkosi/__init__.py
+
- name: Install
run: sudo apt-get update && sudo apt-get install --no-install-recommends python3-pexpect python3-jinja2
diff -Nru systemd-252.27/LICENSES/README.md systemd-252.28/LICENSES/README.md
--- systemd-252.27/LICENSES/README.md 2024-06-25 21:13:13.0 +0100
+++ systemd-252.28/LICENSES/README.md 2024-07-07 11:52:10.0 +0100
@@ -13,7 +13,14 @@
the systemd project source tree.
Unless otherwise noted, the systemd project sources are licensed under the terms
-and conditions of the **GNU Lesser General Public License v2.1 or later**.
+and conditions of
+**LGPL-2.1-or-later** (**GNU Lesser General Public License v2.1 or later**).
+
+Unless otherwise noted, compiled programs and all shared or static libraries
+include sources under **LGPL-2.1-or-later** along with more permissive
+licenses, and are effectively licensed **LGPL-2.1-or-later**.
+systemd-udevd and other udev helper programs also include sources under
+**GPL-2.0-or-later**, and are effectively licensed **GPL-2.0-or-later**.
New sources that cannot be distributed under LGPL-2.1-or-later will no longer
be accepted for inclusion in the systemd project to maintain license uniformity.
@@ -22,8 +29,9 @@
The following exceptions apply:
- * some udev sources under src/udev/ are licensed under **GPL-2.0-or-later**, so the
- udev binaries as a whole are also distributed under **GPL-2.0-or-later**.
+ * some sources under src/udev/ are licensed under **GPL-2.0-or-later**,
+ so all udev programs (`systemd-udevd`, `udevadm`, and the udev builtins
+ and test programs) are also distributed under **GPL-2.0-or-later**.
* the header files contained in src/basic/linux/ and src/shared/linux/ are copied
verbatim from the Linux kernel source tree and are licensed under **GPL-2.0 WITH
Linux-syscall-note** and are used within the scope of the Linux-syscall-note
diff -Nru systemd-252.27/man/file-hierarchy.xml systemd-252.28/man/file-hierarchy.xml
--- systemd-252.27/man/file-hierarchy.x
Bug#1042969: vsftpd: Deletes the ftp user on remove, breaking other packages
Control: tags -1 pending
On Thu, 03 Aug 2023 08:54:40 -0500 John Goerzen
wrote:
> Package: vsftpd
> Version: 3.0.3-13+b2
> Severity: critical
> Justification: breaks unrelated software
>
> On removing this package, it indiscriminately removes the ftp user.
> Unfortunately, that user was required for iksd in package ckermit to
work, so
> this broke the unrelated ckermit package.
>
> It is likely that there are other packages and users that would also
> use the ftp user. It should not be removed on package removal.
Given this will cause the autoremoval of several of my packages, I've
NMU'ed to DELAYED/7 with a fix to stop removing the ftp user/group in
the postinst. debdiff attached.
--
Kind regards,
Luca Boccassi
diff -Nru vsftpd-3.0.3/debian/changelog vsftpd-3.0.3/debian/changelog
--- vsftpd-3.0.3/debian/changelog 2021-03-03 21:05:45.0 +
+++ vsftpd-3.0.3/debian/changelog 2024-07-07 13:39:11.0 +0100
@@ -1,3 +1,10 @@
+vsftpd (3.0.3-13.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Stop removing ftp user/group on removal (Closes: #1042969)
+
+ -- Luca Boccassi Sun, 07 Jul 2024 13:39:11 +0100
+
vsftpd (3.0.3-13) unstable; urgency=medium
[Frey Daniel]
diff -Nru vsftpd-3.0.3/debian/vsftpd.postrm vsftpd-3.0.3/debian/vsftpd.postrm
--- vsftpd-3.0.3/debian/vsftpd.postrm 2015-03-03 17:40:36.0 +
+++ vsftpd-3.0.3/debian/vsftpd.postrm 2024-07-07 13:39:07.0 +0100
@@ -23,22 +23,8 @@
case "${1}" in
remove)
- _USERNAME="ftp"
- _GROUPNAME="${_USERNAME}"
_DIRECTORY="/srv/ftp"
- pathfind deluser
- if [ $? = 0 ] ;
- then
- deluser --quiet --system ${_USERNAME}
- fi
-
- pathfind delgroup
- if [ $? = 0 ] ;
- then
- delgroup --quiet --system --only-if-empty ${_GROUPNAME} || true
- fi
-
if [ -d "${_DIRECTORY}" ]
then
rmdir --ignore-fail-on-non-empty "${_DIRECTORY}" || true
signature.asc
Description: This is a digitally signed message part
Bug#1075882: systemd + crypttab not working after 256-2
Control: tags -1 wontfix Control: close -1 On Sat, 06 Jul 2024 17:58:17 -0400 Wesley Schwengle wrote: > Package: systemd > Version: 256.2-1 > Severity: important > X-Debbugs-Cc: wes...@schwengle.net > > Dear Maintainer, > > Today after an upgrade of systemd my machine was unable to reboot because it > failed to read /etc/crypttab. > > In /etc/crypttab I have a second disk which is encrypted (which is my /home). > My fstab entry for /home could not be mounted, resulting in a timeout. > > I did see a recommendation for a package that wasn't going to be installed: > systemd-cryptsetup. Recommends are installed by default intentionally, if you choose to turn that default off, you need to make sure you install every you need for optional features manually, there's just no way around it. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1074014: encode mandatory merged-/usr into policy
On Fri, 21 Jun 2024 20:27:56 +0200 Helmut Grohne wrote: > Package: debian-policy > Version: 4.7.0.0 > X-Debbugs-Cc: bl...@debian.org,m...@debian.org,mbi...@debian.org,z...@debian.org > > Hi, > > 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. > > Generally speaking DEP17 says that no package should install any files > below /bin/, /lib*/ and /sbin/. Doing so would amount to a symlink vs > directory conflict between base-files which now installs symlinks at the > relevant locations. What happens with these locations depends on the > order of unpacks. In many cases, this is not a problem, because > base-files is essential and thus unpacked early. Other than that, > running dpkg-deb -x foo.deb / causes these symlinks to be overwritten > with actual directories possibly breaking the installation. We currently > have mitigations for these problems in place and plan to drop them after > trixie. > > 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. Seconded -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions
On Wed, 14 Dec 2022 15:27:18 +0100 Juri Grabowski wrote: > Package: wnpp > Version: 1.79 > Severity: wishlist > Owner: Juri Grabowski > X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@jugra.de > > * Package name : distribution-gpg-keys > Version : 1.7.9 > Upstream Author : Miroslav Suchý > * URL : https://github.com/xsuchy/distribution-gpg-keys/ > * License : CC0-1.0 > Programming Lang: data > Description : GPG keys by various Linux distributions > > used by various Linux distributions to sign packages. > > needed by mock/3.5 and I need a sponsor for this package. See current packaging in > https://salsa.debian.org/pkg-rpm-team/distribution-gpg-keys > After I know ITP bug number I upload this source package to > https://mentors.debian.net/package/distribution-gpg-keys/ This has stalled for too long, I'll update the package as it is on Salsa and upload it shortly. I'll set it to be team maintained in pkg- rpm-team and keep you as an uploader, given it's already stored there on Salsa, seems like a good fit. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1075818: ubuntu-keyring: upload to bookworm-backports
Source: ubuntu-keyring Severity: wishlist X-Debbugs-Cc: x...@debian.org Hello, ubuntu-keyring missed the bookworm train due to some RC bugs. Now that it is bug in testing, I'd like to have it in backports. Would you be ok with it? I am happy to NMU it myself if you are busy. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1075759: isa-support: please add armv8 + crc support package
On Fri, 5 Jul 2024 at 18:06, Bastien Roucariès wrote: > > Le jeudi 4 juillet 2024, 12:51:01 UTC Luca Boccassi a écrit : > Hi, > > > Source: isa-support > > Severity: wishlist > > X-Debbugs-Cc: pkg-dpdk-de...@lists.alioth.debian.org > > > > Dear Maintainer(s), > > > > For src:dpdk we would like to depend on a higher arm64 baseline, which > > includes the crc extension. Would it be possible to add a new package > > that matches it? > > > > For reference, we compile with: -march=armv8-a+crc > > I will really prefer to add an arch level like armv8.1-a if possible. > > Does it exist some processor with crc without ‘+lse’, ‘+rdma’ ? Sorry, I am not an expert, I do not know. I am fine with a "wider" flag if it includes crc, that would work just fine. > Next question how can I detect it ? Sorry, I am really not sure, I just know the requirement from the build flags.
Bug#1075759: isa-support: please add armv8 + crc support package
Source: isa-support Severity: wishlist X-Debbugs-Cc: pkg-dpdk-de...@lists.alioth.debian.org Dear Maintainer(s), For src:dpdk we would like to depend on a higher arm64 baseline, which includes the crc extension. Would it be possible to add a new package that matches it? For reference, we compile with: -march=armv8-a+crc https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html Thank you! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1074789: [Pkg-utopia-maintainers] Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists
On Wed, 03 Jul 2024 23:10:30 +0100 Luca Boccassi
wrote:
> On Wed, 03 Jul 2024 22:58:33 +0100 Luca Boccassi
> wrote:
> > On Wed, 3 Jul 2024 21:26:36 +0200 Michael Biebl
> > wrote:
> > > Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:
> > > > On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:
> > > >
> > > >>>>> connect(5, {sa_family=AF_UNIX,
> > sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1
> > ECONNREFUSED (Connection refused)
> > > >
> > > >> systemd should be listening on this socket
> > > >
> > > > Well, on no less than four different Debian machines, it does
> not.
> > > >
> > > >> $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> > > >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE
> NAME
> > > >> systemd 1 root 28u unix 0x73ac41e2 0t0 8696
> > > >> /run/systemd/userdb/io.systemd.DynamicUser type=STREAM
(LISTEN)
> > > >
> > > > Isn't that on a machine where systemd-userdb is installed
maybe?
> > The
> > > > installation of that package triggers the systemd binary to
> listen?
> > >
> > > No, systemd-userdb is not installed and as you can see from the
> above
> > > output it's actually systemd which listens on that socket.
> >
> > I can reproduce it by mounting a tmpfs on /run/systemd/userdb/
_and_
> > creating an empty io.systemd.DynamicUser file on it. Maybe it
should
> > not abort like that, however, if you have the directory in /run/
> _and_
> > the socket file exists _but_ nothing is listening on it, then your
> > machine is broken in some way. If the directory/socket are missing
> they
> > are just skipped gracefully.
>
> I'm not sure what's the alternative here - if consulting NSS fails
for
> some local reasons because the machine is broken/misconfigured, I am
> not sure if it should just ignore it and continue it. If NSS is
> configured and is supposed to work, but doesn't for some
> temporary/local reason, you might end up creating a duplicated
> user/group, and I am not really sure that's better than bailing out
> without touching anything.
Consensus seems to be that in this bad situation it's slightly better
to complain loudly and continue, so the next point release will contain
a fix to this effect. You should still figure out how you ended up with
a dead af_unix socket in the first place, as that's a sign of something
seriously wrong on that machine.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
