valgrind-if-available (3.18.1-1-1) unstable; urgency=medium
...
  * Drop mipsel as valgrind disagrees about blah blah baseline Loongson.


This is wrong, and it makes at least qtmir FTBFS.

If there is any problem with valgrind on mipsel
it should be discussed and resolved in valgrind first,
if valgrind is available then valgrind-if-available
has to provide it.

It is also unclear what the baseline problem is this changelog
entry is referring to, there is no open bug in the valgrind package
mentioned and the closest I could find was a bug that was fixed (sic)
5 years ago.

It is also suprising if this is really a mipsel-only issue as the
changelog claims, I would have expected any issues to also show
up on mips64el.

Therefore please report any issues with valgrind on mipsel as bugs
against src:valgrind, but in any case please make valgrind-if-available
always provide valgrind on all architectures where it is available.

Hello,

Bug #1022222 in qtmir reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ubports-team/qtmir/-/commit/f745393942624a373fb84989b54cff6573377b35
------------------------------------------------------------------------
debian/rules: Don't hard-code architectures with valgrind support. Simply disable valgrind if not found in $PATH. (Closes: #1022222).
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1022222

We believe that the bug you reported is fixed in the latest version of
qtmir, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1022222@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marius Gripsgard <marius@ubports.com> (supplier of updated qtmir package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 08 Feb 2023 00:44:49 +0100
Source: qtmir
Architecture: source
Version: 0.8.0~git20230207.ec35994-1
Distribution: unstable
Urgency: medium
Maintainer: Debian UBports Team <team+ubports@tracker.debian.org>
Changed-By: Marius Gripsgard <marius@ubports.com>
Closes: 1022222
Changes:
 qtmir (0.8.0~git20230207.ec35994-1) unstable; urgency=medium
 .
   [ Mike Gabriel ]
   * debian/rules:
     + Don't hard-code architectures with valgrind support. Simply disable
       valgrind if not found in $PATH. (Closes: #1022222).
   * debian/control:
     + Bump to versioned B-D on liblomiri-api-dev (>= 0.2.0).
 .
   [ Marius Gripsgard ]
   * New git snapshot
Checksums-Sha1:
 a1f406a39fcb992aa200e56ccb86b21f6b5c7197 3349 qtmir_0.8.0~git20230207.ec35994-1.dsc
 8f6b2a953f25ff2ea3bba58fbdb81a1c72506301 252228 qtmir_0.8.0~git20230207.ec35994.orig.tar.xz
 5ae570ab6ab5ad1c51a9995aecf4f2bec01826de 46560 qtmir_0.8.0~git20230207.ec35994-1.debian.tar.xz
 00e6fb717f15ae98fa917aedb264b1243e7e0d61 16486 qtmir_0.8.0~git20230207.ec35994-1_source.buildinfo
Checksums-Sha256:
 456eb1adf037828b33c01d296b08ebb08b4edc495aa1d22bc1f27b99adbb6588 3349 qtmir_0.8.0~git20230207.ec35994-1.dsc
 d7dcff2e60feffd5d3669468ce92ab5606eb3c7d548f2a8ed2da1ef7b7a235af 252228 qtmir_0.8.0~git20230207.ec35994.orig.tar.xz
 81736bebd9593770f0597b44ec1cf4f7b7afb443491f30d8d5f9c5598fba0085 46560 qtmir_0.8.0~git20230207.ec35994-1.debian.tar.xz
 eaf825917756280cc43a593bacdefc2846b4e13b3a8eea69b8e0e10e3adfa138 16486 qtmir_0.8.0~git20230207.ec35994-1_source.buildinfo
Files:
 219d27ee4f3bf0c913792fa019d2273c 3349 libs optional qtmir_0.8.0~git20230207.ec35994-1.dsc
 4b23632ab6fe4cdbd6244932b2f69548 252228 libs optional qtmir_0.8.0~git20230207.ec35994.orig.tar.xz
 a8e7aa65d5394bbeb2c53fd88cd0b275 46560 libs optional qtmir_0.8.0~git20230207.ec35994-1.debian.tar.xz
 8191540437dd6e75812339a1cd5988a4 16486 libs optional qtmir_0.8.0~git20230207.ec35994-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJHBAEBCgAxFiEEm65oPpnDJVLXb56DuvnOw/aSJ4kFAmPi4q4THG1hcml1c0B1
YnBvcnRzLmNvbQAKCRC6+c7D9pInib7zD/9DUXcltP6VkZ0Wbyxfl/5dMhzPZAVZ
Y+A7Engl2x0YIUCMUa3H7EgCMXFipujoNa3teav/KFZIcJoja6bi/eTtRCrGwFNg
/3ny2UYSff3wfa0m5NRehUMOD+ia8wGvk+euwDIei2se+PgIAOtXpjLK/4XIYcgO
QY6zQZBIRZMfTcA19qTx+5fXyU8ACZhkALXXVJ3Nl2rHenaQeUsRbk0cuLRS5fY5
fwVldYoAS4k1T2QqIhzu96FSK1zlxeXUKiumx0rC00TPnjtKDEHR6ZSXyRoY6M33
U2H7jzzG4Zn/bMGtSdi3CPqmcXIjLNG6z2DSUDEPBiBzfVUuPw9IC3BKvq/TFhT2
E0RhFqr0grhHymodGZezgN31f5cSKDMrRusCK+6pFd1he1ZrMBt32nXzWnnBhiU1
JH3aIPFIf0+ywdqIBLq8dqr4rXVS0WNi+i+sG8edpiA9+mldzbQkszvXCydOwXTu
W/DoMPtVc23nxp7UlHdE+msX2L+CyOiiXDnQxQ036knL63MGGqX+CkVCq7HgJGql
AavlLMEQ81NA+DspkQ6jky1Q8Q3I6cqnuv8MGx3fDOGbES7UYqG1NP3EYt8WH2RL
vRzw0pygfAxj59KFcPAApSJpPnZEqJ108PaRvk+ry2pLZBjRE7oFWgdqpfBYHFgF
5B80Nnj7mtY4Mw==
=r+l9
-----END PGP SIGNATURE-----

(I intended to avoid having to argue by implementing specific objective
tests that valgrind has to meet to be declared available, but I did not
manage to get that done.  Thus, arguing...)
available means you're using the package wrong: it may or may not pull in
valgrind, and the set of architectures can and will change without any
warning.  The whole purpose of this metapackage is to track valgrind's
availability so 100+ individual packages don't need to.

Ie, instead of:
  if arch in (foo bar baz quux)
     build --valgrind=yes
  else
     build --valgrind=no
you do:
  if `which valgrind >/dev/null`
     build --valgrind=yes
  else
     build --valgrind=no

No, this particular problem is that valgrind doesn't work on _some_
mipsel machines.  This doesn't make valgrind itself useless, but makes
it unsuitable for being ran as a part of automated testsuites.

As our buildds appear to be all Loongsons, coding some complex machinery
to detect the subarch at runtime would be a waste of time.  Flat out
saying "disable valgrind tests on mipsel" is easier and works good enough
for now.
https://buildd.debian.org/status/fetch.php?pkg=valgrind-if-available&arch=mipsel&ver=3.19.0-1-1&stamp=1667563987&raw=0

==1833049== Memcheck, a memory error detector
==1833049== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1833049== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1833049== Command: /tmp/___
==1833049==

VEX: Unsupported baseline
     Found: Loongson-baseline
Cannot continue. Good-bye

vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==1833049==    at 0x5804FB44: ??? (in /usr/libexec/valgrind/memcheck-mips32-linux)
==1833049==    by 0x5804FA2C: ??? (in /usr/libexec/valgrind/memcheck-mips32-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 1833049)
==1833049==    at 0x401B920: __start (in /lib/mipsel-linux-gnu/ld.so.1)
==1833049==    by 0x7EB7B088: ???
client stack range: [0x7EB78000 0x7EB7BFFF] client SP: 0x7EB7B090
valgrind stack range: [0x42878000 0x42977FFF] top usage: 5512 of 1048576


It appears that no one, both upstream and _in Debian_, cares enough about
mipsel to fix bugs or even report them, thus I don't expect it to be solved
anytime soon -- or, probably, ever, as mipsel is not long for this world.

But, as the trivial solution would be removing support for mipsel completely
from valgrind, I think users are better served by being provided something
that works on at least _some_ hardware.

This very same test works fine on mips64el.

Seems we understand "available" differently:
* for you, it means "shipped at all",
* for me, it means "works for a typical set of tasks".

valgrind on mipsel is functional on old hardware but dies even on "hello
world" on Loongson.  I consider this availability to be lacking.


My plans for this bug are:
* s/available/available and functional/ in the description
* run all tests even on marginal archs, but don't fail the build if it's
  an expected failure


Meow!