Hi Michael, following this morning upload of brian in experimental, out of the build logs[0], I can see so far, under tabular form:
debarch machine build flags tests
========= ========== ================ =======
amd64 x86_64 -march=native ok
arm64 aarch64 -march=native ok
armel armv7l -march=native ok
armhf armv7l -march=native ok
i386 i686 -march=native ok
mips64el mips64 -march=native ok
mipsel mips -march=native ok
ppc64el ppc64le -mcpu -mtune ok
s390x s390x -march=native ok
--------- ---------- ---------------- -------
alpha Build pending pending
hppa parisc64 identify failed ok
hurd-i386 i686-AT386 -march=native ok
m68k m68k no native tuning skipped
powerpc ? Build pending pending
ppc64 ? Build pending pending
riscv64 riscv64 no native tuning ok
sparc64 sparc64 -mcpu -mtune ok
--------- ---------- ---------------- -------
bsd-amd64 ? BD-Uninstallable skipped
bsd-i386 ? BD-Uninstallable skipped
ia64 ? BD-Uninstallable skipped
sh4 ? BD-Uninstallable skipped
x32 ? BD-Uninstallable skipped
[0] https://buildd.debian.org/status/package.php?p=brian&suite=experimental
I didn't expect an "i686-AT386" machine type on hurd-i386, and
even less catching it as it should, with -march=native. I also
didn't know the machine for hppa, but now I should be okay with
catching parisc* CPUs. I also recalled about a part of the
scripts/packages/mkdebian in Linux source code which does a
mapping of deveral deb archs and uname machine, so I'm expecting
to get most of my uname machines right from now on.
alpha and power (big endian) seemed rather busy, so I'm wary to
push too many more brian experimental build needlessly; the
build took more than five hours on riscv64 and still running.
Qemu has been faster on my riscv64 test, so probably a memory
concern. I pushed a new version[1] targeting experimental, more
appropriate hopefully, if you wish to have a look.
[1] https://salsa.debian.org/med-team/brian/
Would you think this would be okay for unstable, or should
remain within experimental ? (Given this is soft freeze,
remaining in experimental is probably the way to go, unless
performances are so slow it would justify an important bug.)
Cheers,
--
Étienne Mollier <[email protected]>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
signature.asc
Description: PGP signature
