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 <etienne.mollier@mailoo.org> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity.
Attachment:
signature.asc
Description: PGP signature