Bug#976402: Proposed official virtual packages - todo and todo.txt
David Steele writes: > On Wed, Dec 9, 2020 at 3:21 AM Ansgar wrote: >> Given topydo just provides/conflicts with devtodo to provide the "todo" >> binary, this seems to violate Policy 10.1 "Binaries" unless they provide >> the same functionality. [...] > From where I stand, I would expect the Policy to use a different word to > indicate something along the lines of greater API compatibility. I have no > additional background information, though. Are you aware of any expansions > on this text, or of any precedents that could help with a consensus process? My understanding is that different alternatives for a binary in PATH should provide a compatible command-line interface as one might not know which alternative is installed. See for example the description of x-terminal-emulator in Policy 11.8.3 or requirements for the sendmail program. It is sufficient to only require some subset to be guaranteed to be provided (as is the case for both x-terminal-emulator and sendmail: any provider will usually also accept provider-specific options in addition to the general ones). David Steele writes in another mail: > That leaves todo.txt, implemented by topydo and (hopefully, soon) > todotxt-cli. Unfortunately, (1) has been invoked here as well - the command > sets of the two packages are close, but not identical. Also, I'm on record > saying an emacs script could comply if: > - it properly supports the "--info" argument > - it supports calling the hooks in the optional todo.txt-base package > - it provides a means to add/modify/delete/show tasks housed in a > todo.txt-format file, noting that the format does not have to be strictly > enforced by the package. > > My latest stake in the ground - I claim that the functionality of the > todo.txt virtual package, from a Policy perspective, is defined, here, and > that the candidates are compliant. I think "todo.txt" is okay if providers of the "todo.txt" virtual package provide a "/usr/bin/todo.txt" alternative that provides some reasonable subset of the command-line interface that topydo / todo.sh / similar tools share so that "todo.txt list", "todo.txt add laundry" and so work. That seems to be the case between topydo and todotxt-cli; just opening emacs wouldn't be valid. (As with the examples above providers can implement more than just the common interface.) Something like this maybe? - name: todo.txt description: command-line task management utility compatible with todo.txt CLI (http://todotxt.org) alternatives: [/usr/bin/todo.txt] Ansgar
Bug#945275: debian-policy: [9.1.2] deprecated `staff` group special case
Package: debian-policy 9.1.2 recommends the following to create a directory under /usr/local: ``` if [ ! -e /usr/local/share/emacs ]; then if mkdir /usr/local/share/emacs 2>/dev/null; then if test -e /etc/staff-group-for-usr-local ; then if chown root:staff /usr/local/share/emacs; then chmod 2775 /usr/local/share/emacs || true fi elif chown root:root /usr/local/share/emacs; then chmod 0755 /usr/local/share/emacs || true fi fi fi ``` That is way too complicated and has race conditions (yes, I know staff is practically almost root). I suggest to have packages just create the directory with ``` mkdir -p /usr/local/share/emacs || true ``` If people want to have /usr/local writable by different users than root, they should use POSIX ACLs or similar means. This would also set correct permissions for directories that aren't created as above, but by, for example, a call to `make install`. The `/etc/staff-group-for-usr-local` flag file could also go away then. Ansgar
Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")
Ben Hutchings writes: > The code signing service logs every file it signs, along with a hash of > the detached signature, but I don't know where the logs are so I can't > comapre with that. I checked the audit log, but I don't think it will help much. It currently records that: - 2019-10-21 07:20:03.898781: decided to sign linux-image-5.3.0-1-amd64-unsigned_5.3.7-1_amd64/[...]/snd-hda-codec-hdmi.ko with sha256sum 3fe77a308b28825f0d18717e073b411246aea9bb753f76f6071b3fc4e60c6005 - 2019-10-21 07:20:04.175379: signature for the file logged with sha256sum c2a36f35867ae92b8664f4bd2193e70370eb3b92013ea53f3573d2508d3da4cb (which matches snd-hda-codec-hdmi.ko.sig in src:linux-signed-amd64) So linux' sign-file likely produced a truncated file for some reason; note that ftp-master still uses linux-kbuild-4.9/4.9.189-3+deb9u1. Ansgar
Bug#942051: debian-policy: [4.9] requirement to write only to /tmp, /var/tmp, ${TMPDIR} is too strict
Package: debian-policy Version: 4.4.1.1 Severity: minor While checking the upgrade checklist I noticed this new requirement: +--- | 4.9 |Required targets must not write outside of the unpacked source |package tree, except for TMPDIR, /tmp and /var/tmp. +--- The wording is a bit too strict and should be relaxed. There are other paths that should be fine to be written to during the build process, for example /dev/shm, /run/lock[1], or possibly anything below /proc/ for processes spawned by the build process. Ansgar [1] Which I noticed is world-writable which I'm not sure should be as users could then fill /run... Note that /run/user/ has separate filesystems to avoid this problem; but then there are many paths below /run writable by service users which can cause the same problems.
Bug#941837: texlive-fonts-extra: file conflice with (older) texlive-fonts-extra-links
Package: texlive-fonts-extra Version: 2019.20190930-2 Severity: serious Hi, when upgrading in Debian testing I saw the following error message: +--- | Unpacking texlive-fonts-extra (2019.20190930-2) over (2019.20190830-1) ... | dpkg: error processing archive /tmp/apt-dpkg-install-h6VDTu/50-texlive-fonts-extra_2019.20190930-2_all.deb (--unpack): | trying to overwrite '/usr/share/texlive/texmf-dist/fonts/opentype/arkandis/berenisadf/BerenisADFProSC-Bold.otf', which is also in package texlive-fonts-extra-links 2019.20190830-1 | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) +--- It looks like texlive-fonts-extra is missing a (versioned) Replaces on texlive-fonts-extra-links. Thanks for maintaining LaTeX in Debian, Ansgar -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'buildd-unstable'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages texlive-fonts-extra depends on: it tex-common6.12 ii texlive-base 2019.20190930-1 Versions of packages texlive-fonts-extra recommends: ii fonts-adf-accanthis0.20190904-1.1 ii fonts-adf-berenis 0.20190904-1.1 ii fonts-adf-gillius 0.20190904-1.1 ii fonts-adf-universalis 0.20190904-1.1 ii fonts-cabin1.5-2 ii fonts-comfortaa3.001-2 ii fonts-croscore 20181227-1 ii fonts-crosextra-caladea20130214-2 ii fonts-crosextra-carlito20130920-1 ii fonts-dejavu-core 2.37-1 ii fonts-dejavu-extra 2.37-1 ii fonts-ebgaramond 0.016-1 ii fonts-ebgaramond-extra 0.016-1 ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-1 ii fonts-freefont-otf 20120503-9 ii fonts-freefont-ttf 20120503-9 ii fonts-gfs-artemisia1.1-5 ii fonts-gfs-complutum1.1-6 ii fonts-gfs-didot1.1-6 ii fonts-gfs-neohellenic 1.1-6 ii fonts-gfs-olga 1.1-5 ii fonts-gfs-solomos 1.1-5 ii fonts-go 0~20170330-1 ii fonts-junicode 1.002-1 ii fonts-lato 2.0-2 ii fonts-linuxlibertine 5.3.0-4 ii fonts-lobstertwo 2.0-2 ii fonts-noto-hinted 20181227-1 ii fonts-noto-mono20181227-1 ii fonts-oflb-asana-math 000.907-6 ii fonts-open-sans1.11-1 ii fonts-roboto-unhinted 2:0~20170802-3 ii fonts-sil-gentium 20081126:1.03-2 ii fonts-sil-gentium-basic1.102-1 ii fonts-sil-gentiumplus 5.000-2 ii fonts-sil-gentiumplus-compact 5.000-2 ii fonts-stix 1.1.1-4 iu texlive-fonts-extra-links 2019.20190930-2 ii texlive-fonts-recommended 2019.20190930-1 iu texlive-latex-extra2019.20190930-2 Versions of packages texlive-fonts-extra suggests: ii cm-super 0.3.4-15 iu texlive-fonts-extra-doc 2019.20190930-2 Versions of packages tex-common depends on: ii dpkg 1.19.7 ii ucf 3.0038+nmu1 Versions of packages tex-common suggests: ii debhelper 12.6.1 Versions of packages texlive-fonts-extra is related to: it tex-common6.12 ii texlive-binaries 2019.20190605.51237-3 -- debconf information excluded
Bug#941276: clamav-daemon: strange use of systemd service files
Package: clamav-daemon Version: 0.101.4+dfsg-1 Severity: normal After a user asked something about clamav on IRC, I noticed that clamav-daemon's postinst creates a file /etc/systemd/system/clamav-daemon.service.d/extend.conf with static content: +--- | echo "#Automatically Generated by clamav-daemon postinst" > $DEBCONFFILE | echo "#To reconfigure clamd run #dpkg-reconfigure clamav-daemon" >> $DEBCONFFILE | echo "#Please read /usr/share/doc/clamav-daemon/README.Debian.gz for details" >> $DEBCONFFILE | echo "[Service]" > "$DEBSYSTEMDCLAMDCONF" | echo "ExecStartPre=-/bin/mkdir /run/clamav" >> "$DEBSYSTEMDCLAMDCONF" | echo "ExecStartPre=/bin/chown $User /run/clamav" >> "$DEBSYSTEMDCLAMDCONF" +--- This really looks like something that doesn't belong in /etc, but either should be part of clamav-daemon.service directly or shipped as /lib/systemd/system/clamav-daemon.service.d/extend.conf (i.e. /lib instead of /etc). (There is also RuntimeDirectory=, but I'm not sure if stretch's systemd already supports that.) For some reason the user had a call to "/bin/mkdir" instead of "-/bin/mkdir" which failed when the directory already existed (e.g. on restart). Ansgar
Bug#941273: runit: FTBFS (looks like endless loop)
Package: src:runit Version: 2.1.2-34 Severity: serious I noticed that the last runit build is already taking over 13h on buildds. The hppa build log[1] looks like the build failed due to an endless loop. I asked the other builds to be killed. Ansgar [1] https://buildd.debian.org/status/fetch.php?pkg=runit=hppa=2.1.2-34=1569581954=0
Bug#941195: bugs.debian.org: do not append to `References` if wanted msgid is already there
Package: bugs.debian.org Severity: minor Tags: upstream It looks like debbugs always appends the bug report's msgid to the `References` field when sending a follow-up message to the bug. This should not be done when the msgid is already listed there. (I noticed because this broke DKIM signatures; I know that trying to make the BTS not break DKIM signatures is a bit of whack-a-mole.) Ansgar
Bug#941194: initscripts: remove some implementation details
Control: reassign -1 debian-policy The section on initscripts has too much implementation details about /etc/rcn.d; these are better explained by external documentation. Also the rationale for why `DISABLED=yes` (or similar) fits better into a footnote than the main text (IMHO). (Policy also should say something about LSB headers in "Writing the scripts", but that will be a different patch.) Ansgar >From 4bdc0bfa5a08ae0481a9820c1d4bfb8b933afcc4 Mon Sep 17 00:00:00 2001 From: Ansgar Date: Thu, 26 Sep 2019 08:49:28 +0200 Subject: [PATCH 1/2] move rationale to discourage old practice into footnote --- policy/ch-opersys.rst | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 6e0c020..1b63064 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -554,16 +554,7 @@ administrator can enable autostarting the daemon using the command ``update-rc.d package enable``. An older practice, which should not be used, was to include a line -like ``DISABLED=yes`` in the package's ``/etc/default`` file. The -package's init script would not start the service until the local -system administrator changed this to ``DISABLED=no``, or similar. The -problem with this approach was that it hides from the init system -whether or not the daemon should actually be started, which leads to -inconsistent and confusing behavior: ``service start`` may -return success but not start the service; services with a dependency -on this service will be started even though the service isn't running; -and init system status commands may incorrectly claim that the service -was started. +like ``DISABLED=yes`` in the package's ``/etc/default`` file. [#]_ Note that if your package changes runlevels or priority, you may have to remove and recreate the links, since otherwise the old links may @@ -1034,6 +1025,17 @@ Debian, so this section has been removed. init scripts, may fail if ``set -e`` is in effect and echoing status messages to the console fails, for example. +.. [#] + The package's init script would not start the service until the + local system administrator changed this to ``DISABLED=no``, or + similar. The problem with this approach was that it hides from the + init system whether or not the daemon should actually be started, + which leads to inconsistent and confusing behavior: ``service +start`` may return success but not start the service; + services with a dependency on this service will be started even + though the service isn't running; and init system status commands + may incorrectly claim that the service was started. + .. [#] Creating, modifying or removing a file in ``/usr/lib/mime/packages/`` using maintainer scripts will not -- 2.23.0 >From 82db1fc4300e2b6563f2436fadf3f964d567c65b Mon Sep 17 00:00:00 2001 From: Ansgar Date: Thu, 26 Sep 2019 08:54:03 +0200 Subject: [PATCH 2/2] refer to external documentation for implementation details of /etc/rcn.d --- policy/ch-opersys.rst | 65 --- 1 file changed, 12 insertions(+), 53 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 1b63064..5a647fd 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -329,59 +329,18 @@ The ``/etc/init.d`` directory contains the scripts executed by ``init`` at boot time and when the init state (or "runlevel") is changed (see ``init(8)``). -There are at least two different, yet functionally equivalent, ways of -handling these scripts. For the sake of simplicity, this document -describes only the symbolic link method. However, it must not be assumed -by maintainer scripts that this method is being used, and any automated -manipulation of the various runlevel behaviors by maintainer scripts -must be performed using ``update-rc.d`` as described below and not by -manually installing or removing symlinks. For information on the -implementation details of the other method, implemented in the -``file-rc`` package, please refer to the documentation of that package. - -These scripts are referenced by symbolic links in the ``/etc/rcn.d`` -directories. When changing runlevels, ``init`` looks in the directory -``/etc/rcn.d`` for the scripts it should execute, where ``n`` is the -runlevel that is being changed to, or ``S`` for the boot-up scripts. - -The names of the links all have the form ``Smmscript`` or ``Kmmscript`` -where mm is a two-digit number and script is the name of the script -(this should be the same as the name of the actual script in -``/etc/init.d``). - -When ``init`` changes runlevel first the targets of the links whose -names start with a ``K`` are executed, each with the single argument -``stop``, followed by the scripts prefixed with an ``S``, each with the -single argument ``start``. (The links are those in the ``/etc/rcn.d`` -directory corresponding to the new runlevel.) The ``K`` links are
Bug#941194: initscripts: remove some implementation details
Package: bugs.debian.org Severity: normal Tags: patch The section on initscripts has too much implementation details about /etc/rcn.d; these are better explained by external documentation. Also the rationale for why `DISABLED=yes` (or similar) fits better into a footnote than the main text (IMHO). (Policy also should say something about LSB headers in "Writing the scripts", but that will be a different patch.) Ansgar >From 4bdc0bfa5a08ae0481a9820c1d4bfb8b933afcc4 Mon Sep 17 00:00:00 2001 From: Ansgar Date: Thu, 26 Sep 2019 08:49:28 +0200 Subject: [PATCH 1/2] move rationale to discourage old practice into footnote --- policy/ch-opersys.rst | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 6e0c020..1b63064 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -554,16 +554,7 @@ administrator can enable autostarting the daemon using the command ``update-rc.d package enable``. An older practice, which should not be used, was to include a line -like ``DISABLED=yes`` in the package's ``/etc/default`` file. The -package's init script would not start the service until the local -system administrator changed this to ``DISABLED=no``, or similar. The -problem with this approach was that it hides from the init system -whether or not the daemon should actually be started, which leads to -inconsistent and confusing behavior: ``service start`` may -return success but not start the service; services with a dependency -on this service will be started even though the service isn't running; -and init system status commands may incorrectly claim that the service -was started. +like ``DISABLED=yes`` in the package's ``/etc/default`` file. [#]_ Note that if your package changes runlevels or priority, you may have to remove and recreate the links, since otherwise the old links may @@ -1034,6 +1025,17 @@ Debian, so this section has been removed. init scripts, may fail if ``set -e`` is in effect and echoing status messages to the console fails, for example. +.. [#] + The package's init script would not start the service until the + local system administrator changed this to ``DISABLED=no``, or + similar. The problem with this approach was that it hides from the + init system whether or not the daemon should actually be started, + which leads to inconsistent and confusing behavior: ``service +start`` may return success but not start the service; + services with a dependency on this service will be started even + though the service isn't running; and init system status commands + may incorrectly claim that the service was started. + .. [#] Creating, modifying or removing a file in ``/usr/lib/mime/packages/`` using maintainer scripts will not -- 2.23.0 >From 82db1fc4300e2b6563f2436fadf3f964d567c65b Mon Sep 17 00:00:00 2001 From: Ansgar Date: Thu, 26 Sep 2019 08:54:03 +0200 Subject: [PATCH 2/2] refer to external documentation for implementation details of /etc/rcn.d --- policy/ch-opersys.rst | 65 --- 1 file changed, 12 insertions(+), 53 deletions(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 1b63064..5a647fd 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -329,59 +329,18 @@ The ``/etc/init.d`` directory contains the scripts executed by ``init`` at boot time and when the init state (or "runlevel") is changed (see ``init(8)``). -There are at least two different, yet functionally equivalent, ways of -handling these scripts. For the sake of simplicity, this document -describes only the symbolic link method. However, it must not be assumed -by maintainer scripts that this method is being used, and any automated -manipulation of the various runlevel behaviors by maintainer scripts -must be performed using ``update-rc.d`` as described below and not by -manually installing or removing symlinks. For information on the -implementation details of the other method, implemented in the -``file-rc`` package, please refer to the documentation of that package. - -These scripts are referenced by symbolic links in the ``/etc/rcn.d`` -directories. When changing runlevels, ``init`` looks in the directory -``/etc/rcn.d`` for the scripts it should execute, where ``n`` is the -runlevel that is being changed to, or ``S`` for the boot-up scripts. - -The names of the links all have the form ``Smmscript`` or ``Kmmscript`` -where mm is a two-digit number and script is the name of the script -(this should be the same as the name of the actual script in -``/etc/init.d``). - -When ``init`` changes runlevel first the targets of the links whose -names start with a ``K`` are executed, each with the single argument -``stop``, followed by the scripts prefixed with an ``S``, each with the -single argument ``start``. (The links are those in the ``/etc/rcn.d`` -directory corresponding to the new runlevel.) The
Bug#940572: gnome-terminal: changing font size on one tab has effect on other tabs
Package: gnome-terminal Version: 3.34.0-1 Severity: minor Tags: upstream Changing the font size in one tab has an effect of other tabs: when switching from tab A (with larger font size) to tab B (regular font size), I can see that tab B gets restored with the larger font size and is only then changed to the normal font size. This causes screen refreshes which is noticable when, for example, running irssi over a SSH connection in one of the tabs. It would be nice if gnome-terminal would switch font size at the same time as changing the terminal emulator's contents to avoid such artifacts. Ansgar -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (300, 'buildd-unstable'), (300, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii dconf-gsettings-backend [gsettings-backend] 0.34.0-1 ii gnome-terminal-data 3.34.0-1 ii gsettings-desktop-schemas 3.34.0-1 ii libatk1.0-0 2.34.0-1 ii libc6 2.29-1 ii libdconf1 0.34.0-1 ii libglib2.0-0 2.62.0-1 ii libgtk-3-03.24.11-1 ii libpango-1.0-01.42.4-7 ii libuuid1 2.34-0.1 ii libvte-2.91-0 0.58.0-1 ii libx11-6 2:1.6.7-1 Versions of packages gnome-terminal recommends: ii gvfs 1.38.1-5+b1 pn nautilus-extension-gnome-terminal ii yelp 3.34.0-1 gnome-terminal suggests no packages. -- no debconf information
Bug#940556: gnome-terminal: uses DPI from wrong screen resulting in hard to read font rendering
Package: gnome-terminal Version: 3.34.0-1 Severity: normal Tags: upstream I have a laptop with an external screen; internal and external screen have different resolutions and DPI. Since a recent update gnome-terminal and other GNOME applications use the DPI from the wrong screen when the window in located close to the screen boundary. (In particular it seems to be triggered by the shadow around the window reaching the other (left) screen.) This results in hard to read text. I've seen this happen with gnome-terminal and gnome-settings under a Wayland GNOME session; not with emacs or firefox (which still use X as far as I know). I've installed gnome-shell 3.34.0-1 and a few other packages from experimental to give them a try. Ansgar -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (300, 'buildd-unstable'), (300, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii dconf-gsettings-backend [gsettings-backend] 0.34.0-1 ii gnome-terminal-data 3.34.0-1 ii gsettings-desktop-schemas 3.34.0-1 ii libatk1.0-0 2.34.0-1 ii libc6 2.29-1 ii libdconf1 0.34.0-1 ii libglib2.0-0 2.62.0-1 ii libgtk-3-03.24.11-1 ii libpango-1.0-01.42.4-7 ii libuuid1 2.34-0.1 ii libvte-2.91-0 0.58.0-1 ii libx11-6 2:1.6.7-1 Versions of packages gnome-terminal recommends: ii gvfs 1.38.1-5+b1 pn nautilus-extension-gnome-terminal ii yelp 3.34.0-1 gnome-terminal suggests no packages. -- no debconf information
Bug#939469: dkimpy-milter: indicate when domain is in "testing mode" in Auth-Results
Package: dkimpy-milter Version: 1.0.1-1 Severity: wishlist Tags: upstream Hi, a recent mail to -devel@ resulted in the following header from dkimpy-milter: Authentication-Results: [...]; dkim=fail (Bad 1024 bit rsa-sha256 signature.) header.d=[...] header.a=rsa-sha256 However the domain (or key) is in testing mode (t=y): +--- | [...]._domainkey.[...] 1513 IN TXT "v=DKIM1; t=y; k=rsa; p=[...]" +---[ $ dig TXT a._domainkey.[...] ] It would be nice if dkimpy-milter would report when a domain is testing DKIM. Ansgar
Bug#932849: ftp.debian.org: NEW process looses .buildinfo files
Control: tag -1 moreinfo Control: retitle -1 ftp.debian.org: `dak process-policy new` loses .buildinfo files The title says "loses .buildinfo files", but the IRC log says: > tar tf /srv/ftp-master.debian.org/queue/done/2019/02.tar.xz | grep > liblogger-simple-perl > 02/04/liblogger-simple-perl_2.0-1_amd64.changes > 02/04/liblogger-simple-perl_2.0-1_amd64.buildinfo > they're still retrievable, just not as friendly So I'm not sure what the problem is? Ansgar
Bug#932789: tor: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111
Package: tor Version: 0.3.5.8-1 Severity: normal Tags: upstream Hi, I found the following warning in my log files: +--- | Tor[2185]: Bug: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:. Stack trace: (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(log_backtrace_impl+0x46) [0x55d7f7455aa6] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x55d7f74511c0] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(channel_tls_handle_cell+0x49a) [0x55d7f72db71a] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(+0x9a16a) [0x55d7f72ff16a] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(connection_handle_read+0x99d) [0x55d7f72c918d] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(+0x69ebe) [0x55d7f72ceebe] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7fe17bc599ba] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7fe17bc5a537] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(do_main_loop+0xb0) [0x55d7f72d0290] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(tor_run_main+0x10e5) [0x55d7f72be0d5] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(tor_main+0x3a) [0x55d7f72bb30a] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(main+0x19) [0x55d7f72baec9] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fe17b53b09b] (on Tor 0.3.5.8 ) | Tor[2185]: Bug: /usr/bin/tor(_start+0x2a) [0x55d7f72baf1a] (on Tor 0.3.5.8 ) +--- (on a Debian buster system) I currently don't have time to investigate further; the system will also be decommissioned next month. Ansgar
Bug#931923: gnupg: should support sha2 fingerprints
Package: gnupg Version: 2.2.12-1 Severity: normal Tags: upstream >From man:gpg(1): +--- | This format is deduced from the length of the string and its content | or the 0x prefix. Note, that only the 20 byte version fingerprint | is available with gpgsm (i.e. the SHA-1 hash of the certificate). +--- SHA-2 fingerprints should be supported for X.509 as well. Web browsers have shown those for quite a while now. The same is true for fingerprints of OpenPGP keys, but I'm not sure if there is any standard for those... Ansgar
Bug#931847: Boggus package-supports-alternative-init-but-no-init.d-script test?
On Thu, 11 Jul 2019 13:26:34 +0200 Laurent Bigonville wrote: > My understanding of the policy is that, if a package supports an > alternative init (other than systemd) it must also support sysvinit. > > Also note that if the check is actually correct, this will create false > positive for all the systemd .service files not started at boot > (scheduled jobs, dbus activated,...). The current policy requirement is that everything would need to provide a sysvinit script, see https://bugs.debian.org/911165 Sadly the process to change this is stuck. Ansgar
Bug#931785: release-notes: bullseye: security suite renamed to bullseye-security (from buster/updates)
Package: release-notes Severity: normal For bullseye, the security suite is now named bullseye-security instead of buster/updates and users should adapt their sources.list accordingly when upgrading. People should probably use something like deb http://security.debian.org/debian-security bullseye-security main (adding /debian-security was proposed in [1]). See [2][3][4] for some more information. I should probably also sent a mail to d-d-a@ or so about this in the near future... Ansgar [1] https://lists.debian.org/debian-devel/2015/12/msg00333.html [2] https://bugs.debian.org/614204 [3] https://lists.debian.org/debian-devel/2015/12/msg00254.html [4] https://lists.debian.org/debian-security/2019/06/msg00015.html
Bug#931764: popularity-contest: please report foreign architectures
Package: popularity-contest Version: 1.67 Severity: wishlist Hi, it would be nice if popularity-contest would report which foreign architecture are enabled, i.e. the list `dpkg --print-foreign-architectures` should report. In particular I'm interested in seeing how many people have enabled i386 as a foreign architecture on amd64. I've seen that i386 installations have, as one would expect, decreased quite a lot (especially if one looks at architecture-over-popcon-version to see arch usage by release). But we have no data how many people are still using i386 software via multiarch. Ansgar
Bug#931525: dak: NVIU removal should only happen after some time
Package: ftp.debian.org Removing packages from experimental when a newer version is available in unstable should only happen after the package has been in unstable for a few days. This works around https://bugs.debian.org/865304 (too early removal of overrides). It also keep binaries available for users if builds take a while. Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Philipp Kern writes: > 20/06/2019 20:22, Ansgar Burchardt wrote: >> You look up which uid the _apt user inside the chroot has and use that. > > Yeah, but that scales poorly if you have a centralized firewall > policy. It means that you need to maintain dynamic rules. I know it's > possible and you can dedicate a chain to it. At the same time I think > this problem is actually common enough that it deserves a solution. If _apt deserves a special solution, I would suggest assigning the _apt user a static uid instead of patching debootstrap. Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Trek writes: > Ansgar Burchardt wrote: >> For limiting network access, I would recommend instead using network >> namespaces (to only provide limited network access for all processes) >> and/or user namespaces (if filtering for single UIDs is really >> needed). These do not require any uids to match between in- and >> outside. > > filtering out the root user is a pretty common security practice and > setting an iptables rule on uids is simple for system administrators So you don't run sshd (requires root with network access)? That seems rather uncommon to me. > using namespaces, how can you block any user but not the _apt user if it > is not already created? You look up which uid the _apt user inside the chroot has and use that. > P.S.: the patch seems ok to me, I don't like hard-conding the _apt user > line in /etc/passwd, as apt postinst uses adduser, but it's not clear > to me when adduser is installed during debootstrap You cannot use `adduser` as debootstrap might install binaries you cannot execute (in the first stage). But the effects of the patch are different from calling adduser, for example the _apt user it creates has no entry in /etc/shadow. Such inconsistencies are not good. Ansgar
Bug#930788: creating /var/lib/dpkg/cmethopt
Package: apt,dselect Severity: normal Hi, [ X-Debbugs-Cc'ed -boot@ for debootstrap ] today I learned that debootstrap as special code to create the file /var/lib/dpkg/cmethopt (contents: "apt apt"); this is the function setup_dselect_method in functions. It seems wrong that debootstrap has to know about such a particular detail. Alternatives to debootstrap might also not create the file at all. So I wonder if this could be created somewhere else. An APT developer said this is used by dselect and suggested to file a bug against apt,dselect; he also had the idea that the file might be created in dselect's postinst. Ansgar
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Michael Biebl writes: > On Wed, 19 Jun 2019 22:16:58 +0200 Ansgar Burchardt wrote: >> I'm just a GNOME user, but from gdm3's changelog the default was >> switched to Wayland in July 2017 (or August 2017 for unstable). I >> myself only noticed the switch after reading it happened somewhere on >> the internet shortly after it happened. [...] > When you talk about "gdm3's default", what exactly do you mean: the > display technology gdm is using or the type of GNOME session that is > started as default? I meant the GNOME session; that is the only thing that changed in July/August 2017 as gdm itself used Wayland already before as far as I understand. For something that has been the default for almost two years to be switched back two weeks before the release there has to be some really huge issues for me. Any change will not see much testing given the time after all and risks new regressions. Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Ansgar Burchardt writes: > (I don't maintain debootstrap.) > > I don't think it is a good idea to require debootstrap to know about > such details. > > For limiting network access, I would recommend instead using network > namespaces (to only provide limited network access for all processes) > and/or user namespaces (if filtering for single UIDs is really needed). > These do not require any uids to match between in- and outside. And sadly the submitter's address bounced my mail as the mail provider the submitter uses cannot parse RFC-5321 mail addresses correctly. Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
Michael Schaller writes: > At the end of the 'apt' package installation the '_apt' user will be > created without specifying a fixed uid. This typically results in a > differing '_apt' uid between the host system and the bootstrapped > system. The differing '_apt' uid is problematic in case the host > system has firewall rules specific to the '_apt' user and that > typically leads to Apt downloads failing inside a chroot. > > For more details see: > * https://lists.debian.org/debian-devel/2019/04/msg00259.html > * https://robots.org.uk/PbuilderFirewallSetup > > Unfortunately this issue isn't easy to detect/troubleshoot, > particularly firewall rules on the '_apt' uid and that there is an uid > mismatch inside a chroot. This could be improved a lot if debootstrap > could avoid this issue if it would ensure that the '_apt' user in the > bootstrapped system has the same uid as on the host system. (I don't maintain debootstrap.) I don't think it is a good idea to require debootstrap to know about such details. For limiting network access, I would recommend instead using network namespaces (to only provide limited network access for all processes) and/or user namespaces (if filtering for single UIDs is really needed). These do not require any uids to match between in- and outside. Ansgar
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Jonathan Dowland writes: > So far as I am aware there is still radio silence from active GNOME > packaging team members regarding this issue. No comment yet on the > patch I adapted, positive or negative; this bug (#927667) remains > at an RC severity. > > I've not yet read all the thread that Samuel linked to[1] but it looks > like it leans in favour of preserving the current default (xorg). > > I'm copying -release team to see if they have any (new) opinions on > the matter. Otherwise I guess it's up to someone to prepare an NMU > upload, which I will *try* to look at in the next few days, but can't > make any guarantees. I'm just a GNOME user, but from gdm3's changelog the default was switched to Wayland in July 2017 (or August 2017 for unstable). I myself only noticed the switch after reading it happened somewhere on the internet shortly after it happened. Switching the default back two weeks before the release seems too late for me. The largest issue seems to be accessibility, but as far as I understand we already recommend a different desktop environment for that. I don't think that warrants changes that would only see very little testing by now :-/ Ansgar
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
Mattia Rizzolo writes: > On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote: >> The .buildinfo files are referred to in the .changes files; renaming >> them would require updating the .changes file. The .changes files are >> used to upload the security updates to ftp-master. > > With .changes being ephemeral, it feels to me that using them to cross > the archive is not really a good solution, and whatever is used to copy > packages from one archive to another (is it dak itself?) should instead > re-create the upload and re-sign it. Also because that way it would be > perfectly able to "upload" all of the sources+binaries from sec-master > to ftp-master in a single go, which can't be bad. We also currently require .dsc to be signed by the same key as the .changes; that wouldn't work either. There are some advantages to changing the way the sync works, but it's not a priority to look at. There are enough other things... >> ftp-master also has the same problem when uploads end up in policy >> queues (the renaming to .buildinfo.N is only done when dak is "done" >> with the file and will never touch it again). > > Also here, it feels to me that once something is accepted into a policy > queue, dak should already consider it something controlled by itself, > store checksums in the database and be done, not keep the .changes > around as a "source of truth" for additional processing, imho. Throwing away .changes doesn't help with .buildinfo name conflicts. > Sure, I understand that things works like that, I'm just showing a few > design points that could potentially be done differently. We could also just not accept .buildinfo uploads when they don't contain useful information about published binaries, that is for source-only uploads. Maybe I should reenable the check for this at least on security-master? It was rejecting uploads that are okay for unstable/experimental so I disabled it again the last time. Ansgar
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On Mon, 2019-06-17 at 13:12 -0700, Vagrant Cascadian wrote: > > This behaviour is really causing issues for the security-archive so in > > one way or the other there needs to be a solution. Regularly we need > > to fetch the buildd changes and build binary packages, resign them and > > reupload them due to this bug. > > What's unclear to me is why the workaround in DAK for the main archive, > which adds .buildinfo.N for duplicate .buildinfo filenames, can't be or > hasn't been applied for the security archive. Is there something > fundamentally different with the security archive? The .buildinfo files are referred to in the .changes files; renaming them would require updating the .changes file. The .changes files are used to upload the security updates to ftp-master. ftp-master also has the same problem when uploads end up in policy queues (the renaming to .buildinfo.N is only done when dak is "done" with the file and will never touch it again). As most uploads go to unstable and experimental, one mostly doesn't notice the issue. Ansgar
Bug#930482: openblas: uses AVX-512 even when AVX-512 is not available in a VM
Package: libopenblas-base Version: 0.3.5+ds-3 Severity: important File: /usr/lib/x86_64-linux-gnu/libopenblas.so.0 Tags: upstream OpenBLAS tries to use AVX-2 / AVX-512 even when it is not actually available, causing programs to crash with SIGILL: +--- | Thread 1 "cholmodtest" received signal SIGILL, Illegal instruction. | 0x7728fc18 in dgemv_n_SKYLAKEX () from /usr/lib/x86_64-linux-gnu/libopenblas.so.0 | (gdb) bt | #0 0x7728fc18 in dgemv_n_SKYLAKEX () from /usr/lib/x86_64-linux-gnu/libopenblas.so.0 | [...] | (gdb) disassemble 0x7728fc18,+8 | Dump of assembler code from 0x7728fc18 to 0x7728fc20: | => 0x7728fc18 : vmovsd (%rdx),%xmm18 |0x7728fc1e : inc%rax +--- As far as I found out, the %xmm18 register should only be available with AVX-512. The CPU model is capable of AVX-2 and AVX-512, however it is not made available in the VM I am using and therefore missing from the "Flags" below. +--- | Architecture:x86_64 | CPU op-mode(s): 32-bit, 64-bit | Byte Order: Little Endian | Address sizes: 40 bits physical, 48 bits virtual | CPU(s): 16 | On-line CPU(s) list: 0-15 | Thread(s) per core: 1 | Core(s) per socket: 1 | Socket(s): 16 | NUMA node(s):2 | Vendor ID: GenuineIntel | CPU family: 6 | Model: 85 | Model name: Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz | Stepping:4 | CPU MHz: 3000.000 | BogoMIPS:6000.00 | Hypervisor vendor: VMware | Virtualization type: full | L1d cache: 32K | L1i cache: 32K | L2 cache:1024K | L3 cache:25344K | NUMA node0 CPU(s): 0-7 | NUMA node1 CPU(s): 8-15 | Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb stibp fsgsbase smep arat md_clear flush_l1d arch_capabilities +---[ Output from `lscpu` ] Ansgar
Bug#929265: coinor-ipopt: new upstream release available
Package: src:coinor-ipopt Version: 3.11.9-2.1 Severity: wishlist The Debian version of IPopt lags quite a bit behind upstream: Debian still ships 3.11.9 (released 2014-08-16); the current upstream release is 3.12.13 (released 2019-04-08), but there were several releases in between that were not includede in Debian. The `Homepage` field in Debian is also no longer current: the page now only says Ipopt has been moved to https://github.com/coin-or/Ipopt Ansgar
Bug#929122: coinor-ipopt: use parallel version of MUMPS (though only with one process)
Package: src:coinor-ipopt
Version: 3.11.9-2.1
Severity: normal
I had some problems with IPopt using the sequential version of MUMPS
recently: as MUMPS provides dummy `MPI_*` functions, my program ended
up using some of them or MUMPS used some of the real MPI functions.
As mentioned in IPopt's README this doesn't work well:
+---
| Note: MUMPS uses interally a fake implementation of MPI. If you are
| using Ipopt within an MPIprogram together with MUMPS, the code will not
| run. You will have to modify the MUMPS sources so that the MPI symbols
| inside the MUMPS code are renamed.
+---[
https://projects.coin-or.org/Ipopt/browser/stable/3.12/Ipopt/doc/documentation.pdf?format=raw
]
I guess I was a bit lucky that is didn't happen before.
The attached patch builds IPopt against the MPI-parallel version of
MUMPS, but uses only one process (MPI_COMM_SELF). That has worked
better for me without needing invasive changes to the MUMPS source
code.
Ansgar
diff -Nru coinor-ipopt-3.11.9/debian/control coinor-ipopt-3.11.9/debian/control
--- coinor-ipopt-3.11.9/debian/control 2015-08-30 14:44:13.0 +0200
+++ coinor-ipopt-3.11.9/debian/control 2019-03-15 14:01:05.0 +0100
@@ -3,8 +3,9 @@
Priority: extra
Maintainer: Greg Horn
Build-Depends: debhelper (>= 5), autotools-dev, gfortran, libblas-dev,
- libmumps-seq-dev (>= 4.9.2.dfsg-4),
- liblapack-dev, doxygen-latex, ghostscript, chrpath, cdbs
+ libmumps-dev (>= 4.9.2.dfsg-4),
+ liblapack-dev, doxygen-latex, ghostscript, chrpath, cdbs,
+ mpi-default-dev, mpi-default-bin
Build-Conflicts: pkg-config
Standards-Version: 3.9.5
Homepage: https://projects.coin-or.org/Ipopt
@@ -34,7 +35,7 @@
Package: coinor-libipopt-dev
Section: libdevel
Architecture: any
-Depends: coinor-libipopt1v5 (= ${binary:Version}), libmumps-seq-dev,
${shlibs:Depends}, ${misc:Depends}
+Depends: coinor-libipopt1v5 (= ${binary:Version}), libmumps-dev,
${shlibs:Depends}, ${misc:Depends}
Description: Interior-Point Optimizer - header files
Ipopt is an open-source solver for large-scale nonlinear continuous
optimization. It can be used from modeling environments, such as AMPL,
diff -Nru coinor-ipopt-3.11.9/debian/patches/parallel-mumps.patch
coinor-ipopt-3.11.9/debian/patches/parallel-mumps.patch
--- coinor-ipopt-3.11.9/debian/patches/parallel-mumps.patch 1970-01-01
01:00:00.0 +0100
+++ coinor-ipopt-3.11.9/debian/patches/parallel-mumps.patch 2019-03-15
14:01:05.0 +0100
@@ -0,0 +1,40 @@
+---
coinor-ipopt-3.11.9.orig/Ipopt/src/Algorithm/LinearSolvers/IpMumpsSolverInterface.cpp
coinor-ipopt-3.11.9/Ipopt/src/Algorithm/LinearSolvers/IpMumpsSolverInterface.cpp
+@@ -12,7 +12,7 @@
+
+ // The following line is a fix for otherwise twice-defined global variable
+ // (This would have to be taken out for a parallel MUMPS version!)
+-#define MPI_COMM_WORLD IPOPT_MPI_COMM_WORLD
++//#define MPI_COMM_WORLD IPOPT_MPI_COMM_WORLD
+ // The first header to include is the one for MPI.
+ #include "mpi.h"
+
+@@ -46,8 +46,6 @@ namespace Ipopt
+ static const Index dbg_verbosity = 0;
+ #endif
+
+-#define USE_COMM_WORLD -987654
+-
+ int MumpsSolverInterface::instancecount_mpi = 0;
+
+ MumpsSolverInterface::MumpsSolverInterface()
+@@ -71,8 +69,9 @@ namespace Ipopt
+ else if( instancecount_mpi > 0 )
+++instancecount_mpi;
+ #endif
++MPI_Comm comm = MPI_COMM_SELF;
+ int myid;
+-MPI_Comm_rank(MPI_COMM_WORLD, );
++MPI_Comm_rank(comm, );
+ #endif
+ mumps_->n = 0;
+ mumps_->nz = 0;
+@@ -82,7 +81,7 @@ namespace Ipopt
+ mumps_->job = -1;//initialize mumps
+ mumps_->par = 1;//working host for sequential version
+ mumps_->sym = 2;//general symetric matrix
+-mumps_->comm_fortran = USE_COMM_WORLD;
++mumps_->comm_fortran = MPI_Comm_c2f(comm);
+ dmumps_c(mumps_);
+ mumps_->icntl[1] = 0;
+ mumps_->icntl[2] = 0;//QUIETLY!
diff -Nru coinor-ipopt-3.11.9/debian/patches/series
coinor-ipopt-3.11.9/debian/patches/series
--- coinor-ipopt-3.11.9/debian/patches/series 2014-10-01 14:42:17.0
+0200
+++ coinor-ipopt-3.11.9/debian/patches/series 2019-03-15 14:01:05.0
+0100
@@ -2,3 +2,4 @@
add_missing_cstddef.patch
doxygen.patch
+parallel-mumps.patch
diff -Nru coinor-ipopt-3.11.9/debian/rules coinor-ipopt-3.11.9/debian/rules
--- coinor-ipopt-3.11.9/debian/rules2015-08-30 14:47:04.0 +0200
+++ coinor-ipopt-3.11.9/debian/rules2019-03-15 14:01:05.0 +0100
@@ -3,11 +3,15 @@
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk
-CPPFLAGS += -I/usr/include/mumps_seq -DHAVE_CSTDDEF
-LDFLAGS += -llapack -lblas -ldmumps_seq -ldl
+export OMPI_MCA_plm_rsh_agent=/bin/false
+export OMPI_MCA_rmaps_base_oversubscribe=1
+
+CPPFLAGS += -DHAVE_CSTDDEF
+LDFLAGS += -llapack -lblas -ldmumps -ldl
DEB_CONFIGURE_EXTRA_FLAGS += --enable-static \
--with-mumps-incdir=/usr/include \
-
Bug#929108: unblock / tpu approval: gmsh/4.1.3+ds1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
gmsh has an old path to OpenCASCADE include files (#927808); this is
easy to fix (see attached diff).
Rebuilding the package also changes a dependency on amd64 (libgmsh4.1
depends on `libhdf5-openmpi-103 (>= 1.8.13)` instead of `libhdf5-103`
after the rebuild); however this matches the dependency on i386.
However gmsh was updated to a new upstream release in unstable on
2019-03-02 with a small fix on 2019-03-04; this missed the freeze date
slightly.
Do you prefer an upload via t-p-u or should I prepare a gmsh
4.1.5+really4.1.3+ds1-1 upload for unstable?
Ansgar
diff -Nru gmsh-4.1.3+ds1/debian/changelog gmsh-4.1.3+ds1/debian/changelog
--- gmsh-4.1.3+ds1/debian/changelog 2019-01-27 12:22:01.0 +0100
+++ gmsh-4.1.3+ds1/debian/changelog 2019-05-17 10:41:56.0 +0200
@@ -1,3 +1,10 @@
+gmsh (4.1.3+ds1-2) buster; urgency=medium
+
+ * Team upload.
+ * debian/rules: Do not pass `-DOCC_INC=...` to cmake (Closes: #927808)
+
+ -- Ansgar Burchardt Fri, 17 May 2019 10:41:56 +0200
+
gmsh (4.1.3+ds1-1) unstable; urgency=medium
* [dbbbe82] New upstream version 4.1.3+ds1
diff -Nru gmsh-4.1.3+ds1/debian/rules gmsh-4.1.3+ds1/debian/rules
--- gmsh-4.1.3+ds1/debian/rules 2019-01-27 12:22:01.0 +0100
+++ gmsh-4.1.3+ds1/debian/rules 2019-05-17 10:39:57.0 +0200
@@ -32,7 +32,6 @@
-DENABLE_ONELAB:BOOL=ON \
-DCMAKE_SKIP_RPATH:BOOL=ON \
-DCMAKE_INCLUDE_PATH:STRING="/usr/include/mpi" \
--DOCC_INC:STRING="/usr/include/occt" \
-DOCC_LIB:STRING="/usr/lib/${DEB_HOST_MULTIARCH}"
│
Bug#910783: Remove doc-base recommendation
Paul Wise writes: > On Thu, 11 Oct 2018 17:32:52 -0700 Sean Whitton wrote: >> Instead, if there is indeed consensus, we should change it so that it >> no longer says that doc-base registration is recommended. > > We need a cross-distro cross-desktop standard for an index of > docs before we can move on from doc-base like we did with menu. I don't think so: we can just remove doc-base without providing a replacement at the same time too. Personally I don't know anyone using doc-base (probably most don't even know it exists). If doc-base has indeed no users (or very few users), it just creates work for maintainers for no real benefit. As [1] says, doc-base had 20+ years to get adopted. I think it is fair to say that it failed to do so. [1] https://bugs.debian.org/910783#13 Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
On Sun, 2019-05-05 at 16:05 +0200, Santiago Vila wrote: > [ Ansgar: If you still can reproduce the assertion failure, please > file > a new bug. It's better not to mix different issues in the same report ]. The other assertion failure I had also disappeared this week. Not sure if there is a real bug, but I don't have time to look at this too much. Before it was reproducible, unless I rebuilt dune-grid which made the problem in dune-pdelab go away as well... Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
Control: reassign -1 src:dune-pdelab 2.6~20180302-1 Control: retitle -1 dune-pdelab: testpk fails with assertion failure On Mon, 2019-04-08 at 08:42 +0200, Ansgar Burchardt wrote: > This is a bug in dune-istl, though I'm not quite sure I understand > what > is exactly wrong. Renaming the template argument from `T` to `T1` in > the definition of `prolongateVector` makes the problem go away, but the > name of template arguments shouldn't really matter? > > There is also a template argument `T` in the generic version of the > `Transfer` class... Maybe that results in the confusion in some way? That problem went away with a GCC update, but there is still a problem with a test in dune-pdelab that now fails... Not sure yet if the problem is in dune-grid or dune-pdelab for that one, reassigning to dune-pdelab for now: +--- | check_mesh: checking mesh 'DUNE AlbertaGrid' | checking done; no error detected | AlbertaGrid< 2, 2 > created from macro grid file '/<>/dune/pdelab/test/grids/ldomain.al'. | GridParameterBlock: Parameter 'refinementedge' not specified, defaulting to 'ARBITRARY'. | testpk: /build/dune-grid-yp9bpw/dune-grid-2.6.0/dune/grid/albertagrid/elementinfo.hh:488: bool Dune::Alberta::ElementInfo::isLeaf() const [with int dim = 2]: Assertion `!(*this) == false' failed. +--- Ansgar
Bug#917535: debian-archive-keyring: ftp-master key for buster
Niels Thykier writes: > We need new archive signing keys for buster, so we can include them in > a debian-archive-keyring upload before the buster release. The two keys are prepared; I'm waiting for a few more signatures from other ftp masters. FWIW they will be: pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12] 5E61B217265DA9807A23C5FF4DFAB270CAA96DFA uid [ full ] Debian Security Archive Automatic Signing Key (10/buster) sub rsa4096 2019-04-14 [S] [expires: 2027-04-12] 5237CEEEF212F3D51C74ABE0112695A0E562B32A pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12] 80D15823B7FD1561F9F7BCDDDC30D7C23CBBABEE uid [ full ] Debian Archive Automatic Signing Key (10/buster) sub rsa4096 2019-04-14 [S] [expires: 2027-04-12] 0146DC6D4A0B2914BDED34DB648ACFD622F3D138 and are also signed by the old signing key. Ansgar signature.asc Description: PGP signature
Bug#926849: Generate treeinfo files to ease automatic installations
On Thu, 2019-04-11 at 11:49 +0200, Guido Günther wrote:
> E.g. for amd64 and stretch we'd have a file
>
>http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/.treeinfo
>
> looking like
>
> [checksums]
> current/images/netboot/mini.iso = sha256:...
> current/images/netboot/debian-installer/amd64/initrd.gz =
> sha256:...
> current/images/netboot/debian-installer/amd64/linux = sha256: ...
>
> [general]
> arch = x86_64
> family = Debian
> name = Debian Stretch
> version = 9.8.0
> platforms = x86_64
>
> [images-x86_64]
> boot.iso = current/images/netboot/mini.iso
> initrd = current/images/netboot/debian-installer/amd64/initrd.gz
> kernel = current/images/netboot/debian-installer/amd64/linux
Given one can list multiple architectures at one place, shouldn't that
be
https://deb.debian.org/debian/dists/${release}/main/treeinfo
or
https://deb.debian.org/debian/dists/${release}/treeinfo
Users shouldn't have to deal with installer-amd64 or such.
"[general]" also seems deprecated (and limited to one arch).
Is there any reason why this should be a hidden file?
Shouldn't such a file be signed in some way? If for some reason you
only want to trust http(s), the canonical location should probably
*not* be the regular mirror network, but some different place (at which
point anyone could generate these files as well).
Ansgar
Bug#926215: dune-pdelab: FTBFS with gcc 8.3
Control: reassign -1 src:dune-istl 2.6.0-2 Control: affects -1 src:dune-pdelab Santiago Vila writes: > /usr/include/dune/istl/paamg/transfer.hh:97:5: error: no declaration matches > 'void Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T, const > Dune::Amg::SequentialInformation&, const Redist&)' > Transfer::prolongateVector(const > AggregatesMap& aggregates, > ^~~~ > /usr/include/dune/istl/paamg/transfer.hh:62:19: note: candidates are: > 'template template static void > Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T1, const > Dune::Amg::SequentialInformation&)' >static void prolongateVector(const AggregatesMap& aggregates, > Vector& coarse, Vector& fine, >^~~~ > /usr/include/dune/istl/paamg/transfer.hh:57:19: note: > 'template template static void > Dune::Amg::Transfer Dune::Amg::SequentialInformation>::prolongateVector(const > Dune::Amg::AggregatesMap&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, Dune::Amg::Transfer Dune::Amg::SequentialInformation>::Vector&, T1, const > Dune::Amg::SequentialInformation&, const Redist&)' >static void prolongateVector(const AggregatesMap& aggregates, > Vector& coarse, Vector& fine, >^~~~ > /usr/include/dune/istl/paamg/transfer.hh:50:11: note: 'class > Dune::Amg::Transfer' defined here > class Transfer >^ This is a bug in dune-istl, though I'm not quite sure I understand what is exactly wrong. Renaming the template argument from `T` to `T1` in the definition of `prolongateVector` makes the problem go away, but the name of template arguments shouldn't really matter? There is also a template argument `T` in the generic version of the `Transfer` class... Maybe that results in the confusion in some way? Ansgar
Bug#925543: matrix-synapse: uses too generic names for programs installed to /usr/bin
Package: matrix-synapse Version: 0.99.2-1 Severity: normal matrix-synapse installs several programs with fairly generic names to /usr/bin, for example: generate_config hash_password move_remote_media_to_new_store.py I suggest that these are either moved to /usr/lib/matrix-synapse or renamed (synapse-generate_config); renaming should probably be done upstream. (The same applied to the man pages.) The programs register_new_matrix_user sync_room_to_group.pl might also be specific to synapse and better moved/renamed as well. They are a bit less generic though. Ansgar
Bug#925435: unblock: fwupd/1.2.5-2
Steve McIntyre writes: > Please unblock package fwupd Please also unblock fwupd-amd64-signed/1.2.5+2 fwupd-arm64-signed/1.2.5+2 fwupd-armhf-signed/1.2.5+2 fwupd-i386-signed/1.2.5+2 at the same time. Ansgar
Bug#925436: unblock: fwupdate/12-4
Steve McIntyre writes: > Please unblock package fwupdate Please also unblock fwupdate-amd64-signed/12+4 fwupdate-arm64-signed/12+4 fwupdate-armhf-signed/12+4 fwupdate-i386-signed/12+4 at the same time. Ansgar
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
On Wed, 20 Mar 2019 15:59:40 + Dimitri John Ledkov wrote: > On Wed, 20 Mar 2019 16:31:25 +0100 Ansgar Burchardt wrote: > > Hi, > > > > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger > > than just libpq5: just looking at a small sample of the direct rdeps of > > libssl1.1, one can find the following GPL-licensed programs linking it: > > > > cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete > > > > Cryptsetup has a linking exception for OpenSSL: > https://tracker.debian.org/media/packages/c/cryptsetup/changelog-22.1.0-2 It has half of an exception. COPYING includes the following: +--- | In addition, as a special exception, the copyright holders give | permission to link the code of portions of this program with the | OpenSSL library under certain conditions as described in each | individual source file, and distribute linked combinations | including the two. +--- But the "certain conditions as described in each individual source file" are nowhere to be found; instead source files only say they are licensed under GPL (without any exception). Also, libcryptsetup12 has GPL-2+ rdeps (w/o any exception). So the problem only gets ever larger... Examples: libcryptsetup12 -> cryptmount (GPL-2+, no exception) libcryptsetup12 -> libvolume-key1 (GPL-2, no exception) -> libblockdev-crypto2 (LGPL-2.1+, no problem) -> udisks2 (GPL-2+, no exception) And indeed: +--- | % ldd /usr/lib/udisks2/udisksd | grep libssl | libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x7ff0c6009000) +--- Ansgar
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
Hi, On Wed, 2019-03-20 at 16:31 +0100, Ansgar Burchardt wrote: > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger > than just libpq5: just looking at a small sample of the direct rdeps > of > libssl1.1, one can find the following GPL-licensed programs linking > it: > > cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete > > Also amanda-client, validns as they contain patches in d/patches > licensed under the GPL. > > There are probably lots more, especially when you start looking at > libraries (and their whole dependency trees). > > There is also cups which was reported to switch to Apache-2 which is > also GPL-2-incompatible... That has lots of rdeps too (including for > example all GTK applications). Also Python programs which often use libssl and are GPL-licensed. > Fedora treats OpenSSL as a "system library"[1]. I would guess they > might do the same for libcups too. I also came up with another interesting problem: libgcc and other low- level runtime libraries are licensed under GPL-3+-with-some-exception. However for a GPL-2-only program FOO with *no* system library exception, the complete source code would include libgcc and would require libgcc do be available under a GPL-2-compatible license... The runtime exception from libgcc doesn't help as FOO would need an exception... (I.e. the same problem just with libgcc instead of libssl) Ansgar
Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies
Hi, the OpenSSL ./. GPL problem (if one sees it as a problem) is larger than just libpq5: just looking at a small sample of the direct rdeps of libssl1.1, one can find the following GPL-licensed programs linking it: cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete Also amanda-client, validns as they contain patches in d/patches licensed under the GPL. There are probably lots more, especially when you start looking at libraries (and their whole dependency trees). There is also cups which was reported to switch to Apache-2 which is also GPL-2-incompatible... That has lots of rdeps too (including for example all GTK applications). Fedora treats OpenSSL as a "system library"[1]. I would guess they might do the same for libcups too. Ansgar [1] https://fedoraproject.org/wiki/Licensing:FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F
Bug#923286: scp: 'protocol error: filename does not match request' even though it does match
Package: openssh-client Version: 1:7.9p1-6 Severity: normal The file "This is a [file].txt" (w/o quotes) exists on `remote`. The following does no longer work: $ scp remote:'./"This is a [file].txt"' blubb protocol error: filename does not match request These however do still work: $ scp remote:'"This is a [file].txt"' blubb $ scp remote:'./This\ is\ a\ \[file\].txt' blubb $ scp remote:'This\ is\ a\ \[file\].txt' blubb Extended globs (from zsh) now only work sometimes as well: $ scp daikoku:'./This\ is\ a\ \[file\].txt(.)' blubb protocol error: filename does not match request $ scp daikoku:'This\ is\ a\ \[file\].txt(.)' blubb Ansgar -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Versions of packages openssh-client depends on: ii adduser 3.118 ii dpkg 1.19.2 ii libc6 2.28-7 ii libedit2 3.1-20181209-1 ii libgssapi-krb5-2 1.17-1 ii libselinux1 2.8-1+b1 ii libssl1.1 1.1.1a-1 ii passwd1:4.5-1.1 ii zlib1g1:1.2.11.dfsg-1
Bug#922674: debian-policy: make symlink requirements consistent
Package: debian-policy
Version: 4.3.0.2
Severity: normal
Policy 10.5 (Symbolic links) currently has two classes of requirements:
Symlinks between /${x} and /${x} (same top-level directory) must use
relative links; symlinks between /${x} and /${y} (different top-level
directories).
The historic reasons[1][2] point out this is to allow /usr (or other
top-level directories) to be a symlink to somewhere else which would
break symlinks using '..' in their target.
It seems strange to treat top-level directories differently: why
should /usr be allowed to be a symlink, but /usr/local, /usr/lib or
/usr/share/doc not? I can't come up with a better idea than that
top-level directories are something like "driver letters".
So I suggest to either:
(a) require *all* symlinks to be relative
(b) forbid using '..' in symlinks
(a) would imply that users would have to use bind-mounts instead of
symlinks; (b) would allow any directory to be a symlink, but require
tools acting on chroots to be aware of symlinks (but they have to be
that already as we sometimes require absolute symlinks already).
Ansgar
[1] https://lists.debian.org/debian-policy/1998/04/msg00110.html
[2] https://lists.debian.org/debian-policy/1998/03/msg00050.html
Bug#922206: code-signing: leaks database sessions; failure when many packages are processed
Package: ftp.debian.org Severity: normal secure-boot-code-sign.py leaks database sessions. This leads to failure when processing several packages. I've attached the traceback. Ansgar ERROR:root: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 1044, in _do_get return self._pool.get(wait, self._timeout) File "/usr/lib/python3/dist-packages/sqlalchemy/util/queue.py", line 156, in get raise Empty sqlalchemy.util.queue.Empty During handling of the above exception, another exception occurred: Traceback (most recent call last): File "./code-signing/secure-boot-code-sign.py", line 513, in main process(p) File "./code-signing/secure-boot-code-sign.py", line 466, in process sign_and_log_files(job) File "./code-signing/secure-boot-code-sign.py", line 327, in sign_and_log_files log_signature(relative_file_path, sig_hash, pkg, job.version, presign_id, job.architecture) File "./code-signing/secure-boot-code-sign.py", line 304, in log_signature s.commit() File "/usr/lib/python3/dist-packages/sqlalchemy/orm/session.py", line 801, in commit self.transaction.commit() File "/usr/lib/python3/dist-packages/sqlalchemy/orm/session.py", line 392, in commit self._prepare_impl() File "/usr/lib/python3/dist-packages/sqlalchemy/orm/session.py", line 372, in _prepare_impl self.session.flush() File "/usr/lib/python3/dist-packages/sqlalchemy/orm/session.py", line 2019, in flush self._flush(objects) File "/usr/lib/python3/dist-packages/sqlalchemy/orm/session.py", line 2137, in _flush transaction.rollback(_capture_exception=True) File "/usr/lib/python3/dist-packages/sqlalchemy/util/langhelpers.py", line 60, in __exit__ compat.reraise(exc_type, exc_value, exc_tb) File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 186, in reraise raise value File "/usr/lib/python3/dist-packages/sqlalchemy/orm/session.py", line 2101, in _flush flush_context.execute() File "/usr/lib/python3/dist-packages/sqlalchemy/orm/unitofwork.py", line 373, in execute rec.execute(self) File "/usr/lib/python3/dist-packages/sqlalchemy/orm/unitofwork.py", line 532, in execute uow File "/usr/lib/python3/dist-packages/sqlalchemy/orm/persistence.py", line 149, in save_obj base_mapper, states, uowtransaction File "/usr/lib/python3/dist-packages/sqlalchemy/orm/persistence.py", line 270, in _organize_states_for_save states): File "/usr/lib/python3/dist-packages/sqlalchemy/orm/persistence.py", line 1053, in _connections_for_states connection = uowtransaction.transaction.connection(base_mapper) File "/usr/lib/python3/dist-packages/sqlalchemy/orm/session.py", line 232, in connection return self._connection_for_bind(bind, execution_options) File "/usr/lib/python3/dist-packages/sqlalchemy/orm/session.py", line 323, in _connection_for_bind conn = self._parent._connection_for_bind(bind, execution_options) File "/usr/lib/python3/dist-packages/sqlalchemy/orm/session.py", line 334, in _connection_for_bind conn = bind.contextual_connect() File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 2039, in contextual_connect self._wrap_pool_connect(self.pool.connect, None), File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 2074, in _wrap_pool_connect return fn() File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 376, in connect return _ConnectionFairy._checkout(self) File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 713, in _checkout fairy = _ConnectionRecord.checkout(pool) File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 480, in checkout rec = pool._do_get() File "/usr/lib/python3/dist-packages/sqlalchemy/pool.py", line 1053, in _do_get (self.size(), self.overflow(), self._timeout)) sqlalchemy.exc.TimeoutError: QueuePool limit of size 5 overflow 10 reached, connection timed out, timeout 30
Bug#922202: src:mandos: modifies d/control during build
Package: src:mandos Version: 1.8.3-2 Severity: serious d/rules modifes d/control during build: ``` override_dh_shlibdeps-arch: [...] dpkg --compare-versions $$gnutls_version lt 3.6.0 \ && sed --in-place --expression='s/libgnutls28-dev (>= 3\.6\.6) | //' debian/control ``` Please don't modify d/control in any way that is automatically run during build; see also the "CDBS" entry of [1]. Ansgar [1] https://ftp-master.debian.org/REJECT-FAQ.html
Bug#919044: lists.d.o: wrong List-Archive for debian-private@
Package: lists.debian.org Severity: minor Hi, debian-private uses the following List-Archive field: List-Archive: It should be file://master.debian.org/home/debian/archive/debian-private/ instead. See also RFC 8089 and in particular the following parts: +--- |Non-local files: | |o A non-local file with an explicit authority. For example: | | * "file://host.example.com/path/to/file" +---[ RFC 8089, Appendix B. Example URIs ] +--- | Common UNIX shells such as the Bourne-Again SHell (bash) and Z SHell | (zsh) provide a function known as "tilde expansion" [Bash-Tilde] or | "filename expansion" [Zsh-Tilde], where a path that begins with a | tilde character "~" can be expanded out to a special directory name. | No such facility exists using the file URI scheme; a tilde in a file | URI is always just a tilde. +---[ RFC 8089, D.1. POSIX Systems ] Ansgar
Bug#918246: dune-common: FTBFS for armhf on arm64, fails tests
Steve McIntyre writes:
> On Fri, Jan 04, 2019 at 08:37:24PM +0200, Graham Inggs wrote:
>>This sounds like #918157.
>
> Nod. I'm seeing similar behaviour in a few more packages since tihs
> point, too. :-(
As mentioned on IRC: if you want to make sure that it is a problem with
OpenMPI, you can just build the attached minimal MPI program.
Ansgar
/*
sudo apt-get install mpi-default-bin mpi-default-dev
export OMPI_MCA_plm_rsh_agent=/bin/false
export OMPI_MCA_rmaps_base_oversubscribe=1
mpicc -o mpi-test mpi-test.c && mpirun -np 2 ./mpi-test
*/
#include
int main(int argc, char** argv)
{
MPI_Init(, );
MPI_Finalize();
return 0;
}
Bug#917995: debian-policy: drop section 1.6 Translations
Sean Whitton writes: > On Wed 02 Jan 2019 at 12:29pm +0900, Ansgar Burchardt wrote: >> I hereby propose to drop section 1.6 Translations and the following >> sentence: "When translations of this document into languages other >> than English disagree with the English text, the English text takes >> precedence." > > (Procedural note: while of course discussion of section 1.6 is welcome, > it's a matter for Policy Editor discretion exactly how translations are > handled.) Well, all of policy handling is under the Policy Editor's discretion. >> If it is wrongly translated, then the English text probably isn't >> clear enough (otherwise the translation would have the same meaning) >> and would need to be clarified anyway to avoid being ambigious. Even >> if not, the same process can be used to clarify the meaning of >> non-English versions. >> >> There should be no need to put one language over others. > > The thought is that that English text receives much greater scrunity, > both because patches get reviewed by several people, and because more > people read it. So it is much less likely to have mistakes that > something that a single person translated. > > Any DD can commit a translation to the repo and it will get published, > basically. Not so for changes to the English text. I see the review process more as generally agreeing on the change; not every problem will be caught anyway. Even if there is a mistake in a translation, it's not like someone will go the prison for following the "wrong" version. A small enough price to pay for being a bit more inclusive :) Ansgar
Bug#917995: debian-policy: drop section 1.6 Translations
Package: debian-policy Version: 4.3.0.1 Severity: normal Hi, I hereby propose to drop section 1.6 Translations and the following sentence: "When translations of this document into languages other than English disagree with the English text, the English text takes precedence." If it is wrongly translated, then the English text probably isn't clear enough (otherwise the translation would have the same meaning) and would need to be clarified anyway to avoid being ambigious. Even if not, the same process can be used to clarify the meaning of non-English versions. There should be no need to put one language over others. Ansgar
Bug#917431: debian-policy: virtual packages: logind, default-logind
Adam Borowski writes: > Thus, the wording would be (as proposed by fsateler): > > logind: an org.freedesktop.login1 D-Bus API implementation > > default-logind: should be provided by the distribution's default logind > provider (currently pam-systemd) So any provider of logind would have to provide the full interface of the current interface (including future updates)? The patch against systemd used versioned provides. Is that still the plan? If so, it should probably be documented in the virtual package list. > Background: currently libpam-systemd provides two features currently used > by third parties: one is the necessary hooks to start the systemd > implementation of login1. You can start logind without libpam-systemd, it just wouldn't know about any session. So it is about providing hooks to register sessions with logind. Ansgar
Bug#916760: emacs: please enable systemd socket activation support
Hi,
Ansgar Burchardt writes:
> emacs26 added support for systemd socket activation (which I'm looking
> forward to use).
I was asked on IRC to test this with the Debian package (1:26.1+1-2).
It works:
After starting the emacs.socket unit, systemd opens the socket:
+---
| [...] /run/user/[...]/emacs [...] users:(("systemd",pid=2375,fd=23))
+---[ `ss -lxp | grep emacs` ]
Running `emacsclient` then starts `emacs` and the socket is passed to
emacs:
+---
| [...] /run/user/[...]/emacs [...]
users:(("emacs",pid=12153,fd=3),("systemd",pid=2375,fd=23))
+---[ `ss -lxp | grep emacs` ]
I've attached the .socket and .service units I'm using as someone was
asking for them (enable only emacs.socket to start emacs on demand); I
also have a wrapper script `e` which calls `emacsclient` with the
`--socket-name=${XDG_RUNTIME_DIR}/emacs` option (this would probably
also be safe to use by default if XDG_RUNTIME_DIR is set).
Ansgar
[Unit]
Description=GNU Emacs (Server)
Documentation=man:emacs(1)
Requires=emacs.socket
[Service]
ExecStart=/usr/bin/emacs --fg-daemon
ExecStop=/usr/bin/emacsclient --socket-name=%t/emacs --eval "(kill-emacs 0)"
Restart=always
Environment=GTK_IM_MODULE=xim
Environment="XMODIFIERS=@im=ibus"
Environment=CLUTTER_IM_MODULE=xim
Environment=GPG_AGENT_INFO=%t/keyring/gpg:0:1
[Install]
WantedBy=default.target
[Unit]
Description=GNU Emacs (Server)
Documentation=man:emacs(1) man:emacsclient(1)
[Socket]
ListenStream=%t/emacs
SocketMode=0600
[Install]
WantedBy=sockets.target
Bug#916959: libjuliaX: please install files to /usr/lib/.../julia-${soversion}
Package: src:julia Version: 1.0.2-1 Severity: normal Hi, libjuliaX installs files to usr/lib/.../julia and thus has to Replaces/Breaks every other version libjuliaY. However the point of package renaming on soname change is that libjuliaX and libjuliaY can be coinstalled (otherwise a Provides: libjuliaX would be sufficient). Please install files to a location that changes with the soname of libjulia such as usr/lib/.../julia-X. Ansgar
Bug#916957: julia (source): missing source for contrib/windows/7zS.sfx
Package: src:julia Version: 0.7.0-2 Severity: serious Hi, the source for contrib/windows/7zS.sfx seems to be missing. As the file is probably not needed for Debian, it could just be removed from Debian's source tarball. Ansgar
Bug#916927: aptitude: should consistently choose between signed and unsigned kernels
Control: reassign -1 src:linux 4.19.9-1 On Thu, 20 Dec 2018 16:26:55 +0100 Vincent Lefevre wrote: > After an upgrade of linux-image-amd64, which now depends on > linux-image-4.19.0-1-amd64, on one machine I got: > > linux-image-4.19.0-1-amd64 4.19.9-1 > > but on another machine I got: > > linux-image-4.19.0-1-amd64-unsigned 4.19.9-1 The issue is that linux-image-4.19.0-1-amd64-unsigned has Provides: linux-image-4.19.0-1-amd64 So if linux-image-amd64 starts depending on linux-image-4.19.0-1-amd64 before the signed version is present, apt will install the unsigned version. This doesn't look like a bug in apt to me. The easiest way to avoid this would be to drop the Provides from the unsigned image. Is there any downside for doing so? Ansgar
Bug#761880: [Pkg-sysvinit-devel] Bug#761880: sysv-rc: support init scripts in /lib/init.d (or similar)
Control: reopen -1 Dmitry Bogatov writes: > control: tags -1 wontfix > > [2014-09-16 18:00] Ansgar Burchardt >> The symlinks in /etc/rc?.d/* and /etc/default/* are configuration files, >> but init script themselves are not (and if admins are supposed to modify >> them, I would call them buggy). > > Your proposal contradicts Debian Policy (9.3.2): No, all scripts in /etc/init.d would still be treated as configuration files. Just packages could choose to *not* do that (as is the sane way) by shipping init scripts in a different location. Policy also seems to lag a decade behind reality: > The /etc/init.d scripts must be treated as configuration files, either > (if they are present in the package, that is, in the .deb file) by > marking them as conffiles, or, (if they do not exist in the .deb) by > managing them correctly in the maintainer scripts (see Configuration > files). This is important since we want to give the local system > administrator the chance to adapt the scripts to the local system, > e.g., to disable a service without de-installing the package, or to It's possible to disable services without editing /etc/init.d/*. > specify some special command line options when starting a service, It's possible to do that without editing /etc/init.d/*. (/etc/default/*) Allowing packages to not have init scripts as configuration files would help dealing with outdated init scripts (from removed, but not purged packages) which cause problems (for example when they lack LSB headers, have outdated dependencies which cause cirular dependencies, ...). Ansgar
Bug#916760: emacs: please enable systemd socket activation support
Hi,
I got around to rebuild emacs with libsystemd-dev installed. That is
enough for socket activation to work (with custom emacs.socket file):
+---
| run/user/[...]/emacs [...]
users:(("emacs",pid=26360,fd=3),("systemd",pid=2487,fd=23)) <->
+---( from ss output )
Ansgar
Bug#916760: emacs: please enable systemd socket activation support
Package: emacs Version: 1:26.1+1-1 Severity: normal Hi, emacs26 added support for systemd socket activation (which I'm looking forward to use). However looking at the buildd log it seems this isn't enabled: +--- | Does Emacs use -lsystemd? no +---[ https://buildd.debian.org/status/fetch.php?pkg=emacs=amd64=1%3A26.1%2B1-1=1545095253=0 ] It might be enough to just add a build-dep on libsystemd-dev. (It's fine for me to not ship systemd units for this, but I would like to at least not have to rebuild emacs.) Ansgar
Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default
Hi, Hideki Yamane writes: > On Sun, 2 Dec 2018 15:15:21 + > Simon McVittie wrote: >> > - What is the problem? (broken build for which packages? Just R?) >> >> The problem we're aware of is: >> >> Some packages auto-detect the absolute path to an executable (for example >> bash or perl) and hard-code it into their output (for example the #! line >> of the bash scripts in quilt). > > Can we check and track this behavior in our packages? The Reproducible Builds project was so kind to help and now runs one build in a non-merged-/usr and a second build in a merged-/usr environment. Packages that hardcode the path to utilities, but would pick up the wrong one in a merged-/usr environment will result in a difference between the two builds and can thus be found. See [1] for an overview of issues found this way; as the entire archive was already rebuilt in this setup, there shouldn't be many more issues of this type that we don't know about[2]. Not all of these differences even cause issues as in a few packages the utility with the hardcoded path is not even used at all. Bug reports were already submitted for over half the packages, often including a simple patch (usually something like adding BASH=/bin/bash to dh_auto_configure). So we look to be on a good track to address the remaining issues. I don't think that the debootstrap default has to be reverted temporarily again to deal with this: there are only very few packages causing problems and these should have a patch soon. In addition one has to actually built one of the very few packages in a merged-/usr environment and then install them in a non-merged-/usr environment to actually trigger the problem and debootstrap already defaults to non-merged-usr for buildd chroots for now. Ansgar [1] https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html [2] https://bugs.debian.org/914897#81
Bug#914897: debating the wrong thing
Adam Borowski writes: > On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote: >> In very rare cases (an estimated 0.3% of the archive or so). I'm fairly >> confident that for more than 0.3% of the archive something can go wrong >> when building in non-clean environments. > > Your figure of ~80 packages counts only packages which went through a > reproducible-builds rebuild. So only all? > We later learned only a part of the archive got rebuilt since the bad > debootstrap backport. Yes, some packages were not yet rebuilt in testing, but having them rebuilt in unstable is enough. >> We had the discussion (usrmerge as default) already quite some time >> ago. Why start again at zero? As a random reference, the D-I Stretch >> RC 1 release announcement explicitly stated: >> >> +--- >> | * The switch to merged-/usr as the default setting for debootstrap >> |was reverted since it uncovered a number of important issues which >> |might not be all fixed in time for stretch. This setting is >> |expected to come back as the default at the beginning of the next >> |release cycle. >> +--- >> >> And just that happened (except a bit later). > > Except that the change went live only on 2018-11-10, then waited until > buildds recreated their chroots, then until dinstall and mirror push... No, anyone using testing/unstable to setup a new build chroot since June should have gotten a merged-/usr chroot. That no issues were found earlier is probably related to there being not so many issues. (Fun fact: there are ~3k debootstrap installations on testing/unstable, compared to 6.2k on stable and 2k on oldstable according to popcon.) Anyway, buildds are not using merged-/usr, so there is no problem with them. > and the sky started falling immediately after that. Hmm, two packages or so were reported to be broken. That is a quite high standard for "sky falling". What would you call an upload that breaks more packages? The monthly apocalypse which we deal with just fine? >> You could have easily asked the tech-ctte back then (or even before) >> instead of waiting until shortly before the Buster freeze and after >> people invested more work. > > It was only shortly before the Buster freeze that we saw this change in > action! Had the switch get flipped sooner we'd have a chance to see the > results. By now, it's much too late to fix things before the freeze > (and I don't see how they could be fixed even had we two years of > time). You keep saying that it is too late to fix anything or that it is too much work, but why do you think so? I've looked at patching packages and how many packages need changes and it does not seem much work; indeed after a week about half of the packages already have a (usually trivial) patch. If you think it is too much work or too many things break, please at least give an estimate of what you are talking about... I feel like only one side is doing any research here. > By now, all we can do is damage control. Which can be a hasty force-merge > or a hasty revert. Unless you can somehow make dpkg-dev omniscient. If we keep merged-/usr as default then we can /recommend/ people to install usrmerge to switch to merged-/usr; reducing the difference between newly-installed and existing setups is a good idea IMHO. I think I filed a report for this two years ago. Maybe we should also mention somewhere that it might be useful to not switch build environments (yet). Ansgar
Bug#914897: debating the wrong thing
Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported. In this case someone would have
>> to write a unusrmerge program to convert systems with merged-/usr to
>> systems with unmerged-/usr.
>
> Currently merged-usr is broken because it can build packages which do
> not work on non-merged-usr systems.
In very rare cases (an estimated 0.3% of the archive or so). I'm fairly
confident that for more than 0.3% of the archive something can go wrong
when building in non-clean environments.
> It would be quite wrong (both technically and socially) to react to
> this lack of foresight,
The reported problems are not really unexpected...
> lack of consultation,
It was discussed on -devel@ several times. I think LWN also reported
about merged-/usr developments in Debian more than once, it wasn't a
secret cabal development.
So where is the lack of consultation?
> and lack of testing, by pressing forward.
It has been tested for quite a while.
A helpful new test was recently added by the Reproducible Builds project
which allowed to identify most problematic packages.
What is technically and socially wrong is reverting a change after a
small issue was found which is already in the process of getting fixed
for most packages.
> When we have stopped generating more lossage, we can start to think
> about whether we want to transition to usrmerge as default, whether to
> make it mandatory, and if so how the transition should be handled, and
> on what timescale.
We had the discussion (usrmerge as default) already quite some time
ago. Why start again at zero? As a random reference, the D-I Stretch
RC 1 release announcement explicitly stated:
+---
| * The switch to merged-/usr as the default setting for debootstrap
|was reverted since it uncovered a number of important issues which
|might not be all fixed in time for stretch. This setting is
|expected to come back as the default at the beginning of the next
|release cycle.
+---
And just that happened (except a bit later).
You could have easily asked the tech-ctte back then (or even before)
instead of waiting until shortly before the Buster freeze and after
people invested more work.
Making it mandatory or not is an unrelated decision. That can easily
just come later.
> We need the space to discuss those options properly without being
> distracted by what is IMO currently a crisis in stretch-backports and
> buster.
There is no such crisis. There was also enough time to discuss this in
the last years or even since June (when it was enabled by default
again)...
Ansgar
Bug#915517: ucspi-tcp: VCS repository is set to private
Source: ucspi-tcp Version: 1:0.88-4 Severity: normal Vcs-* ist set to https://salsa.debian.org/debian/ucspi-tcp which is a private repository. Please make the repository publically accessible. Ansgar
Bug#915511: ucspi-tcp: package broken
Source: ucspi-tcp
Version: 1:0.88-4
Severity: grave
>From /usr/bin/date@:
+---
| /build/ucspi-tcp-J4veAW/ucspi-tcp-0.88/debian/ucspi-tcp/usr/bin/tcpclient
-RHl0 -- "${1-0}" 13 sh -c 'exec
/build/ucspi-tcp-J4veAW/ucspi-tcp-0.88/debian/ucspi-tcp/usr/bin/delcr <&6' |
cat -v
+---
Similar for other scripts.
[ This bug report was sponsored by usrmerge. ]
Ansgar
Bug#914897: debating the wrong thing
"Alexander E. Patrakov" writes: > Ansgar Burchardt wrote: >> Making the feature default was discussed years ago which you are surely >> aware of. It's not mandatory. > > Unfortunately I have to disagree here. Merged /usr is already, > de-facto, mandatory for everyone who installs Debian Testing using the > official netinst CD. Yes, but the "make merged-/usr mandatory" refers only to require to merge /usr on upgrades; nobody has asked for there to be an installer option (and I don't think it would be useful). Ansgar
Bug#914897: debating the wrong thing
Adam Borowski writes: > On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote: > I believe the difference between those is less than between suboptions of 1 > and 3, but then, as an opponent of 2 as a whole I'm biased. > >> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr >> systems would no longer be supported. > > They'd be exactly as supported as they are today. Ie -- they'll continue to > work, Yes. > and continue to be useless for building packages without a clean > chroot. Oh? What makes you think so? You are free to correct my earlier estimate about the number of problems. So long I'll assume I'm not totally wrong. If I'm wrong by a factor of 3, then 99% of the packages will just build fine. And fixing any problem is in most cases straightforward. >> In this case someone would have to write a unusrmerge program to convert >> systems with merged-/usr to systems with unmerged-/usr. >> Such a program doesn't exist yet and is probably more complicated than >> usrmerge: for example how would it know that a /sbin/iptables -> >> /usr/sbin/iptables symlink would have to be created when unmerging the >> system? Moving files from /usr to / is also more likely to run out of >> disk space (if separate partitions are used for /usr and /). >> >> I'm not sure how long it would take to get this right and so agree that >> (2) or (3b) or (3a-with-support-in-buster) are reasonable choices. > > unusrmerge would still be still far less work than continuing with 2. Why do you think so? Trivial patches for the remaining few packages seem easier. > Yet I don't understand your claim why 1 or 3a w/o usrmerge-in-buster > would cause any problems. In fact, they require no work at all (in > Buster's cycle) beyond an upload of debootstrap. Unless someone builds a package in an already existing install... If not being able to build packages in existing installations is not a problem, I'm even less sure what the problem with merged-/usr by default is supposed to be? Ansgar
Bug#914897: debating the wrong thing
Gunnar Wolf writes: > Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]: >> (...) >> So, let's enumerate possible outcomes: >> >> 1. no usrmerge >> 1a. no moves at all (no effort needed!) >> 1b. moves via some dh_usrmove tool, until /bin is empty >> 2. supporting both merged-usr and unmerged-usr >> 3. mandatory usrmerge >> 3a. by Bullseye >> 3b. by Buster >> >> Unless the TC decides for 2., all this work will be a pure waste of yours >> and maintainers' time. > > ...One thing I fear here, that's also not being clearly debated AFAICT > (although the "urgency" of this report points in the right direction) > is that if the TC decides towards anything but 2 or 3b, we will have a > hard time reaching and following through the freeze targets proposed > by the Release Team. Which is something we don't want. I don't think this list is good as (2) doesn't say anything about the question asked originally (the default) and (3a) doesn't say anything about what happens for Buster. Currently implemented is (2) + default to merged-/usr for new installations. Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr systems would no longer be supported. In this case someone would have to write a unusrmerge program to convert systems with merged-/usr to systems with unmerged-/usr. Such a program doesn't exist yet and is probably more complicated than usrmerge: for example how would it know that a /sbin/iptables -> /usr/sbin/iptables symlink would have to be created when unmerging the system? Moving files from /usr to / is also more likely to run out of disk space (if separate partitions are used for /usr and /). I'm not sure how long it would take to get this right and so agree that (2) or (3b) or (3a-with-support-in-buster) are reasonable choices. >> With 1a, 1b, 3a the result will be "revert the change in debootstrap" (in >> 3a "for now"). With 3b you need some way to make sure existing systems are >> converted (also with 3a except for far more time for testing). > > I agree with your assessment. There are still too many mails I haven't > read, though, and I cannot commit my hypothetical vote so far, but I > think the sanest way will be to revert the change in debootstrap. So (2) with the default to non-merged-/usr or (3a)? I'm not sure why (2) should not default to merged-/usr though. Ansgar
Bug#915423: xfce4-session: reproducible build (usrmerge): embeds path of rm found via PATH
Source: xfce4-session Version: 4.12.1-6 Severity: normal Tags: patch User: m...@linux.it Usertags: usrmerge Control: user reproducible-bui...@lists.alioth.debian.org Control: usertag -1 + environment Dear Maintainer, According to reproducible build tests xfce4-session gets built differently on a merged-usr system vs a non-merged system. The package embeds the full path of rm. Since PATH defaults to /usr/bin before /bin, the first will be used on a usrmerged system where they're both essentially the same thing, but /usr/bin/rm does not exist on non-merged systems. The attached patch passes `RM=/bin/rm` to explicitly set the path. Regards, Ansgar diff -Nru xfce4-session-4.13.1/debian/changelog xfce4-session-4.13.1/debian/changelog --- xfce4-session-4.13.1/debian/changelog 2018-08-22 14:26:25.0 +0200 +++ xfce4-session-4.13.1/debian/changelog 2018-12-03 19:46:56.0 +0100 @@ -1,3 +1,10 @@ +xfce4-session (4.13.1-1.1) UNRELEASED; urgency=medium + + * Explicit pass `RM=/bin/rm` to configure to make build reproducible +between merged-usr and non-merged-usr systems. + + -- Ansgar Burchardt Mon, 03 Dec 2018 19:46:56 +0100 + xfce4-session (4.13.1-1) experimental; urgency=medium * New upstream version 4.13.1 diff -Nru xfce4-session-4.13.1/debian/rules xfce4-session-4.13.1/debian/rules --- xfce4-session-4.13.1/debian/rules 2018-08-22 14:26:25.0 +0200 +++ xfce4-session-4.13.1/debian/rules 2018-12-03 19:46:43.0 +0100 @@ -21,7 +21,7 @@ endif override_dh_auto_configure: - dh_auto_configure -- --disable-legacy-sm --with-backend=$(BACKEND) + dh_auto_configure -- RM=/bin/rm --disable-legacy-sm --with-backend=$(BACKEND) %: dh $@
Bug#915413: libmdds-dev: do not ship /usr/share/doc/libmdds-dev/examples/Makefile.gz
Package: libmdds-dev Version: 1.4.3-1 Severity: minor User: m...@linux.it Usertags: usrmerge Hi, while investigating package builds producing different results on merged-/usr vs. non-merged-/usr systems, I noticed that libmdds-dev ships a `Makefile` in /usr/share/doc/libmdds-dev/examples which shows such differences. I wonder if it is really useful to ship this as many variables depend on the build environment, for example: +--- | abs_builddir = /build/mdds-Fcl28G/mdds-1.4.3/example | abs_srcdir = /build/mdds-Fcl28G/mdds-1.4.3/example | abs_top_builddir = /build/mdds-Fcl28G/mdds-1.4.3 | abs_top_srcdir = /build/mdds-Fcl28G/mdds-1.4.3 +--- The directory also includes compressed object files (for example flat_segment_tree.o.gz), compressed ELF binaries (e.g. mtv-collection) and log output (*.log, *.trs) which I'm not sure if they are useful to include. Ansgar
Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives
On Mon, 2018-12-03 at 16:35 +0100, Adam Borowski wrote: > Use cases, for individual packages: (copied from a mail by smcv): > > """ > Packages that need to register their login sessions with logind > (gdm3, lightdm, openssh-server): > - remove libpam-systemd dependency > - add default-logind | logind dependency Doesn't gdm3 start a gnome-session for the login screen? It is a bit different from the standard session and only starts some things (from /usr/share/gnome-session/sessions/gnome-login.session I believe), so I'm not sure about this: > Packages that rely on running systemd --user units (dbus-user- > session, > gnome-session, gnupg): > - unchanged, elogind is not supported here > """ This might imply gdm3 might need `systemd --user` as well; not sure. Have you tried if it works? Ansgar
Bug#914897: debating the wrong thing
On Mon, 2018-12-03 at 12:38 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> > It is very demotivating to have discussed and implemented something
> > mostly years ago, for people then to come and complain "let's not
> > do
> > this at all" years later.
>
> We were told it would be optional. Unfortunately it turns out that
> the design is broken and it cannot sensibly be made optional.
There is no indication of that. So I'll assume the design isn't
broken.
You aren't entitled to just claim that.
> Nor does a failure to review and object to your design of an optional
> feature mean that you are entitled to assume consent for making the
> feature default or mandatory.
Making the feature default was discussed years ago which you are surely
aware of. It's not mandatory.
> The problem comes when a niche optional feature, with wide-ranging
> implications, is suddenly promoted to the default, without proper
> consultation and without a proper transition plan.
It wasn't made "suddenly" the default.
Ansgar
Bug#915379: anacron.service: should probably use KillMode=process
Package: anacron Version: 2.3-26 Severity: normal anacron.service currently uses KillMode=mixed. It probably should not. KillMode=mixed sends SIGTERM to anacron and then SIGKILL to any processes started by anacron. The default (KillMode=control-group) would send SIGTERM to all processes which is probably what one wantes if processes started by anacron should be stopped when anacron is (for example during upgrades). More likely, anacron should probably use KillMode=process. Then stopping anacron would only send SIGTERM to anacron itself and leave the jobs anacron might have started untouched. (This is what cron.service uses.) Ansgar
Bug#915181: dak shouldn't accept changes in components directly in upstream
Hi, please explain what components you are talking about and why they shouldn't be allowed in Debian. Ansgar
Bug#914897: debating the wrong thing
Adam Borowski writes: > I see that we're debating the merits of merged-usr vs non-merged-usr, while > expending lots of effort and filing bugs (requiring further urgent action of > unrelated maintainers), for little gain. There is no "urgent action" required (unlike, say, for the last glibc update). If you don't want support for merged-/usr, could you please discuss this back in 2016 or before that? Also I feel a general discussion would probably just be too long-winded and touch too many unrelated issues; there is not even a terse list of claimed problems. It is very demotivating to have discussed and implemented something mostly years ago, for people then to come and complain "let's not do this at all" years later. Maybe we should also revisit Multi-Arch now that we know that `Multi-Arch: foreign` relations as implemented can result in non-booting systems... Or really revisit the init system question before people file bugs that require further urgent action for little gain (it's probably too late in the release cycle to push in elogind anyway). There is also the question if it is still worth to spend maintainer efforts to ship sysvinit scripts if this means we lose the advantages of declarative service files (which means far more work than merged-/usr changes)... We could also open a tech-ctte bug for secure boot before I spend any more time on it (there are still a few things). Luckily having this discussion delays me spending time on the remaining things I wanted to look at, so at least not more time is wasted. (Not that I currently have too much time for Debian anyway, and secure boot is quite a lot of work for something I don't need...) Ansgar
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Marc Haber writes: > The next debhelper change might choose to give / instead of /usr as a > target directory by default, moving hundreds of megabytes from /usr to / > over time. My question was about the distant future, and not the current > snapshot of things. If anything then /usr would be the prefix for all packages; nothing would be installed to /bin, /sbin or /lib. (And there is no /share or /local.) But this is obviously only possible if non-merged-/usr is not supported at all as that would mean shipping only /usr/bin/sh and no /bin/sh; the /bin -> /usr/bin symlink would then be required. Ansgar
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Marc Haber writes: > On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote: >> Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit : >> > Will binaries move from /usr/bin to /bin? Or will binaries move from >> > /bin to /usr/bin? >> >> A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking >> /bin/grep will make that binary end up in /usr/bin/grep; but the >> /bin → /usr/bin symlink ensures that you can either access /usr/bin/grep >> directly or /bin/grep through the symlink. > > And where will the binaries and up on an un-usrmerged system with a > dedicated /usr? in /usr, I hope? They won't move on a system that doesn't have merged-/usr. /bin/bash will stay in /bin/bash. If you switch to a merged-/usr (for example by installing usrmerge) then they will be moved to /usr. Ansgar
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Marc Haber writes:
> On Sat, Dec 01, 2018 at 07:20:57PM +0100, Didier 'OdyX' Raboud wrote:
>> * Currently, according to my `apt-file`, 259 binaries are shipped in /bin
>> directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).
>
> This might sound like a stupid question, what will happen when a package
> built on a usrmerged System will be installed on a non-usrmerged system?
>
> Will binaries move from /usr/bin to /bin? Or will binaries move from
> /bin to /usr/bin?
They will be installed in the place the package installs them. Note
that there are no /bin -> /usr/bin symlink in the staging area where the
package is built (i.e. debian/${package} or debian/tmp).
Packages have to continue shipping binaries in /bin unless we decide to
make merged-/usr mandatory and convert existing systems.
Ansgar
Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default
Ansgar Burchardt writes: > There were discussions about enabling this by default years ago, I > don't think minor issues should be a reason to delay this change. > > Note that it has been delayed for after the stretch release as there > were major issues back then (it was enabled by default for a short time > in stretch). It took >5 months for someone to find a problem this time > which is pretty good for any change. So, I went through all reproducible build failures in unstable without notes and added notes for differences caused by building in merged-/usr vs non-merged-/usr packages. Together with what other people tagged, about 60 problems were found. (The oldest rebuild result for unstable is 17 days old, the merged-/usr variation was deployed before that[1].) [1] https://bugs.debian.org/901473#43 There might be some more that as diffoscope had problems or the diff was too large for some packages (but I'll assume that in this case merged-/usr is not the only problem the package had). This should cover all packages that had no other problems and were reproducible before, that is about 80% of the archive. Assuming the rate is similar for packages which have other reproducible build problems, I would expect 60 / 80*20 = 15 more problems. I haven't looked at build failures, but I would expect these to be usually not caused by merged-/usr. So an estimated ~80 packages which might need adjustments for building correctly in both merged-/usr and non-merged-/usr. I guess less than for the average new release of GCC ;-) The problems are usually easy to fix by passing an explicit path the the package's configure script at build time; of course there might be some package where it is more complicated. Ansgar
Bug#915183: bsdowl: reproducible build (usrmerge): embeds path of mkdir, grep and sed found via PATH
Source: bsdowl
Version: 2.2.2-1
Severity: normal
Tags: patch
User: m...@linux.it
Usertags: usrmerge
Dear Maintainer,
According to reproducible build tests bsdowl gets built differently
on a merged-usr system vs a non-merged system.
The package embeds the full path of mkdir, grep and sed. Since PATH
defaults to /usr/bin before /bin, the first will be used on a usrmerged
system where they're both essentially the same thing, but
/usr/bin/mkdir does not exist on non-merged systems.
The attached patch passes `MKDIR="/bin/mkdir -p" GREP="/bin/grep"
SED="/bin/sed"` to explicitly set the path.
Regards,
Ansgar
diff -Nru bsdowl-2.2.2/debian/changelog bsdowl-2.2.2/debian/changelog
--- bsdowl-2.2.2/debian/changelog 2014-11-29 13:08:32.0 +0100
+++ bsdowl-2.2.2/debian/changelog 2018-12-01 15:00:28.0 +0100
@@ -1,3 +1,10 @@
+bsdowl (2.2.2-1.1) UNRELEASED; urgency=medium
+
+ * Explicit pass MKDIR_P, GREP and SED to configure to make build
+reproducible between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Sat, 01 Dec 2018 15:00:28 +0100
+
bsdowl (2.2.2-1) unstable; urgency=medium
* Initial release. (Closes: #760592)
diff -Nru bsdowl-2.2.2/debian/rules bsdowl-2.2.2/debian/rules
--- bsdowl-2.2.2/debian/rules 2014-11-29 13:00:29.0 +0100
+++ bsdowl-2.2.2/debian/rules 2018-12-01 14:59:32.0 +0100
@@ -4,6 +4,9 @@
%:
dh $@
+override_dh_auto_configure:
+ dh_auto_configure -- MKDIR_P="/bin/mkdir -p" GREP=/bin/grep SED=/bin/sed
+
override_dh_auto_build:
${MAKETOOL} build
Bug#915180: maildrop: reproducible build (usrmerge): embeds path of cat found via PATH
Source: maildrop Version: 2.9.3-2.1 Severity: normal Tags: patch User: m...@linux.it Usertags: usrmerge Dear Maintainer, According to reproducible build tests maildrop gets built differently on a merged-usr system vs a non-merged system. The package embeds the full path of cat. Since PATH defaults to /usr/bin before /bin, the first will be used on a usrmerged system where they're both essentially the same thing, but /usr/bin/cat does not exist on non-merged systems. The attached patch passes `CAT=/bin/cat` to explicitly set the path. Regards, Ansgar diff -Nru maildrop-2.9.3/debian/changelog maildrop-2.9.3/debian/changelog --- maildrop-2.9.3/debian/changelog 2018-07-01 09:05:35.0 +0200 +++ maildrop-2.9.3/debian/changelog 2018-12-01 14:20:56.0 +0100 @@ -1,3 +1,10 @@ +maildrop (2.9.3-2.1) UNRELEASED; urgency=medium + + * Explicit pass CAT=/bin/cat to configure to make build reproducible +between merged-usr and non-merged-usr systems. + + -- Ansgar Burchardt Sat, 01 Dec 2018 14:20:56 +0100 + maildrop (2.9.3-2) unstable; urgency=medium * Migrate VCS from alioth to salsa. diff -Nru maildrop-2.9.3/debian/rules maildrop-2.9.3/debian/rules --- maildrop-2.9.3/debian/rules 2018-07-01 09:02:52.0 +0200 +++ maildrop-2.9.3/debian/rules 2018-12-01 14:01:42.0 +0100 @@ -23,6 +23,7 @@ override_dh_auto_configure: # trust on the auto-detect of qmail failing (for sendmail compability) dh_auto_configure -- \ + CAT=/bin/cat \ --enable-use-dotlock=1 \ --enable-use-flock=1 \ --enable-sendmail=/usr/sbin/sendmail \
Bug#915170: nvi: reproducible build (usrmerge): embeds path of sh found via PATH
Source: nvi Version: 1.81.6-13 Severity: normal Tags: patch User: m...@linux.it Usertags: usrmerge Dear Maintainer, According to reproducible build tests nvi gets built differently on a merged-usr system vs a non-merged system. The package embeds the full path of sh. Since PATH defaults to /usr/bin before /bin, the first will be used on a usrmerged system where they're both essentially the same thing, but /usr/bin/sh does not exist on non-merged systems. The attached patch passes `vi_cv_path_shell=/bin/sh` to explicitly set the path. Regards, Ansgar diff -Nru nvi-1.81.6/debian/changelog nvi-1.81.6/debian/changelog --- nvi-1.81.6/debian/changelog 2016-12-31 05:10:57.0 +0100 +++ nvi-1.81.6/debian/changelog 2018-12-01 13:41:09.0 +0100 @@ -1,3 +1,10 @@ +nvi (1.81.6-14) UNRELEASED; urgency=medium + + * Explicit pass vi_cv_path_shell=/bin/sh to configure to make build +reproducible between merged-usr and non-merged-usr systems. + + -- Ansgar Burchardt Sat, 01 Dec 2018 13:41:09 +0100 + nvi (1.81.6-13) unstable; urgency=medium * QA upload. diff -Nru nvi-1.81.6/debian/rules nvi-1.81.6/debian/rules --- nvi-1.81.6/debian/rules 2016-12-31 05:03:39.0 +0100 +++ nvi-1.81.6/debian/rules 2018-12-01 13:39:47.0 +0100 @@ -34,6 +34,7 @@ ADDCPPFLAGS="$(CPPFLAGS)" \ ADDLDFLAGS="$(LDFLAGS)" \ ac_cv_path_vi_cv_path_sendmail=/usr/sbin/sendmail \ + vi_cv_path_shell=/bin/sh \ vi_cv_revoke=no \ ../dist/configure \ --build=$(DEB_BUILD_GNU_TYPE) \
Bug#915169: disk-manager: reproducible build (usrmerge): embeds path of {u,}mount found via PATH
Source: disk-manager
Version: 1.1.1-2
Severity: normal
Tags: patch
User: m...@linux.it
Usertags: usrmerge
Dear Maintainer,
According to reproducible build tests disk-manager gets built
differently on a merged-usr system vs a non-merged system.
The package embeds the full path of {u,}mount. Since PATH defaults to
/usr/bin before /bin, the first will be used on a usrmerged system
where they're both essentially the same thing, but /usr/bin/{u,}mount
does not exist on non-merged systems.
The attached patch passes the path to the {u,}mount programs at
configure time to explicitly set the path.
Regards,
Ansgar
diff -Nru disk-manager-1.1.1/debian/changelog disk-manager-1.1.1/debian/changelog
--- disk-manager-1.1.1/debian/changelog 2011-09-25 17:15:27.0 +0200
+++ disk-manager-1.1.1/debian/changelog 2018-12-01 13:40:31.0 +0100
@@ -1,3 +1,10 @@
+disk-manager (1.1.1-2.1) UNRELEASED; urgency=medium
+
+ * Explicit pass path to {u,}mount to configure to make build
+reproducible between merged-usr and non-merged-usr systems.
+
+ -- Ansgar Burchardt Sat, 01 Dec 2018 13:40:31 +0100
+
disk-manager (1.1.1-2) unstable; urgency=low
* Add Build-Depends-Indep on menu, so that su-to-root gets
diff -Nru disk-manager-1.1.1/debian/rules disk-manager-1.1.1/debian/rules
--- disk-manager-1.1.1/debian/rules 2011-09-25 17:15:27.0 +0200
+++ disk-manager-1.1.1/debian/rules 2018-12-01 13:32:54.0 +0100
@@ -7,3 +7,6 @@
%:
dh $@ \
--with python2
+
+override_dh_auto_configure:
+ dh_auto_configure -- MOUNT=/bin/mount UMOUNT=/bin/umount
Bug#915166: apsfilter: reproducible build (usrmerge): embeds path of bash found via PATH
Source: apsfilter Version: 7.2.6-1.3 Severity: normal Tags: patch User: m...@linux.it Usertags: usrmerge Dear Maintainer, According to reproducible build tests apsfilter gets built differently on a merged-usr system vs a non-merged system. The package embeds the full path of bash. Since PATH defaults to /usr/bin before /bin, the first will be used on a usrmerged system where they're both essentially the same thing, but /usr/bin/bash does not exist on non-merged systems. The attached patch passes `--with-shell=/bin/bash` to explicitly set the path. Regards, Ansgar diff -u apsfilter-7.2.6/debian/rules apsfilter-7.2.6/debian/rules --- apsfilter-7.2.6/debian/rules +++ apsfilter-7.2.6/debian/rules @@ -12,7 +12,8 @@ dh_testdir # Add here commands to configure the package. ./configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man \ - --with-awk=/usr/bin/awk --with-sendmail=/usr/sbin/sendmail + --with-awk=/usr/bin/awk --with-sendmail=/usr/sbin/sendmail \ + --with-shell=/bin/bash touch configure-stamp build: configure-stamp build-stamp diff -u apsfilter-7.2.6/debian/changelog apsfilter-7.2.6/debian/changelog --- apsfilter-7.2.6/debian/changelog +++ apsfilter-7.2.6/debian/changelog @@ -1,3 +1,10 @@ +apsfilter (7.2.6-1.4) UNRELEASED; urgency=medium + + * Explicit pass `--with-shell=/bin/bash` to configure to make build +reproducible between merged-usr and non-merged-usr systems. + + -- Ansgar Burchardt Sat, 01 Dec 2018 13:20:25 +0100 + apsfilter (7.2.6-1.3) unstable; urgency=low * Non-maintainer upload.
Bug#915164: libsmi: reproducible build (usrmerge): embeds path of sh found via PATH
Source: libsmi Version: 0.4.8+dfsg2-15 Severity: normal Tags: patch User: m...@linux.it Usertags: usrmerge Dear Maintainer, According to reproducible build tests libsmi gets built differently on a merged-usr system vs a non-merged system. The package embeds the full path of sh. Since PATH defaults to /usr/bin before /bin, the first will be used on a usrmerged system where they're both essentially the same thing, but /usr/bin/sh does not exist on non- merged systems. The attached patch passes SH=/bin/sh to explicitly set the path. Regards, Ansgar diff -Nru libsmi-0.4.8+dfsg2/debian/changelog libsmi-0.4.8+dfsg2/debian/changelog --- libsmi-0.4.8+dfsg2/debian/changelog 2016-11-17 15:33:25.0 +0100 +++ libsmi-0.4.8+dfsg2/debian/changelog 2018-12-01 13:07:16.0 +0100 @@ -1,3 +1,10 @@ +libsmi (0.4.8+dfsg2-15.1) UNRELEASED; urgency=medium + + * Explicit pass SH=/bin/sh to configure to make build reproducible +between merged-usr and non-merged-usr systems. + + -- Ansgar Burchardt Sat, 01 Dec 2018 13:07:16 +0100 + libsmi (0.4.8+dfsg2-15) unstable; urgency=medium * Add /var/lib/snmp/mibs/site to the default search path for MIB files. diff -Nru libsmi-0.4.8+dfsg2/debian/rules libsmi-0.4.8+dfsg2/debian/rules --- libsmi-0.4.8+dfsg2/debian/rules 2016-11-17 15:33:25.0 +0100 +++ libsmi-0.4.8+dfsg2/debian/rules 2018-12-01 13:00:07.0 +0100 @@ -4,6 +4,9 @@ %: dh $@ --with autoreconf +override_dh_auto_configure: + dh_auto_configure -- SH=/bin/sh + override_dh_auto_test: # Don't do that.
Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default
On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote: > Dear Hideki, dear src:debootstrap maintainers, > > tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by > default now, or are you OK letting the TC decide on this subject? There were discussions about enabling this by default years ago, I don't think minor issues should be a reason to delay this change. Note that it has been delayed for after the stretch release as there were major issues back then (it was enabled by default for a short time in stretch). It took >5 months for someone to find a problem this time which is pretty good for any change. Ansgar
Bug#914897: affects private debs too
Simon McVittie writes:
> On Thu, 29 Nov 2018 at 18:34:42 +0100, Ansgar Burchardt wrote:
>> Regardless of debootstrap defaults or flag days, we could also consider
>> moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
>> /{s,}bin
>
> I'm not convinced this is a good idea: it seems like it causes as many
> problems as it solves. It's effectively a gradual implementation of
> making merged /usr mandatory, with a lot of moving parts (places where
> it could go wrong) and a lot of packages and maintainers needing to be
> involved, but without the simpler end result of *actually* merging /usr.
Well, people don't like the simpler solution that someone else
proposed...
> We've been migrating from non-multiarch to multiarch for more than 5
> years and have still not got there, so I'm not confident that ad-hoc
> migration from unmerged to merged /usr would go any quicker.
Migrating /{s,}bin involves far fewer packages (only ~200 binary
packages). There is still /lib though.
> It can also cause the same failure modes with hard-coded executable paths
> as merged /usr. Let's suppose we migrated grep from /bin to /usr/bin in
> the way you suggest during the Debian 11 release cycle. If a package that
> hard-codes the compile-time grep path (again, consider gzip, #914907)
> is built with the new grep, it won't work correctly with the old grep
> during a partial upgrade from Debian 10 to 11; but I don't see how it
> would pick up a versioned Depends on the new grep without manual action
> from the dependent package's maintainer, which isn't going to scale well.
You will always have this problem with partial upgrades unless *every*
package depends on a package that would ensure that the system has all
binaries previously in /bin also in /usr/bin.
In particular, if we want to treat this as a (release critical) bug,
iptables or any other package ever moving from /bin to /usr/bin (or the
other way) will always be buggy, regardless of any merged-/usr. Same
for any binary ever moving between .../bin and .../sbin.
Ansgar
Bug#915038: RM: systemd-shim -- RoQA; unmaintained; dead upstream; broken
Package: ftp.debian.org Severity: normal Please remove systemd-shim from the archive. It is dead upstream, unmaintained, uninstallable and broken. AFAIU people who like systemd-logind's features, but don't want to run systemd-init for some reason plan to use elogind instead which has now entered the archive. Ansgar
Bug#914897: affects private debs too
Adam Borowski writes:
> Andreas Henriksson wrote:
>> On Wed, Nov 28, 2018 at 03:14:20PM +, Ian Jackson wrote:
>> > Julien Cristau writes ("Re: Bug#914897: debootstrap, buster:
>> > Please disabled merged /usr by default"):
>> [...]
>> > > I'd suggest that this should be fixed by not shipping any packages that
>> > > aren't built on buildds.
>> >
>> > It would be quite a radical departure for Debian to no longer support
>> > "I built this package for my mate to install on their computer".
>>
>> For the case of locally built binaries, bringing any problem
>> that usrmerge would hit to the light would be preferable.
>
> Any checks you can do may test only packages that reached the Debian
> archive. We can discipline DDs, be it by requiring source-only, or by
> catching misbuilt packages, but we can't do anything for local packages.
>
> And these in a good part are not based on Debian sources.
>
> I for one use a .deb package to distribute my .bashrc to machines under my
> control. Joe from a derivative named Debuntituan provides an
> uber-proprietary-drivers package to his users. Any PPA. A company-wide
> repo. Etc, etc.
Debian is not responsible how third parties build their packages. We
don't even exclude /usr/local/bin from PATH when building packages...
(If you care about distributions not doing the same as Debian, one would
need to patch every package to build & work on both merged-/usr and
non-merged-/usr systems no matter what Debian does...)
> Thus: sorry but there is no way we can possibly support usrmerged and
> non-usrmerged systems at the same time. Usrmerge is not viable without a
> flag day.
Oh, it's possible. It makes life a bit harder than a flag day or clear
commitment to one setup, but so does supporting multiple init systems
(so the advantages of, for example, easier maintenance by having
declarative definitions is lost).
Regardless of debootstrap defaults or flag days, we could also consider
moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
/{s,}bin; this does not need a flag day. That is useful either way as:
a) some people will use /usr/bin/${x} instead of /bin/${x} anyway (they
don't have to come from Debian), and b) it would also make supporting
merged-/usr and non-merged-/usr simpler as the programs would always be
available in both locations.
Some packages such as iptables have already done this ad-hoc.
I'm toying around with ideas for a dh_usrmove tool which would allow to
easily add this to existing packages. That would also allow to drop it
later in one go should one in the far future require the /bin ->
/usr/bin symlink.
Ansgar
Bug#914979: bumblebee: remove obsolete conffile /etc/init/bumblebeed.conf
Package: bumblebee Version: 3.2.1-17 Severity: normal Tags: patch The upstart job was remove in the last upload (3.2.1-17), but as /etc/init/bumblebeed.conf is a conffile, the file isn't removed on upgrades. The attached patch adds the file to the list of conffiles to remove in debian/bumblebee.maintscript. Ansgar diff -Nru bumblebee-3.2.1/debian/bumblebee.maintscript bumblebee-3.2.1/debian/bumblebee.maintscript --- bumblebee-3.2.1/debian/bumblebee.maintscript2015-10-19 22:38:48.0 +0200 +++ bumblebee-3.2.1/debian/bumblebee.maintscript2018-11-29 10:19:14.0 +0100 @@ -1,2 +1,3 @@ rm_conffile /etc/modprobe.d/bumblebee.conf 3.2.1-6~ rm_conffile /etc/bash_completion.d/bumblebee 3.2.1-8~ +rm_conffile /etc/init/bumblebeed.conf 3.2.1-18~ diff -Nru bumblebee-3.2.1/debian/changelog bumblebee-3.2.1/debian/changelog --- bumblebee-3.2.1/debian/changelog2017-12-09 00:07:05.0 +0100 +++ bumblebee-3.2.1/debian/changelog2018-11-29 10:19:19.0 +0100 @@ -1,3 +1,9 @@ +bumblebee (3.2.1-18) UNRELEASED; urgency=medium + + * Remove obsolete conffile /etc/init/bumblebeed.conf + + -- Ansgar Burchardt Thu, 29 Nov 2018 10:19:19 +0100 + bumblebee (3.2.1-17) unstable; urgency=medium * Switch the triggers to -noawait to fix Lintian warning and to make
Bug#914376: kmc: should install to /usr/bin, not /bin
Source: kmc Version: 2.3+dfsg-6 Severity: normal kmc installs programs to /bin. For a bioinformatics tool this seems not correct; the programs should be installed to /usr/bin instead. Ansgar
Bug#914372: ttygif: ttygif should be installed to /usr/bin
Package: ttygif Version: 1.4.0-1 Severity: normal The ttygif program is installed as /bin/ttygif. From the description it should be installed as /usr/bin/ttygif instead. Ansgar PS: The Build-Depends: gcc-8 also looks incorrect as only `gcc` is called by the Makefile.
Bug#914371: gaffitter: gaffitter should be installed to /usr/bin
Package: gaffitter Version: 0.6.0-2 Severity: normal The package install gaffitter to /bin, but it should be installed to /usr/bin. From looking at the Makefile, passing prefix=/usr when calling `make install` might be enough for this. Ansgar
Bug#913061: systemd: stop shipping /bin/systemd
Package: systemd Version: 239-11 Severity: minor File: /bin/systemd Running `systemd` in an interactive shell is not a good idea. To avoid this happening by accident, the /bin/systemd -> /lib/systemd/systemd symlink should no longer be shipped. Documentation such as [1] still suggests to use `init=/bin/systemd` which would result in non-bootable systems. (The initramfs might be able to catch this and run /lib/systemd/systemd instead in most cases as unbootable systems are not nice.) Ansgar [1]: https://wiki.debian.org/systemd#Configuring_for_testing
Bug#867668: packages on security.debian.org have different Priority than in the main archive
Hi, Steve McIntyre writes: > On Mon, Sep 03, 2018 at 09:45:39AM +0200, intrigeri wrote: >>Hi, >> >>Sven Joachim: >>> The package priorities on security.debian.org differ from the ones in >>> the main archive >> >>Here's another brand new example: >> >>$ apt-cache show mutt | grep -E '^(Version|Priority)' >>Version: 1.7.2-1+deb9u1 >>Priority: standard >>Version: 1.7.2-1 >>Priority: optional >> >>This causes mutt to be installed by default in some setups since >>1.7.2-1+deb9u1 was uploaded, which was not the case before 2018-08-17. >> >>Is there anything a DD who's not on the ftpmaster team can do to help >>fix that? (I was not able to find the relevant file that needs to >>be updated.) > > Nod. That exact example is causing real problems for users - see > > https://lists.debian.org/debian-user/2018/11/msg00022.html I fixed this for mutt (and mutt-kz) in stable (pending the next publishing of the security archive), but we should make sure that overrides on security-master match those on ftp-master (and not just import the initial override and ignore later updates). I'll leave the bug open for that. Ansgar
Bug#824377: slrnpull: expiry cronjob fails after jessie upgrade
Package: slrnpull Version: 1.0.3+dfsg-2 I can confirm that slrnpull's cronjob still fails with "This account is currently not available." in Debian testing (buster). I'm also using RUNFROM='manually', but I'm not sure that is relevant (the check for RUNFROM only occurs later in the cronjob). Ansgar
Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
Steve Langasek writes:
> On Wed, Oct 17, 2018 at 10:07:44AM +0200, Ansgar Burchardt wrote:
>> That exception does not exist in Policy; there is only an exception for
>> packages provided by the init implementation itself. Policy currently
>> requires the "Loose coupling of init systems" option of
>> https://www.debian.org/vote/2014/vote_003 as far as I can tell as
>> services must be able to run under sysvinit.
>
>> We already have several packages only shipping systemd units, including
>> with socket activation (I did not check if any services cannot be
>> configured to not listen on their own, but I wouldn't be surprised).
>> Those with socket activation include: chasquid, cockpit-ws, erlang-base,
>> hddemux, ibacm, rkt, snapd, sssd-kcm, tang, tinysshd.
>
> I actually don't agree with this policy proposal - I think that if we are
> going to support non-systemd init at all in Debian, it needs to be more than
> lip service, and that means policy needs to spell out that maintainers have
> a responsibility to help hold the line
Well, Debian supports several architectures besides amd64 and it works
okay without there being a Policy requirement of "if it works on amd64,
it *must* work on mips64el".
Of course it also helps that we require release architectures to have
porters. sysvinit on the other hand doesn't even really have a
maintainer for the past years (last maintainer upload in 2015, 11 NMUs
since then)...
> The snapd service as implemented upstream generates and manages systemd
> units, including both .service and .mount units. Making snapd work with
> non-systemd init would be a non-negligible upstream porting effort.
>
> Snapd is also not straightforwardly portable to non-Linux kernels, which
> IMHO is the principle reason that Debian should continue to care about
> non-systemd init at all.
>
> Should Debian refuse to allow a package into a stable release ("RC-buggy")
> whose upstream has made technology decisions that tie it to a particular
> sysvinit-incompatible init system?
I think it is fine (even though Policy says snapd is not okay). Just
like we allow packages that work only one some architectures (or even
only one), or that might work in theory also on other architectures, but
nobody bothered to fix them.
All of this works fine without a "must" in Policy for supporting
alternative architectures that then would need strange exceptions.
Given this works mostly fine, I don't think we need more than a "should"
for init scripts either.
If you disagree, please explain why it seems to work for architectures,
but would not for providing init scripts.
Ansgar
Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
Russ Allbery writes: > Ansgar Burchardt writes: >> So shipping a daemon without init scripts is better than shipping one >> with only a systemd unit? > > I don't believe such a daemon package (with no init script) should be > included in Debian at *all*, as a matter of not meeting the quality > bar. Policy says the opposite though... >> Shipping a sysvinit script is only a "should" in Policy, unless you ship >> something for any other init system. > > I think that's just that it's very difficult to write a Policy rule > explaining when something should have an init script and when something > should not. Yes, that's why I suggest the one rule that tries to state that sometimes a init script *must* exist is a bad rule. Even without the "must" in 9.11, there is still the recommendation that init scripts "should" be provided (9.3.2). According to policy that is enough for a bug. Unless one assumes bad faith that seems to be good enough to me. Otherwise one gets to enumerate exceptions or has to forbid packaging applications that only work under systemd. As far as I know snapd delegates some work to systemd and wouldn't work under sysvinit even if you start it from an init script... We could of course also say that this decides the "snap" vs "flatpak" decision ;-) >> We already have several packages only shipping systemd units, including >> with socket activation (I did not check if any services cannot be >> configured to not listen on their own, but I wouldn't be surprised). >> Those with socket activation include: chasquid, cockpit-ws, erlang-base, >> hddemux, ibacm, rkt, snapd, sssd-kcm, tang, tinysshd. > > I'm not surprised, but (and I have not investigated in detail) I suspect > at least some of these are bugs. I think they should be RC bugs in cases > where there's no significant porting required, just no init script, but > I'm not on the release team and don't get to make that call. I do think > they violate a Policy must. If one of them requires socket activation, would it be a RC bug in the package or a RC bug in alternative init systems such as sysvinit to provide no means to start such services? If one of them requires other systemd features and doesn't work under sysvinit anyway, why should an init script be required? I also note that Policy currently has no "where there's no significant porting required" exception and as I said earlier I don't believe in enumerating exceptions if one can just use "should". >> (Also, see DBus-activated services, inetd-style socket activation, >> .timer units with their associated .service; there is no need for a >> sysvinit script in these cases, but Policy requires it.) > > I think you're reading Policy far too literally here; the intent is only > to cover unit files that are equivalent to init scripts, and none of those > things are. I certainly support fixing that to make it clearer. I think the "should" from the earlier section on init scripts is enough. Then one doesn't need to write more complex rules here. Ansgar
Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
Russ Allbery writes: > Ansgar Burchardt writes: > >> a. tor@.service has no init script with the same name. This should be >>fine. (Note: there is also both a "tor.service" and "tor" init >>script.) > > Presumably this is fine for the same reason as b. > >> b. ssh.socket for systemd has no equivalent in sysvinit at all. >>This should be fine. > > This is not a good example, since openssh-server provides an init script > that provides "equivalent functionality" in the form of running sshd as a > daemon, and socket units are not equivalent to an init script and > therefore aren't what this part of Policy is talking about. Policy requires an init script with the same name for *every* init-specific job. That is probably not intended, but what it currently says. >> c. It is better to ship integration with some init systems than >>no integration at all. (Including sysvinit scripts at all is not >>required, only when any other integrations are provided.) > > I don't agree with this. So shipping a daemon without init scripts is better than shipping one with only a systemd unit? Shipping a sysvinit script is only a "should" in Policy, unless you ship something for any other init system. > Until such time as we make a project-wide > decision to drop support for sysvinit, providing an init script for > straightforward daemons is part of packaging a daemon. If people are > unwilling to do this work, I don't believe we should accept the package in > Debian. In other words, I personally believe not providing an init script > should be an RC bug (as Policy currently indicates) given the current > project stance on init systems, except for the standard exception case of > packages that are specifically designed to only be meaningful with systemd > for which making them work with any other init system would require > significant porting (not just writing a simple equivalent init > script). That exception does not exist in Policy; there is only an exception for packages provided by the init implementation itself. Policy currently requires the "Loose coupling of init systems" option of https://www.debian.org/vote/2014/vote_003 as far as I can tell as services must be able to run under sysvinit. We already have several packages only shipping systemd units, including with socket activation (I did not check if any services cannot be configured to not listen on their own, but I wouldn't be surprised). Those with socket activation include: chasquid, cockpit-ws, erlang-base, hddemux, ibacm, rkt, snapd, sssd-kcm, tang, tinysshd. I wouldn't be surprised to see more services require systemd's socket activation in the future. (Also, see DBus-activated services, inetd-style socket activation, .timer units with their associated .service; there is no need for a sysvinit script in these cases, but Policy requires it.) > That doesn't mean that we can't decide to drop formal sysvinit support. > It does mean that we should do this properly, as a project-wide decision, > which is way, WAY beyond the scope of Policy and is *absolutely not* > something that we're going to be able to decide here on this mailing list > or in this bug report. Hmm, I'm slowly getting tempted to suggest that after reading one more of the "systemd is Redhat/NSA cancerware" mails on debian-user@. Giving up sysvinit support might make those people go away and that alone is slowly getting worth it for me... Oh, and another arrived on -devel@ just now. Ansgar
