Hi everyone, On Sat, 6 Jan 2024 11:41:14 +0200, Adrian Bunk <bunk@debian.org> wrote: > On Sat, Jan 06, 2024 at 10:02:18AM +0100, Paul Gevers wrote: > > On 05-01-2024 18:08, Aurelien Jarno wrote: > > > I have just given it back, let's see what happens. > > > > Didn't help. > > it did. Thanks for taking care of this. > > I asked rmadison: > > paul@mulciber ~ $ rmadison gcc-mingw-w64-i686-posix --suite=unstable > > gcc-mingw-w64-i686-posix | 12.3.0-9+25.3 | unstable | mips64el > > gcc-mingw-w64-i686-posix | 13.2.0-4+26.1 | unstable | amd64, arm64, > > armel, armhf, i386, ppc64el, riscv64 > > gcc-mingw-w64-i686-posix | 13.2.0-9+26.1 | unstable | s390x > > > > That version number for s390x looks weird compared to the version number > > for the other architectures. Could there be a problem in that area? > > That's fine, various binutils/gcc cross packages encode the version they > were built with in their own version number. > > Package: gcc-mingw-w64-i686-posix > Version: 13.2.0-4+26.1 > Built-Using: gcc-13 (= 13.2.0-4) Yup, the mingw-w64 toolchain builds using gcc-13-source and binutils-source, and embeds the version number of those. So some skew is expected during development, when uploads of gcc-13 or binutils happen faster than the buildds can all work their way through the builds; it all gets sorted out before release though (when all the "outdated Built-Using" binNMUs are done). > > PS: mips64el still fails, which now we check for mips64el again is a > > problem that needs to be resolved too. > > gcc-13 runs into the same binutils issue, I haven't yet checked whether > it's binutils or gcc or something else that changed and causes it. There are a few other issues with binutils anyway, I’m sorting them out with upstream. This is also fairly typical when using a snapshot build of binutils, since the mingw-w64 packages end up testing unusual combinations (mips64el for one, and big-endian arches targeting mingw-w64 for another). Regards, Stephen
Attachment:
pgpHwiPEZYT1k.pgp
Description: OpenPGP digital signature