Hi ladies and gentelhackers!

A lot of packages Build-Depend on valgrind, in order to run checks for
memory leaks, data races and what not during the testsuite. Alas, valgrind
is not available on some architectures, even release (armel) or want-to-be- release (riscv64). Keeping the list current requires watching the valgrind package, and not just the list it declares but archs where it actually
builds on (not x32...) and works (as of today all, but that wasn't always
the case).

You can now replace that list by:
Build-Depends: valgrind-if-available
or preferably:
Build-Depends: valgrind-if-available <!nocheck>
If you want to temporarily exclude an arch please do that with:
Build-Depends: valgrind-if-available [!zx-spectrum !pdp11]
instead of repeating the whole valgrind list.

Getting the list wrong results either in:
* failing to build on some archs, see eg.
https://buildd.debian.org/status/package.php?p=libdnf
* not running valgrind tests, letting bugs slide

And most packages get it wrong; the counts are:
7 valgrind [amd64 arm64 armhf i386 mips mips64el mipsel powerpc ppc64 ppc64el s390x]
5 valgrind
3 valgrind [amd64 i386 powerpc]
2 valgrind [amd64 i386]
2 valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] 2 valgrind [!riscv64]
2 valgrind <!nocheck>
1 valgrind-mpi [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64]
1 valgrind [i386 amd64 powerpc armhf]
1 valgrind [amd64]
1 valgrind [amd64 i386] <!nocheck>
1 valgrind [amd64 i386 armhf arm64] <!noinsttest>
1 valgrind [amd64 armhf i386 mips mipsel powerpc s390x]
1 valgrind [amd64 armhf arm64 i386 mips64el mipsel ppc64 ppc64el s390x]
1 valgrind [amd64 arm64 armhf i386 ppc64el s390x powerpc ppc64] <!nocheck>
1 valgrind [amd64 arm64 armhf i386 powerpc ppc64el x32]
1 valgrind [amd64 arm64 armhf i386 powerpc ppc64 ppc64el s390x] <!nocheck>
1 valgrind [amd64 arm64 armhf i386 mipsel mips64el powerpc ppc64 ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x]
1 valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64 x32]
1 valgrind [amd64 arm64 armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mips64 mips64el mips mipsel powerpc ppc64 ppc64el s390x]
1 valgrind [amd64 arm64 armhf i386 mips mipsel mips64 mips64el powerpc ppc64 ppc64el s390x x32]
1 valgrind [amd64 arm64 armhf i386 mips mips64el powerpc ppc64el s390x] <!nocheck>
1 valgrind [amd64 arm64 armhf i386 mips mips64 powerpc ppc64 ppc64el s390x] <!nocheck>
1 valgrind [amd64 arm64 armhf i386 mips mips64 mips64el mipsel powerpc ppc64 ppc64el s390x]
1 valgrind [!riscv64], valgrind (>= 1:3.15.0) [arm64]
1 valgrind [!ia64 !riscv64 !x32 !mips !sparc64 !sh4 !ppc64 !powerpcspe !hppa !alpha !mips64el !armhf !armel !mipsel !m68k]
1 valgrind [!arm64 !ppc64el !armel !alpha !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !m68k !powerpcspe !sh4 !sparc64 !x32]
1 valgrind [!arm64 !ppc64el !armel !alpha !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !m68k !powerpcspe !sh4 !sparc64 !x32 !ia64 !riscv64]

The correct answer currently is:
[amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64]
but it keeps changing, and you don't want to track it by hand if I can do
that for you.

Thus: please [b-]depend on valgrind-if-available.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver!
⠈⠳⣄⠀⠀⠀⠀

"Adam C. Powell, IV" <[email protected]>
mpich (U)
petsc (U)
slepc (U)

Adam Borowski <[email protected]>
libpmemobj-cpp
pmdk
pmemkv
vmemcache

Alastair McKinstry <[email protected]>
mpich (U)

Andreas Boll <[email protected]>
libdrm (U)
mesa (U)

Andreas Tille <[email protected]>
pyutilib (U)

Andres Salomon <[email protected]>
chromium (U)

Anton Gladky <[email protected]>
dyssol (U)
sundials (U)

Ayatana Packagers <[email protected]>
xorg-gtest

Benjamin Drung <[email protected]>
rdma-core

Bernd Zeimetz <[email protected]>
ceph (U)

Ceph Packaging Team <[email protected]>
ceph

ChangZhuo Chen (陳昌倬) <[email protected]>
jq

Christophe Trophime <[email protected]>
freefem++ (U)
getdp (U)

Christopher James Halse Rogers <[email protected]>
mir (U)

Debian Bridges Team <[email protected]>
libbloom

Debian Chromium Team <[email protected]>
chromium

Debian EFI <[email protected]>
fwupd

Debian GCC Maintainers <[email protected]>
libabigail

Debian GNOME Maintainers <[email protected]>
gnome-software

Debian GSS Team <[email protected]>
gss

Debian Mir Team <[email protected]>
mir

Debian Multimedia Maintainers <[email protected]>
kodi

Debian Octave Group <[email protected]>
octave

Debian Perl Group <[email protected]>
libfurl-perl
libtest-valgrind-perl

Debian Python Modules Team <[email protected]>
pyutilib

Debian Qt/KDE Maintainers <[email protected]>
qtmir (U)

Debian Remote Maintainers <[email protected]>
arctica-greeter

Debian Science Maintainers <[email protected]>
cthreadpool
deal.ii
dyssol
freefem++
mpich
petsc
petsc4py
slepc
slepc4py

Debian Science Team <[email protected]>
dolfin
fenics-dolfinx
fenicsx-performance-tests
getdp
mshr
sundials

Debian Shishi Team <[email protected]>
shishi

Debian UBports Team <[email protected]>
mir (U)
qtmir

Debian X Strike Force <[email protected]>
libdrm
mesa
xserver-xorg-video-intel

Debichem Team <[email protected]>
opendrop

Dima Kogan <[email protected]>
sundials (U)

Dimitrios Eftaxiopoulos <[email protected]>
freefem++ (U)

Drew Parsons <[email protected]>
dolfin (U)
fenics-dolfinx (U)
fenicsx-performance-tests (U)
mshr (U)
opendrop (U)
petsc (U)
petsc4py (U)
slepc (U)
slepc4py (U)
xserver-xorg-video-intel (U)

Felix Geyer <[email protected]>
libseccomp (U)

Florian Schlichting <[email protected]>
libtest-valgrind-perl (U)

Francis Murtagh <[email protected]>
armnn

Francois Mazen <[email protected]>
freefem++ (U)

Frédéric Pierret <[email protected]>
libdnf (U)

Gabriele N. Tornetta <[email protected]>
austin

Gaudenz Steinlin <[email protected]>
ceph (U)

Georges Khaznadar <[email protected]>
aseba

Graham Inggs <[email protected]>
deal.ii (U)

gregor herrmann <[email protected]>
libtest-valgrind-perl (U)

Gunnar Hjalmarsson <[email protected]>
gnome-software (U)

Héctor Orón Martínez <[email protected]>
device-tree-compiler

James Page <[email protected]>
ceph (U)

James Tocknell <[email protected]>
sundials (U)

Jeremy Bicha <[email protected]>
gnome-software (U)

Jeroen van der Heijden <[email protected]logy>
siridb-server (U)

Johannes Ring <[email protected]>
dolfin (U)
mshr (U)

Jonas Smedegaard <[email protected]>
abiword
libfurl-perl (U)

Jussi Pakkanen <[email protected]>
meson

Kees Cook <[email protected]>
libseccomp

Laurent Bigonville <[email protected]>
gnome-software (U)

Loic Minier <[email protected]>
dbus (U)

Luca Bruno <[email protected]>
libseccomp (U)

Mario Limonciello <[email protected]>
fwupd (U)

Marius Gripsgard <[email protected]>
mir (U)

Martin Quinson <[email protected]>
simgrid

Mathieu Malaterre <[email protected]>
dumpasn1

Matthias Klose <[email protected]>
libabigail (U)

Matthias Klumpp <[email protected]>
fwupd (U)
gnome-software (U)

Matthias Maier <[email protected]>
deal.ii (U)

maximilian attems <[email protected]>
xserver-xorg-video-intel (U)

Michael Biebl <[email protected]>
dbus (U)

Michael Gilbert <[email protected]>
chromium (U)

Michael Stapelberg <[email protected]>
xserver-xorg-video-intel (U)

Michel Le Bihan <[email protected]>
chromium (U)

Mihai Moldovan <[email protected]>
libdnf

Mike Gabriel <[email protected]>
arctica-greeter (U)
libdbusmenu (U)
mir (U)
qtmir (U)
xorg-gtest (U)

Paul Gevers <[email protected]>
siridb-server (U)

Rafael Laboissière <[email protected]>
octave (U)

Riku Voipio <[email protected]>
chromium (U)
device-tree-compiler (U)

Robbie Harwood (frozencemetery) <[email protected]>
gssproxy

Roger Shimizu <[email protected]>
libbloom (U)

Russ Allbery <[email protected]>
gss (U)
shishi (U)

Samuel Thibault <[email protected]>
hwloc
starpu

Sebastian Dröge <[email protected]>
dbus (U)

Simon Josefsson <[email protected]>
gss (U)
shishi (U)

Simon McVittie <[email protected]>
dbus (U)

Simon Quigley <[email protected]>
mir (U)

SiriDB Maintainers <[email protected]>
siridb-server

Sjoerd Simons <[email protected]>
dbus (U)

Stefano Rivera <[email protected]>
pypy
pypy3

Steffen Moeller <[email protected]>
cthreadpool (U)
pyutilib (U)

Steve McIntyre <[email protected]>
fwupd (U)

Stuart Prescott <[email protected]>
opendrop (U)

Sébastien Villemot <[email protected]>
octave (U)

The Ayatana Packagers <[email protected]>
libdbusmenu

Thomas Goirand <[email protected]>
ceph (U)

Timo Aaltonen <[email protected]>
gssproxy (U)

Torquil Macdonald Sørensen <[email protected]>
mpich (U)

Utopia Maintenance Team <[email protected]>
dbus

Vagrant Cascadian <[email protected]>
device-tree-compiler (U)

Vasyl Gello <[email protected]>
kodi (U)

Vincent Cheng <[email protected]>
xserver-xorg-video-intel (U)

Wookey <[email protected]>
armnn (U)

Євгеній Мещеряков <[email protected]>
diod

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski <[email protected]> wrote:

The correct answer currently is:
[amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64]
but it keeps changing, and you don't want to track it by hand if I can do that for you.

Thus: please [b-]depend on valgrind-if-available.

Do you have any suggestions on how to handle this when the valgrind
test is set by a configure flag?

The way I've been handling it is to just keep a hard-coded list of
valgrind architectures in sync between my debian/control and
debian/rules.

Thank you,
Jeremy Bicha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Feb 20, 2022 at 04:32:43PM -0500, Jeremy Bicha wrote:

On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski <[email protected]> wrote:

The correct answer currently is:
[amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] but it keeps changing, and you don't want to track it by hand if I can do that for you.

Thus: please [b-]depend on valgrind-if-available.

Do you have any suggestions on how to handle this when the valgrind
test is set by a configure flag?

Is the configure flag required to enable valgrind tests? If not, the very point of "configure" scripts is to auto-detect presence of tools.

The way I've been handling it is to just keep a hard-coded list of
valgrind architectures in sync between my debian/control and
debian/rules.

if which valgrind >/dev/null; then


Meow!
--
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢠⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄⠀⠀⠀⠀ agriculture, towns then cities. -- whitroth on /.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-02-20 at 19:45 +0100, Adam Borowski wrote:

A lot of packages Build-Depend on valgrind, in order to run checks for
memory leaks, data races and what not during the testsuite.  Alas, valgrind is not available on some architectures, even release (armel) or want-to-be- release (riscv64).  Keeping the list current requires watching the valgrind package, and not just the list it declares but archs where it actually
builds on (not x32...) and works (as of today all, but that wasn't always
the case).

This problem seems like one that will continue to happen as people add
valgrind to their build-deps, so I wonder if this should be a lintian
check and a Debian Janitor fixer rather than a once-off MBF.

You can now replace that list by:
    Build-Depends: valgrind-if-available

I wonder if there could be a better way to do this, perhaps the
valgrind package should be available on all arches but empty on the
ones where valgrind isn't available or doesn't work? Alternatively,
perhaps the valgrind-if-available binary package should get merged into
the valgrind source package for ease of keeping the arches in sync?

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmITJPkACgkQMRa6Xp/6 aaMCuA/9GzP5ep5DYKqypNIPumJvkEqRC7XYxI5iyfG73NbsWDuDgPQZcFcjBm6U 39Nrhm8/KLpZK/aUEnmpqpqx82gza7xSPBqsUpqUuKbLugAiEf+fK38bxa8gZGHK gPkZVoZzpkysIA/2n6m+W/r5VQOqY1ow3olh3yegkIaFWPIIa0GKdCn1PphniSVa sVw7LjTYmoiNgwfbLBSI/beqZCpLQyTrSpk7z3fKFYA1KTju1gHAajmzk9Kf+Gvz ZEeZzLmdfGTnKPTotxGtG2SmKlKbAd+rmPg96H9EMgqVtnVGhw2TA0RidHFtvvdh Ma7JRH7dywk81njQLF0utgV36TVbOgzikKVSEAr8WCfylLvGdSWbEISRq9D079Fy MPQXHPZSBAn6TSfffKzH3WtUn5MYZ+v7HiizbKaZrfb8KN/phjnHsctN+UsMYGg7 9R13eTBpp+qjEVQZSjyYSc5mH+JfRVl4Eovwbo0bzMAnQfgM7Q64aDuxNwuDSVwt ZZrjAUzyAWU/lidvdpcOpZlqoBL9JQ/w8tXQhGxgB8ZZl/ErhHTn4vXACD1CLJTP Xckthl99Y+2uI5thksNS16mvOMaXLpPukg0IgE0MrMNAybJnx/aTD2kWf1S4QVQh qw7jE4tfstTUiVq/sEIglbFQrJnELvKiQS/M3qeJAJwsR/tMesc=
=gH0c
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-02-20 at 22:43 +0100, Adam Borowski wrote:

On Sun, Feb 20, 2022 at 04:32:43PM -0500, Jeremy Bicha wrote:

On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski <[email protected]> wrote:

The correct answer currently is:
[amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] but it keeps changing, and you don't want to track it by hand if I can do that for you.

Thus: please [b-]depend on valgrind-if-available.

Do you have any suggestions on how to handle this when the valgrind
test is set by a configure flag?

Is the configure flag required to enable valgrind tests? If not, the very point of "configure" scripts is to auto-detect presence of tools.

The way I've been handling it is to just keep a hard-coded list of
valgrind architectures in sync between my debian/control and
debian/rules.

if which valgrind >/dev/null; then

This should use "command -v", not which, I think?

Ben.

--
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmIayJEACgkQ57/I7JWG EQl8lBAAxlYrmgVugxUtw27/pI0FvKs1CNzYB8jEWDPlmg4CZuXPvCJevH0iWGNd ZgFkK6Hc6b5uHLTxOikh9hqXnlG2nTkPqxR7bBHZz3Di85z/R5huJjqsik366ggx wT47SY8NBM548+p+xNj0t9bDkHj4MhVaxGVaQIIkhuq63050YEqZrzUYgeJB4GUW EWtveuSQ5RdtoBaMKs0F6LUeq+zqD4eL7vahzvMB2b725CGup24NdXIfx7XUmu8E 0OBmgo4oVzZTbKzejdTqPgLCd5THcFtlTvrHsk9kC0/cVr4zuq/frFd1S9UZ3DdH Hm/YVT+DTKm6w5WGQEt1zYsLd6LX7ljrUximcmexf+NYR/tZTzhJfIR/RdMV1vbi Md+FPYEW1zh4hV7jdkGUyF2zAkipU/kNiWuYF+IB42jZZxOov0vzTPIheeOznJRl ZFHxucx2WULhoFaLkeAxqcT+vpie2+j/ujKEB/Nu9AEgQrfxyKLIzUpoadWIvFd0 PWWQf7IDUS2VfWf2ZtM/h7QUsmOn+fzBKOI+gHy+M7BjQqrlA8/0HB7nxMZ5onzZ +vCQWs4Ee5xe5ULGU8XB2wOpFyaBBJcoFOBsUO/Tm6MahhWSxg4fZuiRyGK1CZG+ Ubzg1j/U3KuGlyf78Ov5ewSV8WGMHI6ry1irz/pzkzFZy/V6AJg=
=TQQL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Feb 27, 2022 at 01:40:48AM +0100, Ben Hutchings wrote:

On Sun, 2022-02-20 at 22:43 +0100, Adam Borowski wrote:

if which valgrind >/dev/null; then

This should use "command -v", not which, I think?

No, and the recent debacle revealed enough reasons that I'm pondering a MBF
to change that _back_ in packages which followed the bad advice.

Among others, "command -v"
* gets confused by aliases
* it fails to check +x perm both in dash and bash. While this is something
required by POSIX, neither shell in unstable checks that, reporting the
command as executable if it's not.
* built-ins get reported as available. And busybox has even "dpkg"
built-in, with a pretty bad implementation.
while the only reason to migrate was:
* one less tool to maintain


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ 'Russkiy voyennyi korabl, idi nakhuy'
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄⠀⠀⠀⠀

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Feb 27, 2022 at 03:40:09AM +0100, Adam Borowski wrote:

No, and the recent debacle revealed enough reasons that I'm pondering a MBF to change that _back_ in packages which followed the bad advice.

do you have a # as a starter?


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Alles weird gut.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmIa8SEACgkQCRq4Vgaa qhyqHw/9ElnlLQP2rR0WmRUGaPSUG+ilmcozj1lTN5iHFwZKy2poZNh/Lt74luli PvZO86EFvRt6NoWTtME+UMc5Tm+LKgwdjLXjJdKk7bQokNnq64fo4QGaOCu21/up YD66x5ZSNU8u6AfIKb1ACh0lsEyU0GoSkpNG4qAOiWOsywQnoynEjdK8gBllJ610 vZUNIhHjPbxcWVB7NOdyzt5/q1rV+wHFffV3AAy+q8wUEY63rSseqlsiQC5cgaVi iSi+d0w8dhijGHPDpNANRyjrZBgbbiiDBPEPOEbYG4gOZZu76i81BHD3ADZERPtq kdkT1N4a+rT2SJB9AC4ZgBG3uzvTGbQO7uVArC88iOuCskBpwhCVwcHUsS6nWLbX vWgvZsWqegsAf6IDrotcylyysVroydDmB75RPx9xifUwJSj/5uTHU+wqgbVkznBo caIkzWtk23Wy1yJgJ6Ak8+0+FGqPjabc0TA0lQbkZYQMViRmcO3a6FNKwU+W6nOt lVeKBFvAT+OPuOkVYT+uvDhseIk45UMOoDhuUmB5OxQIzLpJsAqG52Dm1olGvLwi 8RJI+fG/jdUnnFbUL92aP8ghJ6P3AIag9FPzHJQz67wL5N9l+847Ig7ldvGlS9AP N5UB5IOEP8NdQEnu8hLkKhbtLCM/BGgi72XSI0JnM381jeUTabg=
=rlLV
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-02-27 Adam Borowski <[email protected]> wrote:

On Sun, Feb 27, 2022 at 01:40:48AM +0100, Ben Hutchings wrote:

[...]

This should use "command -v", not which, I think?

No, and the recent debacle revealed enough reasons that I'm pondering a MBF to change that _back_ in packages which followed the bad advice.

Among others, "command -v"
* gets confused by aliases
* it fails to check +x perm both in dash and bash. While this is something
required by POSIX, neither shell in unstable checks that, reporting the
command as executable if it's not.
* built-ins get reported as available. And busybox has even "dpkg"
built-in, with a pretty bad implementation.

[...]

Hello,

Is any of this relevant in the context Debian package building
(especially by autobuilders)? The only thing I can see is if $developer
had a nonexec ~/bin/somecommand and wondered why the local behavior
differed from the autobuilders. Aliases are a non-issue. Built-ins
(like command -v) actually are available, and when the respective
command is called the builtin will be used.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-02-27 at 03:40 +0100, Adam Borowski wrote:

Among others, "command -v"

[...]

* built-ins get reported as available.  And busybox has even "dpkg"
built-in, with a pretty bad implementation.

Like this?

+---
| % which which
| which: shell built-in command
+---

I suggest to implement a new utility named
`/usr/bin/posix-which2` utility if you do not want that ;-)
(Only after proper standardization of course.)

Ansgar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)