Bug#1076374: libplayeronecamera2t64: ineffective replaces for /usr/lib/udev/rules.d/99-player_one_astronomy.rules causes file loss

[Helmut Grohne]

Hi Thorsten and Chris,

On Mon, Jul 15, 2024 at 07:07:37PM +0200, Chris Hofstaedtler wrote:
> The following upgrade scenario demonstrates the loss. It may be
> possible to construct a simpler scenario. (This needs mmdebstrap 1.5.1-4 or
> better.)

Thank you.

> mmdebstrap \
>   --components="main non-free" \
>   --include=libplayeronecamera2 \
>   --hook-dir=/usr/share/mmdebstrap/hooks/no-merged-usr \
>   --chrooted-customize-hook='rm /etc/unsupported-skip-usrmerge-conversion' \
>   --chrooted-customize-hook='apt update' \
>   --chrooted-customize-hook='apt install --reinstall -y usrmerge' \

Unless I am mistaken, I think your reproducer can be simplified by
dropping the no-merged-usr hook as well as installing usrmerge.

>   --chrooted-customize-hook='ls -l /' \
>   --chrooted-customize-hook='dpkg -L libplayeronecamera2' \
>   --chrooted-customize-hook='sed -i -e s/bookworm/unstable/ -e /unstable-/d  
> /etc/apt/sources.list' \
>   --chrooted-customize-hook='apt update' \
>   --chrooted-customize-hook='apt upgrade -y libc6 systemd' \
>   --chrooted-customize-hook='cd /tmp && apt download libplayeronecamera2t64' \
>   --chrooted-customize-hook='cd /tmp && dpkg --auto-deconfigure --unpack 
> *.deb' \
>   --chrooted-customize-hook='dpkg -l libplayerone*' \
>   --chrooted-customize-hook='ls -la 
> /lib/udev/rules.d/99-player_one_astronomy.rules' \
>   --chrooted-customize-hook='apt install -f -y' \
>   --chrooted-customize-hook='dpkg -l libplayerone*' \
>   --chrooted-customize-hook='ls -la 
> /lib/udev/rules.d/99-player_one_astronomy.rules' \
>   bookworm /dev/null

Let me point out that this is not how people usually install packages.
There is a reason that we use apt download and dpkg there as there is no
known way to provoke this with apt yet.

> > If you feel that a stronger mitigation is necessary, I can supply a
> > patch adding protective diversions (via maintainer scripts).
> > 
> > Please let me know your preference. Roughly speaking your options now
> > are:
> >  * rename the rules file (closing both bugs)
> >  * move the rules file to a -common package (closing the -2 bug)
> >  * upgrade Replaces to Conflicts (closing the -1 bug)
> >  * request diversion-based mitigation (closing the -1 bug)
> 
> I'll attach a patch implementing the last option. As you can see this is far
> from beautiful. I'd suggest applying the patch _and_ switching
> Replaces to Conflicts to be extra safe.

Let me be extra clear: Your patch is not a solution on its own as
technicallly speaking you can still unpack (but not configure)
libplayeronecamera2 after having installed libplayeronecamera2t64 (and
thus the protective diversions having been removed). As is, the patch is
only complete when added to the Conflicts.

Given that systemd opted for not including the stronger mitigation in
its own packages (and just using Conflicts), I am not convinced that the
added maintenance cost of the protective diversions is justified. We'll
have to provide post-upgrade checking tools anyway and ask users to
reinstall broken packages.

Helmut

Bug#1076374: libplayeronecamera2t64: ineffective replaces for /usr/lib/udev/rules.d/99-player_one_astronomy.rules causes file loss

[Helmut Grohne]

Package: libplayeronecamera2t64
Version: 3.1.0+20221218103507-2
Severity: serious
User: helm...@debian.org
Usertags: dep17p1
Control: clone -1 -2
Control: retitle -2 libplayeronecamera2t64: soname-independent file in shared 
libarary package
Control: affects -1 libplayeronecamera2
X-Debbugs-Cc: z...@debian.org

Hi Thorsten,

thank you for applying our /usr-move patches. Unfortunately, this one
went wrong and it went to unstable rather than experimental.

libplayeronecamera2 installs
/lib/udev/rules.d/99-player_one_astronomy.rules in bookworm and
currently also trixie. libplayeronecamera2t64 installs the same file to
the corresponding canonical location. Upgrading from bookworm or trixie
to unstable is thus prone to loosing this file. Refer to DEP17 P1 for
more details on the problem class. I file this at rc severity to prevent
testing migration and to help apt-listbugs users.

I note that the name of the udev rules file does not depend on the
soname of the library. Hence, doing a soname bump would cause a file
conflict between shared libraries that are supposed to be coinstallable.
This constitutes a policy violation and I have cloned a separate bug for
this very aspect.

I see multiple possible solutions to these two related bugs and ask you
for help with picking a suitable for this very instance.

For resolving the policy violation, we have two options. One is
introducing a soname-independent -common package and moving the rules
file there. The other is renaming the rules file and making its name
dependent on the soname (and optionally also dependent on the t64
suffix). These options have different implications and trade-offs. The
rules filename is a user-visible aspect as people are entitled to
override this file by creating a corresponding one below /etc. Changing
the name, renders their override ineffective. If you anticipate
overriding, you should not choose the renaming approach and few packages
actually select it. If you choose the renaming approach, you no longer
have to declare Replaces for this very file and as a consequence, you
may close the "ineffective replaces" bug with no further action. If
instead you choose the -common pacakege, said -common package will have
to declare Replaces for libplayeronecamera2 and libplayeronecamera2t64
and will inherit the "ineffective replaces" problem for
libplayeronecamera2.

If you end up keeping the "ineffective replaces" problem (by not
renaming the rules file) whatever package ends up containing it will
require a DEP17 mitigation. Given that this almost is a leaf package
with few installations, I argue that a less reliably mitigation is
ok-ish. If the package containing the rules (libplayeronecamera2t64 or
the -common one) upgrades its "Replaces: libplayeronecamera2" to
"Conflicts; libplayeronecamera2", the file loss will be mitigated for
all users that happen to use apt or aptitude (or any other manager based
on libapt) rather than doing their dist-upgrade using dpkg
--auto-deconfigure --unpack somefile.deb. (I am not aware of anyone
doing such manual dpkg work beyon Ian Jackson's double-skip upgrade
adventure.) And since the loss is not critical to booting their system,
it can be recovered by reinstalling the affected package. The benefit of
this is that your maintenance cost of this mitigation is fairly low. Do
you agree that the proposed risk is reasonable?

If you feel that a stronger mitigation is necessary, I can supply a
patch adding protective diversions (via maintainer scripts).

Please let me know your preference. Roughly speaking your options now
are:
 * rename the rules file (closing both bugs)
 * move the rules file to a -common package (closing the -2 bug)
 * upgrade Replaces to Conflicts (closing the -1 bug)
 * request diversion-based mitigation (closing the -1 bug)

Thanks for bearing with the /usr-move folks!

Helmut

Bug#1076373: docker-cli and podman-docker have an undeclared file conflict on /usr/bin/docker

[Helmut Grohne]

Package: docker-cli,podman-docker
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict

The file /usr/bin/docker is contained in the packages
 * docker-cli/26.1.4+dfsg1-7 as present in experimental
 * podman-docker/5.0.3+ds1-2 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Please figure out which of these packages should properly own the
affected file and reassign the bug as appropriate. When doing so, please
add the other package to the set of affected packages using "Control:
affects -1 + " to avoid the filing of duplicates.

The other package should stop installing the file. In case the file is
being moved between packages, Breaks and Replaces should be declared. In
this case, please refer to policy section 7.6 for details. Another
useful resource is https://wiki.debian.org/PackageTransition.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1076198: libuhd4.7.0-dpdk-tests has an undeclared file conflict

[Helmut Grohne]

Package: libuhd4.7.0-dpdk-tests
Version: 4.7.0.0+ds1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libuhd4.6.0-dpdk-tests

libuhd4.7.0-dpdk-tests has an undeclared file conflict. This may result
in an unpack error from dpkg.

The files
 * /usr/lib/uhd/tests/4.6.0/dpdk_port_test
 * /usr/lib/uhd/tests/4.6.0/dpdk_test
are contained in the packages
 * libuhd4.6.0-dpdk-tests/4.6.0.0+ds1-6+b1 as present in trixie|unstable
 * libuhd4.7.0-dpdk-tests/4.7.0.0+ds1-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1075854: php-common: moves systemd units back to /lib (reverts 93+nmu1)

[Helmut Grohne]

Package: php-common
Version: 95~exp2
Severity: serious
X-Debbugs-Cc: z...@debian.org
User: helm...@debian.org
Usertags: dep17m2

Hi Ondrej,

your php-common upload to experimental reverts Chris' earlier NMU
93+nmu1 moving systemd units from /lib to /usr/lib. We consider moves
from /usr to / an rc bug at this time as we want to finish the /usr-move
transition (DEP17). Please include the changes from Chris NMU in your
next experimental upload and close this bug when doing so.

Helmut

Bug#1074616: libgnustep-dl2-0deb has an undeclared file conflict

[Helmut Grohne]

Package: libgnustep-dl2-0deb
Version: 0.12.0+git20171224-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libgnustep-dl2-0d

libgnustep-dl2-0deb has an undeclared file conflict. This may result in
an unpack error from dpkg.

The files
 * /usr/lib/libEOAccess.so.0.12.0
 * /usr/lib/libEOControl.so.0.12.0
 * /usr/lib/libEOInterface.so.0.12.0
are contained in the packages
 * libgnustep-dl2-0d
   * 0.12.0-15.1+b4 as present in bullseye
   * 0.12.0-16 as present in bookworm
   * 0.12.0-16+b2 as present in trixie|unstable
 * libgnustep-dl2-0deb/0.12.0+git20171224-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074589: libcompiler-libs-ocaml-dev, libstdlib-ocaml and libstdlib-ocaml-dev have an undeclared file conflict

[Helmut Grohne]

Package: libstdlib-ocaml-dev,libcompiler-libs-ocaml-dev,libstdlib-ocaml
Version: 5.2.0-1~exp3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libfindlib-ocaml

libcompiler-libs-ocaml-dev, libstdlib-ocaml and libstdlib-ocaml-dev have
an undeclared file conflict. This may result in an unpack error from
dpkg.

The files
 * /usr/lib/ocaml/compiler-libs/META
 * /usr/lib/ocaml/ocamldoc/META
are contained in the packages
 * libcompiler-libs-ocaml-dev/5.2.0-1~exp3 as present in experimental
 * libfindlib-ocaml/1.9.6-2 as present in trixie|unstable

The files
 * /usr/lib/ocaml/dynlink/META
 * /usr/lib/ocaml/threads/META
are contained in the packages
 * libfindlib-ocaml/1.9.6-2 as present in trixie|unstable
 * libstdlib-ocaml-dev/5.2.0-1~exp3 as present in experimental

The files
 * /usr/lib/ocaml/stdlib/META
 * /usr/lib/ocaml/str/META
 * /usr/lib/ocaml/unix/META
are contained in the packages
 * libfindlib-ocaml/1.9.6-2 as present in trixie|unstable
 * libstdlib-ocaml/5.2.0-1~exp3 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074566: mariadb-client-compat and mariadb-server-compat have an undeclared file conflict

[Helmut Grohne]

Package: mariadb-client-compat,mariadb-server-compat
Version: 1:11.4.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + mariadb-client mariadb-server

mariadb-client-compat and mariadb-server-compat have an undeclared file
conflict. This may result in an unpack error from dpkg.

The files
 * /usr/bin/mysql_convert_table_format
 * /usr/bin/mysql_plugin
 * /usr/bin/mysql_secure_installation
 * /usr/bin/mysql_setpermission
 * /usr/bin/mysql_tzinfo_to_sql
 * /usr/bin/mysqlbinlog
 * /usr/bin/mysqlhotcopy
are contained in the packages
 * mariadb-client-compat/1:11.4.2-1 as present in unstable
 * mariadb-server
   * 1:10.11.6-0+deb12u1 as present in bookworm
   * 1:10.11.8-1 as present in trixie

The files
 * /usr/bin/mysql_find_rows
 * /usr/bin/mysql_fix_extensions
 * /usr/bin/mysql_waitpid
 * /usr/bin/mysqlaccess
 * /usr/bin/mysqladmin
 * /usr/bin/mysqlanalyze
 * /usr/bin/mysqlcheck
 * /usr/bin/mysqldump
 * /usr/bin/mysqldumpslow
 * /usr/bin/mysqlimport
 * /usr/bin/mysqloptimize
 * /usr/bin/mysqlrepair
 * /usr/bin/mysqlreport
 * /usr/bin/mysqlshow
 * /usr/bin/mysqlslap
are contained in the packages
 * mariadb-client
   * 1:10.11.6-0+deb12u1 as present in bookworm
   * 1:10.11.8-1 as present in trixie
 * mariadb-client-compat/1:11.4.2-1 as present in unstable

The files
 * /usr/bin/mysqld_multi
 * /usr/bin/mysqld_safe
 * /usr/bin/mysqld_safe_helper
are contained in the packages
 * mariadb-server
   * 1:10.11.6-0+deb12u1 as present in bookworm
   * 1:10.11.8-1 as present in trixie
 * mariadb-server-compat/1:11.4.2-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074537: lomiri-online-accounts-client and lomiri-system-settings-online-accounts have an undeclared file conflict on /usr/bin/lomiri-online-accounts-service and /usr/bin/lomiri-online-accounts-ui

[Helmut Grohne]

Package: lomiri-online-accounts-client,lomiri-system-settings-online-accounts
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict

The files
 * /usr/bin/lomiri-online-accounts-service
 * /usr/bin/lomiri-online-accounts-ui
are contained in the packages
 * lomiri-online-accounts-client/0.12-1 as present in unstable
 * lomiri-system-settings-online-accounts/0.10-3 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Please figure out which of these packages should properly own the
affected files and reassign the bug as appropriate. When doing so,
please add the other package to the set of affected packages using
"Control: affects -1 + " to avoid the filing of duplicates.

The other package should stop installing the files. In case the files
are being moved between packages, Breaks and Replaces should be
declared. In this case, please refer to policy section 7.6 for details.
Another useful resource is https://wiki.debian.org/PackageTransition.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074451: librecoll39-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/librecoll.so

[Helmut Grohne]

Package: librecoll39-dev
Version: 1.39.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + recollcmd

librecoll39-dev has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/lib/x86_64-linux-gnu/librecoll.so is contained in the
packages
 * librecoll39-dev/1.39.0-1 as present in unstable
 * recollcmd/1.36.1-1+b2 as present in trixie

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074299: samba-vfs-ceph and samba-vfs-glusterfs have an undeclared file conflict

[Helmut Grohne]

Package: samba-vfs-glusterfs,samba-vfs-ceph
Version: 2:4.20.2+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + samba-vfs-modules

samba-vfs-ceph and samba-vfs-glusterfs have an undeclared file conflict.
This may result in an unpack error from dpkg.

The files
 * /usr/lib/x86_64-linux-gnu/samba/vfs/ceph.so
 * /usr/lib/x86_64-linux-gnu/samba/vfs/ceph_snapshots.so
are contained in the packages
 * samba-vfs-ceph/2:4.20.2+dfsg-3 as present in unstable
 * samba-vfs-modules
   * 2:4.13.13+dfsg-1~deb11u5 as present in bullseye
   * 2:4.13.13+dfsg-1~deb11u6 as present in 
bullseye-proposed-updates|bullseye-security
   * 2:4.17.12+dfsg-0+deb12u1 as present in bookworm|bookworm-security
   * 2:4.17.12+dfsg-0+deb12u1~bpo11+1 as present in bullseye-backports
   * 2:4.17.9+dfsg-0+deb12u3 as present in bookworm-updates
   * 2:4.20.2+dfsg-2 as present in trixie
   * 2:4.20.2+dfsg-2~bpo12+2 as present in bookworm-backports

The files
 * /usr/lib/x86_64-linux-gnu/samba/vfs/glusterfs.so
 * /usr/lib/x86_64-linux-gnu/samba/vfs/glusterfs_fuse.so
are contained in the packages
 * samba-vfs-glusterfs/2:4.20.2+dfsg-3 as present in unstable
 * samba-vfs-modules
   * 2:4.13.13+dfsg-1~deb11u5 as present in bullseye
   * 2:4.13.13+dfsg-1~deb11u6 as present in 
bullseye-proposed-updates|bullseye-security
   * 2:4.17.12+dfsg-0+deb12u1 as present in bookworm|bookworm-security
   * 2:4.17.12+dfsg-0+deb12u1~bpo11+1 as present in bullseye-backports
   * 2:4.17.9+dfsg-0+deb12u3 as present in bookworm-updates
   * 2:4.20.2+dfsg-2 as present in trixie
   * 2:4.20.2+dfsg-2~bpo12+2 as present in bookworm-backports

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074298: firebird-utils has an undeclared file conflict

[Helmut Grohne]

Package: firebird-utils
Version: 4.0.4.3010.ds6-4
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + firebird3.0-server

firebird-utils has an undeclared file conflict. This may result in an
unpack error from dpkg.

The files
 * /usr/bin/fb_lock_print
 * /usr/bin/fbtracemgr
 * /usr/sbin/fbguard
 * /usr/sbin/firebird
are contained in the packages
 * firebird-utils/4.0.4.3010.ds6-4 as present in experimental
 * firebird3.0-server/3.0.11.33703.ds4-4 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074166: erlang-dialyzer has an undeclared file conflict on /usr/bin/typer

[Helmut Grohne]

Package: erlang-dialyzer
Version: 1:27.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + typer

erlang-dialyzer has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/bin/typer is contained in the packages
 * erlang-dialyzer/1:27.0+dfsg-1 as present in experimental
 * typer/0.12.3-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074165: libkscreenlocker6 has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet

[Helmut Grohne]

Package: libkscreenlocker6
Version: 6.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libkscreenlocker5

libkscreenlocker6 has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet is
contained in the packages
 * libkscreenlocker5
   * 5.20.5-1+deb11u1 as present in bullseye
   * 5.27.11-1 as present in trixie|unstable
   * 5.27.5-2 as present in bookworm
 * libkscreenlocker6/6.1.0-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074157: non-essential login breaks runuser

[Helmut Grohne]

Package: login
Version: 1:4.15.1-1
Severity: grave
Control: affects -1 + util-linux

Hi Chris et al,

while I recommend making stuff non-essential, I think the process was
suboptimal for login. I already had to fix debvm without having seen an
advance notice and now I figured that it actually breaks runuser. The
following command used to work before login became non-essential:

mmdebstrap unstable /dev/null --variant=apt --chrooted-customize-hook="runuser 
-u nobody echo ok"

This now gives:

runuser: failed to establish user credentials: Permission denied

I think that util-linux must gain Depends: login before login can become
non-essential (and thereby it becomes transitively essential making the
exercise a little pointless, but maybe there is a different solution).
Hence, I request reverting the change for now and redoing it once its
implications are better understood and the fallout is handled more
proactively.

Helmut

Bug#1074086: /usr/sbin/coldreboot is ineffectively diverted by bfh-container, molly-guard and progress-linux-container

[Helmut Grohne]

Package: kexec-tools
Version: 1:2.0.27-1.2
Severity: serious
User: helm...@debian.org
Usertags: dep17p3
Control: affects -1 + bfh-container molly-guard progress-linux-container
X-Debbugs-Cc: z...@debian.org

coldreboot is being moved from /bin to /usr/bin. Unfortunately,
bfh-container, molly-guard and progress-linux-container divert this
location causing problems.

I think we need the same (or similar) dance as with systemd-sysv. Each
of those packages needs to install mitigations and kexec-tools needs
versioned conflicts with unfixed versions of those.

Arguably, combining bfh-container or progress-linux-container with
kexec-tools is not a reasonable thing to do. In those cases, unversioned
conflicts may be applicable though they are not technically policy
compliant.

This bug serves as a migration blocker and helps apt-listbugs users with
not loosing their files.

Helmut

Bug#1074085: python3-proto-plus missing Breaks+Replaces with nanopb

[Helmut Grohne]

Package: python3-proto-plus
Version: 1.23.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + nanopb

Hi,

we're almost done with the file conflict between python3-proto-plus and
nanopb. Thanks for taking the time to work on a proper solution. Now the
python3-proto-plus package still shares files with the nanopb package in
trixie and this breaks smooth upgrades. We really are taking over files
now. When you upgrade python3-proto-plus and have nanopb installed,
nanopb should be upgraded as well to avoid that file conflict. Thus
please add:

Breaks: nanopb (<< 0.4.8-2~)
Replaces: nanopb (<< 0.4.8-2~)

Helmut

Bug#1074070: imgcrypt has an undeclared file conflict on /usr/bin/ctr

[Helmut Grohne]

Package: imgcrypt
Version: 1.1.11-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + containerd

imgcrypt has an undeclared file conflict. This may result in an unpack
error from dpkg.

The file /usr/bin/ctr is contained in the packages
 * containerd
   * 1.4.13~ds1-1~deb11u2 as present in bullseye-security
   * 1.4.13~ds1-1~deb11u4 as present in bullseye
   * 1.6.20~ds1-1+b1 as present in bookworm
   * 1.6.24~ds1-2 as present in trixie|unstable
 * imgcrypt/1.1.11-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074071: libkf6screen-bin has an undeclared file conflict

[Helmut Grohne]

Package: libkf6screen-bin
Version: 4:6.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libkf5screen-bin

libkf6screen-bin has an undeclared file conflict. This may result in an
unpack error from dpkg.

The files
 * /usr/bin/kscreen-doctor
 * /usr/lib/systemd/user/plasma-kscreen.service
are contained in the packages
 * libkf5screen-bin
   * 4:5.27.11-1 as present in trixie|unstable
   * 4:5.27.5-2 as present in bookworm
 * libkf6screen-bin/4:6.1.0-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1073922: systemd-{container,cryptsetup,repart}: ineffective Replaces due to /usr-move (DEP17)

[Helmut Grohne]

Control: reassign -1 systemd-container,systemd-cryptsetup,systemd-repart
Control: found -1 systemd/256.1-1
Control: tags -1 + patch

On Thu, Jun 20, 2024 at 10:58:23AM +0200, Helmut Grohne wrote:
> Package: systemd-container,systemd-cryptsetup,cryptsetup-repart

Fixed bad package cryptsetup-repart.

> Let me not go into details of this problem just yet and just install
> this bug as a temporary migration blocker. I shall have an update within
> three working days, ideally with a patch. Thanks for your patience.

The recurring theme is that systemd moved all of its files from / to
/usr (expected via DEP17) and now moves components from the main systemd
package into systemd-container, systemd-cryptsetup and systemd-repart.
In all of these cases, affected files may be lost in upgrades from
either bookworm or bookworm-backports to unstable and eventually trixie.
Users upgrading from trixie to sid, will likely not experience loss
unless they skip systemd versions.

There are multiple mitigation techniques available. Upgrading
Breaks+Replaces to Conflicts provides a relatively strong protection as
long as one uses an apt-based package management tool. However, the CTTE
advised that packages relevant to booting a system should also be safe
when installing packages directly with dpkg and in that scenario,
Conflicts are insufficient, because dpkg allows a conflicting package to
be unpacked before the conflicted package is removed to facilitate a
smooth handover. This is only exercised by apt when the relevant
packages employ a mutual conflict, which is not the case here. As such,
I also add temporary diversions that exist from preinst to postinst to
protect the relevant files from loss.

While I could have just written the maintainer scripts, I expect more
restructuring to happen until the trixie release and hence went for a
templating system. Affected files should be added (with their aliased
path) to debian/$PKG.usrmergemitigate. Then a debian/rules snippet will
construct relevant debian/*.preinst-usrmerge and
debian/*.postinst-usrmerge snippets that substitute
#USRMERGEMITIGATEPREINST# and #USRMERGEMITIGATEPOSTINST# in actual
debian/*.preinst and debian/*.postinst via dh_installdeb's substitution
mechanism. When adding a new debian/*.usrmergemitigate file, one also
has to add these substitutions to the relevant .preinst and .postinst.
I think this bears a good trade-off regarding complexity and repetition.
Let me know whether you disagree with this judgement.

Helmut
diff --minimal -Nru systemd-256.1/debian/changelog 
systemd-256.1/debian/changelog
--- systemd-256.1/debian/changelog  2024-06-19 00:19:16.0 +0200
+++ systemd-256.1/debian/changelog  2024-06-19 14:51:07.0 +0200
@@ -1,3 +1,13 @@
+systemd (256.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mitigate file loss arising from the combination of restructuring
+and /usr-move (DEP17 P1, Closes: #-1):
++ Upgrade relevant Breaks+Replaces to Conflicts.
++ Add protective diversions for lost files.
+
+ -- Helmut Grohne   Wed, 19 Jun 2024 14:51:07 +0200
+
 systemd (256.1-1) unstable; urgency=medium
 
   * Bump versioned breaks against dracut to 102-2 (Closes: #1073290)
diff --minimal -Nru systemd-256.1/debian/control systemd-256.1/debian/control
--- systemd-256.1/debian/control2024-06-19 00:19:11.0 +0200
+++ systemd-256.1/debian/control2024-06-19 14:51:07.0 +0200
@@ -164,8 +164,7 @@
 Recommends: libnss-mymachines,
 ${dlopen:Recommends},
 Suggests: ${dlopen:Suggests},
-Breaks: systemd (<< 256-2~),
-Replaces: systemd (<< 256-2~),
+Conflicts: systemd (<< 256-2~),
 Description: systemd container/nspawn tools
  This package provides systemd's tools for nspawn and container/VM management:
   * systemd-nspawn
@@ -649,8 +648,7 @@
  ${misc:Depends},
 Recommends: ${dlopen:Recommends},
 Suggests: ${dlopen:Suggests},
-Breaks: systemd (<< 256-2~),
-Replaces: systemd (<< 256-2~),
+Conflicts: systemd (<< 256-2~),
 Description: Provides the systemd-repart utility
  systemd-repart is a configuration-driven system partitioning tool. It follows
  the Discoverable Partitions Specification and provides support for encryption
@@ -663,8 +661,7 @@
  ${misc:Depends},
 Recommends: ${dlopen:Recommends},
 Suggests: ${dlopen:Suggests},
-Breaks: systemd (<< 256-2~),
-Replaces: systemd (<< 256-2~),
+Conflicts: systemd (<< 256-2~),
 Description: Provides cryptsetup, integritysetup and veritysetup utilities
  Utilities and units that integrated cryptsetup/integritysetup/veritysetup
  support in systemd.
diff --minimal -Nru systemd-256.1/debian/postinst.usrmergetemplate 
systemd-256.1/debian/postinst.usrmergetemplate
--- systemd-256.1/debian/postinst.usrmergetemplate  1970-01-01 
01:00:00.0 +0100
+++ systemd-256.1/debian/postinst.usrmergetemplate  2024-06-19 
14:51:07.0 +0200
@@ 

Bug#1073995: libcompiler-libs-ocaml-dev, libstdlib-ocaml and libstdlib-ocaml-dev have an undeclared file conflict

[Helmut Grohne]

Package: libstdlib-ocaml-dev,libcompiler-libs-ocaml-dev,libstdlib-ocaml
Version: 5.2.0-1~exp2
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libfindlib-ocaml

libcompiler-libs-ocaml-dev, libstdlib-ocaml and libstdlib-ocaml-dev have
an undeclared file conflict. This may result in an unpack error from
dpkg.

The files
 * /usr/lib/ocaml/compiler-libs/META
 * /usr/lib/ocaml/ocamldoc/META
are contained in the packages
 * libcompiler-libs-ocaml-dev/5.2.0-1~exp2 as present in experimental
 * libfindlib-ocaml
   * 1.8.1-2 as present in bullseye
   * 1.9.6-1+b1 as present in bookworm
   * 1.9.6-2 as present in trixie|unstable

The files
 * /usr/lib/ocaml/dynlink/META
 * /usr/lib/ocaml/threads/META
are contained in the packages
 * libfindlib-ocaml
   * 1.8.1-2 as present in bullseye
   * 1.9.6-1+b1 as present in bookworm
   * 1.9.6-2 as present in trixie|unstable
 * libstdlib-ocaml-dev/5.2.0-1~exp2 as present in experimental

The files
 * /usr/lib/ocaml/stdlib/META
 * /usr/lib/ocaml/str/META
 * /usr/lib/ocaml/unix/META
are contained in the packages
 * libfindlib-ocaml/1.9.6-2 as present in trixie|unstable
 * libstdlib-ocaml/5.2.0-1~exp2 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1073922: systemd-{container,cryptsetup,repart}: ineffective Replaces due to /usr-move (DEP17)

[Helmut Grohne]

Package: systemd-container,systemd-cryptsetup,cryptsetup-repart
Version: 256.1-1
Severity: serious
Control: affects -1 + systemd
User: helm...@debian.org
Usertags: dep17p1

Hi,

Version 256.1-1 was restructured splitting a number of pieces from the
main systemd package into other packages. As far as I can see, the same
changes were already present in experimental and I need to investigate
why dumat did not flag them there.

Let me not go into details of this problem just yet and just install
this bug as a temporary migration blocker. I shall have an update within
three working days, ideally with a patch. Thanks for your patience.

The dumat report is not very human-readable, but available at
https://subdivi.de/~helmut/dumat.yaml.

Helmut

Bug#1073832: firmware-{intel-graphics,intel-misc,marvell-prestera,mediatek,misc-nonfree,nvidia-graphics}: ineffective replaces due to /usr-move (DEP17)

[Helmut Grohne]

Package: 
firmware-intel-graphics,firmware-intel-misc,firmware-marvell-prestera,firmware-mediatek,firmware-misc-nonfree,firmware-nvidia-graphics
Version: 20230625-3~exp2
Severity: serious
Tags: patch
Control: affecs -1 + firmware-libertas,firmware-ti-connectivity
User: helm...@debian.org
Usertags: dep17p1

Hi,

thank you for uploading restructuring changes of firmware-nonfree to
experimental. dumat duly spot problems. Roughly speaking many of the
firmware files move from one package to another and at the same time all
of them move from /lib/firmware to /usr/lib/firmware causing the
earliest known /usr-merge problem that resulted in the file move
moratorium.

I don't think it helps to spell out lengthy details of what is broken
exactly and instead I'm attaching a patch. It may need some polishing to
your liking.

There are multiple mitigation strategies available. When it comes to
using apt-based resolvers, upgrading Replaces to Conflicts practically
solves the file loss problems. However, firmware tends to be relevant
for boot and the CTTE recommended doing more thorough mitigations when
booting may be impacted. Hence, my patch also adds protective
diversions. When you dpkg --unpack --auto-deconfigure the experimental
e.g. firmware-intel-graphics on a bookworm system with
firmware-misc-nonfree, dpkg will actually perform the unpack before the
removal despite declared Conflicts and hence loose files in an upgrade.
The protective diversions are installed in preinst and deleted in
postinst and thus the upgraded system no longer has them.

Note that even though the added usrmergemitigation list may look as
though it duplicates files, but that is not the case. For some packages,
it lists fewer files. If you later add more files to individual
packages, you should not add them to usrmergemitigation as that field
only carries those files that also are present in earlier releases. I
hope you won't forget when firmware-nonfree is in need of updating.

Please let me know what you think about the patch and whether you want
to turn it into a consumable shape or provide feedback as to how you
want it. I note that testing using piuparts does not work due to the
license stuff and a manual upgrade test looked good.

Helmut
diff --minimal -Nru firmware-nonfree-20230625/debian/README.source 
firmware-nonfree-20230625/debian/README.source
--- firmware-nonfree-20230625/debian/README.source  2024-06-02 
22:08:30.0 +0200
+++ firmware-nonfree-20230625/debian/README.source  2024-06-19 
12:45:44.0 +0200
@@ -79,6 +79,8 @@
 [base] replaces: Used as Replaces field
 [base] conflicts: Used as Conflicts field
 [base] provides: Used as Provides field
+[base] usrmergemitigation: List of firmware files that require protective
+   diversions
 
 Optional per-file metadata:
 
diff --minimal -Nru firmware-nonfree-20230625/debian/bin/gencontrol.py 
firmware-nonfree-20230625/debian/bin/gencontrol.py
--- firmware-nonfree-20230625/debian/bin/gencontrol.py  2024-06-18 
02:33:12.0 +0200
+++ firmware-nonfree-20230625/debian/bin/gencontrol.py  2024-06-19 
13:11:28.0 +0200
@@ -256,15 +256,16 @@
 
 packages_binary[0]['Description'].append_pre(files_desc)
 
+scripts = {}
+
 if 'initramfs-tools' in config_entry.get('support', []):
 postinst = self.templates.get('postinst.initramfs-tools')
-open("debian/firmware-%s.postinst" % package, 
'w').write(self.substitute(postinst, vars))
+scripts.setdefault("postinst", 
[]).append(self.substitute(postinst, vars))
 
 if 'license-accept' in config_entry:
 license = open("%s/LICENSE.install" % package_dir, 'r').read()
 preinst = self.templates.get('preinst.license')
-preinst_filename = "debian/firmware-%s.preinst" % package
-open(preinst_filename, 'w').write(self.substitute(preinst, vars))
+scripts.setdefault("preinst", []).append(self.substitute(preinst, 
vars))
 
 templates = 
self.templates.get_templates_control('templates.license', vars)
 templates[0]['Description'].append(re.sub('\n\n', '\n.\n', 
license))
@@ -278,6 +279,17 @@
 % vars['license-title'])
 packages_binary[0]['Pre-Depends'] = PackageRelation('debconf | 
debconf-2.0')
 
+if config_entry.get('usrmovemitigation', []):
+for script in ("preinst", "postinst"):
+script_template = self.templates.get(script + 
'.usrmovemitigation')
+script_content = self.substitute(script_template, 
dict(files=config_entry["usrmovemitigation"]))
+scripts.setdefault(script, []).append(script_content)
+
+for script, script_contents in scripts.items():
+script_contents.insert(0, "#!/bin/sh\n\nset -e\n")
+script_contents.append("#DEBHELPER#\n\nexit 0\n")

Bug#1052788: python-asyncssh: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 --system=custom "--test-args={interpreter} -m unittest discover -v" returned exit code 13

[Helmut Grohne]

^^^
|   File "/usr/lib/python3.11/asyncio/base_events.py", line 654, in 
run_until_complete
| return future.result()
|^^^
|   File "/<>/tests/test_sk.py", line 191, in 
test_enroll_pin_required
| asyncssh.generate_private_key('sk-ssh-ed25...@openssh.com')
|   File "/<>/asyncssh/public_key.py", line 3082, in 
generate_private_key
| key = handler.generate(algorithm, **kwargs)
|   ^
|   File "/<>/asyncssh/sk_eddsa.py", line 85, in generate
| public_value, key_handle = sk_enroll(SSH_SK_ED25519, application,
|^^
|   File "/<>/asyncssh/sk.py", line 168, in sk_enroll
| return _ctap2_enroll(dev, alg, application, user, pin, resident)
|^
|   File "/<>/asyncssh/sk.py", line 112, in _ctap2_enroll
| cred = ctap2.make_credential(_dummy_hash, rp, user_cred, key_params,
|^^^^^
|   File "/<>/tests/sk_stub.py", line 198, in make_credential
| raise CtapError(CtapError.ERR.PIN_REQUIRED)
| ^^
|   File "/usr/lib/python3.11/enum.py", line 786, in __getattr__
| raise AttributeError(name) from None
| AttributeError: PIN_REQUIRED
| 
| --
| Ran 1464 tests in 668.033s
| 
| FAILED (errors=8, skipped=21)
| E: pybuild pybuild:389: test: plugin custom failed with: exit code=1: 
python3.11 -m unittest discover -v
| dh_auto_test: error: pybuild --test -i python{version} -p "3.12 3.11" 
--system=custom "--test-args={interpreter} -m unittest discover -v" returned 
exit code 13
| make[1]: *** [debian/rules:16: override_dh_auto_test] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:8: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#1073244: ruby-xmlrpc has an undeclared file conflict on /usr/bin/console

[Helmut Grohne]

Package: ruby-xmlrpc
Version: 0.3.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + conserver-client

ruby-xmlrpc has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/bin/console is contained in the packages
 * conserver-client
   * 8.2.6-2 as present in bullseye
   * 8.2.7-2+b1 as present in bookworm
   * 8.2.7-2+b3 as present in trixie|unstable
 * ruby-xmlrpc/0.3.3-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1073243: libcompiler-libs-ocaml-dev, libstdlib-ocaml and libstdlib-ocaml-dev have an undeclared file conflict

[Helmut Grohne]

Package: libstdlib-ocaml,libcompiler-libs-ocaml-dev,libstdlib-ocaml-dev
Version: 5.2.0-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libfindlib-ocaml

libcompiler-libs-ocaml-dev, libstdlib-ocaml and libstdlib-ocaml-dev have
an undeclared file conflict. This may result in an unpack error from
dpkg.

The files
 * /usr/lib/ocaml/compiler-libs/META
 * /usr/lib/ocaml/ocamldoc/META
are contained in the packages
 * libcompiler-libs-ocaml-dev/5.2.0-1~exp1 as present in experimental
 * libfindlib-ocaml
   * 1.8.1-2 as present in bullseye
   * 1.9.6-1+b1 as present in bookworm
   * 1.9.6-1+b2 as present in trixie|unstable

The files
 * /usr/lib/ocaml/dynlink/META
 * /usr/lib/ocaml/threads/META
are contained in the packages
 * libfindlib-ocaml
   * 1.8.1-2 as present in bullseye
   * 1.9.6-1+b1 as present in bookworm
   * 1.9.6-1+b2 as present in trixie|unstable
 * libstdlib-ocaml-dev/5.2.0-1~exp1 as present in experimental

The files
 * /usr/lib/ocaml/stdlib/META
 * /usr/lib/ocaml/str/META
 * /usr/lib/ocaml/unix/META
are contained in the packages
 * libfindlib-ocaml
   * 1.8.1-2 as present in bullseye
   * 1.9.6-1+b1 as present in bookworm
   * 1.9.6-1+b2 as present in trixie|unstable
 * libstdlib-ocaml/5.2.0-1~exp1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1073056: stardict: stop using pcre3

[Helmut Grohne]

Source: stardict
Severity: serious
Tags: trixie sid

Hi,

we want to get rid of pcre3 in trixie. As such startdict's libpcre3-dev
dependency will become unsatisfiable. Ironically, the replacement is
pcre2.

Helmut

Bug#1073055: gnome-builder: stop using pcre3

[Helmut Grohne]

Source: gnome-builder
Severity: serious
Tags: trixie sid

Hi,

we're in the process of removing pcre3 from Debian and it shall not be
part of trixie. Hence gnome-builder should stop depending on it.
Ironically, the new version is pcre2.

Helmut

Bug#1073030: kglobalacceld has an undeclared file conflict on /usr/lib/systemd/user/plasma-kglobalaccel.service

[Helmut Grohne]

Package: kglobalacceld
Version: 6.0.90-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libkf5globalaccel-bin

kglobalacceld has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/lib/systemd/user/plasma-kglobalaccel.service is contained
in the packages
 * kglobalacceld/6.0.90-1 as present in experimental
 * libkf5globalaccel-bin
   * 5.103.0-1 as present in bookworm
   * 5.115.0-2 as present in trixie|unstable
   * 5.78.0-3 as present in bullseye

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1073001: buildbot FTBFS: python3-sqlalchemy (<< 1.5) no longer satisfiable

[Helmut Grohne]

Source: buildbot
Version: 3.10.1-2
Severity: serious
Tags: ftbfs trixie sid

buildbot can no longer be built in unstable as the python3-sqlalchemy
package is too new to satisfy buildbot's build dependencies. It likely
needs an upload that establishes compatibility with newer sqlalchemy.

Helmut

Bug#1072752: libcomedi0t64: contains soname-independent library support files

[Helmut Grohne]

Package: libcomedi0t64,libcomedi0
Severity: serious
Justification: policy 8.2

Debian policy 8.2 requires that library support files installed into the
shared library package must be soname-dependent in order to allow
coinstallation of multiple sonames. The file
/lib/udev/rules.d/90-comedi.rules is considered to be such a support
file and its name does not look like it'd automatically change with a
new soname.

There are two main ways to deal with this requirement. One is renaming
the file and including its soname somewhere. Consider though that you
may have two conflicting comedi udev rules installed concurrently then.
The other is adding a -common package containing this file and having
the shared library depend on the -common package. The -common package
should not be soname-dependent. In this case, the old library needs to
be able to work with comedi udev rules from a newer version (which seems
at least plausible).

Helmut

Bug#1072733: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/sherlock/__init__.py

[Helmut Grohne]

Package: sherlock
Version: 0.14.4+git20240531.e5ad3c4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + python3-sherlock

sherlock has an undeclared file conflict. This may result in an unpack
error from dpkg.

The file /usr/lib/python3/dist-packages/sherlock/__init__.py is
contained in the packages
 * python3-sherlock/0.4.1-2 as present in trixie|unstable
 * sherlock/0.14.4+git20240531.e5ad3c4-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1072730: libfishcamp1t64: ineffective Replaces due to /usr-move (DEP17)

[Helmut Grohne]

Package: libfishcamp1t64
Version: 1.2+20220607003151-2
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p1
Control: clone -1 -2
Control: retitle -2 violates policy 8.2: soname-independent library support 
files

Hi Thorsten,

I am sorry to tell you that libfishcamp1t64 slipped through my review.
It really is one of the packages that cannot be just moved. I'll review
my analysis regarding this after sending this patch.

libfishcamp combines three ingredients:
 * It installed aliased files in bookworm (firmware and udev rules)
 * It is affected by the time64 transition and thus renames packages.
 * It installs files that are not soname-dependent into the shared
   library package violating Debian policy section 8.2. I've cloned a
   separate bug about this problem.

As a result, you are experiencing a DEP17 P1 problem. Roughly speaking,
an upgrade could first unpack libfishcamp1t64 thereby installing the
firmware and udev files into /usr. In doing so, dpkg overwrites the
files from libfishcamp1 without attributing it to Replaces due to the
difference in aliasing. Then, when libfishcamp1 is removed, it also
removes firmware and udev files for real as they have not been replaced.
Once the upgrade is complete, these files go missing.

So this is indeed a case where dh-sequence-movetousr does not just work
(and maybe it now becomes more clear why we didn't make
dh-sequence-movetousr opt-out). There are multiple options to mitigate
this with varying level of reliability. A reliable mitigation requires
using protective diversions installed for the entire trixie release.
This is fairly annoying and causes maintenance costs down the road
(removing diversions, later removing diversion removing code). I propose
using a less reliable method for this case. fishcamp seems to be a
relatively unpopular package, so the number of affected users is
expected to be small. When upgrading the Breaks to Conflicts (without
having reverse Breaks), we are not aware of any scenario where this
mitigation would be unreliable when using apt or aptitude (i.e. you need
to install libfishcamp1t64 using dpkg directly in a specific setting to
actually experience file loss). In any case, users can detect the loss
using dpkg --verify and reinstalling libfishcamp1t64 will reinstate the
lost files. Loss of these files would likely not render systems
unbootable. Hence, I think this is a relatively low probability,
relatively low impact and the more reliable mitigation has significantly
higher maintenance cost.

Do you agree with this risk assessment? If not, I can provide a more
elaborate patch doing a more reliable mitigation.

Another alternative to fixing this problem is reverting the t64
transition. I looked for the abi report, but there is none nor is there
a bug report from the t64 people. Hence, I looked at the headers and
found that none of them use off_t or time_t or other relevant types in
structures or types. time_t is used internally, but not exposed. As a
result, fishcamp very likely is unaffected by the time64 transition and
its rename can be reverted. The revert briefly introduces the reverse
DEP17 P1 problem into unstable, but for bookworm -> trixie upgrades,
things would work then. If you opt for reverting, you don't have to use
Conflicts and you can continue to use dh-sequence-movetousr.

I note that the attached patch is not appropriate for bookworm-backports
(but neither is the t64 rename).

Helmut
diff --minimal -Nru libfishcamp-1.2+20220607003151/debian/changelog 
libfishcamp-1.2+20220607003151/debian/changelog
--- libfishcamp-1.2+20220607003151/debian/changelog 2024-06-03 
23:30:36.0 +0200
+++ libfishcamp-1.2+20220607003151/debian/changelog 2024-06-07 
10:14:24.0 +0200
@@ -1,3 +1,12 @@
+libfishcamp (1.2+20220607003151-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mitigate /usr-move DEP17 P1 problems. (Closes: #-1)
++ Manually move files instead of using dh-sequence-movetousr.
++ Upgrade Breaks to Conflicts.
+
+ -- Helmut Grohne   Fri, 07 Jun 2024 10:14:24 +0200
+
 libfishcamp (1.2+20220607003151-2) unstable; urgency=medium
 
   * upload to unstable
diff --minimal -Nru libfishcamp-1.2+20220607003151/debian/control 
libfishcamp-1.2+20220607003151/debian/control
--- libfishcamp-1.2+20220607003151/debian/control   2024-06-03 
23:30:36.0 +0200
+++ libfishcamp-1.2+20220607003151/debian/control   2024-06-07 
10:14:24.0 +0200
@@ -8,7 +8,6 @@
, libusb-1.0-0-dev
, zlib1g-dev
, libindi-dev
-   , dh-sequence-movetousr
 Standards-Version: 4.7.0
 Homepage: https://github.com/indilib/indi-3rdparty
 Rules-Requires-Root: no
@@ -19,7 +18,7 @@
 Package: libfishcamp1t64
 Provides: ${t64:Provides}
 Replaces: libfishcamp1
-Breaks: libfishcamp1 (<< ${source:Version})
+Conflicts: libfishcamp1 (<< ${source:Version})
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: library f

Bug#1072012: libxml-libxml-perl: new upstream release 2.0210, addressing test failures with libxml2 >= 2.11

[Helmut Grohne]

ocks
==1303314==indirectly lost: 59,036 bytes in 34 blocks
==1303314==  possibly lost: 10,544,904 bytes in 38,816 blocks
==1303314==still reachable: 108,554 bytes in 70 blocks
==1303314==   of which reachable via heuristic:
==1303314== newarray   : 54,032 bytes in 
1,649 blocks
==1303314== suppressed: 0 bytes in 0 blocks
==1303314== Rerun with --leak-check=full to see details of leaked memory
==1303314==
==1303314== Use --track-origins=yes to see where uninitialised values come 
from
==1303314== For lists of detected and suppressed errors, rerun with: -s
==1303314== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 0 from 0)
$

Notably, when I see crashes on armel, they're always after test 10,
which is where we see the use of uninitialized values. Maybe, amd64 is
just a bit luckier with its choice of uninitialized values?

Digging into the source of libxml2 __xmlRaiseError examines a ctxt
pointer, which is a casted aliased of its fourth argument ctx.
xmlErrValidNode receives a xmlValidCtxtPtr ctxt and passes
ctxt->userData as ctx to __xmlRaiseError. This first ctxt argument is
common to a number of xmlValidate* functions and passed from the
LibXML.xs in is_valid as cvp. The is_valid function initializes
cvp->userData to saved_error, which is defined by the
PREINIT_SAVED_ERROR.

It is a surprising that libxml2 interprets the use ctx->userData field
as a xmlParserCtxt*. Looking closer, it only does that when ctx->flags
has XML_VCTXT_USE_PCTXT set. When that bit is unset, xmlErrValid
reliably sets the ctx argument to __xmlRaiseError to NULL. Hence, we may
assume that XML_VCTXT_USE_PCTXT is set. LibXML.xs does not mention
XML_VCTXT_USE_PCTXT though. Reading the libxml source tells that any
place that sets this bit in ctx->flags also sets ctx->userData to
something compatible with that use.

I locally instrumented LibXML.xs's is_valid to show its cvp.flags and
it's uninitialized (and 0 on amd64)!

So let's test the hypothesis.

--- a/LibXML.xs
+++ b/LibXML.xs
@@ -4025,6 +4025,6 @@
 CODE:
 INIT_ERROR_HANDLER;

+memset(, 0, sizeof(cvp));
 cvp.userData = saved_error;
 cvp.error = (xmlValidityErrorFunc)LibXML_validity_error_ctx;
 cvp.warning = (xmlValidityWarningFunc)LibXML_validity_warning_ctx;

And after this change the segfaulting test passes, but I still get other
failures from dh_auto_test.

Is this good enough to go ahead and upload a slightly less FTBFSy
version of libxml-libxml-perl to see more of the remaining failure?

Helmut

Bug#1072521: fakeroot hangs on some commands with faked-sysv using 100% CPU

[Helmut Grohne]

Control: severity -1 important

Hi,

On Mon, Jun 03, 2024 at 04:31:39PM +0200, Pierre-Elliott Bécue wrote:
> Assigning to fakeroot for now, but not sure it's not something for ftp.d.o (a
> binNMU) or libc6.
> 
> Today, after an upgrade, I am not able to build packages with sbuild as
> it hanks with this process tree:

I suggest that the cause may be something else and we are looking at
some red herrings at least. In the mean time, the buildd network is
reporting successful builds, Jochen Sprickerhof and I cannot readily
reproduce the problem. I'm relatively certain that it doesn't affect
everyone at this time and hence downgrading the report.

> In parallel, one can find a faked-sysv process eating all a CPU resources.
> 
> peb   225847  100  0.0   2440   648 pts/4R+   16:25   0:02  \_ 
> /usr/bin/faked-sysv

I think I have a plausible explanation for the CPU consumption.

> strace: Process 230857 attached
> close(200453)   = -1 EBADF (Bad file descriptor)
> close(200454)   = -1 EBADF (Bad file descriptor)
> close(200455)   = -1 EBADF (Bad file descriptor)
...
> close(200511)   = -1 EBADF (Bad file descriptor)
> ... and so on

What we see here is a loop closing increasing file descriptors. I looked
into fakeroot's source code and indeed there is such a loop that may
correspond to this trace.

https://sources.debian.org/src/fakeroot-ng/0.18-4.1/daemon.cpp/?hl=411#L414
| int fd_limit=getdtablesize();
| for( int i=0; i An hypothesis is that a rebuild against the current sid could solve the issue.
> I will try that and report back.

This no longer feels plausible to me. I have a few other ones:

A. Your machine is relatively slow and closing 1e6 fds (for whatever
   reason) takes it very long time leaving the impression of hanging.

B. Your file descriptor limit is even higher than 1e6 and in that case,
   the close loop really can take very long.

C. You captured part of the close loop (with a higher than usual file
   descriptor limit), but it is not the cause of the hang. Rather it
   hangs for other reasons after having closed all those file
   descriptors.

> Feel free to reassign.

>From what I can tell, fakeroot would be better served with using
close_range(2). That would lower the CPU consumption with a higher
resource limit and make the real problem more apparent or disappear.

Hope this helps, but I am fairly convinced now that this is not a glibc
regression.

Helmut

Bug#1072391: python3-specreduce has an undeclared file conflict

[Helmut Grohne]

Package: python3-specreduce
Version: 1.4.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + pipenv python3-google-auth-oauthlib

python3-specreduce has an undeclared file conflict. This may result in
an unpack error from dpkg.

The file /usr/lib/python3/dist-packages/build/lib/docs/conf.py is
contained in the packages
 * pipenv/2023.12.1+ds-1 as present in trixie|unstable
 * python3-specreduce/1.4.0-1 as present in unstable

The file /usr/lib/python3/dist-packages/docs/conf.py is contained in the
packages
 * python3-google-auth-oauthlib/1.2.0-1 as present in trixie|unstable
 * python3-specreduce/1.4.0-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1072214: python3-proto-plus declares Conflicts: nanopb in violation of Debian policy 10.1

[Helmut Grohne]

Package: python3-proto-plus
Version: 1.23.0-2
Severity: serious
Justification: policy 10.1

python3-proto-plus declares a conflict with nanopb. Doing so violates
Debian policy section 10.1. More background can be found in #1072073.

Helmut

Bug#1072073: python3-proto-plus has an undeclared file conflict on /usr/lib/python3/dist-packages/proto/__init__.py

[Helmut Grohne]

Control: reassign -1 python3-proto-plus,nanopb
Control: affects -1 =

On Wed, May 29, 2024 at 08:40:03PM -0400, Yogeswaran Umasankar wrote:
> For now, I am planning to declare nanopb in Conflicts for
> 'python3-proto-plus' binary. Let me know if it might not be advisable.

Doing so violates Debian policy 10.1:

Two different packages must not install programs with different
functionality but with the same filenames.

Arguably, this extends to Python modules. Generally speaking, packages
should be coinstallable unless they fundamentally cannot and in this
case renaming either is a reasonable solution.

I recommend talking to the nanopb maintainer, because what their
package does is unusual. The affected module name "proto" is part of the
python3-proto package, but the nanopb package isn't even identifying a
Python module. It would be plausible to make their module private and
hence resolve the conflict. I very much expect a solution of this bug to
require changes in nanopb of some form.

So this bug likely involves more coordination than originally
anticipated. Keep in mind that every mail to this bug resets the
testing autoremover and the freeze is not exactly close.

Helmut

Bug#1072159: rust-pango-sys FTBFS with nocheck build profile: cp: cannot stat '/usr/share/gir-1.0/Pango-1.0.gir': No such file or directory

[Helmut Grohne]

Source: rust-pango-sys
Version: 0.19.5-2
Severity: serious
Tags: ftbfs trixie sid

rust-pango-sys fails to build from source when enabling the nocheck
build profile. A build ends with:

|dh_auto_configure -O--buildsystem=cargo
| debian cargo wrapper: options, profiles, parallel, lto: ['nocheck', 
'parallel=8'] ['nocheck'] ['-j8'] 0
| debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
| debian cargo wrapper: linking /usr/share/cargo/registry/* into 
/<>/debian/cargo_registry/
|debian/rules execute_before_dh_auto_build
| make[1]: Entering directory '/<>'
| cp /usr/share/gir-1.0/GLib-2.0.gir /<>
| cp /usr/share/gir-1.0/GModule-2.0.gir /<>
| cp /usr/share/gir-1.0/GObject-2.0.gir /<>
| cp /usr/share/gir-1.0/Pango-1.0.gir /<>
| cp: cannot stat '/usr/share/gir-1.0/Pango-1.0.gir': No such file or directory
| make[1]: *** [debian/rules:12: execute_before_dh_auto_build] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:4: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Please review the  annotations in your package. Since trixie,
a nocheck build failure is considered release-critical.

Helmut

Bug#1072102: samba-ad-dc: ineffective replaces due to /usr-move (DEP17)

[Helmut Grohne]

Package: samba-ad-dc
Version: 2:4.20.1+dfsg-3
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p1
Control: affects -1 + samba

Hi,

/lib/systemd/system/samba-ad-dc.service is part of the samba package
in the following versions:
 * 2:4.13.13+dfsg-1~deb11u5: bullseye   
  
 * 2:4.13.13+dfsg-1~deb11u6: bullseye-security|bullseye-proposed-updates
  
 * 2:4.17.12+dfsg-0+deb12u1: bookworm|bookworm-security 
  
 * 2:4.17.12+dfsg-0+deb12u1~bpo11+1: bullseye-backports 
  
 * 2:4.17.9+dfsg-0+deb12u3: bookworm-updates
  
 * 2:4.19.6+dfsg-3~bpo12+1: bookworm-backports  
  

/usr/lib/systemd/system/samba-ad-dc.service is now part of samba-ad-dc.
Since these actually refer to the same file via different paths (due to
/usr-move), we produce a DEP17 P1 problem and the declared Replaces are
ineffective leading to file loss in an upgrade scenario (what the file
move moratorium meant to prevent). This needs to be mitigated and I am
attaching the necessary patch.

Helmut
diff -Nru samba-4.20.1+dfsg/debian/changelog samba-4.20.1+dfsg/debian/changelog
--- samba-4.20.1+dfsg/debian/changelog  2024-05-26 17:48:17.0 +0200
+++ samba-4.20.1+dfsg/debian/changelog  2024-05-28 13:37:34.0 +0200
@@ -1,3 +1,10 @@
+samba (2:4.20.1+dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mitigate ineffective replaces due to /usr-move (DEP17 P1). (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 28 May 2024 13:37:34 +0200
+
 samba (2:4.20.1+dfsg-3) unstable; urgency=medium
 
   * d/rules: move samba-common install to d/samba-common.install
diff -Nru samba-4.20.1+dfsg/debian/control samba-4.20.1+dfsg/debian/control
--- samba-4.20.1+dfsg/debian/control2024-05-26 14:33:25.0 +0200
+++ samba-4.20.1+dfsg/debian/control2024-05-28 12:36:04.0 +0200
@@ -203,8 +203,10 @@
 Enhances: bind9, ntp
 Breaks:   samba-ad-provision (<< ${source:Upstream-Version}),
 # files moved from samba & samba-common-bin in 4.20.1-2:
- samba (<< 2:4.20.1+dfsg-2~), samba-common-bin (<< 2:4.20.1+dfsg-2~),
-Replaces: samba (<< 2:4.20.1+dfsg-2~), samba-common-bin (<< 2:4.20.1+dfsg-2~),
+ samba-common-bin (<< 2:4.20.1+dfsg-2~),
+Replaces: samba-common-bin (<< 2:4.20.1+dfsg-2~),
+# Breaks+Replaces upgraded to Conflicts for DEP17 + /usr-move
+Conflicts: samba (<< 2:4.20.1+dfsg-2~),
 Description: Samba control files to run AD Domain Controller
  Samba is an implementation of the SMB/CIFS protocol for Unix systems,
  providing support for cross-platform file and printer sharing with
diff -Nru samba-4.20.1+dfsg/debian/samba-ad-dc.lintian-overrides 
samba-4.20.1+dfsg/debian/samba-ad-dc.lintian-overrides
--- samba-4.20.1+dfsg/debian/samba-ad-dc.lintian-overrides  1970-01-01 
01:00:00.0 +0100
+++ samba-4.20.1+dfsg/debian/samba-ad-dc.lintian-overrides  2024-05-28 
13:37:34.0 +0200
@@ -0,0 +1,3 @@
+# begin-remove-after: trixie
+diversion-for-unknown-file lib/systemd/system/samba-ad-dc.service [preinst:*]
+# end-remove-after
diff -Nru samba-4.20.1+dfsg/debian/samba-ad-dc.postinst 
samba-4.20.1+dfsg/debian/samba-ad-dc.postinst
--- samba-4.20.1+dfsg/debian/samba-ad-dc.postinst   1970-01-01 
01:00:00.0 +0100
+++ samba-4.20.1+dfsg/debian/samba-ad-dc.postinst   2024-05-28 
13:37:30.0 +0200
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+# begin-remove-after: released:trixie
+# protective diversion of files moved from / to /usr, to avoid file loss.
+# Only for upgrades.
+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then
+   dpkg-divert --package #PACKAGE# --no-rename \
+   --divert /lib/systemd/system/samba-ad-dc.service.usr-is-merged \
+   --remove /lib/systemd/system/samba-ad-dc.service
+fi
+# end-remove-after
+
+#DEBHELPER#
+
+exit 0
diff -Nru samba-4.20.1+dfsg/debian/samba-ad-dc.preinst 
samba-4.20.1+dfsg/debian/samba-ad-dc.preinst
--- samba-4.20.1+dfsg/debian/samba-ad-dc.preinst1970-01-01 
01:00:00.0 +0100
+++ samba-4.20.1+dfsg/debian/samba-ad-dc.preinst2024-05-28 
13:36:29.0 +0200
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+# begin-remove-after: released:trixie
+# protective diversion of files moved from / to /usr, to avoid file loss.
+# Only for upgrades.
+if [ "$1" = "upgrade" ] || [ "$1" = "install" ]; then
+   dpkg-divert --package #PACKAGE# --no-rename \
+   --divert /lib/systemd/system/samba-ad-dc.service.usr-is-merged \
+   --add /lib/systemd/system/samba-ad-dc.service
+fi
+# end-remove-after
+
+#DEBHELPER#
+
+exit 0

Bug#1072074: 7zip has an undeclared file conflict

[Helmut Grohne]

Package: 7zip
Version: 24.06+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + p7zip p7zip-full

7zip has an undeclared file conflict. This may result in an unpack error
from dpkg.

The files
 * /usr/bin/7z
 * /usr/bin/7za
are contained in the packages
 * 7zip/24.06+dfsg-1 as present in unstable
 * p7zip-full/16.02+dfsg-8 as present in bookworm|bullseye

The files
 * /usr/bin/7zr
 * /usr/bin/p7zip
are contained in the packages
 * 7zip/24.06+dfsg-1 as present in unstable
 * p7zip/16.02+dfsg-8 as present in bookworm|bullseye

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1072073: python3-proto-plus has an undeclared file conflict on /usr/lib/python3/dist-packages/proto/__init__.py

[Helmut Grohne]

Package: python3-proto-plus
Version: 1.23.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + nanopb

python3-proto-plus has an undeclared file conflict. This may result in
an unpack error from dpkg.

The file /usr/lib/python3/dist-packages/proto/__init__.py is contained
in the packages
 * nanopb
   * 0.4.4-2 as present in bullseye
   * 0.4.7-2 as present in bookworm
   * 0.4.8-1 as present in trixie|unstable
 * python3-proto-plus/1.23.0-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071735: libxmlrpc-util-dev and libxmlrpc-util4 have an undeclared file conflict

[Helmut Grohne]

Package: libxmlrpc-util4,libxmlrpc-util-dev
Version: 1.59.03-2+b1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libxmlrpc-core-c3-dev libxmlrpc-core-c3t64

libxmlrpc-util-dev and libxmlrpc-util4 have an undeclared file conflict.
This may result in an unpack error from dpkg.

The files
 * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.a
 * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.so
are contained in the packages
 * libxmlrpc-core-c3-dev
   * 1.33.14-11 as present in bookworm
   * 1.33.14-9 as present in bullseye
 * libxmlrpc-util-dev/1.59.03-2+b1 as present in unstable

The files
 * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.a
 * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.so
 * /usr/lib/x86_64-linux-gnu/pkgconfig/xmlrpc_util.pc
are contained in the packages
 * libxmlrpc-core-c3-dev/1.59.03-1+b1 as present in trixie
 * libxmlrpc-util-dev/1.59.03-2+b1 as present in unstable

The files
 * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.so.4
 * /usr/lib/x86_64-linux-gnu/libxmlrpc_util.so.4.59
are contained in the packages
 * libxmlrpc-core-c3t64/1.59.03-1+b1 as present in trixie
 * libxmlrpc-util4/1.59.03-2+b1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071734: libsingular4m4n0 has an undeclared file conflict

[Helmut Grohne]

Package: libsingular4m4n0
Version: 1:4.4.0+ds-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libsingular4m3n0t64

libsingular4m4n0 has an undeclared file conflict. This may result in an
unpack error from dpkg.

The files
 * /usr/lib/x86_64-linux-gnu/libsingular-factory-4.4.0.so
 * /usr/lib/x86_64-linux-gnu/libsingular-omalloc-4.4.0+ds+0.9.6.so
 * /usr/lib/x86_64-linux-gnu/libsingular-polys-4.4.0.so
 * /usr/lib/x86_64-linux-gnu/libsingular-resources-4.4.0.so
 * /usr/lib/x86_64-linux-gnu/libsingular-Singular-4.4.0.so
are contained in the packages
 * libsingular4m3n0t64/1:4.4.0+ds-1 as present in trixie|unstable
 * libsingular4m4n0/1:4.4.0+ds-3 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1066632: djbdns: FTBFS: hier.c:10:3: error: implicit declaration of function ‘h’ [-Werror=implicit-function-declaration]

[Helmut Grohne]

Control: tags -1 + patch

On Wed, Mar 13, 2024 at 12:49:27PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

I prepared a patch for another djbdns problem and in that proces also
fixed this FTBFS. You can find the combined patch on #1071526. 

Helmut

Bug#1071244: dracut-install has an undeclared file conflict on /usr/lib/dracut/dracut-install

[Helmut Grohne]

Package: dracut-install
Version: 060+5-7
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + dracut-core

dracut-install has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/lib/dracut/dracut-install is contained in the packages
 * dracut-core/060+5-1 as present in trixie
 * dracut-install/060+5-7 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071243: elfkickers has an undeclared file conflict on /bin/rebind

[Helmut Grohne]

Package: elfkickers
Version: 0+git20240221+ds-2
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + websockify

elfkickers has an undeclared file conflict. This may result in an unpack
error from dpkg.

The file /bin/rebind is contained in the packages
 * elfkickers/0+git20240221+ds-2 as present in unstable
 * websockify
   * 0.10.0+dfsg1-4+b1 as present in bookworm
   * 0.10.0+dfsg1-6 as present in trixie|unstable
   * 0.9.0+dfsg1-3 as present in bullseye

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071242: rust-llvm has an undeclared file conflict

[Helmut Grohne]

Package: rust-llvm
Version: 1.71.1+dfsg1-1~exp2
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + rustc-mozilla rustc-web

rust-llvm has an undeclared file conflict. This may result in an unpack
error from dpkg.

The files
 * /usr/bin/rust-clang
 * /usr/bin/rust-lld
 * /usr/bin/rust-llvm-dwp
 * /usr/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld
 * /usr/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld64
are contained in the packages
 * rust-llvm/1.71.1+dfsg1-1~exp2 as present in experimental
 * rustc-mozilla/1.63.0+dfsg1-2~deb11u1 as present in bullseye
 * rustc-web/1.70.0+dfsg1-7~deb12u2 as present in bookworm-proposed-updates

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071241: elfkickers adds new aliased files when we want to get rid of them

[Helmut Grohne]

Package: elfkickers
Version: 0+git20240221+ds-2
Severity: serious
Justification: keep out of testing
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Hi Alex,

you may know this /usr-move thingy. We want to stop installing aliased
files and your package installs them to /bin via debian/install now.
Please change

bin/*

to

bin/* usr/bin

to help with the transition. I'm setting severity serious to avoid
introducing regressions in trixie.

Helmut

Bug#1071142: dnsmasq-base: fails to purge when passwd is not installed

[Helmut Grohne]

Package: dnsmasq-base
Version: 2.90-3
Severity: serious

When passwd is not installed, dnsmasq-base fails to purge.

| $ mmdebstrap --variant=essential --include=dnsmasq-base 
--customize-hook='dpkg --root "$1" --remove dnsmasq-base passwd' 
--customize-hook='dpkg --root "$1" --purge dnsmasq-base' --verbose unstable 
/dev/null
| ...
| Purging configuration files for dnsmasq-base (2.90-3) ...
| /var/lib/dpkg/info/dnsmasq-base.postrm: 5: userdel: not found
| dpkg: error processing package dnsmasq-base (--purge):
|  installed dnsmasq-base package post-removal script subprocess returned error 
exit status 127
| Errors were encountered while processing:
|  dnsmasq-base
| ...
| $

Arguably, users should not deleted on package removal.

Helmut

Bug#1071125: python3-donfig and python3-nabu have an undeclared file conflict on /usr/lib/python3/dist-packages/doc/conf.py

[Helmut Grohne]

Package: python3-donfig,python3-nabu
Version: 0.8.1+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + python3-nabu

python3-donfig and python3-nabu have an undeclared file conflict. This may
result in an unpack error from dpkg.

The file /usr/lib/python3/dist-packages/doc/conf.py is contained in the
packages
 * python3-donfig/0.8.1+dfsg-2 as present in trixie|unstable
 * python3-nabu/2024.1.6-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1064003: Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Helmut Grohne]

Hi Bastian,

I've intentionally snipped much of your reply as I think we two agree on
many of the aspects.

On Sun, May 12, 2024 at 07:35:09PM +0200, Bastian Blank wrote:
> > 1. API expectation of *-$arch-cross packages
> 
> I asked exactly that in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#55

I guess the best description is to be found in man dpkg-cross
"Conversion process" and even that isn't entirely helpful.

> > 4. cross-toolchain-base being bd-uninstallable
> 
> Which directly correlates to undocumented Build-Conflicts in the
> package.  They neither show up in the changelog or the commit logs.
> 
> >I don't exactly understand why it declares them, but I guess that
> >having a different set of kernel headers available in
> >/usr/$DEB_HOST_GNU_TYPE would cause them to be picked up by the build
> >and potentially cause misbuilds. cross-toolchain-base builds these
> >packages and it also uses them during build of glibc.
> 
> So this reason is now gone.  linux-source-* and linux-libc-dev are
> similar enough in almost all cases.

It's not gone as non-virtual linux-libc-dev-$arch-cross packages are
still built from c-t-b. If c-t-b were to stop building them, I'd concur.

> > 6. Cross bootstrap cannot tell whether linux-libc-dev supports an
> >architecture
> 
> Even in the past it could not.  It could try to build the linux package
> to see if it gets a working linux-libc-dev.  Or have other code to hack
> around, like changing the config.

In the past, there was no need to tell. It would always build
linux-libc-dev. Now that linux-libc-dev works for many but not all
architectures, there is a need to tell.

> Actually linux-libc-dev-$arch-cross is uncommunicated and uncoordinated
> duplication of exactly the same content as linux-libc-dev.

It is news to me that it is uncommunicated and uncoordinated, but that
very accurately matches the rest of the disagreement. Yes, it is
duplication.

> 9. linux-libc-dev-*-cross provides incompatible headers to
>build-essential
> 
>Both linux-libc-dev and linux-libc-dev-*-cross provide the linux/*
>includes that are used by the compiler but of different versions.  It
>is undefined if those can work with the (always older) asm/* provided
>by linux-libc-dev-*-cross.

Yes, this is a problem. It kinda is the same problem that we have with
libc6-dev vs libc6-dev-$arch-cross and is why libc6-dev declares
versioned breaks for libc6-dev-$arch-cross.

> > 3. cross-toolchain-base could build a linux-libc-dev-cross package
> >that Provides the earlier -$arch-cross packages and contains a
> >similar symlink farm to linux-libc-dev.
> 
> This requires coordination of the versions and strict enough
> dependencies.  So linux-libc-dev-cross would need to come out of the
> same source as linux-libc-dev.

Technically speaking, a linux-libc-dev-cross package could be built from
c-t-b. It would just inherit all the other problems including your
problem 9 from the previous approach and only address the space aspect.
I listed it more for completeness sake than suggesting we actually go
for this.

> > 4. cross-toolchain-base could drop its Build-Conflicts. This may cause
> >further problems though.
> >Patch: https://bugs.debian.org/1067370#17
> 
> The build will now see multiple architectures of headers.  So it needs
> to handle this both for native (where build-conflicts can't be used
> anyway) and cross the same.

I don't understand what you are trying to say here. c-t-b only builds
Arch:all packages, so the terms native and cross appear to not apply.
Then again we also don't know what "further problems" are. I hope
Matthias can shed some light here.

> On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote:
> > 2+3+6+7. linux-libc-dev could be split into linux-libc-dev-common
> >arch:all m-a:foreign and the symlink farms could be kept in
> >linux-libc-dev:any m-a:same retaining the size reduction.
> 
> This would not actually work.  linux-libc-dev-common would only contain
> known architectures.  So the current "change config, build
> linux-libc-dev" will not longer work as well.  This package would then
> depend on a linux-libc-dev-common without the headers for this
> architecture.

I agree that it is not as simple as I pictured it. I was imagining that
a m-a:same linux-libc-dev could simply contain all the
architecture-dependent stuff. For many architectures that would
practically work initially, but there is no bijective mapping between
kernel architecture names and Debian architecture names, so for
directories like /usr/lib/linux/uapi/arm is is unclear whether it should
be part of linux-libc-dev:armel or linux-libc-dev:armhf or
linux-li

Bug#1071010: pcp has an undeclared file conflict on /usr/bin/pmcheck

[Helmut Grohne]

Package: pcp
Version: 6.2.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + pmtools

pcp has an undeclared file conflict. This may result in an unpack error
from dpkg.

The file /usr/bin/pmcheck is contained in the packages
 * pcp/6.2.1-1 as present in unstable
 * pmtools
   * 2.2.0-2 as present in bullseye
   * 2.2.0-3 as present in bookworm|trixie|unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071008: libx52pro0: installs udev rules twice to /usr and /

[Helmut Grohne]

Package: libx52pro0
Version: 0.1.1-3
Severity: serious
Justification: policy 10.1
Tags: patch
X-Debbugs-Cc: Petter Reinholdtsen 

Hi,

since the last upload, libx52pro0 contains both
/lib/udev/rules.d/99-x52pro.rules and
/usr/lib/udev/rules.d/99-x52pro.rule. Doing so violates Debian policy
section 10.1. The former is installed via the upstream build system
combined with dh_install and debian/libx52pro0.install while the latter
is installed via debian/*.udev with dh_installudev. Given DEP17, the
latter is the desired location. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru x52pro-0.1.1/debian/changelog x52pro-0.1.1/debian/changelog
--- x52pro-0.1.1/debian/changelog   2024-05-12 10:39:38.0 +0200
+++ x52pro-0.1.1/debian/changelog   2024-05-12 22:59:37.0 +0200
@@ -1,3 +1,9 @@
+x52pro (0.1.1-4) UNRELEASED; urgency=medium
+
+  * Install udev rules only once. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 12 May 2024 22:59:37 +0200
+
 x52pro (0.1.1-3) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru x52pro-0.1.1/debian/libx52pro0.install 
x52pro-0.1.1/debian/libx52pro0.install
--- x52pro-0.1.1/debian/libx52pro0.install  2024-05-12 10:14:01.0 
+0200
+++ x52pro-0.1.1/debian/libx52pro0.install  2024-05-12 22:59:36.0 
+0200
@@ -1,4 +1,3 @@
-lib/udev/rules.d
 usr/bin/x52output
 usr/lib/lib*.so.*
 usr/share/man
diff --minimal -Nru x52pro-0.1.1/debian/not-installed 
x52pro-0.1.1/debian/not-installed
--- x52pro-0.1.1/debian/not-installed   1970-01-01 01:00:00.0 +0100
+++ x52pro-0.1.1/debian/not-installed   2024-05-12 22:59:37.0 +0200
@@ -0,0 +1,2 @@
+# Installed via debian/*.udev symbolic link
+lib/udev/rules.d

Bug#1071009: libpoppler-cpp0t64 has an undeclared file conflict

[Helmut Grohne]

Package: libpoppler-cpp0t64
Version: 24.02.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libpoppler-cpp0v5

libpoppler-cpp0t64 has an undeclared file conflict. This may result in
an unpack error from dpkg.

The files
 * /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0
 * /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.11.0
are contained in the packages
 * libpoppler-cpp0t64/24.02.0-3 as present in unstable
 * libpoppler-cpp0v5/22.12.0-2+b1 as present in bookworm

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071007: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py

[Helmut Grohne]

Package: sherlock
Version: 0.14.3+git20240511.b83f5be-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + pycrc

sherlock has an undeclared file conflict. This may result in an unpack
error from dpkg.

The file /usr/lib/python3/dist-packages/__init__.py is contained in the
packages
 * pycrc/0.10.0-2 as present in trixie|unstable
 * sherlock/0.14.3+git20240511.b83f5be-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071006: conky-all, conky-cli and conky-std have an undeclared file conflict

[Helmut Grohne]

Package: conky-cli,conky-std,conky-all
Version: 1.21.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + vc-dev

conky-all, conky-cli and conky-std have an undeclared file conflict.
This may result in an unpack error from dpkg.

The files
 * /usr/lib/cmake/Vc/AddCompilerFlag.cmake
 * /usr/lib/cmake/Vc/CheckCCompilerFlag.cmake
 * /usr/lib/cmake/Vc/CheckCXXCompilerFlag.cmake
 * /usr/lib/cmake/Vc/FindVc.cmake
 * /usr/lib/cmake/Vc/OptimizeForArchitecture.cmake
 * /usr/lib/cmake/Vc/UserWarning.cmake
 * /usr/lib/cmake/Vc/VcConfig.cmake
 * /usr/lib/cmake/Vc/VcConfigVersion.cmake
 * /usr/lib/cmake/Vc/VcMacros.cmake
 * /usr/lib/cmake/Vc/VcTargets.cmake
 * /usr/lib/libVc.a
are contained in the packages
 * conky-all/1.21.0-1 as present in unstable
 * conky-cli/1.21.0-1 as present in unstable
 * conky-std/1.21.0-1 as present in unstable
 * vc-dev
   * 1.4.3-2 as present in bookworm
   * 1.4.4-1 as present in trixie|unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1071005: rust-llvm has an undeclared file conflict

[Helmut Grohne]

Package: rust-llvm
Version: 1.71.1+dfsg1-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + rustc rustc-mozilla rustc-web

rust-llvm has an undeclared file conflict. This may result in an unpack
error from dpkg.

The files
 * /usr/bin/rust-clang
 * /usr/bin/rust-lld
 * /usr/bin/rust-llvm-dwp
 * /usr/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld
 * /usr/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld64
are contained in the packages
 * rust-llvm/1.71.1+dfsg1-1~exp1 as present in experimental
 * rustc
   * 1.63.0+dfsg1-2 as present in bookworm
   * 1.70.0+dfsg2-1 as present in trixie|unstable
 * rustc-mozilla/1.63.0+dfsg1-2~deb11u1 as present in bullseye
 * rustc-web/1.70.0+dfsg1-7~deb12u2 as present in bookworm-proposed-updates

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1064003: Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Helmut Grohne]

Hi,

In this mail, I'll try to summarize my state of knowledge on this
matter while noting that I don't see the full picture.

On Fri, Mar 29, 2024 at 11:17:55AM +0100, Bastian Blank wrote:
> On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote:
> > I was recently working on gcc builds and this disagreement currently
> > makes stuff unbuildable. Hence I looked into solutions and/or
> > workarounds.
> 
> Care to just share what you actually found?  Where is it broken and how
> to see this?
> 
> Because this whole thing started with "it is broken, but I won't tell
> you where or what or how".

Quite clearly, this is not a single problem, but a mesh of problems and
in a few cases it is not obvious where to solve them.

> > As a result, I implemented the proposed change and am attaching it for
> > discussion here. I've implemented it in a way that if there is a sysroot
> > linux header installation, it'll be preferred. Do you see any downsides
> > of this approach?
> 
> I wonder now.  How would that ever work for the native build?  Or does
> the native build already do those symlinks?  Or are native and cross
> configured differently?  Or is that a weird difference in gcc itself?

Native and cross builds work quite differently indeed.

So let me first try to collect all relevant problems that I encountered
here. I vaguely try to list the more important ones earlier. I have
caused some of these problems and don't want to assign any blame but
look for solutions.

1. API expectation of *-$arch-cross packages

   When *-$arch-cross packages were first introduced before multiarch
   was a thing, there was (and still is) and implicit contract saying
   that their functionality is to be provided within the
   /usr/$DEB_HOST_GNU_TYPE hierarchy. In particular, this layout does
   not interfere with multiarch on a filesystem level and hence
   *-$arch-cross packages typically are arch:all m-a:foreign.

   In particular, linux-libc-dev now provides such packages without
   actually providing those paths violating this implicit contract.

2. Violation of Multi-Arch: foreign

   linux-libc-dev was changed from an Arch:any + Multi-Arch:same package
   to an Architecture:all + Multi-Arch:foreign package. It does so by
   providing the headers for all architectures in a single package via
   symlink farms. "all" architectures is debatable though. The set of
   architectures changes rather frequently with new ones being added and
   old ones being removed. Therefore, linux-libc-dev will often look
   like it provides linux-libc-dev:$somearch to dependency resolvers
   while in fact not providing the functionality - thus violating the
   promise of Multi-Arch: foreign. For example, linux-libc-dev is
   currently dysfunctional for arc, but next year it'll be a different
   architecture.

   Moreover, looking at the metadata of linux-libc-dev initially did not
   provide means of figuring out which architectures were actually
   supported and which were not. This has been changed as linux-libc-dev
   now Provides linux-libc-dev-$arch-cross packages (causing the first
   problem), but at least giving bootstrappers a means to figure out
   whether a given linux-libc-dev package is usable to them.

3. linux-libc-dev consumes much space on mirrors and installations

   linux-libc-dev originally was Arch:any and yet much of its content
   was the same across architectures albeit in different paths. Thus,
   the size of the .deb (multiplied by the number of architectures) was
   quite big and also coinstalling linux-libc-dev would result in
   duplicate files being extracted to multiple locations increasing the
   installation size in a multiarch setting.

   As a result, linux-libc-dev now is Arch:all and we only get to have
   one package. It grew from about 1.8MB (times 10 architectures) to
   about 2.2MB and its installed size grew from about 7MB (per
   architecture) to 10MB (for all architectures).

   This change caused the second problem.

4. cross-toolchain-base being bd-uninstallable

   cross-toolchain-base cannot currently be built (FTBFS #1064003 and
   #1067370) and one of the aspects is that it declares Build-Conflicts
   with linux-libc-dev-$arch-cross. The recently added Provides on
   linux-libc-dev satisfy them and thus cause cross-toolchain-base to be
   bd-uninstallable.

   I don't exactly understand why it declares them, but I guess that
   having a different set of kernel headers available in
   /usr/$DEB_HOST_GNU_TYPE would cause them to be picked up by the build
   and potentially cause misbuilds. cross-toolchain-base builds these
   packages and it also uses them during build of glibc.

5. gcc-V-cross not being buildable

   The gcc-V-cross package relies on -$arch-cross packages usually built
   from cross-toolchain-base and expects them to provide their
   functionality in /usr/$DEB_HOST_GNU_TYPE. Th

Bug#1064003: patch for c-t-b build

[Helmut Grohne]

Control: tags -1 + patch

Hi Matthias,

I'm attaching a patch for the c-t-b FTBFS. Note that due to the
glibc/2.38 upload c-t-b has become completely uninstallable. Hence, a
timely upload is appreciated. Due to linux-libc-dev currently providing
the -$arch-cross packages, we have to remove the Build-Conflicts or make
rename the Provides on linux-libc-dev. I'm ok with both approaches and
offer dropping the conflict here.

Helmut
diff --minimal -Nru cross-toolchain-base-68/debian/changelog 
cross-toolchain-base-68+nmu1/debian/changelog
--- cross-toolchain-base-68/debian/changelog2023-10-31 09:50:26.0 
+0100
+++ cross-toolchain-base-68+nmu1/debian/changelog   2024-05-04 
09:23:39.0 +0200
@@ -1,3 +1,12 @@
+cross-toolchain-base (68+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build using linux 6.7. Closes: #1064003, #1067370.
+  * Build using glibc 2.38.
+  * Remove linux-libc-dev-ARCH-cross from GLIBC_BUILD_CONFLICTS.
+
+ -- Helmut Grohne   Sat, 04 May 2024 09:23:39 +0200
+
 cross-toolchain-base (68) unstable; urgency=medium
 
   * Build using linux 6.5.8. Closes: #1042118.
diff --minimal -Nru cross-toolchain-base-68/debian/control 
cross-toolchain-base-68+nmu1/debian/control
--- cross-toolchain-base-68/debian/control  2023-10-31 09:50:26.0 
+0100
+++ cross-toolchain-base-68+nmu1/debian/control 2024-05-04 09:23:39.0 
+0200
@@ -9,9 +9,9 @@
 Build-Depends: binutils-multiarch,
   dpkg (>= 1.21.17), rdfind, symlinks, lsb-release,
   binutils-source (>= 2.41-6~),
-  glibc-source (>= 2.37-3~),
+  glibc-source (>= 2.38),
   gcc-12-source (>= 12.3.0-11~), g++-12 (>= 12.3.0-11~),
-  linux-source-6.5 (>= 6.5.8), linux-libc-dev (>= 6.5.8),
+  linux-source-6.7 (>= 6.7.0), linux-libc-dev (>= 6.7.0),
   autoconf (>= 2.69), autoconf2.69, autogen,
   automake, bison (>= 1:2.3), chrpath, debhelper-compat (= 13),
   dpkg-dev (>= 1.15.3.1), fakeroot, file, flex,
@@ -27,7 +27,7 @@
   libjansson-dev, pkg-config,
 Build-Conflicts: dpkg-cross, libdebian-dpkgcross-perl,
   binutils-x86-64-linux-gnu [!amd64], binutils-i686-linux-gnu [!i386], 
binutils-s390x-linux-gnu [!s390x], binutils-powerpc64le-linux-gnu [!ppc64el], 
binutils-aarch64-linux-gnu [!arm64], binutils-arm-linux-gnueabihf [!armhf], 
binutils-arm-linux-gnueabi [!armel], binutils-riscv64-linux-gnu [!riscv64],
-  libc6-amd64-cross, linux-libc-dev-amd64-cross, libc6-i386-cross, 
linux-libc-dev-i386-cross, libc6-s390x-cross, linux-libc-dev-s390x-cross, 
libc6-ppc64el-cross, linux-libc-dev-ppc64el-cross, libc6-arm64-cross, 
linux-libc-dev-arm64-cross, libc6-armhf-cross, linux-libc-dev-armhf-cross, 
libc6-armel-cross, linux-libc-dev-armel-cross, libc6-riscv64-cross, 
linux-libc-dev-riscv64-cross,
+  libc6-amd64-cross, libc6-i386-cross, libc6-s390x-cross, libc6-ppc64el-cross, 
libc6-arm64-cross, libc6-armhf-cross, libc6-armel-cross, libc6-riscv64-cross,
   libc6-amd64 [i386 x32], libc6-i386 [amd64 x32], libc6-x32 [amd64 i386]
 
 Package: linux-libc-dev-amd64-cross
diff --minimal -Nru cross-toolchain-base-68/debian/rules 
cross-toolchain-base-68+nmu1/debian/rules
--- cross-toolchain-base-68/debian/rules2023-10-31 09:50:26.0 
+0100
+++ cross-toolchain-base-68+nmu1/debian/rules   2024-05-04 09:23:39.0 
+0200
@@ -61,8 +61,8 @@
 CROSS_GNU_TYPE   = $(call _gnu_type,${CROSS_ARCH})
 CROSS_PKG_GNU_TYPE = $(subst _,-,$(call _gnu_type,${CROSS_ARCH}))
 
-MIN_VER_GLIBC  := 2.37-3~
-MIN_VER_LINUX  := 6.5.8
+MIN_VER_GLIBC  := 2.38
+MIN_VER_LINUX  := 6.7.0
 MIN_VER_GCC:= 12.3.0-11~
 MIN_VER_BINUTILS   := 2.41-6~
 VER_GCC_BASE   := 12
@@ -110,7 +110,7 @@
 
 # FIXME: No conflict for the host == cross case ...
 BINUTILS_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),binutils-$(subst 
_,-,$(call _gnu_type,$(a))) [!$(a)]$(,))
-GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,) 
linux-libc-dev-$(a)-cross$(,))
+GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,))
 
 # taken from gcc packaging
 define unpack_tarball

Bug#1070327: libauparse0t64 fails piuparts: missing postrm for /usr-move mitigation

[Helmut Grohne]

Source: audit
Version: 1:3.1.2-2.1
Severity: serious
Justification: fails piuparts, blocks testing migration
Tags: patch
X-Debbugs-Cc: z...@debian.org

Hi,

I looked into why audit fails to migrate and noticed that it fails
piuparts as it leaves diversions behind after purge. The patch provided
by the /usr-move team failed to account for package removal and lacks
the postrm bit. I'm attaching a patch that fixes this problem. It also
removes the manual interpolation in favour of relying on dh_installdeb's
builtin interpolation. I'd appreciate a timely upload, because audit is
one of the last missing pieces moving forward with the /usr-move. Would
you mind a NMU?

Helmut
diff --minimal -Nru audit-3.1.2/debian/changelog audit-3.1.2/debian/changelog
--- audit-3.1.2/debian/changelog2024-02-28 04:02:13.0 +0100
+++ audit-3.1.2/debian/changelog2024-05-03 07:49:46.0 +0200
@@ -1,3 +1,10 @@
+audit (1:3.1.2-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix piuparts failure arising from /usr-move mitigation. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 03 May 2024 07:49:46 +0200
+
 audit (1:3.1.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.lintian-overrides 
audit-3.1.2/debian/libauparse0t64.lintian-overrides
--- audit-3.1.2/debian/libauparse0t64.lintian-overrides 2024-02-28 
03:58:37.0 +0100
+++ audit-3.1.2/debian/libauparse0t64.lintian-overrides 2024-05-03 
07:49:46.0 +0200
@@ -1 +1,2 @@
 libauparse0t64: package-name-doesnt-match-sonames libauparse0
+libauparse0t64: remove-of-unknown-diversion lib/* [postrm:*]
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.postrm 
audit-3.1.2/debian/libauparse0t64.postrm
--- audit-3.1.2/debian/libauparse0t64.postrm1970-01-01 01:00:00.0 
+0100
+++ audit-3.1.2/debian/libauparse0t64.postrm2024-05-03 07:49:40.0 
+0200
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+set -e
+
+case $1 in
+   remove|disappear)
+   for file in libauparse.so.0 libauparse.so.0.0.0; do
+   dpkg-divert --package libauparse0t64 --no-rename \
+   --remove --divert \
+   "/lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged" 
\
+   "/lib/#DEB_HOST_MULTIARCH#/$file"
+   done
+   ;;
+esac
+
+#DEBHELPER#
+
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.preinst 
audit-3.1.2/debian/libauparse0t64.preinst
--- audit-3.1.2/debian/libauparse0t64.preinst   1970-01-01 01:00:00.0 
+0100
+++ audit-3.1.2/debian/libauparse0t64.preinst   2024-05-03 07:49:46.0 
+0200
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+set -e
+
+case $1 in
+   install)
+   for file in libauparse.so.0 libauparse.so.0.0.0; do
+   dpkg-divert --package libauparse0t64 --no-rename \
+   --add --divert \
+   "/lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged" 
\
+   "/lib/#DEB_HOST_MULTIARCH#/$file"
+   done
+   ;;
+esac
+
+#DEBHELPER#
+
diff --minimal -Nru audit-3.1.2/debian/libauparse0t64.preinst.in 
audit-3.1.2/debian/libauparse0t64.preinst.in
--- audit-3.1.2/debian/libauparse0t64.preinst.in2024-02-28 
04:02:11.0 +0100
+++ audit-3.1.2/debian/libauparse0t64.preinst.in1970-01-01 
01:00:00.0 +0100
@@ -1,17 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case $1 in
-   install)
-   for file in libauparse.so.0 libauparse.so.0.0.0; do
-   dpkg-divert --package libauparse0t64 --no-rename \
-   --divert \
-   /lib/#DEB_HOST_MULTIARCH#/$file.usr-is-merged \
-   /lib/#DEB_HOST_MULTIARCH#/$file
-   done
-   ;;
-esac
-
-#DEBHELPER#
-
diff --minimal -Nru audit-3.1.2/debian/rules audit-3.1.2/debian/rules
--- audit-3.1.2/debian/rules2024-02-28 04:02:11.0 +0100
+++ audit-3.1.2/debian/rules2024-05-03 07:47:04.0 +0200
@@ -109,11 +109,6 @@
chgrp adm debian/auditd/var/log/audit
chmod -R o-rwx debian/auditd/etc/audit debian/audispd-plugins/etc/audit
 
-override_dh_installdeb:
-   sed -e"s/#DEB_HOST_MULTIARCH#/$(DEB_HOST_MULTIARCH)/" \
-   debian/libauparse0t64.preinst.in > debian/libauparse0t64.preinst
-   dh_installdeb
-
 get-orig-source:
-uscan --upstream-version 0
 

Bug#1070256: libcxx-serial FTBFS with the nocheck build profile

[Helmut Grohne]

Source: libcxx-serial
Version: 1.2.1-5
Severity: serious
Justification: nocheck ftbfs is rc since trixie
Tags: ftbfs trixie sid

libcxx-serial fails to build from source when enabling the nocheck build
profile. I think the relevant part is:

| -- catkin 0.8.10
| -- BUILD_SHARED_LIBS is on
| CMake Error at /usr/share/catkin/cmake/test/tests.cmake:21 (message):
|   () is not available when tests are not enabled.  The CMake code should only
|   use it inside a conditional block which checks that testing is enabled:
| 
|   if(CATKIN_ENABLE_TESTING)
| 
| (...)
| 
|   endif()
| 
| Call Stack (most recent call first):
|   tests/CMakeLists.txt:20 (catkin_add_gtest)
| 
| 
| -- Configuring incomplete, errors occurred!
| cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
| ==> CMakeCache.txt <==

Helmut

Bug#1070254: ktp-text-ui FTBFS: undefined reference to `snappy::RawCompress(char const*, unsigned long, char*, unsigned long*)'

[Helmut Grohne]

ll] 
Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[1]: *** [Makefile:149: all] Error 2
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j8 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
| make: *** [debian/rules:4: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Helmut

Bug#1070047: python3-django-pipeline: installs files into aliased locations

[Helmut Grohne]

Control: tags -1 - patch

Hi Alexandre,

On Mon, Apr 29, 2024 at 12:35:02PM +0200, Alexandre Detiste wrote:
> If I revert the NAME change autodep8 breaks on Salsa

Dang. I was looking for what I could have broken and didn't see this.

> Is there an easy way to have one name for pybuild and another one for
> autodep8 ... ? I ll search.

I looked at man pybuild and https://wiki.debian.org/Python/Pybuild and
neither was particularly enlightening to me. Possibly setting
PYBUILD_NAME=pipeline and PYBUILD_DESTDIR=debian/python3-django-pipeline
works?

Helmut

Bug#1070047: python3-django-pipeline: installs files into aliased locations

[Helmut Grohne]

Package: python3-django-pipeline
Version: 3.0.0-1
Severity: serious
Justification: introduces new aliasing
Tags: patch
Control: affects -1 + python3-distutils
User: helm...@debian.org
Usertags: dep17p6

The last upload of python3-django-pipeline moved all of its files from
/usr/lib to /lib. Whils this works somewhat on a /usr-merged
installations, it causes subtle bugs due to dpkg not being prepared with
aliasing. In DEP17, we're resolving this by moving all files out of
aliased locations and python3-django-pipelines has just introduced new.
Hence, I'm filing this at RC severity. I think the move was accidental
and can be fixed by dropping the faulty "mv" command in favour of
setting PYBUILD_NAME to the package name rather than the module name.
I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru django-pipeline-3.0.0/debian/changelog 
django-pipeline-3.0.0/debian/changelog
--- django-pipeline-3.0.0/debian/changelog  2024-04-28 19:35:05.0 
+0200
+++ django-pipeline-3.0.0/debian/changelog  2024-04-29 10:17:13.0 
+0200
@@ -1,3 +1,10 @@
+django-pipeline (3.0.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not install into /lib. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Apr 2024 10:17:13 +0200
+
 django-pipeline (3.0.0-1) unstable; urgency=medium
 
   * Team Upload
diff --minimal -Nru django-pipeline-3.0.0/debian/rules 
django-pipeline-3.0.0/debian/rules
--- django-pipeline-3.0.0/debian/rules  2024-04-28 19:35:05.0 +0200
+++ django-pipeline-3.0.0/debian/rules  2024-04-29 10:17:13.0 +0200
@@ -4,7 +4,7 @@
 include /usr/share/dpkg/pkg-info.mk
 export SETUPTOOLS_SCM_PRETEND_VERSION=${DEB_VERSION_UPSTREAM}
 
-export PYBUILD_NAME=pipeline
+export PYBUILD_NAME=django-pipeline
 export PYBUILD_AFTER_BUILD_python3=PYTHONPATH=. sphinx-build -b html -d 
docs/.build/.doctrees -N docs docs/.build/html
 
 # Uncomment this to turn on verbose mode.
@@ -25,6 +25,5 @@
PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="PYTHONPATH=. python{version} 
/usr/bin/django-admin test --settings=tests.settings" dh_auto_test
 
 execute_after_dh_auto_install:
-   mv debian/python3-pipeline/* debian/python3-django-pipeline/
find -type f -name '*.pyc' -delete
find -type d -name __pycache__ -empty -delete

Bug#1069923: util-linux-extra: /usr-move mitigation fails to cover ctrlaltdel

[Helmut Grohne]

Package: util-linux-extra
Version: 2.40-7
Severity: serious
Tags: patch
Control: affects -1 + util-linux
User: helm...@debian.org
Usertags: dep17p1

Hi Chris,

in my last patch, I trusted your earlier changes too much and failed to
notice that it didn't cover ctrlaltdel. I'm attaching a patch to also
cover that.

Helmut
diff --minimal -Nru util-linux-2.40/debian/changelog 
util-linux-2.40/debian/changelog
--- util-linux-2.40/debian/changelog2024-04-26 11:41:02.0 +0200
+++ util-linux-2.40/debian/changelog2024-04-27 08:46:20.0 +0200
@@ -1,3 +1,10 @@
+util-linux (2.40-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Also cover ctrlaltdel in /usr-move mitigation (Closes: #-1).
+
+ -- Helmut Grohne   Sat, 27 Apr 2024 08:46:20 +0200
+
 util-linux (2.40-7) unstable; urgency=medium
 
   [ Chris Hofstaedtler ]
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.lintian-overrides 
util-linux-2.40/debian/util-linux-extra.lintian-overrides
--- util-linux-2.40/debian/util-linux-extra.lintian-overrides   2024-04-26 
11:41:02.0 +0200
+++ util-linux-2.40/debian/util-linux-extra.lintian-overrides   1970-01-01 
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-# DEP17 P1 mitigation
-diversion-for-unknown-file sbin/* [preinst:*]
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.postrm 
util-linux-2.40/debian/util-linux-extra.postrm
--- util-linux-2.40/debian/util-linux-extra.postrm  2024-04-26 
11:41:02.0 +0200
+++ util-linux-2.40/debian/util-linux-extra.postrm  2024-04-27 
08:46:12.0 +0200
@@ -3,11 +3,9 @@
 set -e
 
 if test "$1" = remove || test "$1" = disappear; then
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.cramfs.usr-is-merged --remove /sbin/fsck.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.minix.usr-is-merged --remove /sbin/fsck.minix
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.bfs.usr-is-merged --remove /sbin/mkfs.bfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.cramfs.usr-is-merged --remove /sbin/mkfs.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.minix.usr-is-merged --remove /sbin/mkfs.minix
+  for f in ctrlaltdel fsck.cramfs fsck.minix mkfs.bfs mkfs.cramfs mkfs.minix; 
do
+dpkg-divert --no-rename --package util-linux-extra --divert 
"/sbin/$f.usr-is-merged" --remove "/sbin/$f"
+  done
 fi
 
 #DEBHELPER#
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.preinst 
util-linux-2.40/debian/util-linux-extra.preinst
--- util-linux-2.40/debian/util-linux-extra.preinst 2024-04-26 
11:41:02.0 +0200
+++ util-linux-2.40/debian/util-linux-extra.preinst 2024-04-27 
08:45:19.0 +0200
@@ -3,11 +3,9 @@
 set -e
 
 if test "$1" = upgrade || test "$1" = install; then
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.cramfs.usr-is-merged --add /sbin/fsck.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.minix.usr-is-merged --add /sbin/fsck.minix
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.bfs.usr-is-merged --add /sbin/mkfs.bfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.cramfs.usr-is-merged --add /sbin/mkfs.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.minix.usr-is-merged --add /sbin/mkfs.minix
+  for f in ctrlaltdel fsck.cramfs fsck.minix mkfs.bfs mkfs.cramfs mkfs.minix; 
do
+dpkg-divert --no-rename --package util-linux-extra --divert 
"/sbin/$f.usr-is-merged" --add "/sbin/$f"
+  done
 fi
 
 #DEBHELPER#

Bug#1069064: util-linux-extra: insufficient Replaces for util-linux due to /usr-move

[Helmut Grohne]

Control: tags -1 + patch

Hi Chris,

On Tue, Apr 16, 2024 at 09:44:13AM +0200, Chris Hofstaedtler wrote:
> I think half of 2) exists now, but Conflicts: util-linux will
> probably end badly as you note. I'd welcome a patch implementing 3).
> 
> Initially I favored 1), but then u-l will never make progress on
> moving the non-essential files.

Thanks for pinging me. I observe that util-linux-extra already had
mitigations except that preinst and postinst were swapped. Additionally,
it did not have Conflicts, which allow for unpacking an aliased
util-linux concurrently with a moved util-linux-extra despite the
protective diversions being removed. Since we want to avoid the
Conflicts, I've extended the protective diversions until postrm. In
trixie's postinst we can then remove them for good. Unfortunately, that
also means that we cannot use begin-remove-after magic.

Helmut
diff --minimal -Nru util-linux-2.40/debian/changelog 
util-linux-2.40/debian/changelog
--- util-linux-2.40/debian/changelog2024-04-15 09:51:01.0 +0200
+++ util-linux-2.40/debian/changelog2024-04-26 07:32:56.0 +0200
@@ -1,3 +1,10 @@
+util-linux (2.40-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix /usr-move mitigation. (Closes: #1069064)
+
+ -- Helmut Grohne   Fri, 26 Apr 2024 07:32:56 +0200
+
 util-linux (2.40-6) unstable; urgency=medium
 
   * Add upstream patches fixing enosys on m68k, sh and dmesg -H output
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.lintian-overrides 
util-linux-2.40/debian/util-linux-extra.lintian-overrides
--- util-linux-2.40/debian/util-linux-extra.lintian-overrides   1970-01-01 
01:00:00.0 +0100
+++ util-linux-2.40/debian/util-linux-extra.lintian-overrides   2024-04-26 
07:32:56.0 +0200
@@ -0,0 +1,2 @@
+# DEP17 P1 mitigation
+diversion-for-unknown-file sbin/* [preinst:*]
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.postinst 
util-linux-2.40/debian/util-linux-extra.postinst
--- util-linux-2.40/debian/util-linux-extra.postinst2024-04-15 
09:51:01.0 +0200
+++ util-linux-2.40/debian/util-linux-extra.postinst1970-01-01 
01:00:00.0 +0100
@@ -1,15 +0,0 @@
-#!/bin/sh
-
-set -e
-
-# begin-remove-after: released:trixie
-if test "$1" = upgrade || test "$1" = install; then
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.cramfs.usr-is-merged --add /sbin/fsck.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.minix.usr-is-merged --add /sbin/fsck.minix
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.bfs.usr-is-merged --add /sbin/mkfs.bfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.cramfs.usr-is-merged --add /sbin/mkfs.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.minix.usr-is-merged --add /sbin/mkfs.minix
-fi
-# end-remove-after
-
-#DEBHELPER#
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.postrm 
util-linux-2.40/debian/util-linux-extra.postrm
--- util-linux-2.40/debian/util-linux-extra.postrm  1970-01-01 
01:00:00.0 +0100
+++ util-linux-2.40/debian/util-linux-extra.postrm  2024-04-26 
07:32:56.0 +0200
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+if test "$1" = remove || test "$1" = disappear; then
+  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.cramfs.usr-is-merged --remove /sbin/fsck.cramfs
+  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.minix.usr-is-merged --remove /sbin/fsck.minix
+  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.bfs.usr-is-merged --remove /sbin/mkfs.bfs
+  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.cramfs.usr-is-merged --remove /sbin/mkfs.cramfs
+  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.minix.usr-is-merged --remove /sbin/mkfs.minix
+fi
+
+#DEBHELPER#
+
diff --minimal -Nru util-linux-2.40/debian/util-linux-extra.preinst 
util-linux-2.40/debian/util-linux-extra.preinst
--- util-linux-2.40/debian/util-linux-extra.preinst 2024-04-15 
09:51:01.0 +0200
+++ util-linux-2.40/debian/util-linux-extra.preinst 2024-04-26 
07:32:56.0 +0200
@@ -2,15 +2,12 @@
 
 set -e
 
-# begin-remove-after: released:trixie
-if test "$1" = configure; then
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.cramfs.usr-is-merged --remove /sbin/fsck.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/fsck.minix.usr-is-merged --remove /sbin/fsck.minix
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.bfs.usr-is-merged --remove /sbin/mkfs.bfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.cramfs.usr-is-merged --remove /sbin/mkfs.cramfs
-  dpkg-divert --no-rename --package util-linux-extra --divert 
/sbin/mkfs.minix.usr-is

Bug#1069815: wesnoth-1.8-server: new package installs systemd unit in aliased location

[Helmut Grohne]

Package: wesnoth-1.18-server
Version: 1:1.17.26-1
Severity: serious
Justification: do not introduce aliased files into Debian

Hi,

I noticed that wesnoth-1.18-server is a new package and installs a file
below /lib, which is an aliased location that we try to empty to
complete the /usr-move transition via DEP17. I am filing this bug at
RC-severity to stop it from migrating to trixie and hope you agree with
this. Please downgrade if you disagree though note that this kind of
issue will become an RC-bug for all packages later in the trixie cycle.

The simplest fix to this problem is changing

SYSTEMD_SERVICE = 
debian/wesnoth-$(BRANCH_VERSION)-server/lib/systemd/system/wesnoth-$(BRANCH_VERSION)-server.service

in debian/rules and move the file to /usr/lib. This is mostly safe for
backports, except that bookworm's debhelper will fail to generate
necessary maintainer scripts. Please bump your debhelper dependency to
13.11.6 (available in bookworm-backports).

Alternatively, adding dh-sequence-movetousr to Build-Depends should also
resolve the matter, but for a new package I'd prefer to fix this right
from the start.

Both solutions are likely applicable to other wesnoth versions as well,
though we don't consider those RC-bugs yet.

Helmut

Bug#1069687: librust-bitflags-1-dev: fails to co-install

[Helmut Grohne]

Hi Matthias,

On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote:
> This is the same situation as in #1040477. This is an issue wrt how we
> generate the semvers. I image rust-proc-macro-crate-1 would pose the same
> problem. Quoting you from 1040477:

Right!

> Is the only workaround dropping Ma:same here ?

I see very little alternatives. We must choose:

 * Do not combine M-A:same + Provides: foo + Breaks: foo.
 * Fix dose/apt/dpkg to agree on what this means.

If we were to adapt dose and apt, they's simply arrive at the conclusion
that M-A:same would not work here so that really is not what you'd want
here. This amounts to fixing dpkg to allow this very combination in the
same way that apt and dose allow it. So yeah, changing dpkg could be an
option. Ccing dpkg-devel about it.

The first alternative means that we must not combine them at the same
time. As we very much want M-A:same, we must not have this combination
of Provides and Brekas. Keep in mind that they serve slightly different
purposes. We have Breaks + Replaces and you can only replace a real
package but Provides introduce a virtual package. In effect we're
dealing with a package that sometimes is virtual and other times is
real. We can choose different names for these uses. The real package
could be renamed and also provide the virtual facility. All of them
would now provide the virtual one as virtual only and none of them would
have the virtual name. The Breaks and Replaces would be updated to match
the real name.

This may not work for the in-archive situations right now as Breaks and
Replaces may still be necessary for upgrades, but it is something that
may work in future situations of the same kind.

In the mean time, consider that M-A:same presently is a lie. Removing it
is better than continuing to lie. It's not like we must have everything
in perfect multiarch. Even for cross compilation, we often can get away
without M-A:same by only requiring a package for the host architecture.
M-A:same is not the goal. It's a tool and way may consider using other
tools.

Helmut

Bug#1069689: mandos lost mandos.service systemd unit

[Helmut Grohne]

Source: mandos
Version: 1.8.16-1.1
Severity: serious
Tags: patch
Justification: prevent testing migration after unintentional deletion of 
systemd unit
X-Debbugs-Cc: Bastian Germann 
User: helm...@debian.org
Usertags: dep17p6

The last mandos upload is the first after systemd.pc having moved
systemdsystemunitdir from /lib to /usr/lib. mandos' upstream Makefile
uses this to see where to install units to, but it also only does that
if the relevant directory exists. Now since the new location wasn't
created, it ceased installing the unit. We need to create the new
location to reinstate the unit. Patch attached. I think the loss of the
unit is unintantional and for that reason file this as rc bug. Please
adjust if you disagree.

This change makes mandos backports-unsafe. I don't expect mandos to be
backported.

Helmut
diff --minimal -Nru mandos-1.8.16/debian/changelog 
mandos-1.8.16/debian/changelog
--- mandos-1.8.16/debian/changelog  2024-04-19 13:08:30.0 +0200
+++ mandos-1.8.16/debian/changelog  2024-04-22 21:13:43.0 +0200
@@ -1,3 +1,10 @@
+mandos (1.8.16-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install mandos.service again. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 22 Apr 2024 21:13:43 +0200
+
 mandos (1.8.16-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru mandos-1.8.16/debian/mandos.dirs 
mandos-1.8.16/debian/mandos.dirs
--- mandos-1.8.16/debian/mandos.dirs2019-08-18 21:51:02.0 +0200
+++ mandos-1.8.16/debian/mandos.dirs2024-04-22 21:13:43.0 +0200
@@ -5,6 +5,6 @@
 etc/dbus-1/system.d
 usr/sbin
 var/lib/mandos
-lib/systemd/system
 usr/lib/tmpfiles.d
 usr/lib/sysusers.d
+usr/lib/systemd/system

Bug#1069688: libsequoia-octopus-librnp has an undeclared file conflict on /usr/lib/thunderbird/librnp.so

[Helmut Grohne]

Package: libsequoia-octopus-librnp
Version: 1.8.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + thunderbird

libsequoia-octopus-librnp has an undeclared file conflict. This may result in
an unpack error from dpkg.

The file /usr/lib/thunderbird/librnp.so is contained in the packages
 * libsequoia-octopus-librnp/1.8.1-3 as present in unstable
 * thunderbird/1:122.0~b2-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1069687: librust-bitflags-1-dev: fails to co-install

[Helmut Grohne]

Package: librust-bitflags-1-dev
Version: 1.3.2-5+b1
Severity: serious
Justification: causes an installation failure

Hi,

Attempting to install librust-bitflags-1-dev for multiple architectures
fails, because apt and dpkg disagree about how breaks and provides work.
apt thinks that self-breaks can be ignored, but dpkg thinks that since
librust-bitflags-1-dev breaks+provides librust-bitflags-1.3.2-dev it
cannot be coinstalled and gives up. You cannot combine such
breaks+provides with m-a:same. The simplest workaround here is dropping
m-a:same as it cannot be exercised anyway.

Helmut

Bug#1069630: libcupsfilters-dev and libcupsfilters2-dev have an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libcupsfilters.a, /usr/lib/x86_64-linux-gnu/libcupsfilters.so and /usr/lib/x86_64-

[Helmut Grohne]

Package: libcupsfilters2-dev
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libcupsfilters-dev

The files
 * /usr/lib/x86_64-linux-gnu/libcupsfilters.a
 * /usr/lib/x86_64-linux-gnu/libcupsfilters.so
 * /usr/lib/x86_64-linux-gnu/pkgconfig/libcupsfilters.pc
are contained in the packages
 * libcupsfilters-dev/1.28.17-4 as present in unstable
 * libcupsfilters2-dev/2.0.0-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Please figure out which of these packages should properly own the
affected files and reassign the bug as appropriate. When doing so,
please add the other package to the set of affected packages using
"Control: affects -1 + " to avoid the filing of duplicates.

The other package should stop installing the files. In case the files
are being moved between packages, Breaks and Replaces should be
declared. In this case, please refer to policy section 7.6 for details.
Another useful resource is https://wiki.debian.org/PackageTransition.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1069299: kodi-visualization-waveform FTBFS on arm*: does not agree on gl vs gles

[Helmut Grohne]

Source: kodi-visualization-waveform
Version: 20.2.1+ds1-1
Severity: serious
Tags: ftbfs

kodi-visualization-waveform fails to build from source on arm
architectures. A build fails like this:

| CMake Error at 
/usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
|   Could NOT find OpenGLES (missing: OPENGLES_gl_LIBRARY OPENGLES_INCLUDE_DIR)
| Call Stack (most recent call first):
|   /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
|   FindOpenGLES.cmake:37 (find_package_handle_standard_args)
|   CMakeLists.txt:41 (find_package)

Looking into CMakeLists.txt, one can see that it takes the
APP_RENDER_SYSTEM=gles path. I guess this is rooted in kodi recently
having changed this for all arm architectures via #1056563. Now
kodi-visualization-waveform does not have any dependency on gles
libraries but happens to pull gl libraries transitively. As a result the
build now fails.

I'm not sure whether this is to be fixed in kodi-visualization-waveform
or kodi. The end result is that this very package FTBFS. Hence filing
here initially, but reassigning may still make sense.

Helmut

Bug#1069064: util-linux-extra: insufficient Replaces for util-linux due to /usr-move

[Helmut Grohne]

Package: util-linux-extra
Version: 2.40-6
Severity: serious
User: helm...@debian.org
Usertags: dep17p1
Control: affects -1 + util-linux

Hi Chris,

I think I mentioned this on IRC already and you intended to revert, but
nothing happened, so lets turn this into a bug for tracking purposes at
least.

util-linux-extra gained the utils ctrlaltdel, fsck.cramfs, fsck.minix,
mkfs.bfs, mkfs.cramfs, and mkfs.minix. In util-linux-extra, these now
reside below /usr/sbin while they used to reside in /sbin in util-linux
in bookworm and earlier. Hence upgrading from bookworm to sid can cause
these files to be lost.

I think we have three ways to address this:

 1. Revert the move and retry after trixie. I think you favoured this?
 2. Upgrade Breaks to Conflicts and issue a temporary protective
diversion from u-l-e.preinst to u-l-e.postinst. In theory, apt can
first unpack u-l, then unpack u-l-e and then configure both, so
there is a safe solution. However, there is a risk that apt could
decide to temporarily remove u-l and that would be really bad.
 3. Keep Breaks and issue temporary diversions to be removed in forky's
u-l-e.postinst.

Please let me know your choice and I can do a patch.

Helmut

Bug#1069030: subread FTBFS on 32bit architectures: -Werror=implicit-function-declaration

[Helmut Grohne]

Source: subread
Version: 2.0.6+dfsg-2
Severity: serious
Tags: ftbfs

subread fails to build from source on 32bit architectures: A
non-parallel build contains:

| i686-linux-gnu-gcc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -mtune=generic -msse3 -O3 -fsigned-char -Wall 
-DMAKE_FOR_EXON  -D MAKE_STANDALONE -D SUBREAD_VERSION=\""2.0.6"\"  
-D_FILE_OFFSET_BITS=64  -fmessage-length=0 -ggdb -Wdate-time 
-D_FORTIFY_SOURCE=2  -c -o input-files.o input-files.c
| input-files.c: In function ‘f_subr_open’:
| input-files.c:54:24: error: implicit declaration of function ‘fopen64’; did 
you mean ‘gzopen64’? [-Werror=implicit-function-declaration]
|54 | return fopen64(fname, mode);
|   |^~~
|   |    gzopen64

Helmut

Bug#1068808: openmpi-bin has an undeclared file conflict on /usr/bin/pterm

[Helmut Grohne]

Package: openmpi-bin
Version: 5.0.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + pterm

openmpi-bin has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/bin/pterm is contained in the packages
 * openmpi-bin/5.0.3-1 as present in experimental
 * pterm
   * 0.74-1+deb11u1 as present in bullseye|bullseye-security
   * 0.78-2+deb12u1 as present in bookworm|bookworm-security
   * 0.80-1 as present in trixie
   * 0.80-1+b1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t

[Helmut Grohne]

Hi Aurelien,

On Mon, Apr 08, 2024 at 11:24:40PM +0200, Aurelien Jarno wrote:
> Thanks for you analysis and your patch. In short your proposal is to
> extend the initial patch from Steve to fully hide the fact that the
> compiler default to -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.
> 
> This indeed works and fixes the FTBFS. However it seems that, at least
> for some of the issues, it just hides them. For instance the wrong type
> for timeval.tv_usec, reported by Simon upstream [1], was detected by the
> conformance tests. Quoting utmpx.h/conform.out:

I think this needs a more nuanced look. From the comments in the
conformance test suite, it is evident that it expects to be run without
_FILE_OFFSET_BITS and _TIME_BITS. Many of the symbols it requires to
exist only exist when these macros are unset. The conformance test suite
has a comment saying that it should be testing the case where
_FILE_OFFSET_BITS is defined, but it currently does not provide
expectations for that case.

Before we can reasonably run the conformance test suite with these
macros set (and really, the test suite should be in control of these
macros), we cannot reasonably use it with them set. Let us now imagine a
future where the conformance test suite has been extended to provide
expectations (which in lots of cases means that *64 symbols disappear
when -D_FILE_OFFSET_BITS=64). Then what still remains is Simon's issue:

> | /tmp/tmp98wzaavx/test.c:4:35: error: conflicting types for ‘b2_10’; have 
> ‘__suseconds64_t’ {aka ‘long long int’}
> | 4 | extern __typeof__ (a2_10.tv_usec) b2_10;
> |   |   ^
> | /tmp/tmp98wzaavx/test.c:3:20: note: previous declaration of ‘b2_10’ with 
> type ‘suseconds_t’ {aka ‘long int’}
> | 3 | extern suseconds_t b2_10;
> |   |^
> | FAIL: Type of member tv_usec

Indeed, this is not something that can easily be fixed and where
upstream is still debating on what the correct solution should be. It
also is an issue that existed for a long time. If you head over to a
bookworm glibc and enable -D_TIME_BITS=64 there, you'll also notice that
tv_usec and suseconds_t have different sizes. So yes, this is a bug, but
it is not one that is directly related to Debian changing the default.
We merely increased the visibility of this problem that existed earlier
already.

Given that
 * the issue is already present in bookworm,
 * there are two mutually exclusive solutions and
 * upstream is still discussing the best solution
I recommend deferring this aspect.

> And we know it is the reason for the FTBFS of libflorist [2], so should
> we just ignore that issue anyway?

The libflorist issue likely is a consequence. It arises from
gnat_to_gnu_field where GNAT verifies that the value (of type
suseconds_t) to be assigned to a field (tv_usec) has the matching size.
This is directly based on the POSIX expectation and will be fixed with
the glibc issue.

How about filing a separate bug with glibc that tracks this POSIX
divergence and mark the libflorist bug as being blocked by this other
glibc bug? It can be RC or not, but since it affects bookworm, it won't
block testing migration.

Helmut

Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t

[Helmut Grohne]

Control: tags -1 + patch

Hi Aurelien and Canonical folks,

On Tue, Apr 02, 2024 at 08:53:31PM +0200, Aurelien Jarno wrote:
> Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
> -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
> except i386.
> 
> This has been partially fixed in the 2.37-15.1 NMU by adding
> -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:

There are two subtleties about -U_TIME_BITS in a moment.

> | +-+
> | | Encountered regressions that don't match expected failures. |
> | +-+
> | FAIL: conform/ISO/stdio.h/linknamespace

The detail for this failure is:

| [initial] fgetpos64
| [initial] fopen64
| [initial] freopen64
| [initial] fsetpos64
| [initial] tmpfile64

What linknamespace.py wants to tell us here is that it expected
fgetpos64, but no fgetpos64 was declared. It was not declared, because
there is no difference between fgetpos and fgetpos64 after defining
-D_FILE_OFFSET_BITS=64 (which is also in the default compiler flags).

The other failures are of very similar kind, but there also is another
kind.

> | FAIL: conform/POSIX/sys/stat.h/conform

The detail for this failure contains:

| /tmp/tmpnzda_r9j/test.c:90:35: error: conflicting types for 'b2_8'; have 
'__time64_t' {aka 'long long int'}
|90 | extern __typeof__ (a2_8.st_atime) b2_8;
|   |   ^~~~
| /tmp/tmpnzda_r9j/test.c:89:17: note: previous declaration of 'b2_8' with type 
'__time_t' {aka 'long int'}
|89 | extern __time_t b2_8;
|   | ^~~~

Here, it tells us that it expected the st_atime field of struct stat to
have type __time_t (the 32 bit one), but it really has __time64_t.

Looking at the invocation of linknamespace.py you can see:

| python3 -B linknamespace.py --cc='arm-linux-gnueabihf-gcc-12' 
--flags='-I../include  
-I/build/reproducible-path/glibc-2.37/build-tree/armhf-libc  
-I../sysdeps/unix/sysv/linux/arm/le  -I../sysdeps/unix/sysv/linux/arm  
-I../sysdeps/arm/nptl  -I../sysdeps/unix/sysv/linux/include 
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  
-I../sysdeps/unix/arm  -I../sysdeps/unix  -I../sysdeps/posix  
-I../sysdeps/arm/le/armv7/multiarch  -I../sysdeps/arm/armv7/multiarch  
-I../sysdeps/arm/le/armv7  -I../sysdeps/arm/armv7  -I../sysdeps/arm/armv6t2  
-I../sysdeps/arm/armv6  -I../sysdeps/arm/le  -I../sysdeps/arm/include 
-I../sysdeps/arm  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/flt-32  
-I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754  -I../sysdeps/generic 
-nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/12/include -isystem 
/build/reproducible-path/glibc-2.37/debian/include -I..' ...

In particular, what you do not see is -U_TIME_BITS inside --flags.

> Ubuntu has just ignored those failures for now, but I am just afraid
> that if we do the same, nobody will fix them.

Armed with this knowledge, I think we need two changes. For one thing
debian/sysdeps/linux.mk needs to add -U_FILE_OFFSET_BITS to extra_cflags
to revert any possible ABI changing effects. For another, the
conformance tests use independent compiler flags defined in
conform/Makefile. There, a naive patch seems to be:

-conformtest-cc-flags = -I../include $(+sysdep-includes) $(sysincludes) -I..
+conformtest-cc-flags = -U_FILE_OFFSET_BITS -U_TIME_BITS -I../include 
$(+sysdep-includes) $(sysincludes) -I..

With these two changes, I am able to successfully build glibc on armhf
with the conformance test suite passing.

> In addition it means that upstream glibc does not build anymore by
> default on a 32-bit Debian. Not really a Debian issue, but that is not
> nice either and should probably be fixed.

I think that latter change may be applicable upstream. Running the
conformance test suite with either _FILE_OFFSET_BITS or _TIME_BITS set
is not expected nor supported. This is partially evident from
conform/linknamespace.py in a comment:

| # * Header inclusions should be compiled several times with
| # different options such as -O2, -D_FORTIFY_SOURCE and
| # -D_FILE_OFFSET_BITS=64 to find out what symbols are undefined
| # from such a compilation; this is not yet implemented.

The conformance test suite clearly wants to manage these macros (and its
effects on symbols) explicitly and does not expect them to be
pre-defined.

Hope this helps

Helmut

Bug#1068610: dico: binary-all FTBFS

[Helmut Grohne]

Control: tags -1 + patch

Hi Adrian,

On Mon, Apr 08, 2024 at 02:03:01AM +0300, Adrian Bunk wrote:
> Source: dico
> Version: 2.11-4
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: Helmut Grohne 

Thank you for notifying me. Mea culpa. Patch attached.

> https://buildd.debian.org/status/logs.php?pkg=dico=all
> 
> ...
>debian/rules execute_after_dh_installsystemd
> make[1]: Entering directory '/<>'
> ln -s dicod.service debian/dicod/`test -e 
> debian/dicod/lib/systemd/system/dicod.service || echo 
> usr/`lib/systemd/system/dictd.service
> ln: failed to create symbolic link 
> 'debian/dicod/usr/lib/systemd/system/dictd.service': No such file or directory
> make[1]: *** [debian/rules:52: execute_after_dh_installsystemd] Error 1

Helmut
diff --minimal -Nru dico-2.11/debian/changelog dico-2.11/debian/changelog
--- dico-2.11/debian/changelog  2024-03-01 12:57:59.0 +0100
+++ dico-2.11/debian/changelog  2024-04-08 09:21:47.0 +0200
@@ -1,3 +1,10 @@
+dico (2.11-4.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix indep-only FTBFS arising from #1054187. (Closes: #1068610)
+
+ -- Helmut Grohne   Mon, 08 Apr 2024 09:21:47 +0200
+
 dico (2.11-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru dico-2.11/debian/rules dico-2.11/debian/rules
--- dico-2.11/debian/rules  2023-11-20 17:26:32.0 +0100
+++ dico-2.11/debian/rules  2024-04-08 09:21:31.0 +0200
@@ -48,5 +48,5 @@
mkdir -p $(TEST_HOME)
HOME=$(TEST_HOME) dh_auto_test || cat dicod/tests/testsuite.log
 
-execute_after_dh_installsystemd:
+execute_after_dh_installsystemd-arch:
ln -s dicod.service debian/dicod/`test -e 
debian/dicod/lib/systemd/system/dicod.service || echo 
usr/`lib/systemd/system/dictd.service

Bug#1068634: libdialog-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libdialog.a

[Helmut Grohne]

Package: libdialog-dev
Version: 1.3-20240307-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + dialog

libdialog-dev has an undeclared file conflict. This may result in an
unpack error from dpkg.

The file /usr/lib/x86_64-linux-gnu/libdialog.a is contained in the
packages
 * dialog
   * 1.3-20201126-1 as present in bullseye
   * 1.3-20230209-1 as present in bookworm
   * 1.3-20240101-1 as present in trixie
 * libdialog-dev/1.3-20240307-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1067790: nut: move files to /usr (DEP17) and partially revert time64

[Helmut Grohne]

Package: libnutclient2t64,libnutscan2t64,libupsclient6t64
Version: 2.8.1-3.1
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p1 dep17m2
Control: affects -1 + libnutclient2 libnutscan2 libupsclient6

Hi,

a number of packages from src:nut install files in aliased locations. In
order to finalize the /usr-merge, we want to move all of them below /usr
as doing so removes the bad effects arising from aliasing.
Unfortunately, the time64 transition renamed libraries built from nut,
so we are triggering a file loss scenario (DEP17 P1) - exactly the thing
we want to avoid in future by moving them. To complete this transition
in trixie, we have to add a mitigation (protective diversion) and this
is why I am sending a patch.

Said diversion incurs non-trivial maintainer scripts that are best
avoided if possible. Therefore, I reviewed the time64 transition and
concluded that the ABI of libnutscan did not change. I therefore propose
reverting the time64 transition for libnutscan only. The other two
libraries do change ABI and need to be renamed. In reverting libnutscan,
we also eliminate the need to mitigate the file loss. I have set the
severity of this bug to serious to prevent libnutscan2t64 from
transitioning to trixie. The time64 transition should either be reverted
before it transitions to trixie or not at all. If you think that it
should not be reverted, please lower the severity of this bug and I'll
send an updated patch. I note that having fewer library renames makes
the bookworm -> trixie upgrade easier, so reverting (when correct)
generally is a good thing (and it also reduces maintainer script
complexity).

I have tested this patch using piuparts. This happens to fail, because
some fontconfig files below /etc are not properly removed. I believe
this failure is unrelated to my change. I also tested for the particular
file loss scenario specifically.

mmdebstrap trixie /dev/null --variant=apt --include libnutclient-dev 
--customize-hook='echo "deb http://deb.debian.org/debian sid main" > 
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get 
update" --customize-hook="upload libnutclient2t64_2.8.1-3.2_amd64.deb /l.deb" 
--customize-hook="upload libnutclient-dev_2.8.1-3.2_amd64.deb /d.deb" 
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb; 
apt-get -y install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"
mmdebstrap trixie /dev/null --variant=apt --include libupsclient-dev 
--customize-hook='echo "deb http://deb.debian.org/debian sid main" > 
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get 
update" --customize-hook="upload libupsclient6t64_2.8.1-3.2_amd64.deb /l.deb" 
--customize-hook="upload libupsclient-dev_2.8.1-3.2_amd64.deb /d.deb" 
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb; 
apt-get -y install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"

Last but not least, this patch must not be uploaded to
bookworm-backports or earlier as it would violate the file move
moratorium there. If you plan to backport nut, you must revert both the
time64 transition and this patch.

Helmut
diff -Nru nut-2.8.1/debian/changelog nut-2.8.1/debian/changelog
--- nut-2.8.1/debian/changelog  2024-02-29 02:26:20.0 +0100
+++ nut-2.8.1/debian/changelog  2024-03-26 14:40:41.0 +0100
@@ -1,3 +1,11 @@
+nut (2.8.1-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert unnecessary time64 transition for libnutscan.
+  * Move files to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 26 Mar 2024 14:40:41 +0100
+
 nut (2.8.1-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru nut-2.8.1/debian/control nut-2.8.1/debian/control
--- nut-2.8.1/debian/control2024-02-29 02:26:20.0 +0100
+++ nut-2.8.1/debian/control2024-03-26 14:40:41.0 +0100
@@ -203,7 +203,7 @@
 Package: libupsclient6t64
 Provides: ${t64:Provides}
 Replaces: libupsclient6
-Breaks: libupsclient6 (<< ${source:Version})
+Conflicts: libupsclient6 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
@@ -238,7 +238,7 @@
 Package: libnutclient2t64
 Provides: ${t64:Provides}
 Replaces: libnutclient2
-Breaks: libnutclient2 (<< ${source:Version})
+Conflicts: libnutclient2 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
@@ -269,10 +269,10 @@
  .
  This package provides the development files for the new client library.
 
-Package: libnutscan2t64
-Provides: ${t64:Provides}
-Replaces: libnutscan2
-Breaks: libnutscan2 (<< ${source:Version})
+Package: libnutscan2
+Provides: libnutscan2t64 (= ${binary:Version})
+Replaces: libnutscan2t64
+Breaks: libnutscan2t64 (<< ${source:Version})
 Section: libs
 Archi

Bug#1067776: openrc: move files to /usr (DEP17) and revert unnecessary time64 transition

[Helmut Grohne]

Package: openrc,libeinfo1,libeinfo1t64,librc1t64
Version: 0.53-1.1
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p1 dep17m2
Control: affects -1 librc1

Hi,

I am sending you a patch for moving files to /usr for DEP17, because
doing so requires mitigations due to time64 having renamed libraries. In
particular, I verified that libeinfo did not actually break ABI.
Therefore, I am proposing to revert the time64 transition for libeinfo.
As a consequence of the reversion, we need fewer /usr-move mitigations.
We still need the mitigation for librc though. I have set the severity
of this bug to serious to prevent libeinfo1t64 from migrating to trixie.
It should either be reverted before migration or it should not be
reverted. If you disagree with the reversion, please lower the severity
of this bug and I'll send a patch that extends the mitigation to
libeinfo. That said, fewer library renames make upgrades less painful.

I've tested the patch using piuparts and with a manual test case
precisely triggering the DEP17 P1 file loss scenario:

mmdebstrap trixie /dev/null --variant=apt --include librc-dev 
--customize-hook='echo "deb http://deb.debian.org/debian sid main" > 
"$1/etc/apt/sources.list.d/sid.list"' --chrooted-customize-hook="apt-get 
update" --customize-hook="upload librc1t64_0.53-1.2_amd64.deb /l.deb" 
--customize-hook="upload librc-dev_0.53-1.2_amd64.deb /d.deb" 
--chrooted-customize-hook="dpkg --auto-deconfigure --unpack /l.deb /d.deb; 
apt-get -y install /l.deb /d.deb" --chrooted-customize-hook="dpkg --verify"

Do note that this patch must not be backported to bookworm-backports or
earlier. If you intend to backport, you must revert both this patch and
the time64 transition for your backport.

I recommend uploading this sooner rather than later, because the
reversion helps people who have not yet upgraded libeinfo to unstable.

Helmut
diff -Nru openrc-0.53/debian/changelog openrc-0.53/debian/changelog
--- openrc-0.53/debian/changelog2024-02-29 13:48:11.0 +0100
+++ openrc-0.53/debian/changelog2024-03-26 15:56:35.0 +0100
@@ -1,3 +1,11 @@
+openrc (0.53-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert unnecessary time64 transition for libeinfo
+  * Move files to /usr and mitigate file loss (DEP17) (Closes: #-1).
+
+ -- Helmut Grohne   Tue, 26 Mar 2024 15:56:35 +0100
+
 openrc (0.53-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru openrc-0.53/debian/control openrc-0.53/debian/control
--- openrc-0.53/debian/control  2024-02-29 13:48:11.0 +0100
+++ openrc-0.53/debian/control  2024-03-26 15:56:35.0 +0100
@@ -47,7 +47,7 @@
 Package: librc1t64
 Provides: ${t64:Provides}
 Replaces: librc1
-Breaks: librc1 (<< ${source:Version})
+Conflicts: librc1 (<< ${source:Version})
 Architecture: any
 Section: libs
 Depends: ${misc:Depends},
@@ -84,10 +84,10 @@
  .
  This package provides development files for the runtime library.
 
-Package: libeinfo1t64
-Provides: ${t64:Provides}
-Replaces: libeinfo1
-Breaks: libeinfo1 (<< ${source:Version})
+Package: libeinfo1
+Provides: libeinfo1t64
+Replaces: libeinfo1t64
+Breaks: libeinfo1t64 (<< ${source:Version})
 Architecture: any
 Section: libs
 Depends: ${misc:Depends},
@@ -110,7 +110,7 @@
 Package: libeinfo-dev
 Architecture: any
 Section: libdevel
-Depends: libeinfo1t64 (=${binary:Version}),
+Depends: libeinfo1 (=${binary:Version}),
  ${misc:Depends},
 Multi-Arch: same
 Description: dependency based service manager (pretty console display 
development)
diff -Nru openrc-0.53/debian/libeinfo-dev.links 
openrc-0.53/debian/libeinfo-dev.links
--- openrc-0.53/debian/libeinfo-dev.links   2024-01-22 18:18:38.0 
+0100
+++ openrc-0.53/debian/libeinfo-dev.links   2024-03-26 15:56:35.0 
+0100
@@ -1,3 +1,3 @@
 #! /usr/bin/dh-exec
 
-lib/${DEB_HOST_MULTIARCH}/libeinfo.so.1 
usr/lib/${DEB_HOST_MULTIARCH}/libeinfo.so
+usr/lib/${DEB_HOST_MULTIARCH}/libeinfo.so.1 
usr/lib/${DEB_HOST_MULTIARCH}/libeinfo.so
diff -Nru openrc-0.53/debian/libeinfo1.install 
openrc-0.53/debian/libeinfo1.install
--- openrc-0.53/debian/libeinfo1.install1970-01-01 01:00:00.0 
+0100
+++ openrc-0.53/debian/libeinfo1.install2024-03-26 15:56:35.0 
+0100
@@ -0,0 +1 @@
+usr/lib/*/libeinfo.so.*
diff -Nru openrc-0.53/debian/libeinfo1t64.install 
openrc-0.53/debian/libeinfo1t64.install
--- openrc-0.53/debian/libeinfo1t64.install 2024-01-22 18:18:38.0 
+0100
+++ openrc-0.53/debian/libeinfo1t64.install 1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-lib/*/libeinfo.so.*
diff -Nru openrc-0.53/debian/libeinfo1t64.lintian-overrides 
openrc-0.53/debian/libeinfo1t64.lintian-overrides
--- openrc-0.53/debian/libeinfo1t64.lintian-overrides   2024-02-29 
13:48:06.0 +0100
+++ openrc-0.53/debian/libeinfo1t64.lintian-overrides   1970-01-01 

Bug#1063664: gcc-13-cross: file conflicts between gnat-13- and gnat-{9,10}-

[Helmut Grohne]

user debian...@lists.debian.org
usertags 1063664 + fileconflict
reassign 1063664 
gnat-13-aarch64-linux-gnu,gnat-13-arm-linux-gnueabihf,gnat-13-i686-linux-gnu,gnat-13-powerpc64le-linux-gnu,gnat-13-riscv64-linux-gnu,gnat-13-s390x-linux-gnu
found 1063664 10.5.0-1cross2
affects 1063664 + gnat-10-aarch64-linux-gnu gnat-10-arm-linux-gnueabihf 
gnat-10-i686-linux-gnu gnat-10-powerpc64le-linux-gnu gnat-10-riscv64-linux-gnu 
gnat-10-s390x-linux-gnu gnat-11-aarch64-linux-gnu gnat-11-arm-linux-gnueabihf 
gnat-11-i686-linux-gnu gnat-11-powerpc64le-linux-gnu gnat-11-riscv64-linux-gnu 
gnat-11-s390x-linux-gnu gnat-12-aarch64-linux-gnu gnat-12-arm-linux-gnueabihf 
gnat-12-i686-linux-gnu gnat-12-powerpc64le-linux-gnu gnat-12-riscv64-linux-gnu 
gnat-12-s390x-linux-gnu gnat-9-aarch64-linux-gnu gnat-9-arm-linux-gnueabihf 
gnat-9-i686-linux-gnu gnat-9-powerpc64le-linux-gnu gnat-9-riscv64-linux-gnu 
gnat-9-s390x-linux-gnu
tags 1063664 + patch
thanks

On Sat, Feb 10, 2024 at 07:55:09PM +0100, Andreas Beckmann wrote:
> there are undeclared file conflicts between gnat-13- and
> gnat-{9,10}- in sid. (but not between -9- and -10-).
> Maybe it would be sufficient to rebuild the package against gcc-13
> 13.2.0-13 which had some gnat conflict fixes.

I confirm. Usually, the higher gnat version declares Conflicts for the
lower one. Starting with gcc-14, the unversioned link is no longer
provided and gnat is part of gcc-defaults, so this problem will go away
in future. I also verified that src:gcc-13 already issues these
Conflicts and that a no-change upload of gcc-13-cross adds these
Conflicts to the cross toolchain packages. Hence tagging the issue as
patch.

Matthias, would you do that upload?

Helmut

Bug#1041832: #1041832: libsequoia-octopus-librnp: undeclared file conflict with thunderbird

[Helmut Grohne]

Hi Holger,

On Fri, Mar 22, 2024 at 07:36:37PM +, Holger Levsen wrote:
> < h01ger> helmut: re:  #1041832: i just could not reproduce this bug, see
>   https://paste.debian.net/1311659/ - though we "didnt change
>   anything" in sequoia-octopus, so what am i missing? :)
> 
> that paste had basically this content:
> 
> ± dpkg -L libsequoia-octopus-librnp |grep librnp.so
> /usr/lib/sequoia/libsequoia_octopus_librnp.so
> /usr/lib/thunderbird/librnp.so
> ± dpkg -L thunderbird|grep librnp.so
> 1 ±

You're faced with a relatively early dumat-generated report and I see
how the lack of detail makes diagnosing this difficult. Later reports
have been improved to include the missing detail.

Let me paste the machine-readable report and explain it.

libsequoia-octopus-librnp:
  1.4.1-1:
issues:
- bugs:
  - 1041832
  files:
  - /usr/lib/thunderbird/librnp.so
  others:
thunderbird:
  1:115.7.0-1~deb11u1: bullseye
  1:115.7.0-1~deb12u1: bookworm
  1:115.8.0-1~deb12u1: bookworm-proposed-updates
  1:115.9.0-1~deb11u1: bullseye-security
  1:115.9.0-1~deb12u1: bookworm-security
  1:122.0~b2-1: experimental
  what: undeclared file conflict
source: rust-sequoia-octopus-librnp
suites: experimental
  1.8.1-1:
issues:
- bugs:
  - 1041832
  files:
  - /usr/lib/thunderbird/librnp.so
  others:
thunderbird:
  1:115.7.0-1~deb11u1: bullseye
  1:115.7.0-1~deb12u1: bookworm
  1:115.8.0-1~deb12u1: bookworm-proposed-updates
  1:115.9.0-1~deb11u1: bullseye-security
  1:115.9.0-1~deb12u1: bookworm-security
  1:122.0~b2-1: experimental
  what: undeclared file conflict
source: rust-sequoia-octopus-librnp
suites: unstable
thunderbird:
  1:122.0~b2-1:
issues:
- bugs:
  - 1041832
  files:
  - /usr/lib/thunderbird/librnp.so
  others:
libsequoia-octopus-librnp:
  1.4.1-1: experimental
  1.8.1-1: unstable
  what: undeclared file conflict
suites: experimental

Specifically, you need a version of libsequoia-octopus-librnp from
unstable or experimental and combine it with a thunderbird version from
bullseye, bookworm or experimental. If we disregard experimental and
assume that libsequoia-octopus-librnp to trixe, apt could choose to
first install libsequoia-octopus-librnp in a bookworm to trixie upgrade
before upgrading thunderbird to drop the file.

So to reproduce this, I recommend using a bookworm system, install
thunderbird, add unstable to apt sources, install
libsequoia-octopus-librnp.

Helmut

Bug#1064003: Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Helmut Grohne]

Hi Bastian and Matthias,

I was recently working on gcc builds and this disagreement currently
makes stuff unbuildable. Hence I looked into solutions and/or
workarounds.

On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> > You just said that the search path used during the build of the
> > toolchain and the one for everything else are unrelated.  So you are
> > free to create $BUILD/tmp-include with symlinks for asm, asm-generic,
> > linux.
> > 
> > The toolchain as installed already finds all headers.  So I still don't
> > see why we need this in the final system.
> 
> I find this argument fairly convincing and hope Matthias also does.

As a result, I implemented the proposed change and am attaching it for
discussion here. I've implemented it in a way that if there is a sysroot
linux header installation, it'll be preferred. Do you see any downsides
of this approach?

Helmut
linux-libc-dev now provides linux-libc-dev-$arch-cross without actually
providing /usr//include. Thus we symlink it to where we need it.

See also #1064003.

diff --git a/debian/rules2 b/debian/rules2
index 651d14af..6a486ffe 100644
--- a/debian/rules2
+++ b/debian/rules2
@@ -1266,6 +1266,13 @@ endif
 	  ln -sf /usr/include/$(DEB_HOST_MULTIARCH)/crypt.h \
 	$(builddir)/sys-include/crypt.h; \
 	fi
+	: # Import headers from Multi-Arch:foreign linux-libc-dev
+	set -e; for d in asm-generic linux; do \
+	  if [ -d "/usr/include/$$d" ] && ! [ -d "/usr/$(DEB_TARGET_GNU_TYPE)/include/$$d" ]; then \
+	mkdir -p '$(builddir)/sys-include'; \
+	ln -sf "/usr/include/$$d" "$(builddir)/sys-include/$$d"; \
+	  fi; \
+	done
 
 	touch $(configure_stamp)
 

Bug#1067215: 4 packages from libgdchart-gd2 have an undeclared file conflict

[Helmut Grohne]

Package: 
libgdchart-gd2-noxpm-dev,libgdchart-gd2-noxpm,libgdchart-gd2-xpm-dev,libgdchart-gd2-xpm
Version: 0.11.5-11
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict

4 packages from libgdchart-gd2 have an undeclared file conflict. This
may result in an unpack error from dpkg.

The files
 * /usr/lib/libgdc.so.0
 * /usr/lib/libgdc.so.0.11.5
are contained in the packages
 * libgdchart-gd2-noxpm
   * 0.11.5-11 as present in unstable
   * 0.11.5-10 as present in bookworm|bullseye
   * 0.11.5-10+b1 as present in trixie
 * libgdchart-gd2-xpm
   * 0.11.5-10 as present in bookworm|bullseye
   * 0.11.5-10+b1 as present in trixie
   * 0.11.5-11 as present in unstable

The files
 * /usr/lib/libgdc.a
 * /usr/lib/libgdc.so
are contained in the packages
 * libgdchart-gd2-noxpm-dev
   * 0.11.5-11 as present in unstable
   * 0.11.5-10 as present in bookworm|bullseye
   * 0.11.5-10+b1 as present in trixie
 * libgdchart-gd2-xpm-dev
   * 0.11.5-10 as present in bookworm|bullseye
   * 0.11.5-10+b1 as present in trixie
   * 0.11.5-11 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1067134: Try to remove i386 packages

[Helmut Grohne]

On Tue, Mar 19, 2024 at 10:45:44AM +0100, Christian Marillat wrote:
> ,
> | $ dpkg -l | grep libcom-err
> | ii  libcom-err2t64:amd64   1.47.0-2.3+b1
>amd64common error description library
> | ii  libcom-err2t64:i3861.47.0-2.3+b1
>i386 common error description library

This is the bumpy unstable state that should never migrate to trixie.

> upgrading libcom-err2 to 1.47.0-2.4 remove all i386 packages

Consider guiding apt by asking it to install both libcom-err2:amd64 and
libcom-err2:i386.

> ,
> | $ dpkg -l |grep libcom-err2  
> | ii  libcom-err2:amd64  1.47.0-2.4   
>amd64common error description library
> `
> 
> but now I can reinstall i386 packages again :
> 
> ,
> | $ dpkg -l |grep libcom-err2
> | ii  libcom-err2:amd64  1.47.0-2.4   
>amd64common error description library
> | ii  libcom-err2:i386   1.47.0-2.4   
>i386 common error description library
> `

I agree that the experience is a little messed up, but this is
resolvable with apt and it only affects unstable users. Do you agree
with closing this bug with no action?

Helmut

Bug#1067134: Try to remove i386 packages

[Helmut Grohne]

Control: tags -1 + moreinfo

Hi Christian,

On Tue, Mar 19, 2024 at 10:11:53AM +0100, Christian Marillat wrote:
> I'm unable to install comerr-dev under a multiarch amd64/i386
> machine.
> 
> Here is a simple example :
> 
> ,
> | $ sudo apt-get install comerr-dev 
> | Reading package lists... Done
> | Building dependency tree... Done
> | Reading state information... Done
> | 
> | [...]
> | 
> | The following additional packages will be installed:
> |   libcom-err2
> | Suggested packages:
> |   doc-base
> | The following packages will be REMOVED:
> |   inetutils-telnet:i386
> | The following NEW packages will be installed:
> |   comerr-dev libcom-err2
> | 0 upgraded, 2 newly installed, 1 to remove and 0 not upgraded.
> `

I fear this is not enough information to diagnose the problem. I'm
giving you some context to better understand what we need here.

e2fsprogs was identified as one of the packages whose ABI is affected by
time64. That analsys did not discriminate between individual shared
libraries built from e2fsprogs and hence all libraries including
libcom-err2 were bumped. It turned out that libss2 and libcom-err2
really were not affected and libss2t64 and libcom-err2t64 did not
transition to trixie. Hence, I reverted the transition for these to ease
upgrades knowing that I'd be making upgrades in unstable slightly harder
though those are difficult at best.

So we need to know which libcom-err2 and libcom-err2t64 packages are
installed for which architectures on your system. If there is any
libcom-err2t64, please "upgrade" to libcom-err2. Then retry your
original apt. I fear this is going to be manual in unstable as there is
no sane way to make apt understand that we really don't need
libco-err2t64. I expect that upgrades from bookworm and trixie are
unaffected by this issue. Unless this expectation is wrong, I suggest
that we close this bug as wontfix.

Helmut

Bug#1066910: chromium: downloads non-free component libchromescreenai.so without asking

[Helmut Grohne]

Package: chromium
Version: 122.0.6261.128-1
Severity: serious

In recent versions, chromium started downloading a file
~/.config/chromium/screen_ai/*/libchromescreenai.so. Evidently, the
source of this shared object is not in the chromium source package. I
think the chromium package - being in main - should not download a
shared object and run it without user confirmation.

Helmut

Bug#1066190: mtree-netbsd FTBFS due to -Werror=implicit-function-declaration

[Helmut Grohne]

Source: mtree-netbsd
Version: 20180822-7
Severity: serious
Tags: ftbfs

As part of the time64 transition, -Werror=implicit-function-declaration
was enabled in default build flags. This makes mtree-netbsd fail to
build from source. A build ends with:

| gcc -DHAVE_CONFIG_H -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -DBSD4_4 
-Dst_mtimespec=st_mtim -I. -I. -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c 
getid.c
| getid.c: In function ‘setup_getid’:
| getid.c:163:13: error: implicit declaration of function ‘pwcache_groupdb’ 
[-Werror=implicit-function-declaration]
|   163 | if (pwcache_groupdb(gi_setgroupent, gi_endgrent,
|   | ^~~
| getid.c:165:16: error: implicit declaration of function ‘pwcache_userdb’ 
[-Werror=implicit-function-declaration]
|   165 | || pwcache_userdb(gi_setpassent, gi_endpwent,
|   |^~
| cc1: some warnings being treated as errors
| make[1]: *** [Makefile:30: getid.o] Error 1
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:18: build] Error 255
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#1066183: mate-equake-applet FTBFS due to -Werror=implicit-function-declaration

[Helmut Grohne]

Source: mate-equake-applet
Version: 1.3.8.2-1.1
Severity: serious
Tags: ftbfs

Due to the time64 transition -Werror=implicit-function-declaration was
turned on by default in unstable. This change makes mate-equake-applet
fail to build from source. Relevant snippet:

| equake_processdata.c: In function ‘convert_localtime’:
| equake_processdata.c:1105:3: error: implicit declaration of function 
‘strptime’; did you mean ‘strftime’? [-Werror=implicit-function-declaration]
|  1105 |   strptime(datetime, "%Y %m %d %H %M %S %z", tp); /* year month day 
hour minute second */
|   |   ^~~~
|   |   strftime

Helmut

Bug#1065214: NMU iproute2

[Helmut Grohne]

Control: tags -1 + pending

Hi Luca,

this bug causes issues to /usr-move. iproute2 pulls libtirpc3 and
nothing pulls libtirpc3t64. Hence, the we still include libtirpc3, which
is aliased rather than libtirpc3t64, which is /usr-moved. To fix this,
I'd need a binNMU of iproute2, but this bug would cause that binNMU to
be broken. Hence, I rather fix this bug.

I used reproducible builds to see that iproute2 really only uses tirpc
and not nsl. Hence I'm uploading the simple fix of explicitly depending
on libtirpc-dev. NMU diff attached. No delay in accordance with DevRef
(rc bug older than 7 days with no maintainer activity).

Helmut
diff -Nru iproute2-6.7.0/debian/changelog iproute2-6.7.0/debian/changelog
--- iproute2-6.7.0/debian/changelog 2024-01-22 13:24:29.0 +0100
+++ iproute2-6.7.0/debian/changelog 2024-03-12 09:03:30.0 +0100
@@ -1,3 +1,10 @@
+iproute2 (6.7.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Explicitly depend on libtirpc-dev. (Closes: #1065214)
+
+ -- Helmut Grohne   Tue, 12 Mar 2024 09:03:30 +0100
+
 iproute2 (6.7.0-2) unstable; urgency=medium
 
   * Backport fix for 'ss' output
diff -Nru iproute2-6.7.0/debian/control iproute2-6.7.0/debian/control
--- iproute2-6.7.0/debian/control   2024-01-12 22:09:28.0 +0100
+++ iproute2-6.7.0/debian/control   2024-03-12 09:02:10.0 +0100
@@ -22,6 +22,7 @@
libelf-dev,
libmnl-dev,
libselinux1-dev,
+   libtirpc-dev,
linux-libc-dev,
pkg-config,
po-debconf,

Bug#1066078: vigor FTBFS due to -Werror=implicit-function-declaration

[Helmut Grohne]

Source: vigor
Version: 0.016-31
Severity: serious
Tags: ftbfs

Due to time64 and thus enabling -Werror=implicit-function-declaration,
vigor now fails to build from source:

| ../../build/../cl/cl_screen.c: In function ‘cl_screen’:
| ../../build/../cl/cl_screen.c:112:25: error: implicit declaration of function 
‘tputs’; did you mean ‘puts’? [-Werror=implicit-function-declaration]
|   112 | tputs(tgoto(clp->cup,
|   | ^
|   | puts
| ../../build/../cl/cl_screen.c:112:31: error: implicit declaration of function 
‘tgoto’ [-Werror=implicit-function-declaration]
|   112 | tputs(tgoto(clp->cup,
|   |   ^
| ../../build/../cl/cl_funcs.c: In function ‘cl_attr’:
| ../../build/../cl/cl_funcs.c:125:39: error: implicit declaration of function 
‘tputs’; did you mean ‘puts’? [-Werror=implicit-function-declaration]
|   125 | (void)tputs(clp->smcup, 1, 
cl_putchar);
|   |   ^
|   |   puts
| ../../build/../cl/cl_read.c: In function ‘block_for_read’:
| ../../build/../cl/cl_read.c:137:9: error: implicit declaration of function 
‘mega_select’ [-Werror=implicit-function-declaration]
|   137 | mega_select(fd+1, , NULL, NULL, NULL);
|   | ^~~
| ../../build/../cl/cl_funcs.c: In function ‘cl_ex_adjust’:
| ../../build/../cl/cl_funcs.c:350:37: error: implicit declaration of function 
‘tgoto’; did you mean ‘v_lgoto’? [-Werror=implicit-function-declaration]
|   350 | (void)tputs(tgoto(clp->cup,
|   | ^
|   | v_lgoto
| ../../build/../cl/cl_funcs.c: In function ‘cl_bell’:
| ../../build/../cl/cl_funcs.c:214:23: warning: ignoring return value of 
‘write’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
|   214 | (void)write(STDOUT_FILENO, "\07", 1);   /* \a 
*/
|   |   ^~
| ../../build/../cl/cl_bsd.c: In function ‘setupterm’:
| ../../build/../cl/cl_bsd.c:176:22: error: implicit declaration of function 
‘tgetent’; did you mean ‘getenv’? [-Werror=implicit-function-declaration]
|   176 | if ((*errp = tgetent(buf, ttype)) > 0) {
|   |  ^~~
|   |      getenv

Helmut

Bug#1066057: libhalide17-1-dev has an undeclared file conflict

[Helmut Grohne]

Package: libhalide17-1-dev
Version: 17.0.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libhalide17-0-dev

libhalide17-1-dev has an undeclared file conflict. This may result in an
unpack error from dpkg.

The files
 * /usr/lib/x86_64-linux-gnu/cmake/Halide17/Halide-shared-deps.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/Halide17/Halide-shared-targets-release.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/Halide17/Halide-shared-targets.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/Halide17/HalideConfig.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/Halide17/HalideConfigVersion.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/FindHalide_WebGPU.cmake
 * 
/usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/Halide-Interfaces-release.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/Halide-Interfaces.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideGeneratorHelpers.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideHelpersConfig.cmake
 * 
/usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideHelpersConfigVersion.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideTargetHelpers.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/TargetExportScript.cmake
 * /usr/lib/x86_64-linux-gnu/halide17/adams2019_retrain_cost_model
 * /usr/lib/x86_64-linux-gnu/halide17/adams2019_weightsdir_to_weightsfile
 * /usr/lib/x86_64-linux-gnu/halide17/anderson2021_retrain_cost_model
 * /usr/lib/x86_64-linux-gnu/halide17/anderson2021_weightsdir_to_weightsfile
 * /usr/lib/x86_64-linux-gnu/halide17/featurization_to_sample
 * /usr/lib/x86_64-linux-gnu/halide17/get_host_target
 * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_adams2019.so
 * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_anderson2021.so
 * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_li2018.so
 * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_mullapudi2016.so
 * /usr/lib/x86_64-linux-gnu/libHalide17.so
 * /usr/lib/x86_64-linux-gnu/libHalidePyStubs17.a
are contained in the packages
 * libhalide17-0-dev/17.0.0-2 as present in trixie
 * libhalide17-1-dev/17.0.1-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1066054: spacearyarya FTBFS due to -Werror=implicit-function-declaration

[Helmut Grohne]

Source: spacearyarya
Version: 1.0.2-8
Severity: serious
Tags: ftbfs

Due to the time64 transition, -Werror=-implicit-function-declaration was
enabled in default build flags and this makes spacearyarya FTBFS: Please
include the time.h header.

| gcc -DPACKAGE_NAME=\"SpaceAryarya-KXL\" 
-DPACKAGE_TARNAME=\"spacearyarya-kxl\" -DPACKAGE_VERSION=\"1.0.2\" 
-DPACKAGE_STRING=\"SpaceAryarya-KXL\ 1.0.2\" 
-DPACKAGE_BUGREPORT=\"m...@kxl.hn.or\" -DPACKAGE_URL=\"\" 
-DPACKAGE=\"spacearyarya-kxl\" -DVERSION=\"1.0.2\" -DHAVE_LIBKXL=1 
-DHAVE_LIBKXL=1 -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 
-DDATA_PATH=\"/usr/share/games/spacearyarya/data\" 
-DBMP_PATH=\"/usr/share/games/spacearyarya/bmp\" 
-DWAV_PATH=\"/usr/share/games/spacearyarya/wav\" -DTITLE=\"spacearyarya-kxl\ 
1.0.2\" -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -c -o main.o main.c
| main.c: In function ‘options’:
| main.c:144:10: error: implicit declaration of function ‘strcmp’ 
[-Werror=implicit-function-declaration]
|   144 | if (!strcmp(argv[i], "-h") || !strcmp(argv[i], "--help")) {
|   |  ^~
| main.c:7:1: note: include ‘’ or provide a declaration of ‘strcmp’
| 6 | #include "extern.h"
|   +++ |+#include 
| 7 | 
| main.c: In function ‘main’:
| main.c:179:9: error: implicit declaration of function ‘time’ 
[-Werror=implicit-function-declaration]
|   179 |   srand(time(NULL));
|   | ^~~~
| main.c:7:1: note: ‘time’ is defined in header ‘’; did you forget to 
‘#include ’?
| 6 | #include "extern.h"
|   +++ |+#include 
| 7 | 
| misc.c: In function ‘ClearAndGameOver’:
| misc.c:107:5: error: implicit declaration of function ‘ScoreRanking’ 
[-Werror=implicit-function-declaration]
|   107 | ScoreRanking();
|   | ^~~~
| ranking.c: In function ‘ReadScore’:
| ranking.c:41:5: warning: ignoring return value of ‘fscanf’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
|41 | fscanf(fp, "%"SCNu32, &(Root->HiScore));
|   | ^~~
| ranking.c:43:7: warning: ignoring return value of ‘fscanf’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
|43 |   fscanf(fp, "%"SCNu32" %"SCNu8" %s",
|   |   ^~~
|44 |  &(Ranking[i]->Score),
|   |  ~
|45 |  &(Ranking[i]->Stage),
|   |  ~
|46 |  Ranking[i]->Name);
|   |  ~

Helmut

Bug#1066053: sgrep FTBFS due to -Werror=implicit-function-declaration

[Helmut Grohne]

Source: sgrep
Version: 1.94a-5
Severity: serious
Tags: ftbfs

Due to the time64 transition, default build flags now include
-Werror=implicit-function-declaration. This happens to cause a build
failure for sgrep:

| gcc -DHAVE_CONFIG_H -I. -DDATADIR="\"/usr/share/sgrep\"" 
-DSYSCONFDIR="\"/etc\""  -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -c -o index_main.o index_main.c
| sysdeps.c: In function ‘check_memory_leaks’:
| sysdeps.c:489:49: warning: format ‘%d’ expects argument of type ‘int’, but 
argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
|   489 | "Memory leak: %d blocks having %d bytes total size\n",
|   |~^
|   | |
|   | int
|   |%ld
| sysdeps.c:496:32: warning: format ‘%d’ expects argument of type ‘int’, but 
argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
|   496 | "\t%s:%d: %d 
bytes\n",block->file,block->line,block->size);
|   |   ~^  
~~~
|   ||  
 |
|   |int
 size_t {aka long unsigned int}
|   |   %ld
| index_main.c: In function ‘parse_index_options’:
| index_main.c:84:21: error: implicit declaration of function ‘strcmp’ 
[-Werror=implicit-function-declaration]
|84 | if (strcmp(*argv,"--")==0) return i+1;
|   | ^~
| index_main.c:2:1: note: include ‘’ or provide a declaration of 
‘strcmp’
| 1 | #include "sgrep.h"
|   +++ |+#include 
| 2 |
| index_main.c:138:41: warning: macro "__DATE__" might prevent reproducible 
builds [-Wdate-time]
|   138 | VERSION,__DATE__);
|   | ^~~~
| index_main.c: In function ‘index_main’:
| index_main.c:241:13: error: implicit declaration of function ‘index_query’ 
[-Werror=implicit-function-declaration]
|   241 | if (index_query(,argc-end_options,argv+end_options)
|   | ^~~
| cc1: some warnings being treated as errors
| make[2]: *** [Makefile:488: index_main.o] Error 1

Helmut

Bug#1065696: Fwd: E: unsupported command: poweroff.no-molly-guard

[Helmut Grohne]

Control: forcemerge 1059691 -1

On Fri, Mar 08, 2024 at 09:37:05PM -0800, Francois Marier wrote:
> Hi Helmut,
> 
> This looks like an unexpected edge case from the recent usr-merge changes:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065696
> 
> It sounds like a system using sysvinit, instead of systemd, which was
> recently upgraded using usrmerge.

Yes, I think this is a duplicate of #1059691. Could you give feedback on
the contained patch?

Helmut

Bug#1064852: incus: missing depends on iproute2

[Helmut Grohne]

On Tue, Mar 05, 2024 at 12:00:15PM +, Mathias Gibbens wrote:
> to add iproute2. I would be interested to know more about what
> environment Incus is being used in that doesn't have the `ip` command
> available.

debvm-create --include=incus
# This should have created a file named rootfs.ext4.
debvm-run

>   My normal testing setup for Incus is a fresh, minimal expert install
> of sid via the netinst iso. During the install of the VM, I only
> install the base system and deselect the "standard system utilities"
> group. I do use DHCP, which looks like that might be responsible for
> pulling in iproute2 for me. If there's a way to create an even more
> minimal install, I'd be happy to incorporate that into my testing
> routine.

Turns out your minimal expert install is not so minimal. debvm tends to
give you a smaller but still functional installation. I think adding
--variant=important to debvm-create roughly gets you the minimal expert
installation, but creating the machine takes slightly longer and uses
more disk space of course.

Rather than adding debvm on top of your testing, I think adding
autopkgtests with isolation-machine should get you more automatic
coverage. Possibly such tests need to be explicitly allowed by debci
folks and currently are only available on amd64.

Helmut

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Helmut Grohne]

Hi Bastian,

On Mon, Mar 04, 2024 at 11:04:22PM +0100, Bastian Blank wrote:
> > Arguably, a cross toolchain build should probably search
> > /usr/include/. I went back and forth a bit with Matthias
> > about whether we could add this and did not fully understand his
> > reasons, but there is one technical reason we want to avoid it for now.
> > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed
> > and these packages can have differing versions. When that happens and we
> > search both /usr//include and /usr/include/, we'd
> > mix two glibc versions with usually bad results (been there).
> 
> But this is a search path.  If a file exists in one, the second one is
> not found.  So nothing can happen even from version skew.

The problem arises in the reverse sense. If a file does not exist in
one, it is searched in the second and erroneously may be found. That may
make tests pass that should not pass and typically causes a link failure
later. While I do not have a concrete example at hand, I have seen this
pattern repeatedly and generally favour moving stuff out of /usr/include
to avoid this kind of confusion that causes difficult to debug problems.
This also motivates #798955 (in addition to the problem with file
conflicts).

> > The other aspect here is that it is not sufficient to add
> > /usr/include/ to the search path as you also need
> > /usr/include to get a complete linux kernel headers experience. We
> > definitely do not want to add /usr/include, because that is known to
> > misguide configure tests performed for the target architecture.
> 
> We are talking about the toolchain itself.  What configure tests could
> that be?  Or is that premature optimization of the gcc build?

The one case I really do remember quite well is sanitizers. These should
not be enabled in the earlier toolchain stages and failing to disable
them tends to cause linker failures. I don't think it matches the
concrete situation exactly though. You also make a good case in your
followup reporting that gcc-13-cross actually builds.

> You just said that the search path used during the build of the
> toolchain and the one for everything else are unrelated.  So you are
> free to create $BUILD/tmp-include with symlinks for asm, asm-generic,
> linux.
> 
> The toolchain as installed already finds all headers.  So I still don't
> see why we need this in the final system.

I find this argument fairly convincing and hope Matthias also does.

Thank you

Helmut