Closed ZedThree closed 4 years ago
I can reproduce this locally with the .travis_fedora.sh
script, so it's not a Travis thing. I've not working out how to get a debugger on it yet, as it makes a container.
Also, I can't reproduce this on a Fedora 32 machine (as opposed to 33) using PETSc 3.13.0 local build (as opposed to 3.13.4 system build).
Looks like Fedora updated to PETSc 3.13.4 a couple of weeks ago, which might be it. I'll try building that version of PETSc locally.
For running gdb within a container, I normally use:
podman run --rm --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -it registry.fedoraproject.org/fedora:rawhide
I'll have a look. Recently there was also a mass-rebuild, where LTO got enabled, but I only had issues on s390x architecture, not on x86_64 ...
Thanks! I was literally just struggling with that!
I spotted a commit message about mass rebuild, but didn't know what that was about. I might try LTO natively, not in a container.
No worries, I have a cannot remember it either, I have an alias for that :-)
Mass rebuild is where every package is rebuild to ensure they are still building from source, and also ensures that all packages are build with the most recent flags/compilers.
The issues might also be related to flexiblas, a wrapper for blas that allows to switch blas implementations at runtime ...
Could be caused by https://github.com/mpimd-csc/flexiblas/issues/1
Thanks @dschwoerer ! Glad it isn't us. I don't think there's really an easy/nice way to disable the fedora job just for a few PRs. I'll try to keep an eye on that issue and then rerun the fedora job when it's in.
Looks like the fix in #2079 failed when it merged into next: https://travis-ci.org/github/boutproject/BOUT-dev/jobs/718552571#L587
warning: /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/MUMPS-common-5.3.3-1.fc33.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
Fedora - Rawhide - Developmental packages for t 1.6 MB/s | 1.6 kB 00:00
GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64 (0x9570FF31) is already installed
The GPG keys listed for the "Fedora - Rawhide - Developmental packages for the next Fedora release" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.. Failing package is: MUMPS-common-5.3.3-1.fc33.noarch
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
Public key for MUMPS-mpich-5.3.3-1.fc33.x86_64.rpm is not installed. Failing package is: MUMPS-mpich-5.3.3-1.fc33.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
...
Public key for libxcrypt-4.4.16-7.fc34.x86_64.rpm is not installed. Failing package is: libxcrypt-4.4.16-7.fc34.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
Public key for zlib-1.2.11-22.fc33.x86_64.rpm is not installed. Failing package is: zlib-1.2.11-22.fc33.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
Error: GPG check FAILED
Might be a Travis cache problem? Is there a way to force install those keys?
This seems to be fixed in next, do we want backports for 4.x and and 4.3.x ?
It's probably worth backporting the Fedora job to 4.4, probably not to 4.3, just because I want to release 4.4 soon.
Also, forgot to say, thanks for sorting this out! :tada:
Lots of PRs currently failing due to the Fedora build on Travis. Weirdly in
parseCommandLineArgs
, so should have nothing to do with PETSc. @dschwoerer any ideas?