Bug#1071201: systemd 256~rc2-1
Hi, On Wed, 2024-05-15 at 22:38 -0600, Antonio Russo wrote: > I can confirm this version of systemd breaks my system's boot as well. I > don't have any > modified journald.conf settings. > > I'm running dracut, and the image that is built fails to start > systemd-modules-load.service This is a separate issue: https://bugs.debian.org/1071182 Ansgar
Bug#1071182: dracut: requires changes for systemd 256; boot fails otherwise
Source: dracut Version: 060+5-1 Severity: serious Tags: upstream X-Debbugs-Cc: Debian systemd Maintainers Hi, dracut requires two changes for systemd 256: 1. systemd 256 makes /usr read-only in initrd: - https://github.com/systemd/systemd/issues/32511 - https://github.com/dracut-ng/dracut-ng/issues/253 2. libkmod.so.2 might need to be installed manually: - https://github.com/systemd/systemd/issues/32508#issuecomment-2080063182 systemd should get a `Breaks: dracut (<< fixed-version-goes-here)` once a fixed version is uploaded. Ansgar -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (300, 'buildd-unstable'), (300, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#996202: EFI Secure Boot for systemd-boot
Hi, On Fri, 2024-05-10 at 15:20 +0100, Luca Boccassi wrote: > On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi > > On IRC Steve mentioned that he's ok with proceeding with this. > > jcristau from DSA said that it's the FTP team that should confirm the > > request > > for the new intermediate signer cert for systemd-boot to DSA. > > > > FTP team, are you ok with proceeding with this? If so, would it be > > possible to have an ACK, please? Is there any more information required > > beforehand? As long as the security boot people are fine with this, I think this should be fine. (And AFAIU this seems to be the case.) Maybe we should use a non-trusted cert for the initial setup and only switch to a proper cert once everything is confirmed to be working as expected? Ansgar
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Hi, On Mon, 2024-04-01 at 17:52 +0200, Bill Allombert wrote: > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote: > > This gives constraints on the build daemons infrastructure and also > > brings some security concerns. Would it be possible to extend this > > restriction to all archives? > > Does the build daemons actually build non-free ? Yes: allowlisted non-free packages get built on buildds. Not allowing network access for contrib and non-free as well seems reasonable to me. Ansgar
Bug#1064951: UDD/upload_history: importer broken by switch to detached PGP signatures
Hi Lucas, On Wed, 28 Feb 2024 08:30:28 +0100 Lucas Nussbaum wrote: > The upload_history importer parses email received by the > debian-devel-changes mailing list. On 2024-02-11, the format of those > emails changed to multipart/signed. Previously the PGP signature was > inlined. This isn't correct: the mails themselves were not signed previously, but contained a inlined-signed part (the .changes signed by the uploader), but that wasn't the full mail. Now the mail also has a signature from the archive software, but the importer could just ignore the outer signature and process the inner part in the same way as before. Ansgar
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Sat, 6 Jan 2024 19:38:42 -0800 Steve Langasek wrote: > - dpkg will be uploaded to experimental with 64-bit time_t in the default > flags As far as I understand this approach will break any consumer on a library whose ABI changes to to the ABI changes introduced here unless the consumer is built with the flags from `dpkg-buildflags` (which would now define the ABI). In particular users could no longer just invoke `gcc` alone, but would have to also rely on `dpkg-buildflags` for any software they built on their own using runtime libraries shipped by Debian. It would work in some cases (multi-ABI libraries like libc6 or libraries not affected by the ABI change), but it is not reliable. Do we want this? It must at least be documented, probably in Debian Policy and GCC. This was asked on debian-devel@ multiple times, but there was no answer so far. Ansgar
Bug#1063641: dpkg-buildflags: please document how to enable/disable area features for different areas
Package: dpkg-dev
Version: 1.22.4
Severity: minor
man:dpkg-buildflags(1) documents only how to specify multiple area
features fot the same area with examples like:
export DEB_BUILD_MAINT_OPTIONS=hardening=+pie,-fortify
export DEB_BUILD_MAINT_OPTIONS=hardening=-all,+format,+fortify
There is no documentation how to specify area features for different
areas like "abi" and "hardening" at the same time.
(This probably also leads to the question if one can specify
hardening=+pie{something-for-abi}hardening=+fortify
or if all area features have to be enabled/disabled at once.)
Ansgar
Bug#1063605: debian-policy: mandate use of `dpkg-buildflags` for all software compilation on Debian
On Fri, 2024-02-09 at 22:01 +0100, Bill Allombert wrote:
> On Fri, Feb 09, 2024 at 09:16:00PM +0100, Ansgar wrote:
> > with the upcoming time_t & friends 64-bit transition, dpkg-
> > buildflags
> > will be used to configure the ABI in use.
>
> This decision comes from the wrong premise that the use of dpkg-
> buildflags
> is universal, which is not the case. Hence it needs to be
> reconsidered.
> There is not magic that will make all packages use dpkg-buildflags
> consistently
> in the timeframe of this migration.
If packages do not use dpkg-buildflags, but use any ABI changed by the
transititon, they will just be broken and must already be fixed.
> > Thus all compiler
> > invocations *must* use the flags specified by dpkg-buildflags to
> > avoid
> > ABI inconsistencies like this one:
> >
> > struct T { time_t a; time_t b; };
> >
> > If this struct is accessed from both `libfoo1t64` (built respecting
> > dpkg-buildflags and thus time_t is 64-bit) and `bar` (built by a
> > user
> > invoking gcc themselves), the result is probably not what one
> > wants.
> >
> > Thus `dpkg-buildflags` *must* be used by all packages *and* all
> > users,
> > including users building their own software. There is one
> > exception
> > when libraries provide both 32-bit and 64-bit time_t ABIs like
> > glibc
> > itself (but I doubt there are many of those).
>
> No, it is required that packages use correctly the right compiler
> flags.
The interface for the compiler flags is dpkg-buildflags. See
the transition annoucnement.
I did not come up with this interface, but am not aware of an
alternative.
(C++ ABI changes were handled differently, but this transition did
choose a different way; I'm not aware of the details why.)
> Since packages need to be reuploaded anyway this is not a real issue.
> dpkg-buildflags is not required for that, and does not necessarily
> achieve it
> either, since upstream build system might not honor the environment
> variables
> CFLAGS etc. consistently.
Packages must ensure that these flags are passed correctly to the
upstream build system. As mentioned above, any package not doing so is
already broken (or will be by the transition).
> > Any compiler invocation missing these *should* be a serious bug.
> > (This should probably be mentioned in user documentation as well.)
>
> This a different issue than mandating dpkg-buildflags.
You can also establish another interface, but currently the only one
I'm aware of is dpkg-buildflags.
Ansgar
Bug#1063605: debian-policy: mandate use of `dpkg-buildflags` for all software compilation on Debian
Package: debian-policy
Version: 4.6.2.0
Severity: important
Hi,
with the upcoming time_t & friends 64-bit transition, dpkg-buildflags
will be used to configure the ABI in use. Thus all compiler
invocations *must* use the flags specified by dpkg-buildflags to avoid
ABI inconsistencies like this one:
struct T { time_t a; time_t b; };
If this struct is accessed from both `libfoo1t64` (built respecting
dpkg-buildflags and thus time_t is 64-bit) and `bar` (built by a user
invoking gcc themselves), the result is probably not what one wants.
Thus `dpkg-buildflags` *must* be used by all packages *and* all users,
including users building their own software. There is one exception
when libraries provide both 32-bit and 64-bit time_t ABIs like glibc
itself (but I doubt there are many of those).
Any compiler invocation missing these *should* be a serious bug.
(This should probably be mentioned in user documentation as well.)
Currently Debian Policy does not mention dpkg-buildflags at all.
Ansgar
Bug#1061335: python3-breezy: ships files in `/build`
Package: python3-breezy Version: 3.3.5-1 Severity: serious Hi, python3-breezy ships files in `/build`: +--- | % dpkg-deb -c python3-breezy_3.3.5-1_amd64.deb | head | drwxr-xr-x root/root 0 2024-01-19 23:12 ./ | drwxr-xr-x root/root 0 2024-01-19 23:12 ./build/ | drwxr-xr-x root/root 0 2024-01-19 23:12 ./build/reproducible-path/ | drwxr-xr-x root/root 0 2024-01-19 23:12 ./build/reproducible-path/breezy-3.3.5/ | drwxr-xr-x root/root 0 2024-01-19 23:12 ./build/reproducible-path/breezy-3.3.5/debian/ +--- This is probably not intended. Ansgar
Bug#1058945: python3-secretstorage: please do not depend on dbus package
Hi, On Sun, 2024-01-07 at 22:15 +0300, Dmitry Shachnev wrote: > On Sun, Jan 07, 2024 at 07:31:48PM +0100, Ansgar wrote: > > > gnome-keyring | alternatives is in Recommends, not in Depends. > > > > > > The reason for that is because someone may want to use secretstorage > > > with a different server that is not listed there, and we do not have a > > > virtual package name that any such implementation can provide (like e.g. > > > notification-daemon is provided by 14 different packages). > > > > So will you add a virtual package and a strict dependency? AFAIU it is > > about as uesless without one of these providers as it is without Dbus. > > I think you really don't want it to be a strict dependency, do you? I would prefer no such dependency, yes. I'm just wondering why dbus and the provider of the dbus interface are handled differently. > Your analogy doesn't 100% apply to Python world. In C, if you link to some > library, your application won't start when that library is not installed. > However, in Python, it's quite easy to make imports optional. And Keyring > does exactly this, "import keyring" will not fail if python3-secretstorage > is not installed. In C one can load optional plugins as well, but it is more work to implement, yes. > Similarly, I see that poetry imports keyring not on the top level, but in > the code where it's actually needed [1], and poetry will start when keyring > is not installed, so maybe poetry should Recommend python3-keyring, not > depend on it. Maybe that too, but this can get harder for users to find: assume Poetry still depends on python3-keyring, but python3-secretstorage. Then it is hard to find out that python3-secretstorage might need to be installed in order to store credentials in gnome-keyring (or others). > But anyway, if you insist that python3-secretstorage should not depend on > dbus-related packages, I can demote that to Recommends. For most users > that shouldn't make any difference because we have Recommends enabled by > default. Will that work for you? I would assume that pretty much everyone who wants to use the DBus secret store with gnome-keyring, kwallet or keepassxc has a GUI with DBus already installed. So "Suggests:" would be enough. The question of libraries depending on services comes up from time to time again, so it might be better to decide on a general policy for this. I've started a thread on -devel@ for this: https://lists.debian.org/msgid-search/da70d4ba9cae7261698718b2d50303be50d074c2.ca...@43-1.org (link should work in ~20 minutes or so). Ansgar
Bug#1058945: python3-secretstorage: please do not depend on dbus package
On Sun, 2024-01-07 at 18:23 +0300, Dmitry Shachnev wrote: > On Sat, Jan 06, 2024 at 07:50:47PM +0100, Ansgar wrote: > > Now try not to install an init system, dbus, ... in a application > > container wanting to use python3-poetry to install some Python > > application. > > > > And this still doesn't ensure that: > > 1. dbus is actually running in the context where python3-secretstorage is > > used, > > 2. the Dbus interface python3-secretstorage wants to talk to is actually > > provided by a service > > > > (For 2. it doesn't even have a Depends: gnome-keyring | alternatives > > either which is inconsistent with the dependency on Dbus...) > > gnome-keyring | alternatives is in Recommends, not in Depends. > > The reason for that is because someone may want to use secretstorage > with a different server that is not listed there, and we do not have a > virtual package name that any such implementation can provide (like e.g. > notification-daemon is provided by 14 different packages). So will you add a virtual package and a strict dependency? AFAIU it is about as uesless without one of these providers as it is without Dbus. > > Also it's unknown whether that is actually useful or not (as python3- > > secretstorage is just a library that could not be relevant at all as > > the application's user might not actually want to manage secrets via > > keepassxc). > > > > It seems excessive to *always* require all of this to be installed for > > *any* use of python3-poetry (which can optionally use python3- > > secretstorage if that is even required). bash doesn't depend on gnome- > > terminal either just because one needs some terminal to run it in ;-) > > I think python3-secretstorage is completely useless without D-Bus. I think you miss my point: The dependency currently says "python3-poetry is useless without Dbus". > So maybe this dependency chain should be cut at a higher level, e.g. > between python3-keyring and python3-secretstorage. > > I am also the uploader of python3-keyring, so we can discuss it here. > > I can suggest two solutions: > > 1. Replace python3-keyring → python3-secretstorage Depends with Recommends. > 2. Keep it Depends, but add some alternatives, e.g. python3-secretstorage > | python3-keyrings.alt. > > Will any of that work for you? I think that is still fundamentally wrong. A program X linking a library (classic C libraries or python3-* stuff; implementation doesn't matter) will result in a relation "X depends libY". But that doesn't say anything about if users actually will use "libY". For example, consider libY as a library speaking to Pulseaudio, libZ a library speaking to jack2d. The application X now links libY and libZ as it has support for audio output via libY or libZ; it can also output audio via ALSA. Installing X thus installs libY and libZ. Clearly libY is useless without PA and libZ useless without Jack in the same way as python3-keyring is useless without Dbus + Secret Service backend. Should libY thus depend on Dbus + Pulseaudio and libZ depend on jackd? That would result in a user wanting to install X having to install Dbus, Pulseaudio and Jack. That is in particular two audio servers that will then be enabled by default. As Debian tries to build packages with as much optional stuff as possible enabled, this would happen very often (we have more sound servers...). Is that useful? I think not and think libraries *must not* depend on services for that reason. If soemthing explicitly depends on a service, it should be an application, not some library. Ansgar
Bug#1058945: python3-secretstorage: please do not depend on dbus package
Hi, On Sat, 2024-01-06 at 20:39 +0300, Dmitry Shachnev wrote: > On Mon, Dec 18, 2023 at 08:14:55PM +0100, Ansgar wrote: > > If anything, only applications should require specific interfaces. > > A library like python3-secretstorage cannot know whether its use is > > essential (in which case dbus should probably be a dependency) or > > totally optional (in which case dbus should be > > suggested/recommended). > > I am confused. In version 3.3.3-2, python3-secretstorage changed > dependency from dbus to default-dbus-session-bus | dbus-session-bus. > > And you filed this bug against the new version, 3.3.3-2. Is that a > mistake? Or the new dependency is still not good? That doesn't help much unless one takes special care. This is what installing python3-poetry in a Podman container looks like: % podman run --rm -it debian:unstable root@6663e6910965:/# apt update Get:1 http://deb.debian.org/debian unstable InRelease [198 kB] Get:2 http://deb.debian.org/debian unstable/main amd64 Packages [9642 kB] Fetched 9840 kB in 2s (5939 kB/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done 39 packages can be upgraded. Run 'apt list --upgradable' to see them. root@6663e6910965:/# apt install python3-poetry Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: adduser adwaita-icon-theme at-spi2-common at-spi2-core binutils binutils-common binutils-x86-64-linux-gnu bsdutils build-essential bzip2 ca-certificates cpp cpp-13 dbus dbus-bin dbus-daemon dbus-session-bus-common dbus-system-bus-common dbus-user-session dconf-gsettings-backend dconf-service dirmngr dmsetup dpkg dpkg-dev fakeroot fontconfig fontconfig-config fonts-dejavu-core fonts-dejavu-mono g++ g++-13 gcc gcc-13 gcr gnome-keyring gnome-keyring-pkcs11 gnupg gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gsettings-desktop-schemas gtk-update-icon-cache hicolor-icon-theme javascript-common krb5-locales libabsl20220623 libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl libaom3 libapparmor1 libargon2-1 libasan8 libassuan0 libatk-bridge2.0-0 libatk1.0-0 libatomic1 libatspi2.0-0 libavahi-client3 libavahi-common-data libavahi-common3 libavif16 libbinutils libblkid1 libbrotli1 libbsd0 libbz2-1.0 libc-dev-bin libc-devtools libc6-dev libcairo-gobject2 libcairo2 libcc1-0 libcloudproviders0 libcolord2 libcrypt-dev libcrypt1 libcryptsetup12 libctf-nobfd0 libctf0 libcups2 libdatrie1 libdav1d7 libdbus-1-3 libdconf1 libde265-0 libdeflate0 libdevmapper1.02.1 libdpkg-perl libepoxy0 libexpat1 libexpat1-dev libfakeroot libfdisk1 libfile-fcntllock-perl libfontconfig1 libfreetype6 libfribidi0 libgav1-1 libgcc-13-dev libgck-1-0 libgcr-base-3-1 libgcr-ui-3-1 libgd3 libgdbm-compat4 libgdbm6 libgdk-pixbuf-2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libglib2.0-0 libglib2.0-data libgomp1 libgpm2 libgprofng0 libgraphite2-3 libgssapi-krb5-2 libgtk-3-0 libgtk-3-bin libgtk-3-common libharfbuzz0b libheif-plugin-aomenc libheif-plugin-dav1d libheif-plugin-libde265 libheif-plugin-x265 libheif1 libhwasan0 libicu72 libisl23 libitm1 libjansson4 libjbig0 libjpeg62-turbo libjs-jquery libjs-sphinxdoc libjs-underscore libjson-c5 libk5crypto3 libkeyutils1 libkmod2 libkrb5-3 libkrb5support0 libksba8 liblcms2-2 libldap-2.5-0 libldap-common liblerc4 liblocale-gettext-perl liblsan0 liblzma5 libmount1 libmpc3 libmpfr6 libncursesw6 libnpth0 libnsl-dev libnsl2 libnss-systemd libnuma1 libp11-kit0 libpam-gnome-keyring libpam-systemd libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libperl5.36 libpixman-1-0 libpng16-16 libproc2-0 libpython3-dev libpython3-stdlib libpython3.11 libpython3.11-dev libpython3.11-minimal libpython3.11-stdlib libquadmath0 librav1e0 libreadline8 librsvg2-2 librsvg2-common libsasl2-2 libsasl2-modules libsasl2-modules-db libsecret-1-0 libsecret-common libsframe1 libsharpyuv0 libsmartcols1 libsqlite3-0 libstdc++-13-dev libsvtav1enc1d1 libsystemd-shared libsystemd0 libthai-data libthai0 libtiff6 libtirpc-common libtirpc-dev libtirpc3 libtsan2 libubsan1 libudev1 libuuid1 libwayland-client0 libwayland-cursor0 libwayland-egl1 libwebp7 libx11-6 libx11-data libx265-199 libxau6 libxcb-render0 libxcb-shm0 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxi6 libxinerama1 libxkbcommon0 libxml2 libxpm4 libxrandr2 libxrender1 libxtst6 libyuv0 linux-libc-dev make manpages manpages-dev media-types mount netbase openssl p11-kit p11-kit-modules patch perl perl-base perl-modules-5.36 pinentry-gnome3 procps psmisc python-pkginfo-doc python3 python3-build python3-cachecontrol python3-certifi python3-cffi-backend python3-chardet python3-charset-normalizer python3-cleo python3-crashtest python3-cryptography pyt
Bug#1060034: ITP: python-openai -- OpenAI Python API library
On Fri, 2024-01-05 at 08:50 -0500, Mo Zhou wrote: > > On 1/5/24 03:48, Ansgar wrote: > > On Thu, 2024-01-04 at 21:30 -0500, Mo Zhou wrote: > > > Dependency of DebGPT. Will be maintained by deep learning team. > > > It will go to the contrib section based on policy section 2.2.2, > > > because this API client requires either > > > (1) paied access to the proprietary backend > > > (2) compatible open-source backend implementations are not yet > > > available in the archive. > > > > > > I'm confused. Will this package have a "Depends: some- > > > proprietary- > > > openai-thing"? Can't it talk to a web service providing the API? > No. All the dependencies are: python3-anyio,python3-distro, > python3-httpx,python3-pydantic,python3-sniffio,python3-tqdm, > python3-typing-extensions,python3:any. > Can be satisfied using packages from main section. > > That said, this package does not work at all without (1) paid > access token from OpenAI (2) open-source alternative Then the package should be in main. We do not require external software to be free as well, be that Web APIs provided by Github, Twitter, or the NVidia firmware required for Nouveau, microcode or storage/keyboard/sound/printer firmware required for Linux, ... We would have to move pretty much everything to contrib if that was the case. Ansgar
Bug#1060034: ITP: python-openai -- OpenAI Python API library
On Thu, 2024-01-04 at 21:30 -0500, Mo Zhou wrote: > Dependency of DebGPT. Will be maintained by deep learning team. > It will go to the contrib section based on policy section 2.2.2, > because this API client requires either > (1) paied access to the proprietary backend > (2) compatible open-source backend implementations are not yet > available in the archive. I'm confused. Will this package have a "Depends: some-proprietary- openai-thing"? Can't it talk to a web service providing the API? Does OpenAI even offer this "some-proprietary-openai-thing" package to the general public? Ansgar
Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup
On Sun, 2023-12-31 at 18:49 +0800, YunQiang Su wrote: > * Package name : cryptsetup-2fa > Version : 0.1 > Upstream Contact: YunQiang Su > * URL : https://github.com/wzssyqa/cryptsetup-2fa/ > * License : BSD-2 > Programming Lang: SHELL > Description : 2FA plugin for cryptsetup > > 2 mthods are supported for 2 FA: > - Yubikey Challenge > - TPM2 Keypair > PIN-less is also supported, if the PINs are present in > /etc/cryptsetup/2fa.conf. > > Since I am not expert of security and encrypt: > CODE Review is requested here, too. Is there any reason to not just use systemd-cryptenroll? It seems to be a more featureful implementation and also doesn't require storing PINs in plain text in configuration files like /etc/cryptsetup/2fa/2fa.conf as README instructs users to do here. Nor does it store plain text credentials in /var/cache. Ansgar PS: I also don't understand why cryptsetup-2fa-enroll(1) references privacyIDEA.
Bug#1059654: tablix2: please build without PVM support; blocks removal of PVM
Source: tablix2 Version: 0.3.5-7 Severity: important Control: block 1055957 by -1 Please build tablix2 without PVM support. PVM is no longer maintained, seems irrelevant for parallel applications these days and has been proposed to be removed (#1055957). Ansgar
Bug#1059653: netpipe: stop building netpipe-pvm; blocks removal of pvm
Source: netpipe Version: 3.7.2-8 Severity: important Control: block 1055957 by -1 Please stop building netpipe-pvm, it blocks removal of PVM (#1055957). I don't think PVM is still relevant for parallel applications these days. Ansgar
Bug#1059652: Proposed-RM: slpvm -- RoQA; PVM no longer maintained
Source: slpvm Version: 0.1.5-17 Severity: serious Control: block 1055957 by -1 Please consider removing src:slpvm. The last upstream release (0.1.5) is from 2005-10-28 and PVM itself doesn't seem relevant for parallel applications these days and is also unmaintained. If there are no objections, I'll reassign this bug to the FTP team. I'll wait at least two weeks, i.e., at least until 2024-01-13; though it might take longer until I look at this again. Ansgar
Bug#1059644: inetutils: provide rsh-client & rsh-server?
On Fri, 29 Dec 2023 20:03:33 +0100 Simon Josefsson wrote: > I noticed that netkit-rsh is orphaned and there are even requests to > remove it: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041864 > > That is stalled because there are two reverse dependencies that > allegedly uses: pdsh and pvm. PVM seems irrelevant these days and should probably be removed; there is already #1059644 for that, but it still has reverse dependencies. pdsh already depends on openssh-client and the package description states "It has built-in, thread-safe clients for rsh". I wonder if it really needs rsh-client or whether that dependency could just be dropped? Ansgar
Bug#1058945: python3-secretstorage: please do not depend on dbus package
Package: python3-secretstorage Version: 3.3.3-2 Severity: normal Please do not depend on dbus. Currently installing anything depending on python3-secretstorage will install dbus-user-session and with it systemd-sysv, for example: python3-poetry -> python3-keyring -> poetry3-secretstorage -> dbus This is pretty useless in containers. So please do not force to install it: it should be fine to just return an error in case the secret storage service is not reachable, for example because there is no dbus bus to use. If anything, only applications should require specific interfaces. A library like python3-secretstorage cannot know whether its use is essential (in which case dbus should probably be a dependency) or totally optional (in which case dbus should be suggested/recommended). Ansgar
Bug#1057000: Broken OPENSSL_init_ssl
On Mon, 27 Nov 2023 19:11:44 +0100 Klaus Ethgen wrote: > merged-usr: no This is not supported by Debian and random breakage may occur. Please only submit bugs that are reproducible on Debian and happen in a supported configuration (or at least not in an explicitly not supported configuration). This might be the case here (who knows). Or it might be due to Devuan's mirrors. Or other changes introduced by Devuan. So the report should probably be closed. > Versions of packages apt-listchanges depends on: > ii apt 2.7.6devuan2 Please report Devuan bugs to Devuan's bug tracker. Debian cannot do technical support for derivative distributions. Ansgar
Bug#1055777: opensysusers: `--replace` does not match systemd-sysusers
Package: opensysusers
Version: 0.7.3-2
Severity: important
Tags: upstream
opensysusers' usage function describes `--replaces` as this:
+---
| --replace=PATH Don't run check in the package
+---[ opensysusers ]
It is only used in a conditional:
+---
| if [ "$#" -eq 0 ] || [ -n "${replace}" ]; then
+---
I have no idea what the description wants to say and the
implementation doesn't seem related to it. Both ways also don't match
systemd-sysusers behavior as described in man:systemd-sysusers(8):
+---
| --replace=PATH
|
| When this option is given, one or more positional arguments must be
| specified. All configuration files found in the directories listed
| in sysusers.d(5) will be read, and the configuration given on the
| command line will be handled instead of and with the same priority
| as the configuration file PATH.
+---[ man:systemd-sysusers(8) ]
Ansgar
Bug#1055517: opensysusers: modifies host system instead of target environment
Package: opensysusers Version: 0.7.3-2 Severity: grave Tags: security upstream X-Debbugs-Cc: Debian Security Team opensysusers doesn't really implement the `--root` option (though it pretends a bit). Functions like `add_group` always access `/etc/group` and use tools like `groupadd`: ```sh grep -q "^$1:" /etc/group || groupadd -r "$1" ``` So they will always modify the host system, even when supposed to operate on some chroot environment. Applying changes intended for some other environment to the host system looks like a potential security issue. AFAIR there are other incompatibilities with systemd-sysusers so that opensysusers should arguably not claim to be a compatible drop-in replacement. Ansgar
Bug#1055459: reportbug: ask user if bug is reported from affected system
Package: reportbug Version: 12.0.0 Severity: wishlist Hi, users often file bug reports from other systems than the affected one. (For example I use my desktop system as other systems don't have reportbug installed.) In this case the system information / other information gathered by bug report scripts might not be helpful or even totally misleading. It would be nice if reportbug would ask users if they are reporting the bug from the affected system and (a) omit system information if not or (b) at least indicate the user's answer. Ansgar
Bug#1055429: bind9: iproute2 change ripples through bind9 sysvinit script preventing start
Hi Bob, I understand you are not using Debian. Please indicate that if you file bugs encountered on other distributions. > On systems using sysvinit and not yet UsrMerged this snags a problem > in the sysvinit init script. I know and understand that this is not a > combination that you or Debian is officially supporting. But it would > help out interoperability if a one line fix were applied and your > kindness would be appreciated. This approach does not scale: it would require maintainers to continue to support split-usr and it will not work very well for shell interpreter lines like "#! /bin/bash" when the basy binary gets installed to /usr/bin/bash. So to me it seems pretty useless to fix singular instances of this problem. It would probably be better for your distribution to fix this. Please file a bug with them. > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing') > Architecture: amd64 (x86_64) You said elsewhere that this was a bug coming from using a different distribution. Please talk to them so they make sure the system information says so when people are using it. Ansgar
Bug#1051371: Post-/usr-merge paths for script interpreters
On Sun, 2023-09-17 at 11:54 +0200, Bill Allombert wrote: > /bin/perl, /bin/env, /bin/python3 did not exist in the old scheme, so > there is no point in creating them now. No, in Debian's current filesystem layout (Debian stable and later; partly Debian oldoldstable and later) all of these exist. They are also used, both by software shipping in Debian and outside. Dropping them would break existing software. I'm assuming the Jackson symlink proposal would retain them for this reason instead of breaking software for no good reason. Ansgar
Bug#1050001: Bug#1051371: Post-/usr-merge paths for script interpreters
Hi, On Sat, 2023-09-16 at 12:58 -0700, Russ Allbery wrote: > Control: unblock 1051371 by 1050001 > > Ansgar writes: > > > However, there is a proposal by Jackson for an alternative filesystem > > layout based on symlink farms in consideration by the technical > > committee. This advocates removing compat symlinks in /bin, /sbin over > > time[1], thus requiring (c). > > This is not a correct summary of Ian's proposal. In the message that you > linked, Ian says: > > /bin and /lib etc. remain directories (so there is no aliasing). All > actual files are shipped in /usr. / contains compatibility symlinks > pointing into /usr, for those files/APIs/programs where this is needed > (which is far from all of them). Eventualloy, over time, the set of > compatibility links is reduced to a mere handful. > > I am absolutely certain that Ian would consider /bin/sh to be one of the > programs for which a compatibility symlink is needed, and one of the > remaining handful of links that would exist indefinitely into the future. > Indeed, he mentions /bin/sh explicitly later in that message. But the subject of this issue talks about "script interpreters", not just `/bin/sh` (which I guess is safe to assume would be one of the "handful"). It is unclear what files the Jackson symlink farm proposal would leave in /bin. Would /bin/python3 stay? Or would it stay first, but dropped at some later point? What about /bin/perl, /bin/zsh, /bin/env, ...? As far as I understand most compat symlinks should eventually be dropped (but which is unclear). Therefore doing (c) is safe, but anything else might use symlinks that eventually disappear. (And really: what about calling /sbin/ifconfig, ... as well? Here (c) is again the only safe solution with the Jackson symlink farming proposal.) It was asked to clarify the plan for this multiple times, sadly the proposers of the newly proposed filesystem layout have refused to give any answer so far. Ansgar
Bug#1050001: Bug#1051371: Post-/usr-merge paths for script interpreters
Control: block 1051371 by 1050001 Hi, On Tue, 2023-09-12 at 20:48 -0700, Russ Allbery wrote: > I think the root problem behind this bug is that it is revealing we have > not made a decision about /bin and /usr/bin path references in Debian > after /usr-merge. Various people, myself included, made assumptions about > what the policy would be, but we never actually decided anything that I am > aware of and people's assumptions are not matching. I think we need to > talk about this directly, after which what to do with this bug will > probably become obvious. > > So far as I can tell, there are three main possibilities: > > (a) Although /bin and /usr/bin are merged (and likewise for the other > merged paths), Debian will continue to require (or at least recommend) > use of /bin paths for things such as /bin/sh that historically used > those paths. > > (b) Since /bin and /usr/bin (and likewise for the other paths) are merged, > /bin/sh and /usr/bin/sh are equivalent. Packages can use whichever > path they want, and Debian will end up with a mix of both references. > > (c) Although /bin and /lib technically work due to the aliasing, they are > deprecated and everything in Debian should stop using those paths. > All paths should point to /usr/bin and /usr/lib now. As far as I understand people wanting merged-/usr want (b) (I do). There have been people advocating (a) in this bug. However, there is a proposal by Jackson for an alternative filesystem layout based on symlink farms in consideration by the technical committee. This advocates removing compat symlinks in /bin, /sbin over time[1], thus requiring (c). The technical committee should therefore probably be aware of this policy issue in their consideration of #1050001; the resolution of which might also cover this issue (#1051371). Ansgar [1]: https://bugs.debian.org/1050001#33
Bug#1051673: deal.ii: uploader email address maybe invalid (Matthias Maier)
On Mon, 2023-09-11 at 10:32 +0200, Ben Tris wrote: > Source: deal.ii > Version: 9.4.1-1 > Severity: minor > X-Debbugs-Cc: benatt...@gezapig.nl, m...@qa.debian.org > > Dear Maintainer, > > The email address for uploader Matthias Maier is now > this is not found in qa. I don't understand what the problem here should be? The mail address should be valid. Ansgar
Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
On Wed, 2023-09-06 at 16:51 -0600, Sam Hartman wrote: > > > > > > "Luca" == Luca Boccassi writes: > Luca> /bin/sh is not universally compatible with non-Linux OSes. > > I claim it is more compatible. Why should that matter to Debian? Should Debian invest resources to make upstream software more portable to systems like Mac OS X? For me this seems out of scope for Debian. > Luca> Also I thought that policy should not be used to beat other > Luca> developers (it is because of this) and it should reflect > the > Luca> common practices adopted in Debian (it does not because of > Luca> this). Is that no longer the case? > > I'd consider it a non-RC bug if someone were manually writing > #!/usr/bin/sh > > We can debate about normal vs minor. Should we require Debian maintainers to patch this in software packaged for Debian? Why? I think it is fine to wait with this until buildds use merged-/usr for builds, but I don't see any reason to spend resources on this after that. Ansgar
Bug#1050001: Third-party tooling support for merged-/usr vs symlink farms
Hi, On Fri, 2023-09-01 at 13:42 +0100, Luca Boccassi wrote: > the claim that Ansible, Puppet, Chef, Docker, Rsync and whatnot no > longer work on Debian/Ubuntu/Fedora/Arch/SUSE/CentOS/RHEL/etc I think this is a valid point that should be discussed. How do third-party tools cope with merged-/usr (as implemented in Debian and elsewhere)? And how is the support for the proposed symlink farm layout? Has anyone done prior investigation on this? Are there already experimental systems converted to the new layout or some way to convert an existing system to this for testing (not on a production system)? It might be interesting to experiment with the new layout. Ansgar
Bug#1050001: Practical problems with proposed symlink farming: diversions
Hi, a practical thing with usrmerge and legacy layout[1] is the following: assume you do not want programs to find a specific program via PATH lookup or even a fully-qualified path. Then a user can just divert that single program away (or just remove it, depending on details). With Jackson's proposed symlink farms this property goes away: users now have to handle both the copy in / and /usr! What is worse: both entries could be managed by different means (shipped by the package, created by maintscript, created by some external process). This will probably cause breakage with third party integrations of management systems like Ansible. It also seems like a nice property that I don't see any convincing reason to lose so far; we should try to keep the system simple and not introduce such complexities without reason (and rigorous reasoning that it is safe to do so!). Any thoughts about this? Ansgar [1]: With some exceptions such as some programs have compat symlinks in the legacy layout or between .../bin and .../sbin.
Bug#1050001: Unwinding directory aliasing [and 3 more messages] [and 1 more messages]
Hi Ian, On Wed, 2023-08-30 at 12:52 +0100, Ian Jackson wrote: > Debian has historically been simply much more reliable. Could you quantify this? This is not my experience. As far as I understand you often use non-standard configurations (split-/usr, non-standard init system, ...) which might explain your impression. But non-standard ocnfigurations have been less reliable since forever. > usrmerge is a facet of Debian's culture wars. I would appreciate keeping the discussion to technical parts; could I ask you to keep your concerns about cancel culture elsewhere? > > > This argument is basically drawing together the common Affected > > > tooling includes not just our .debs, but also remote > > > configuration management systems like Ansible, image construction > > > (Dockerfiles), and 3rd-party software installation progrmas > > > (including > > > both 3rd-party .debs and 3rd-party script-based installation > > > systems). > > > > I don't follow the reasoning. [...] > > Sam has posted a helpful set of examples of things that one might do, > whose consequences with aliased directories are unclear. > > These are of course only examples. Tools like Ansible, Dockerfiles, ... have probably already been changed to handle merged-/usr. If they are still horribly broken, please document major issues (there are probably always cases that need a change). I somehow doubt many tools will be broken on many distributions for many years and nobody caring. So please substantiate this claim; it seems wild speculation that tools no longer work on Debian, Ubuntu, Red Hat, SuSE, Arch, Gentoo, ... and that they haven't been changed to work (in so far as this has been neccessary). I see this more as a reason against moving to the proposed Jackson layout with symlink farms: this new layout seems more likely to introduce problems with tooling like Ansible, Docker, ... than an existing layout shared between most(?) larger distributions and already the default for many years. Is there any risk evaluation what happen when moving to symlink farms? > > * Become more precise about what your layout looks like precisely. > > Our > ... > > Let me give some examples to get you started: > > libreoffice -> /bin/python > > ghostscript, imagemagick, mesa -> /bin/env > > bind9, manpages, net-snmp, qtbase-opensource-src -> /bin/perl > > Of these I would hope (by, say, 2033) to only include env. I think "hope" is not a good decision mechanism to produce a high quality operating system. How do you plan to do this? Drop links by throwing a coin, releasing stable, then waiting for user systems to be broken? This has been asked several times, but you refuse to give any answer. > perl upstream doctrine used to be that /usr/bin/perl was the correct > canonical path. I haven't checked if that recommendation still > stands. > > I don't know what Python upstream doctrine is on /bin vs /usr/bin; if > it were that Python is supposed to be in /bin, then we might need to > follow that. (But, are they dropping support for the BSDs?) > > With another hat on in an upstream project I've have been receiving > patches to change #!/bin/bash in CI scripts to #!/usr/bin/env bash. How do you ensure all users follow this scheme required by your proposed symlink farm layout, including for local scripts or scripts taken from systems where they just work? > I think it's worth pointing out that any software which is trying to > be portable to Unix systems other than just Linux (which includes the > BSDs and MacOS) will need to avoid assuming directory aliasing. Which seems irrelevant for what we do in Debian. On portable system you can't assume `/bin/sh` to be there either... Ansgar
Bug#1050001: Unwinding directory aliasing [and 3 more messages]
Hi Matthew, On Sun, 2023-08-27 at 11:30 +0100, Matthew Vernon wrote: > Any such consideration must be mindful of the fact that the majority of > Debian installs are now /usr-merged, which means that the complexity of > unwinding such installs has to be a heavy factor in thinking about > alternative approaches. Yes, I think there are many technical challenges required before Debian would be in a position to adopt the proposed Jackson filesystem layout. If Debian would choose to adopt it at all (an open question). Besides conversion, there is also the telemetry service that seems to be required to safely move to the proposed layout (AFAIK no alternative to this has been proposed yet). I'm not sure if there is already any work done on the path by the proposers? I'm also still missing an overview what the Jackson layout's advantages over the existing filesystem layout (merged-/usr) or the 2000's layout is (split-/usr). As far as I can tell it combines the disadvantages of both with much additional work required to get to it; I don't really see any advantage so far (besides "our tools can't handle anything else", but in practice it seems to work fine, and of course avoiding stuff associated with a certain company which I understand is a goal in itself for some people)... I would appreciate a list of technical and ideological reasons why switching to the Jackson layout is important for Debian. Ansgar
Bug#1043114: Please remove mipsel port from testing and sid
Hi, On Sun, 2023-08-06 at 16:50 +0800, YunQiang Su wrote: > Since the Y2038 problem, 2G user space memory limit, > and some lack of manpower, It's time for us to drop mipsel support > from the list of official release architectures. > > Note: please keep mips64el for now. Please stop building packages for mipsel for unstable/experimental so we can proceed here. Ansgar
Bug#1050001: enabling telemetry to track usage of /bin compat shims?
On Wed, 2023-08-23 at 20:50 +0200, Ansgar wrote:
> > /bin and /lib etc. remain directories (so there is no aliasing). All
> > actual files are shipped in /usr. / contains compatibility symlinks
> > pointing into /usr, for those files/APIs/programs where this is
> > needed
> > (which is far from all of them). Eventualloy, over time, the set of
> > compatibility links is reduced to a mere handful.
[...]
> How do you decide when to remove a link? Is there a simple mechanism to
> detect when users no longer use it?
I thought about this a bit. A possible solution might be using a small
wrapper program in /bin that tracks usage of the compat shim (possibly
together with minimal information about the callee) plus a telemetry
service collecting this data and submitting it to Debian.
The shim should also look at $PATH and make some educated guess whether
it was invoked explicitly using /bin/${something} or just as
${something} and PATH lookup would have found /usr/bin/${something}
either way.
To get accurate data, this should be enabled by default (with
possibility to opt out).
I think solving this issue is crucial before we can agree on proceeding
the proposed switch to the Jackson filesystem layout.
Ansgar
Bug#1050001: Unwinding directory aliasing
Control: retitle -1 migrate from merged-/usr to new alternative filesystem layout On Thu, 2023-08-24 at 13:36 -0600, Sam Hartman wrote: > > > > > > For myself, I think the issues raised in DEP17 are significant enough > that I would at least read a proposal to explain a different way to get > to a merged /usr system. > I.E. yes, I believe that something has changed significantly enough that > I would be willing to read proposals for alternate ways to get to the > end goal we've agreed to. > > However: > > 1) Jackson is not making such a proposal. Yes, we are talking about migrating all installations to a new, alternative filesystem layout now. Which was mentioned years ago already and dismissed (for reasons). The proposal to move to this alternative layout and why one would want to do so hasn't seen any recent discussion before coming to the tech- ctte as far as I know. If someone wants to go this way, I suggest to just have a GR about it instead of iterating this at tech-ctte yet again. It's not very motivating to have some people endlessly argue against moving forward and wanting to revisit/reverse/change some decisions endlessly. Ansgar
Bug#1050001: Unwinding directory aliasing
Hi Simon, On Wed, 2023-08-23 at 20:12 +0100, Simon McVittie wrote: > I'm keen to avoid the anti-pattern where a valid technical point gets > disregarded or even opposed because the way it was expressed puts > other project members on the defensive. [...] > I alluded to that in a previous mail to this thread, but I don't have > first-hand knowledge of the specifics of how that went, and it sounds > as though you might. Do you have references that you can point us to? > (To the list or as private email for me to summarize on-list later, > whichever seems more appropriate. Does it matter? Is it worth investing time into investigating this? Or are we not really considering moving to the proposed Jackson filesystem layout? (In which case it's probably not worth investing time to look what SuSE did in detail.) And the more important question: how often do we want to rehash the usrmerge discussion? At some point we should stick with a decision and not endlessly restart discussions (unless something really significant changes, but I don't think this is the case). *mumble* leadership something *mumble* If we want to restart discussions, we can talk about init system support in Debian and costs/benefits of supporting some of them. :-) Ansgar
Bug#1050001: Unwinding directory aliasing
Hi,
On Wed, 2023-08-23 at 17:04 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Bug#1050001: Unwinding directory aliasing"):
> > What do you consider to be the end goal of this proposal?
>
> Desired end state
> =
>
> This is a very good question. I had a very constructive conversation
> with Helmut via video chat. It seems that there's a misunderstanding
> about the desired end state.
>
> My idea of a desired end state is as follows:
>
> /bin and /lib etc. remain directories (so there is no aliasing). All
> actual files are shipped in /usr. / contains compatibility symlinks
> pointing into /usr, for those files/APIs/programs where this is
> needed
> (which is far from all of them). Eventualloy, over time, the set of
> compatibility links is reduced to a mere handful.
Cool, so we need to touch all packages shipping packages in /usr/bin to
also include a /bin symlink? Like /bin/python3 -> /usr/bin/python3?
(And yes, users use these, so they are necessary unless you want to
break working systems; if so please provide good reasons).
How do you decide when to remove a link? Is there a simple mechanism to
detect when users no longer use it?
> I think this is a more desirable situation than the current planned
> end state, which is that /bin and /lib are symlinks.
Why should we invent again another, incompatible filesystem layout?
Is there any good technical reason to do so? One that was not discussed
already?
Sorry, I feel like we are going back ignoring any discussion in the
last years and would invite you to read what was discussed about these
approaches in previous discussions first. So far it looks like NIH
syndrome, similar to the need to invent yet another daemon readiness
protocol when systemd was the topic.
> Looking towards the future
> --
>
> It seems to me that directory aliasing will continue to be a source
> of very annoying bugs indefinitely, well after the transition is
> fully complete. In another 20 years we'll still be debugging strange
> installation breakage that will turn out to be due to directory
> aliasing.
But introducing an incompatible filesystem where we only detect that
something references files in the wrong path (as presumably only a
random subset will be in /bin) will not give any bugs?
We already *had* these bugs for several releases and found them only
after release (even before usrmerge which makes them non-bugs).
Please provide a plan how to fix these ahead of time; please be aware
that they might only occur with some hardware / configurations.
Ansgar
Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken
Hi,
On Sat, 2023-08-19 at 11:17 +0200, Vincent Lefevre wrote:
> First, I initially wasn't aware that this was assuming usrmerge:
> there was no announce at all. Moreover, doing partial upgrades
> is not breaking the system. This is perfectly allowed. That's why
> there is a dependency system, and here, no Depends or Recommends
> was broken.
No, packages in testing/unstable will expect essential packages to come
from stable or later without explicit versioned dependencies.
If you mix oldstable + unstable packages, you create an unsupportable
system state ("Frankendebian"). If something then breaks, you get to
fix it yourself; don't expect others to support such a setup.
Ansgar
Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken
On Fri, 2023-08-18 at 22:45 +0200, Vincent Lefevre wrote: > On 2023-08-18 07:35:33 +0200, Ansgar wrote: > > Please investigate why "usrmerge" is not installed (I assume this is an > > upgraded system). Or, if it is installed, why /bin, /sbin, /lib* are > > not symlinks to their respective counterparts in /usr. > > I've not upgraded init-system-helpers to 1.65.2 yet Please don't file RC bugs if you intentionally break your system. Probably not non-RC bugs either. Ansgar
Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken
Control: retitle -1 trixie/sid system ended up with split-usr Hi, On Thu, 17 Aug 2023 18:42:14 +0200 Vincent Lefevre wrote: > Control: retitle -1 cron-daemon-common: in /etc/crontab, run-parts is no > longer in $PATH > > That's actually the real reason. > > /etc/crontab has > > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin > > but > > zira:~> dlocate =run-parts > debianutils: /bin/run-parts This seems the be the real issue: +--- | Debian Release: trixie/sid | [...] | merged-usr: no +---[ https://bugs.debian.org/1049969#5 ] /bin *must* be a symlink to /usr/bin, so /usr/bin/run-parts must exist and cron's PATH is sufficient. Please investigate why "usrmerge" is not installed (I assume this is an upgraded system). Or, if it is installed, why /bin, /sbin, /lib* are not symlinks to their respective counterparts in /usr. Ansgar
Bug#1049462: dpkg-source: Ignore __pycache__ by default (was: Re: __pycache__ directories)
Package: dpkg Severity: wishlist X-Debbugs-Cc: Michael Biebl , debian-de...@lists.debian.org On Mon, 2023-08-14 at 22:09 +0200, Michael Biebl wrote: > I received a couple of bug reports against packages I (co) maintain > regarding this issue and having a quick look, quite a few fail due to > python scripts being run during the build and creating a __pycache__ > directory. dpkg-source already ignores various paths for the diff when building source packages, for example ".git", ".svn", "CVS", "*~", ... Maybe $diff_ignore_default_regex should just be extended to include "__pycache__" as well and these would be non-issues. Ansgar
Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE
On Sun, 2023-07-16 at 12:54 +0100, Simon McVittie wrote: > On Sun, 16 Jul 2023 at 12:42:11 +0100, Luca Boccassi wrote: > > In the meanwhile, I'll immediately revert the sabotage. > > Both of you, please don't turn this into an NMU war in the archive: > that doesn't benefit anyone. I would have preferred it if Adam had not > immediately uploaded a 0-day revert, but preserving the status quo from > bookworm is not the worst state to be in while we discuss this. No, we should just have made a decision a long time ago and not go back and forth the entire time. That we do not do that shows lack of leadership in Debian. (And yes, you can reconsider stuff, but the barrier to stop a process and reconsider it again should not be zero and probably higher the later one does block progress.) > If Adam's concerns about this change are valid, then we should address > them, either by doing something different in debootstrap or by reporting > bugs against affected packages. I guess Adam could go ahead with the GR he wanted to bring up the last time he did NMUs this way (for reverting enabling usrmerge by default on upgrades). I would like to ask Adam to stop interfering with usrmerge until that long announced GR is there (and note that if we waited for that GR to happen as Adam demanded then we would still be waiting). > If Adam's concerns about this change turn out to be unfounded, then we > should reinstate my change (as NMU'd by Luca) in a calm and considered > way, and all we will have lost is a few days of progress and a few bytes > of changelog. That is false in so far as that only considers technical changes we get. However we also lose more and more energy/motivation/* even if we eventually go ahead as planned, i.e., social costs are not considered, but should be (IMHO). Ansgar
Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services
Hi, On Sun, 2023-06-25 at 18:51 +0100, Luca Boccassi wrote: > Patch attached and pushed to > https://salsa.debian.org/bluca/policy/-/commits/mandatory_units?ref_type=hea I support this as using the compat layer with systemd-sysv-generator has some limitations that confuse users (e.g., behavior of "start" as the unit stays running due to RemainAfterExit=yes set). We should really aim at providing native systemd units. There is one part I think should not be changed: we currently don't require integration with service management at all. That should probably not be changed. So please consider reverting +--- | Packages that include system services must include ``systemd`` service +--- to the original +--- | Packages that include system services should include ``systemd`` service +--- Ansgar
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Hi Luca, On Tue, 2023-06-20 at 22:53 +0100, Luca Boccassi wrote: > Russ, anything I've missed that you want me to change from the most > recent revision at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269#160 ? I suggest a minor change: In the paragraph +--- | Init systems other than ``systemd`` should allow providing the same | functionality as appropriate for each system, for example managing the | directories from the init script shipped by the package. +--- change "init script shipped by the package" to "appropriate service startup configuration". This should address concerns raise on d-devel@ that some packages might not ship an init script. It also better covers alternative init systems that do something more interesting than just starting the same sysvinit scripts of old (not sure if any do). Ansgar
Bug#1038886: /usr/share/initramfs-tools/hooks/udev fails in chroot
On Thu, 2023-06-22 at 14:56 +, Patrick Schleizer wrote: > ls -la /lib/systemd/systemd-udevd > lrwxrwxrwx 1 root root 12 Feb 28 11:15 /lib/systemd/systemd-udevd -> > /bin/udevadm > > ls -la /bin/udevadm > ls: cannot access '/bin/udevadm': No such file or directory What is the output of ls -ld /bin /bin/udevadm /usr/bin/udevadm ? How did you create the chroot? Ansgar
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Tue, 2023-06-13 at 12:51 -0700, Russ Allbery wrote: > I still am curious if it's safe to configure the same files in both > tmpfiles.d and in the unit file, because it would make it much easier for > those who want to support other init systems to do so. Having this configured in two places would at least be confusing for users: where would users need to change settings? In the unit file? In the tmpfiles files? Both? Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Matthew Garrett writes: > With my non-CTTE hat on, I think this is a demonstration that Debian > *does* care about derivatives. It's important to ensure that derivatives > are aware of the subtle interactions between dpkg and usrmerge, > otherwise they may suffer from hard to diagnose issues on upgrades. The > message from dpkg says nothing about reverting to split-/usr, and > instead points at a wiki page. If our documentation on how to avoid > these issues is incomplete (ie, if we're only describing how to avoid it > by using split-/usr rather than describing the mitigations we've imposed > within Debian to avoid triggering the issues), perhaps a better approach > would be to improve that documentation? We don't benefit our users by > pretending there isn't a problem here. Okay, I followed your recommendation and added a small warning to the FAQ: https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff=78=79 Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Tue, 2023-06-13 at 20:01 +0100, Matthew Garrett wrote: > After discussing this at our monthly meeting, we concluded that the > technical committee isn't going to take action on this at the moment. > There's a legitimate technical consideration behind the warning, and > it's necessary for derivatives to ensure that they handle the > associated scenarios properly. Okay, I take that as "Debian doesn't care about derivatives". Suggesting users to revert to split-/usr *will* break stuff for users once more code Debian assumes merged-/usr. > While those underlying technical issues exist, we > think it's premature for the committee to intervene on this specific > issue. Okay, I guess the very long drama about this last year was not sufficiently long and we did not discuss it in sufficient detail. I'm a bit disappointed how the ctte appears to do as much as they can to avoid deciding on this :-( Ansgar
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Tue, 2023-06-13 at 18:36 +0200, Marco d'Itri wrote: > On Jun 13, Bill Allombert wrote: > > > Conversely, sometimes I need to use chroots to test init scripts. > > start-stop-daemon should not refuse to run in a chroot if policy- > > rc.d allows > > it. > I suggest that you try systemd-nspawn for this purpose. > Or podman or docker or various other things. Plain chroots and an unclean environment which violates various assumptions system startup scripts make are not a great way to test stuff. Ansgar
Bug#820423: 64-bit time_t transition for 32-bit archs: a proposal
On Fri, 2023-06-09 at 09:22 +, Holger Levsen wrote: > On Fri, Jun 09, 2023 at 11:49:21AM +0800, Paul Wise wrote: > > > You mean by somehow refreshing the signatures there? > > Some ideas for that are here: > > https://bugs.debian.org/763419 > > https://bugs.debian.org/820423 > > interesting. thanks for those pointers! I did write a prototype once, but haven't touched it for some time. For example: https://defi.43-1.org/debian-defi-archive/debian/dists/stretch-backports/InRelease (It should also work for other things.) The test key is available from https://defi.43-1.org/defibrillator-test-key.asc Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Tue, 2023-06-06 at 11:04 +0100, Sean Whitton wrote: > I don't think the TC has or should have any authority over dpkg > upstream, but with dpkg being a native package, any implementation of > our decision for the Debian archive is also implemented for dpkg > upstream. And it might be that the dpkg developers would be against > the TC override solely or mostly because of this fact. So possibly > changing that would resolve things peacefully. Given the Debian project owns dpkg.org, the upstream mailing list is @lists.debian.org, official releases are published on deb.debian.org and so on, I think the Debian project *is* the upstream for dpkg. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On Sun, 2023-05-21 at 16:25 +0200, Helmut Grohne wrote: > On a process level, I think I miss attempts to resolve this with the > dpkg maintainer in a constructive way. The patch was already suggested to the dpkg maintainer and rejected. > Does anyone mind just closing the bug? Yes, I do. Please pass a resolution that you don't want to override the dpkg maintainer and that telling derivative users to configure their system in a way that will cause breakage is okay to do for packages in Debian. Ansgar
Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386
Package: release-notes X-Debbugs-Cc: Steve McIntyre , debian-de...@lists.debian.org On Fri, 2023-05-19 at 15:03 +0100, Steve McIntyre wrote: > I had been thinking about doing similar for installer images too, but > with other work going on too I think it got too late in the cycle to > make that change. My plan is therefore to ship i386 installer images > for bookworm as normal (including bookworm point releases going > forwards), but to disable those builds for testing/trixie > ~immediately after the release. I suggest to already document this in the release notes for bookworm, possibly in Section 2.1 (Supported architectures) or a subsection in Section 5 (Issues to be aware of for bookworm). Maybe something along these lines: +--- | Debian 12 is expected to be the last Debian release providing | full support for i386. Debian 13 will only partially support | i386 and no longer provide installation media for i386. | | We recommend hosts still running the i386 port to be upgraded | to amd64. Legacy i386 software can be run using multi-arch, | chroot environments or containers. +--- Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi, On Fri, 2023-05-19 at 07:09 -0700, Sean Whitton wrote: > On Thu 18 May 2023 at 07:55PM +02, Ansgar wrote: > > > Why not? > > We will not move that fast. So there is no real reason? As there doesn't seem to be anything you think need to be talked about that is missing to get to a decision (given you ignored all other questions multiple times). Do you expect this to take longer than 2-3 months? I would suggest to just use a GR in that case: it seems quicker and less painful than a multi-month long process for a simple(!) question. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Thu, 2023-05-18 at 12:14 -0600, Gunnar Wolf wrote: > Ansgar dijo [Thu, May 18, 2023 at 07:55:03PM +0200]: > > Why not? > > > > Do you think the implications of removing the warning are unclear? > > > > Do you think we need to explore alternative solutions? > > (I am no longer part of the Committee, answering just as another > developer) > > dpkg has many bits that make it special. It has been discussed whethe > dpkg should be a native package or it should become non-native; if it > were non-native, having a patch that contradicts the upstream > author's wishes would be easier (and I'm not saying that I'd be up > for patching this warning out as it is). Do you think this implementation detail is relevant for what we do in Debian? I don't care how a patch is applied and don't think that detail has to be part of the decision. I also don't see any further active discussion on this aspect (unless I missed something). > If we were to force a patch silencing out this warning right now and > for all of the Bookworm cycle, and the dpkg authors disagree with it, > they could remove (even omit to include it) in any updates. So? That is the case with any ruling the ctte makes, including the non- binding one the ctte just did under Constitution 6.1.5. > Upstream > has repeatedly expressed their opposition to the way usrmerge has > been brought forward, and the warning silenced specifically for > Debian is already the best compromise situation we have been able to > reach -- even though we are aware the situation is far from ideal. If the best solution we have been able to reach is telling users of derivative distributions to configure their system in a way that is expected to cause breakage, then it would be worth documenting that this is the case and we cannot do more for derivative users. If the ctte believes this to be fine, then the ctte can decide to not overrule the maintainer. I don't think this is a good reason to delay the decision indefinitely unless there is some reason to believe something will change within a reasonable period of time (which I don't see happening). Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi, On Thu, 2023-05-18 at 10:48 -0700, Sean Whitton wrote: > On Thu 18 May 2023 at 07:21PM +02, Ansgar wrote: > > > The full freeze is approaching and there has been no progress on > > this > > issue. Does the ctte think a decision before the release is still > > possible? > > Not speaking for the whole ctte, but I don't think that is possible. Why not? Do you think the implications of removing the warning are unclear? Do you think we need to explore alternative solutions? Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
Hi, On Thu, 2023-05-11 at 00:32 +0200, Ansgar wrote: > On Wed, 2023-05-10 at 23:47 +0200, Ansgar wrote: > > Cool, then let's ask tech-ctte. > > > > Dear ctte, please consider overruling the dpkg maintainer to > > include > > the patch from #994388[1]. > > > > Thanks, > > Ansgar > > > > [1]: https://bugs.debian.org/994388#397 > > For derivatives based on Debian stable it might be worth having this > included in the next stable release; this would need a fairly quick > decision on this issue. The full freeze is approaching and there has been no progress on this issue. Does the ctte think a decision before the release is still possible? As asked earlier I'm also interested in whether the ctte thinks there is enough consensus about how this issue should be solved or do we need a longer discussion to explore the solution space? I admit not having read all mails in the thread as it went fairly off topic IMHO. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Wed, 2023-05-10 at 19:01 -0700, Sean Whitton wrote: > On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote: > > Cool, then let's ask tech-ctte. > > > > Dear ctte, please consider overruling the dpkg maintainer to > > include > > the patch from #994388[1]. > > > > Thanks, > > Ansgar > > > > [1]: https://bugs.debian.org/994388#397 > > This would require a new, maintainer-overruling vote. > Our existing decisions do not apply, so far as I can tell. Yes, I agree. > I have written a separate message to the bug and to debian-dpkg with > a proposal to avoid having to have such a vote. That seems to be about an implementation detail on how to apply the patch. I don't think that is the core of the issue? The core issue as I see it is as follows: - Debian has decided to support only merged-/usr, including possibly moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 as the interpreter in binaries. - This change breaks on non-merged-/usr systems, including derivatives that do not revert *all* relevant changes. (Do you know one that does this or plans to do so?) - dpkg recommends derivative users to move to non-merged-/usr. I think this contradiction is not good and the core conflict. For me a distribution should have some coherence. It is not just a distribution of unrelated parts (like linux, libc, dpkg, dash, ...), but also integrates them to work together. And this also means not one package telling users to do X which breaks other packages. Or (if other packages would do similar things as dpkg) one package asking users to do X and the other asking users to do the opposite of X. Just imagine dpkg asking users to move to split-/usr and then another package starting to warn users to move back to merged- /usr. Would that be a good state? I think not which is why this bug exists. Do you think this summary of the issue is right? Is there some consensus about how this issue should be solved or do we need a longer discussion to explore the solution space? Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On Wed, 2023-05-10 at 23:47 +0200, Ansgar wrote: > Cool, then let's ask tech-ctte. > > Dear ctte, please consider overruling the dpkg maintainer to include > the patch from #994388[1]. > > Thanks, > Ansgar > > [1]: https://bugs.debian.org/994388#397 For derivatives based on Debian stable it might be worth having this included in the next stable release; this would need a fairly quick decision on this issue. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
Package: tech-ctte X-Debbugs-Cc: Russ Allbery , Sean Whitton , Helmut Grohne , Luca Boccassi , debian-d...@lists.debian.org, debian-de...@lists.debian.org On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote: > Ansgar writes: > > Debian going out of its way to tell derivative users to switch back from > > merged-/usr to split-/usr is the *opposite* of trying to make things as > > smooth for them as possible. > > Yes, I agree with that part and I think I objected to that at the time. > Nonetheless, one bad decision doesn't mean that it is Debian policy that > we don't care about derivatives or their users. I think we made a mistake > there which is not in alignment with our ideals or our goals. We should > try to reverse that mistake, not double down on it. Cool, then let's ask tech-ctte. Dear ctte, please consider overruling the dpkg maintainer to include the patch from #994388[1]. Thanks, Ansgar [1]: https://bugs.debian.org/994388#397
Bug#830857: [Pkg-libvirt-maintainers] Bug#830857: libvirt-daemon: CPU feature cmt not found
Hi, since I'm not using this Debian/libvirt version anymore, I think the issue can be closed/marked as resolved. Thanks, Ansgar On Thu, 2023-04-27 at 17:26 +0200, Emanuele Rocca wrote: > Hi, > > On Tue, Jul 12, 2016 at 08:22:31PM +0200, Ansgar Hegerfeld wrote: > > Okay, thanks. I opened a bugreport upstream: > > https://bugzilla.redhat.com/show_bug.cgi?id=1355857 > > The upstream bug was fixed a long time ago. Is the issue still reproducible in > Debian, or can this bug be closed? > > Thanks, > ema
Bug#1029214: debian-archive-keyring: bookworm archive signing keys
Adam D. Barratt wrote: > We need new archive signing keys for bookworm, so that we can include > them in the release. The keys are published now, see https://lists.debian.org/debian-devel-announce/2023/03/msg1.html Ansgar
Bug#1031389: gdm3: installing fprintd, but not libpam-fprintd makes login via gdm impossible
On Thu, 2023-02-16 at 10:20 +, Simon McVittie wrote: > > I logged in via getty and installed libpam-fprintd and could login > > again. > > > > GDM should not make login impossible when fprintd is installed and > > libpam-fprintd is not. Login via password should still be possible > > in > > this case. > > In principle the /etc/pam.d/gdm-fingerprint PAM stack could probably > fall back to password authentication, but I'm not sure how that would > be achieved. Marco Trevisan would probably know better? GDM does still allow password login as a fallback, but only when libpam-fprintd is installed. Otherwise login fails before a password prompt is shown. Ansgar
Bug#1031389: gdm3: installing fprintd, but not libpam-fprintd makes login via gdm impossible
Package: gdm3 Version: 43.0-3 Severity: important Tags: upstream I wanted to try out the fingerprint reader in my laptop and installed fprintd (but not libpam-fprintd yet). I also did not yet configure any fingerprints. However after a reboot I could no longer login (I could still unlock the screen before the reboot). The system journal says: +--- | Feb 16 09:35:34 gdm-fingerprint][1708]: PAM unable to dlopen(pam_fprintd.so): /lib/security/pam_fprintd.so: cannot open shared object file: No such file or directory | Feb 16 09:35:34 gdm-fingerprint][1708]: PAM adding faulty module: pam_fprintd.so | Feb 16 09:35:34 gdm-fingerprint][1708]: gkr-pam: no password is available for user | Feb 16 09:35:34 gdm-fingerprint][1716]: PAM unable to dlopen(pam_fprintd.so): /lib/security/pam_fprintd.so: cannot open shared object file: No such file or directory | Feb 16 09:35:34 gdm-fingerprint][1716]: PAM adding faulty module: pam_fprintd.so | Feb 16 09:35:34 gdm-fingerprint][1716]: gkr-pam: no password is available for user +--- There was no prompt for the password at all: I chose my user and was returned back to the user selection. I logged in via getty and installed libpam-fprintd and could login again. GDM should not make login impossible when fprintd is installed and libpam-fprintd is not. Login via password should still be possible in this case. I also noticed that for some reason there is a "]" after "gdm-fingerprint" and before the PID in the log. That might also be a minor bug. Ansgar -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (300, 'buildd-unstable'), (300, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 22.08.8-5 ii adduser 3.131 ii dbus [default-dbus-system-bus]1.14.6-1 ii dbus-bin 1.14.6-1 ii dbus-daemon 1.14.6-1 ii dconf-cli 0.40.0-4 ii dconf-gsettings-backend 0.40.0-4 ii debconf [debconf-2.0] 1.5.82 ii gir1.2-gdm-1.043.0-3 ii gnome-session [x-session-manager] 43.0-1 ii gnome-session-bin 43.0-1 ii gnome-session-common 43.0-1 ii gnome-settings-daemon 43.0-4 ii gnome-shell 43.2-2 ii gnome-terminal [x-terminal-emulator] 3.46.7-1 ii gsettings-desktop-schemas 43.0-1 ii libaccountsservice0 22.08.8-5 ii libaudit1 1:3.0.7-1.1+b3 ii libc6 2.36-8 ii libcanberra-gtk3-00.30-10 ii libcanberra0 0.30-10 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgdm1 43.0-3 ii libglib2.0-0 2.74.5-1 ii libglib2.0-bin2.74.5-1 ii libgtk-3-03.24.36-3 ii libgudev-1.0-0237-2 ii libkeyutils1 1.6.3-2 ii libpam-modules1.5.2-6 ii libpam-runtime1.5.2-6 ii libpam-systemd [logind] 252.5-2 ii libpam0g 1.5.2-6 ii librsvg2-common 2.54.5+dfsg-1 ii libselinux1 3.4-1+b5 ii libsystemd0 252.5-2 ii libx11-6 2:1.8.3-3 ii libxau6 1:1.0.9-1 ii libxcb1 1.15-1 ii libxdmcp6 1:1.1.2-3 ii polkitd 122-3 ii procps2:4.0.2-3 ii systemd-sysv 252.5-2 ii ucf 3.0043+nmu1 ii x11-common1:7.7+23 ii x11-xserver-utils 7.7+9+b1 Versions of packages gdm3 recommends: ii at-spi2-core 2.46.0-5 ii desktop-base 12.0.2 ii gnome-session [x-session-manager] 43.0-1 ii x11-xkb-utils 7.7+7 pn xserver-xephyr pn xserver-xorg ii zenity 3.44.0-1 Versions of packages gdm3 suggests: ii libpam-fprintd1.94.2-2 ii libpam-gnome-keyring 42.1-1+b1 pn libpam-pkcs11 pn libpam-sss ii orca 43.1-1 -- Configuration Files: /etc/pam.d/gdm-password changed [not included] -- debconf information excluded
Bug#801065: Documenting how to not fail postinst on service fails to start
On Sat, 2023-02-11 at 21:12 -0800, Russ Allbery wrote: > An interesting problem case is a package whose point is to run a service, > but which requires mandatory and not-automatable setup before the service > can usefully run. After package installation, the service cannot start. > So the options are either attempt to start the service as normal in the > postinst but ignore the failure, or add some more complex logic to > postinst to attempt to determine whether the service has been set up > properly and only attempt to start the service if it has. Just do not enable the systemd unit for the service by default for such services. If an admin has configured and enabled then the service will be (re)started. If the admin has not done anything then the service will not be started and there is no error to ignore. You need to do that for "automatable setup" too if the automation means debconf as the admin might not have answered to the questions, for example when the package is installed in an automated setup ;-) Ansgar
Bug#1030668: dinstall could run more often (every hour?)
Control: tag -1 + moreinfo On Mon, 2023-02-06 at 12:31 +0100, Gioele Barabucci wrote: > > Can you please show the error you got from the upload? > > A -2 version will be REJECTed by mentors.d.n if version -1 is still > being processed: That is a mentors.d.n issue and can still happen as mirror pushes take time. mentors.d.n might want to use incoming.d.o as well. > > Not sure what you mean. Can you please explain the workflow you > > are talking about? > > The linked Michale Stapelberg's blog post explains it better than I > can: > > https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/#old-infrastructure-package-uploads That sounds like Michael didn't know about incoming.d.o which has been publically accessible since 2014[1]. [1]: https://lists.debian.org/debian-devel-announce/2014/08/msg8.html Please explain what issues you have that are not solved by using incoming.d.o. Ansgar
Bug#1030189: Let regular users know need to put non-free-firmware in sources.list
On Wed, 2023-02-01 at 20:13 +0100, IOhannes m zmölnig wrote: > Am 1. Februar 2023 01:30:10 MEZ schrieb Dan Jacobson > : > > So he must do Google Search. > > Do you think this problem only affects make users? I would expect at least ninja-build users to be affected as well unless they use a VM. Ansgar
Bug#1029214: debian-archive-keyring: bookworm archive signing keys
Hi, On Thu, 2023-01-19 at 18:22 +, Adam D. Barratt wrote: > We need new archive signing keys for bookworm, so that we can include > them in the release. We have in principle a new key prepared. It is now in the frustrating phase of trying to collect replies from other people that they have received the recovery share. Or that the share was lost on the way. I'm not sure how long it will take. Ansgar
Bug#1029831: debian-policy: Make required packages build-essential
On Sun, 2023-01-29 at 13:53 +0100, Santiago Vila wrote:
> What you call current practice is only current debootstrap behaviour.
Then I'll reply here as well (content is the same as -devel):
Current practice is to use Build-Depends to specify build dependencies
in a way that the buildd network will successfully build packages. The
data might also be of (limited) use for other purposes.
We do *not* specify additional Build-Conflicts (that might make builds
fail / produce different results). Neither does the buildd network
require that packages already installed are listed additionally in
Build-Depends to install those and build packages successfully.
The set of preinstalled packages in build environments is decided by
the debootstrap implementation, so yes, the debootstrap behavior is
current practice.
If you want Build-{Depends,Conflicts} to provide stronger promises,
that is a change from current practice. And could be extended to
forcing /usr/local to be empty and a sane, standard environment and
contents of $HOME and anything else that could affect build results.
Ansgar
Bug#1029831: debian-policy: Make required packages build-essential
Package: debian-policy [ This is basically #1027832 ] Timo Röhling writes: > * Andreas Henriksson [2023-01-28 12:50]: >>Policy is not a religion. Policy has many bugs. Policy is very outdated. >>[...] >>Here's an example you could follow: >>https://lists.debian.org/debian-policy/2022/12/msg00023.html > Your argument cuts both ways. Right now, Policy says that > the bugs are RC, and if you believe that should be different, why > don't you propose such a change and seek consensus yourself? I don't think it does. Policy doesn't specify what packages actually are build-essential; it only refers to an "informational list" in Section 4.2. I think discussion in #1027832 suggested that required packages should be build-essential as well. Maybe this should be made explicit, for example by changing +--- | The required packages are called build-essential, and an informational | list can be found in /usr/share/doc/build-essential/list (which is | contained in the build-essential package). +---[ Section 4.2 ] to something like +--- | The required packages are called build-essential, and include packages | with Priority "required" and additional packages. An informational | list of additional packages can be found in | /usr/share/doc/build-essential/list (which is contained in the | build-essential package). +--- This only documents existing practice as practically all systems have required packages installed. Ansgar
Bug#1029518: git: "git bundle create" results in segfault
Package: git Version: 1:2.39.0-1 Severity: minor File: /usr/bin/git Tags: upstream Running "git bundle create" (without further arguments) results in a segmentation fault: +--- | $ $ git bundle create | Segmentation fault (core dumped) +--- It works fine if I add the other required arguments, but I expected an error message telling me what the other arguments are and in which order "git bundle create" expects them. Ansgar -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (300, 'buildd-unstable'), (300, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git depends on: ii git-man 1:2.39.0-1 ii libc62.36-8 ii libcurl3-gnutls 7.87.0-2 ii liberror-perl0.17029-2 ii libexpat12.5.0-1 ii libpcre2-8-0 10.40-3 ii perl 5.36.0-7 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages git recommends: ii ca-certificates 20211016 ii less 590-1.1 ii openssh-client [ssh-client] 1:9.1p1-2 ii patch2.7.6-7 Versions of packages git suggests: ii gettext-base 0.21-10 pn git-cvs pn git-daemon-run | git-daemon-sysvinit pn git-doc pn git-email ii git-gui 1:2.39.0-1 pn git-mediawiki pn git-svn ii gitk 1:2.39.0-1 pn gitweb -- no debconf information
Bug#1028961: dpkg: reverts to using insecure cryptographic algorithms by default
Package: dpkg Version: 1.21.13 Severity: serious Tags: security X-Debbugs-Cc: Debian Security Team Hi, dpkg 1.21.13 introduced passing "--openpgp" to GnuPG by default due to some conflict between the dpkg maintainer and gnupg upstream. This causes GnuPG to use insecure cryptographic algorithms like the SHA-1 digest algorithm by default. Please revert https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?h=1.21.13=b83114daa69c50d368199d00fbb67e190068b273 I do not think that cryptographic default from over 15 years ago are a good default choice today; rather they are a security issue (just like, for example, reverting to using SSL3 instead of TLS1.3). Ansgar -- Package-specific info: This system uses merged-usr-via-aliased-dirs, going behind dpkg's back, breaking its core assumptions. This can cause silent file overwrites and disappearances, and its general tools misbehavior. See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>. I think this message should be removed as it confuses users.
Bug#1028523: dpkg-dev: No obvious way to include upstream signature in dpkg-genchanges
Hi, On Thu, 12 Jan 2023 11:29:53 +0100 Helge Kreutzmann wrote: > -- Package-specific info: > This system uses merged-usr-via-aliased-dirs, going behind dpkg's > back, breaking its core assumptions. This can cause silent file > overwrites and disappearances, and its general tools misbehavior. > See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>. > > I did not do this on purpose. Strange that I'm told this by reportbug > and not some other means? There was a project decision to adopt usrmerge so no other tool warns about it. dpkg's maintainer is unhappy with the project decision and included this warning which sadly unsettles users. Ansgar
Bug#1008281: setting sysctl net.ipv4.ping_group_range
On Sat, 2023-01-07 at 16:55 -0800, Steve Langasek wrote: > On Tue, Jan 03, 2023 at 03:26:37AM +0100, Marco d'Itri wrote: > > > Nowadays systemd is a source of common sysctl settings among different > > distributions. > > Debian still supports other init systems in the archive besides systemd. Not really: we only support exploring and developing alternative init systems. That doesn't mean full support and random things might not work correctly (and that is accepted). > Should ping fail to run on a Debian system that is not using systemd? Why not? It's not different from other software where we allow this? > We also recently ran into a bug with systemd in Ubuntu because the "common > sysctl settings among different distributions" that they had added clobbered > settings that had been shipped for years already in the Ubuntu procps > package. No thank you. > > https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962038 > > What would really be a great place for shipping common sysctl settings among > different distributions would be in the Linux kernel, instead of diverging > from the kernel defaults in userspace and representing this as "common". I think I read somewhere that linux upstream is not enthusiastic about choosing more appropriate defaults and leaves that to downstream. Diverting those is only possible in userspace as we still support using self-built kernels (which can come from upstream) ;-) If you want some other "common" ground, I guess it would need to be created and adopted instead of the current one first. Ansgar
Bug#1026017: ITP: designate-tlds -- Designate TLDs population
On Tue, 2022-12-13 at 11:01 +0100, Thomas Goirand wrote: > * Package name : designate-tlds > Version : 0.0.1 > Upstream Author : Axel Jacquet > * URL : > https://salsa.debian.org/openstack-team/services/designate-tlds > * License : Apache-2.0 > Programming Lang: Python > Description : Designate TLDs population > > Designate provides DNSaaS services for OpenStack. It provides a multi-tenant > REST API for domain & record management. It is Integrated with Keystone for > authentication, and provides a framework in place to integrate with Nova and > Neutron notifications (for auto-generated records). Designate supports > PowerDNS and Bind9 out of the box. > > This package fill-up the Designate database with the global TLDs list > downloaded from Mozilla. I think the package description should explicitly state that "TLDs" is an abbrevation for "public suffix list" here as that is not a common use of that three letter acronym ;-) At least at a quick glance it doesn't seem to filter the list to only include top-level domains also listed on the public suffix list (I'm not sure all top-level domains are there?) Ansgar
Bug#1025502: dak: `dak rm -b ${package}` does not work if source of ${package} already gone
Package: ftp.debian.org
`dak rm -b ${package}` or other variants do not when when `${package}`'s
source is already removed. This happened with lostirc (bug #1024341).
The cause is likely the SQL queries in dak/rm.py that include
+---
| JOIN newest_source on s.source = newest_source.source AND su.id =
newest_source.suite
+---[ dak/rm.py ]
which then results in an empty set if `${package}`'s source is no longer
in the suite.
Ansgar
Bug#1024493: Proposed-RM: bs1770gain -- RoQA; inappropriate content
Source: bs1770gain Version: 0.6.5-1 Severity: serious Hi, I proposed to remove bs1770gain from Debian. Besides the problem from #913352, the upstream homepage and domain that we direct users to (via Homepage: field and other places) contain extremist content. I don't think it's worth distributing software that does this in Debian. If there are no objections from the maintainers, I'll reassign this to ftp.d.o in the next days. Ansgar
Bug#1023124: libsystemd-shared-251.so: cannot open shared object file
On Sun, 2022-10-30 at 13:34 +0100, Salvo "LtWorf" Tomaselli wrote: > Preconfiguring packages ... > Setting up systemd (252~rc3-2) ... > systemd-machine-id-setup: error while loading shared libraries: > libsystemd-shared-251.so: cannot open shared object file: No such file or > directory > dpkg: error processing package systemd (--configure): > installed systemd package post-installation script subprocess returned error > exit status 127 > Errors were encountered while processing: > systemd > E: Sub-process /usr/bin/dpkg returned an error code (1) The /bin/systemd-machine-id-setup shipped in the systemd 252~rc3-2 package is linked against libsystemd-shared-252.so, not libsystemd- shared-251.so. Please check all paths given in the PATH used when calling dpkg/apt for systemd-machine-id-setup (e.g., by using `which -a systemd-machine-id- setup` with the correct PATH) and report their location and sha1 hash (sha1sum /bin/systemd-machine-id-setup ...). Please also report the output of `ls -ld /bin /usr/bin` and whether the system is merged-/usr already or not. Ansgar
Bug#648185: reportbug: ftp.debian.org RM bugs should get X-Debbugs-CC: maintainer
On Sun, 2022-10-30 at 10:30 +0800, Paul Wise wrote: > In Debian bug #648185 it was proposed to set affects src:$PACKAGE > and XCC $PACKAGE@packages.d.o for ftp.d.o removal bugs. > > I would like to apply this to ftp.d.o override request bugs too and > also any future package related ftp.d.o bugs too. > > This would help maintainers and people reading the bugs web pages > find out about the removal, override and other requests. > > The reportbug maintainers usually require changes to pseudo-package > bugs to be approved by the teams owning those pseudo-packages. > > Would the above changes be acceptable to you? Sure, that looks reasonable to do. Ansgar
Bug#1022068: linux: kernel NULL pointer dereference in nouveau driver on Thinkpad W541
On Wed, 2022-10-19 at 18:47 +0200, Ansgar wrote: > After upgrading to linux 6.0.2-1 I see the following message during > boot: [...] > Besides the null pointer dereference above, suspend to RAM also no > longer works properly after the upgrade. I have not investigated that > further so far. At least this part is easy: after blacklisting the nouveau driver to avoid the warning about the NULL pointer dereference, suspend works again. Ansgar
Bug#1022068: linux: kernel NULL pointer dereference in nouveau driver on Thinkpad W541
c64_rocksoft crc_t10dif crct10dif_generic crc64 crct10dif_pclmul crct10dif_common drm_ttm_helper crc32_pclmul mxm_wmi crc32c_intel drm_buddy i2c_algo_bit drm_display_helper ghash_clmulni_intel drm_kms_helper cec rc_core ahci libahci ttm sdhci_pci xhci_pci cqhci libata xhci_hcd aesni_intel ehci_pci ehci_hcd crypto_simd serio_raw scsi_mod sdhci drm cryptd usbcore scsi_common mmc_core usb_common wmi battery video button dm_mod msr parport_pc ppdev lp parport efivarfs autofs4 | [3.860292] CR2: 0020 | [3.860307] ---[ end trace ]--- | [3.860320] RIP: 0010:nvif_object_mthd+0xba/0x200 [nouveau] | [3.861040] Code: 72 ce 41 8d 56 20 49 8b 44 24 08 83 fa 17 0f 86 35 01 00 00 4c 39 e0 0f 84 ea 00 00 00 4c 89 63 10 31 c9 48 89 de c6 43 06 ff <48> 8b 78 20 48 8b 40 38 48 8b 40 28 e8 d5 e3 95 ce 48 8b 3c 24 4c | [3.861725] RSP: 0018:a8e7409bb718 EFLAGS: 00010246 | [3.862422] RAX: RBX: a8e7409bb720 RCX: | [3.863110] RDX: 0028 RSI: a8e7409bb720 RDI: a8e7409bb748 | [3.863831] RBP: R08: a8e7409bb968 R09: 0008 | [3.864542] R10: 95661041f9c0 R11: a8e740e3 R12: 9565ca2114f8 | [3.865219] R13: a8e7409bb720 R14: 0008 R15: a8e7409bb740 | [3.865886] FS: 7fc0a2a6e8c0() GS:956d1e24() knlGS: | [3.866620] CS: 0010 DS: ES: CR0: 80050033 | [3.867309] CR2: 0020 CR3: 000100f74001 CR4: 001706e0 +--- I only use the integrated Intel graphics, the Nvidia card is unused. There was no null pointer dereference with the previous kernel (5.19.11-1 (2022-09-24)). Besides the null pointer dereference above, suspend to RAM also no longer works properly after the upgrade. I have not investigated that further so far. Ansgar -- System Information: Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_DIE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1021301: grub-pc: regression: update to 2.06-3~deb11u2 fails with gpt
Control: retitle -1 grub-pc: use persistent disk identifier stored in configuration file Control: affects -1 - release.debian.org [ Cc'ed -release@ to notify them it's not a regression after all ] On Wed, 05 Oct 2022 10:27:29 +0200 Ansgar wrote: > On Wed, 2022-10-05 at 09:48 +0200, Ansgar wrote: > > the upgrade to grub-pc 2.06-3~deb11u2 fails: > > > > +--- > > > Setting up grub-pc (2.06-3~deb11u2) ... > > > Installing for i386-pc platform. > > > grub-install: warning: this GPT partition label contains no BIOS > > > Boot Partition; embedding won't be possible. > > > grub-install: error: embedding is not possible, but this is > > > required for cross-disk install. > > > You must correct your GRUB install devices before proceeding: > > > > > > DEBIAN_FRONTEND=dialog dpkg --configure grub-pc > > > dpkg --configure -a > > > dpkg: error processing package grub-pc (--configure): > > > installed grub-pc package post-installation script subprocess > > > returned error exit status 1 > > > Errors were encountered while processing: > > > grub-pc > > > Log ended: 2022-09-23 06:09:42 > > +--- > [...] > > /dev/sda uses GPT and has one partition /dev/sda1; it was created > > this way by d-i (though it has the setting to use gpt enabled). > > Ah, but this was a distraction: /dev/sda isn't the boot device. The > boot device is currently /dev/sdb. That still has a DOS disk label; the > systems using GPT for the boot device as well have a small 1M partition > for BIOS boot. > > So grub-install shouldn't try to install to /dev/sda, but I find > nothing in /etc referencing /dev/sda at all (except for a comment in > /etc/fstab). So I'm not sure why the system tries to install grub > there. > > I now also checked /var/log/installer/syslog and when installing the > system /dev/sda and /dev/sdb were the other way around. And it looks > like that was the case before the previous reboot as well. > > So possibly one of the race conditions I read about? (FWIW, this is a > VM running under VMware.) >From some more investigation and chat on IRC: - Currently the only place where the configuration where grub should be installed is debconf, in particular grub-pc/install_devices. This should be moved to a configuration file in /etc. - grub should use a persistent device identifier instead of /dev/sda and similar. Steve McIntyre said on #-devel: | so we go to all the effort finding out the device details in a | sustainable way, then don't store it :facepalm: | we should be using a persistent device identifier here | and each time we run grub-install that should be re-resolved to a | /dev/*** reference | for added cleverness, we should also warn users that disks have moved | if we no longer find the disk(s) we expect to install ointo | and prompt for an update | so we pick up on disk replacement, etc. I think one has to check that grub doesn't get confused as well: in my case the device can be /dev/sda or /dev/sdb for Linux, but it should always be (hd0) for grub. Implementing this probably also requires changes to the grub-installer package. Ansgar
Bug#1021301: grub-pc: regression: update to 2.06-3~deb11u2 fails with gpt
On Wed, 2022-10-05 at 09:48 +0200, Ansgar wrote: > the upgrade to grub-pc 2.06-3~deb11u2 fails: > > +--- > > Setting up grub-pc (2.06-3~deb11u2) ... > > Installing for i386-pc platform. > > grub-install: warning: this GPT partition label contains no BIOS > > Boot Partition; embedding won't be possible. > > grub-install: error: embedding is not possible, but this is > > required for cross-disk install. > > You must correct your GRUB install devices before proceeding: > > > > DEBIAN_FRONTEND=dialog dpkg --configure grub-pc > > dpkg --configure -a > > dpkg: error processing package grub-pc (--configure): > > installed grub-pc package post-installation script subprocess > > returned error exit status 1 > > Errors were encountered while processing: > > grub-pc > > Log ended: 2022-09-23 06:09:42 > +--- [...] > /dev/sda uses GPT and has one partition /dev/sda1; it was created > this way by d-i (though it has the setting to use gpt enabled). Ah, but this was a distraction: /dev/sda isn't the boot device. The boot device is currently /dev/sdb. That still has a DOS disk label; the systems using GPT for the boot device as well have a small 1M partition for BIOS boot. So grub-install shouldn't try to install to /dev/sda, but I find nothing in /etc referencing /dev/sda at all (except for a comment in /etc/fstab). So I'm not sure why the system tries to install grub there. I now also checked /var/log/installer/syslog and when installing the system /dev/sda and /dev/sdb were the other way around. And it looks like that was the case before the previous reboot as well. So possibly one of the race conditions I read about? (FWIW, this is a VM running under VMware.) Ansgar
Bug#1021301: grub-pc: regression: update to 2.06-3~deb11u2 fails with gpt
Package: grub-pc Version: 2.06-3~deb11u2 Severity: important X-Debbugs-Cc: debian-rele...@lists.debian.org Hi, the upgrade to grub-pc 2.06-3~deb11u2 fails: +--- | Setting up grub-pc (2.06-3~deb11u2) ... | Installing for i386-pc platform. | grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. | grub-install: error: embedding is not possible, but this is required for cross-disk install. | You must correct your GRUB install devices before proceeding: | | DEBIAN_FRONTEND=dialog dpkg --configure grub-pc | dpkg --configure -a | dpkg: error processing package grub-pc (--configure): | installed grub-pc package post-installation script subprocess returned error exit status 1 | Errors were encountered while processing: | grub-pc | Log ended: 2022-09-23 06:09:42 +--- The previous version installed successfully and the system was booting without problems so far: +--- | Setting up grub-pc (2.06-3~deb11u1) ... | Installing for i386-pc platform. | Installation finished. No error reported. | Generating grub configuration file ... | Found linux image: /boot/vmlinuz-5.10.0-17-amd64 | Found initrd image: /boot/initrd.img-5.10.0-17-amd64 | Found linux image: /boot/vmlinuz-5.10.0-16-amd64 | Found initrd image: /boot/initrd.img-5.10.0-16-amd64 | Warning: os-prober will be executed to detect other bootable partitions. | Its output will be used to detect bootable binaries on them and create new boot entries. | done | Log ended: 2022-09-12 06:51:32 +--- /dev/sda uses GPT and has one partition /dev/sda1; it was created this way by d-i (though it has the setting to use gpt enabled). Ansgar
Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable
On Wed, 2022-09-28 at 17:59 -0400, Zack Weinberg wrote: > On 2022-09-28 5:30 PM, Ansgar wrote: > > On Wed, 2022-09-28 at 16:40 -0400, Zack Weinberg wrote: > > > "Available and usable at all times" is orthogonal to "maintainer > > > scripts > > > do not render the system unbootable". As I read things, *all* > > > packages > > > bear the responsibility of not rendering the system unbootable. > > > > No, it's a significantly weaker requirement than what you want to > > impose. If it is not available and usable at all time, it can > > clearly > > render the system unbootable (by not being available or usable at > > boot). > > The vast majority of Debian packages provide programs, libraries, > etc. > that are not used at all during the boot process. Therefore, *even > if* > those packages are currently unusable, due to a crash in the middle > of > an upgrade that left them unpacked-but-not-configured, or whatever, > they > can't prevent the system from coming up at least as far as the point > where it's possible to get a root shell and run `dpkg -a -- > configure`. Yes, those packages are irrelevant and I wasn't talking about them anywhere. So I don't know why you mention them now. > The small subset of packages that *are* used at boot time, do need to > take extra care to keep working even if they are unpacked but not > configured, and that subset and that extra requirement is codified as > the rules for (transitively) Essential packages. No, that is not correct. The set of packages required for boot is significantly larger than essential and not well defined. Common examples include: kernel, boot loaders, init system, ...; they are often required for boot, but not essential. I also don't think the essential requirements are sufficient for "works after system crash". > But *all* packages must take particular care *in their maintainer > scripts* to not render the system unbootable, because maintainer scripts > are all run with full root privileges, at a time when the system is in a > partially ill-defined state (since it is in the process of being > upgraded -- No, they usually aren't run in an ill-defined state. > this is why we have the "postinst scripts can't assume any > non-Essential functionality works" rule), There is no such rule. Seriously, this is getting nowhere. If you want to tell maintainers they are wrong and everything they do must be reverted, please at least inform yourself a bit more before filing bugs with tech-ctte or vague release-critical bugs. Especially if you do so for issues where people are already tired of talking about. > and yet it could still be in > active use (there has never been a requirement to take the system to > single-user mode before running 'apt-get upgrade'). That would be a different problem from "must work after arbitrary system crash". I would prefer if we would not switch between different problems. > > I tried searching for that justification and a major internet > > search > > provider just says 'Your search - "potentially renders the system > > unbootable" - did not match any documents.' > > https://www.debian.org/Bugs/Developer#severities > > The official wording appears to be "makes unrelated software on the > system (or the entire system) break". I hope you will agree that a > system that doesn't boot is entirely broken. > > https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/debbugs.py#L79 > > is where I got the "unbootable" phrasing. No, there is a significant difference between "renders the entire system unusable (e.g., unbootable [...]" and "potentially renders the system unbootable". Anyway, please take it to the ctte bug or just close this bug. Ansgar
Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable
On Wed, 2022-09-28 at 16:40 -0400, Zack Weinberg wrote: > On 2022-09-28 3:45 PM, Ansgar wrote: > > On Wed, 2022-09-28 at 15:39 -0400, Zack Weinberg wrote: > > > On 2022-09-28 3:29 PM, Ansgar wrote: > > > > On Wed, 2022-09-28 at 15:22 -0400, Zack Weinberg wrote: > > > > > On 2022-09-28 3:06 PM, Ansgar wrote: > > > > > > Your requirement is that a system must *never* become > > > > > > unbootable in > > > > > > *all* of these states. > > > > > > > > > > Yes, and furthermore I think Debian has required this for many, > > > > > many > > > > > years. > > > > > > > > No, it never did. > > > > > > I told you why I think it does. Unless you can provide _evidence_ > > > that it doesn't, you're not going to change my mind. > > > > Policy makes a special guarantee about essential packages: > > > > +--- > > > Essential is defined as the minimal set of functionality that must > > > be available and usable on the system at all times, even when > > > packages are in the “Unpacked” state. > > +--- > > "Available and usable at all times" is orthogonal to "maintainer scripts > do not render the system unbootable". As I read things, *all* packages > bear the responsibility of not rendering the system unbootable. No, it's a significantly weaker requirement than what you want to impose. If it is not available and usable at all time, it can clearly render the system unbootable (by not being available or usable at boot). > Naturally, most packages don't need to take particular care to avoid > rendering the system unbootable, since they don't do anything in their > maintainer scripts that would risk that. But some do -- like bash, like > libc6, and like usrmerge -- and so they do need to take extra care, and > have always been expected to do so. Maintainer scripts are only one part; not fully installed packages can make the system unbootable for other reasons as mentioned earlier. As you now only talk about maintainer scripts, are these no longer relevant? > > Please provide evidence that the even harder guarantees you demand are > > made somewhere for a much larger set of packages that are critical for > > boot. And are actually fulfilled in practice. > > I already told you the answer to that question: it's inherent in the > definition of a severity:critical bug. One of the several documented > justifications for that severity is "potentially renders the system > unbootable". I see nothing anywhere that limits the scope of that > justification to essential packages, or to any other subset of the archive. I tried searching for that justification and a major internet search provider just says 'Your search - "potentially renders the system unbootable" - did not match any documents.' Anyway, please send follow-ups not just to me, but the bug tracker and ideally the tech-ctte bug. Ansgar
Bug#1020923: tech-ctte: please clarify if atomic updates are required
On Wed, 2022-09-28 at 13:05 -0700, Sean Whitton wrote: > On Wed 28 Sep 2022 at 08:00PM +02, Ansgar wrote: > > Package: tech-ctte > > X-Debbugs-Cc: Zack Weinberg > > Control: block 1020920 by -1 > > > > Hi, > > > > please clarify if atomic updates are mandatory for the Debian system. > > Or other measures to ensure that system crashes at *any* time do not > > render a system unbootable. > > > > See also: https://bugs.debian.org/1020920 > > (1) Do you mean any package update? Certain packages? dist-upgrade? Any package relevant for successful boot. Any upgrade. As far as I can tell, the submitter requires some guarantees significantly stronger than what Debian requires for essential packages. In particular, boot-relevant packages are demanded to work in unconfigured state, with not fully satisfied dependencies (possibly not even unpackaged?), in partly unpackaged states, after maintainer script errors, and all of that in combination with system crashes that might result in partly written data to filesystems. And possibly in other interesting system states too. > (2) The TC is a decision-making body of last resort. The bug you > mention was filed today. Might this be premature? Well, if we close it or don't act on it, people will complain and/or demand to remove us from Debian for not acting on it (the latter might be limited to people just sitting on their porch). The other tech-ctte bug about usrmerge also suggested it would just end up here either way. Ansgar
Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable
On Wed, 2022-09-28 at 15:39 -0400, Zack Weinberg wrote: > On 2022-09-28 3:29 PM, Ansgar wrote: > > On Wed, 2022-09-28 at 15:22 -0400, Zack Weinberg wrote: > > > On 2022-09-28 3:06 PM, Ansgar wrote: > > > > Your requirement is that a system must *never* become > > > > unbootable in > > > > *all* of these states. > > > > > > Yes, and furthermore I think Debian has required this for many, > > > many > > > years. > > > > No, it never did. > > I told you why I think it does. Unless you can provide _evidence_ > that it doesn't, you're not going to change my mind. Policy makes a special guarantee about essential packages: +--- | Essential is defined as the minimal set of functionality that must | be available and usable on the system at all times, even when | packages are in the “Unpacked” state. +--- Please provide evidence that the even harder guarantees you demand are made somewhere for a much larger set of packages that are critical for boot. And are actually fulfilled in practice. Ansgar
Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable
On Wed, 2022-09-28 at 15:22 -0400, Zack Weinberg wrote: > On 2022-09-28 3:06 PM, Ansgar wrote: > > On Wed, 2022-09-28 at 14:54 -0400, Zack Weinberg wrote: > > > On 2022-09-28 2:40 PM, Ansgar wrote: > > > > > If I thought there was a bug in some other package that posed > > > > > a > > > > > significant risk of rendering Debian systems unbootable on > > > > > upgrade, I > > > > > would have filed a report against THAT PACKAGE. > > > > > > > > Okay, so I understand this is an arbitrary requirement for > > > > *just* > > > > usrmerge. Any other package may still break the system (as > > > > there are > > > > enough critical packages). > > > > > > I don't understand how you got from what I said to "this is an > > > arbitrary > > > requirement just for usrmerge". > > > > > > It is, in fact, a *non*-arbitrary requirement, spelled out in > > > Policy as > > > such, that applies to *all* packages. "Potentially breaks the > > > entire > > > system (e.g. by rendering it unbootable)" = critical-severity > > > bug. > > > > During upgrades, package dependencies might not be satisfied, there > > is > > no guarantee that non-essential (as in the Policy meaning of > > essential) > > packages work at all, partly-unpacked essential packages are likely > > also interesting. > > > > The system can crash while any of this is the case, not even > > involving > > more complex parts like maintainer scripts. > > > > This obviously also includes boot loaders and similar. > > > > Your requirement is that a system must *never* become unbootable in > > *all* of these states. > > Yes, and furthermore I think Debian has required this for many, many > years. No, it never did. > > So again: please show that other packages don't have such issues in > > general. > > I do not think it is reasonable for you to ask that I investigate the > possibility of bugs existing in other packages before I file a bug on > your package. If you want to impose requirements on this package that are not imposed elsewhere... Ansgar
Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable
On Wed, 2022-09-28 at 14:54 -0400, Zack Weinberg wrote: > On 2022-09-28 2:40 PM, Ansgar wrote: > > > If I thought there was a bug in some other package that posed a > > > significant risk of rendering Debian systems unbootable on upgrade, I > > > would have filed a report against THAT PACKAGE. > > > > Okay, so I understand this is an arbitrary requirement for *just* > > usrmerge. Any other package may still break the system (as there are > > enough critical packages). > > I don't understand how you got from what I said to "this is an arbitrary > requirement just for usrmerge". > > It is, in fact, a *non*-arbitrary requirement, spelled out in Policy as > such, that applies to *all* packages. "Potentially breaks the entire > system (e.g. by rendering it unbootable)" = critical-severity bug. During upgrades, package dependencies might not be satisfied, there is no guarantee that non-essential (as in the Policy meaning of essential) packages work at all, partly-unpacked essential packages are likely also interesting. The system can crash while any of this is the case, not even involving more complex parts like maintainer scripts. This obviously also includes boot loaders and similar. Your requirement is that a system must *never* become unbootable in *all* of these states. Unless of course, it is just usrmerge that is required to provide guarantees that no other package is. (Or change the entire system to mandatory A/B updates or similar things.) So again: please show that other packages don't have such issues in general. I very much don't think so and do not think it is particularily useful to demand this from one specific package. Ansgar
Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable
On Wed, 2022-09-28 at 14:32 -0400, Zack Weinberg wrote: > On 2022-09-28 2:04 PM, Ansgar wrote: > > On Wed, 2022-09-28 at 13:53 -0400, Zack Weinberg wrote: > > > On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote: > > > > No, you would need to atomically replace the *entire* system, > > > > not > > > > just > > > > individual directories. > > > > > > ??? Atomic replacement of each affected directory is, as far as I > > > can > > > see, both necessary and sufficient to prevent the system being > > > rendered unbootable. > > > > No. It is not sufficient. Upgrading packages can affect multiple > > directories and half-upgraded packages can easily render systems > > unbootable. > > Do I really have to spell this out for you? > > Atomic replacement of each directory replaced with a symlink by > convert-usrmerge should be sufficient [unless I missed something > while > reading through convert-usrmerge's code] to prevent the system being > unbootable AS A CONSEQUENCE OF ACTIONS PERFORMED BY convert-usrmerge. > > If I thought there was a bug in some other package that posed a > significant risk of rendering Debian systems unbootable on upgrade, I > would have filed a report against THAT PACKAGE. Okay, so I understand this is an arbitrary requirement for *just* usrmerge. Any other package may still break the system (as there are enough critical packages). Of course, if not correct, you can demonstrate there are no other packages that will make the system unbootable if half-upgraded (including combinations involving multiple packages). Ansgar
Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable
On Wed, 2022-09-28 at 13:53 -0400, Zack Weinberg wrote: > On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote: > > No, you would need to atomically replace the *entire* system, not > > just > > individual directories. > > ??? Atomic replacement of each affected directory is, as far as I can > see, both necessary and sufficient to prevent the system being > rendered unbootable. No. It is not sufficient. Upgrading packages can affect multiple directories and half-upgraded packages can easily render systems unbootable. Ansgar
Bug#1020923: tech-ctte: please clarify if atomic updates are required
Package: tech-ctte X-Debbugs-Cc: Zack Weinberg Control: block 1020920 by -1 Hi, please clarify if atomic updates are mandatory for the Debian system. Or other measures to ensure that system crashes at *any* time do not render a system unbootable. See also: https://bugs.debian.org/1020920 Thanks, Ansgar
Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable
On Wed, 2022-09-28 at 13:39 -0400, Zack Weinberg wrote: > convert-usrmerge is nominally idempotent and restartable, but (as it > says in the script’s own documentation) if “the system crashes at a > really bad time” during the conversion process it might not be > possible to recover without manual intervention. Unfortunately, it’s > worse than that: if the system crashes at _just_ the wrong time > (specifically, in the middle of a convert_directory operation, in > between the rename() and symlink() calls) it appears to be possible > for the next boot to find the root filesystem in a state where /lib > or /bin doesn’t exist at all. Recovery from this state will require > booting from installation media. There are many packages that will render a package unbootable if the system crashes at just the wrong time... You need a very, very large change to how Debian works to change that. > To fix this, I think some technique for replacing directories with > symlinks _atomically_ needs to be found. No, you would need to atomically replace the *entire* system, not just individual directories. But please explain how this is specifc to usrmerge and not many other packages. Ansgar
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
On Wed, 2022-09-28 at 12:29 -0400, Zack Weinberg wrote: > 1. Is there already a rule (or multiple rules) somewhere that forbids > the existence of pairs of packages where one ships /X/Y and the > other ships /usr/X/Y, where X is a directory on non-merged-/usr > systems and a symlink on merged-/usr systems, and Y is any name? *sigh* There has been such a rule for many, many years already. I really feel you lack investigating the issue before filing yet another ctte bug about it. Ansgar
Bug#1020783: init-system-helpers 1.65.2 broke cdebootstrap
On Mon, 2022-09-26 at 17:54 +0200, Holger Levsen wrote: > Sadly I've only enabled verbose bootstrapping today, but at least I > did that now > so you can look at > https://jenkins.debian.net/job/reproducible_cdebootstrap_unstable/40/consoleFull > and maybe actually understand the problem: There is this warning: +--- | W: resolver (perl:any): package doesn't exist +--- Which looks like cdebootstrap doesn't handle the multi-arch qualifier (in usrmerge's Depends field), then fails to install usrmerge (as dependency of init-system-helpers) and thus init-system-helpers. I guess the last one missing causes this: > ( > https://jenkins.debian.net/job/reproducible_cdebootstrap_bullseye/30/c > onsole > is a verbose build too.) > > So I *guess* this is the place it breaks: > > /var/lib/dpkg/info/dpkg.postinst: 115: deb-systemd-helper: not found > /var/lib/dpkg/info/dpkg.postinst: 118: deb-systemd-helper: not found > /var/lib/dpkg/info/dpkg.postinst: 125: deb-systemd-helper: not found > P: Configuring package dpkg We had a similar problem with base-installer (used as an implementation detail of debootstrap in d-i): https://bugs.debian.org/1020426 Which has a patch available: https://salsa.debian.org/installer-team/base-installer/-/merge_requests/9 Ansgar
Bug#1020692: Proposed RM: condor -- RoQA; unmaintained in Debian; depends on Python2; RC buggy
Source: condor Version: 8.6.8~dfsg.1-2 Severity: serious I propose to remove src:condor for Debian. It looks unmaintained, still depends on Python2 and has various RC bugs open for a long time. If there are no objections, I'll reassign the bug in two weeks (or later) to the ftp.debian.org metapackage. Ansgar
