Re: MBF: valgrind-if-available
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
Re: MBF: valgrind-if-available
On 2022-02-27 Adam Borowski 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'
Re: MBF: valgrind-if-available
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. signature.asc Description: PGP signature
Re: MBF: valgrind-if-available
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' ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: MBF: valgrind-if-available
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 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 signature.asc Description: This is a digitally signed message part
Re: MBF: valgrind-if-available
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 signature.asc Description: This is a digitally signed message part
Re: MBF: valgrind-if-available
On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski 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
Re: MBF: valgrind-if-available
On Sun, Feb 20, 2022 at 04:32:43PM -0500, Jeremy Bicha wrote: > On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski 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 /.
MBF: valgrind-if-available
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 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 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] 1 valgrind [amd64 i386 armhf arm64] 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] 1 valgrind [amd64 arm64 armhf i386 powerpc ppc64el x32] 1 valgrind [amd64 arm64 armhf i386 powerpc ppc64 ppc64el s390x] 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] 1 valgrind [amd64 arm64 armhf i386 mips mips64 powerpc ppc64 ppc64el s390x] 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" mpich (U) petsc (U) slepc (U) Adam Borowski libpmemobj-cpp pmdk pmemkv vmemcache Alastair McKinstry mpich (U) Andreas Boll libdrm (U) mesa (U) Andreas Tille pyutilib (U) Andres Salomon chromium (U) Anton Gladky dyssol (U) sundials (U) Ayatana Packagers xorg-gtest Benjamin Drung rdma-core Bernd Zeimetz ceph (U) Ceph Packaging Team ceph ChangZhuo Chen (陳昌倬) jq Christophe Trophime freefem++ (U) getdp (U) Christopher James Halse Rogers mir (U) Debian Bridges Team libbloom Debian Chromium Team chromium Debian EFI fwupd Debian GCC Maintainers libabigail Debian GNOME Maintainers gnome-software Debian GSS Team gss Debian Mir Team mir Debian Multimedia Maintainers kodi Debian Octave Group octave Debian Perl Group libfurl-perl libtest-valgrind-perl Debian Python Modules Team pyutilib Debian Qt/KDE Maintainers qtmir (U) Debian Remote Maintainers arctica-greeter Debian Science Maintainers cthreadpool deal.ii dyssol freefem++ mpich petsc petsc4py slepc slepc4py Debian Science Team dolfin fenics-dolfinx fenicsx-performance-tests getdp mshr sundials Debian Shishi Team shishi Debian UBports Team mir (U) qtmir Debian X Strike Force libdrm mesa xserver-xorg-video-intel Debichem Team opendrop Dima Kogan sundials (U) Dimitrios Eftaxiopoulos freefem++ (U) Drew Parsons dolfin (U) fenics-dolfinx (U) fenicsx-performance-tests (U) mshr (U)
