https://bugzilla.redhat.com/show_bug.cgi?id=1350884 --- Comment #60 from Andy Mender <andymenderunix@xxxxxxxxx> --- > I cannot recreate s390x failures locally, even tests work fine. I have no idea what the issue is on koji. I experimented some with building on copr but it seems to timeout even with the max possible value[0]. Theoretically, Koji uses the same mock environment you would use locally, but of course resource allocation is different. Same with COPR. In some cases like this one, the errors are not reproducible :(. > I also poked at the armhfp test failues some more. They're segfaults (in qemu?), not regular test failures. I again have no idea what the issue is. I tried patching out the tests that segfault and then started running into tests that hang indefintely (eg. gdb.base/utf8-identifiers.exp). I think the best course of action is to disable tests for armhfp, and possibly s390x as well to work around timeouts there? armhfp is actually virtualized on x86_64 machines, at least that's what I see in COPR. So you might run into resource limitations (especially hard disk space) and weird errors again. In general I would disable tests altogether if they're the source of issues and the compiler toolchain itself works as intended. If it was possible to create patches applicable to *all* supported architectures to fix the tests, these could then be upstreamed to TI for inclusion in future tarballs. But since upstream is really just the tarballs and errors on Koji and COPR are not reproducible, I'd say leave them out :). There is also the option to make tests conditional altogether by adding "%bcond_with tests" at the top of the SPEC file and enclosing the test calls in "%if %{with tests} <> %endif", and add a comment explaining why the tests are conditional (f.e. fails in build systems on virtualized hardware). Then, you can run a local build with "rpmbuild -ba --with tests" to run the tests explicitly. More here: http://rpm.org/user_doc/conditional_builds.html > My last remaining question is why I cannot get all packages to install by doing a `dnf install msp430-elf-toolchain` as described in comment 35. I thought the issue was the wrong requires on the main package, but I've corrected those in the latest spec[1] (lines 50-53) and it still doesn't work. Any thoughts? I noticed that the last successful armhfp build from COPR mentioned in [0] doesn't generate a msp430-elf-toolchain binary RPM at all. There is also no %files section for msp430-elf-toolchain so the SPEC file now behaves in a way similar to Golang and Python packages - the SRPM is msp430-elf-toolchain, but the generated RPMs are only for the subpackages. I don't know how to make it so that msp430-elf-toolchain registers in dnf as a metapackage, but I found this: https://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/sect-Creating_a_Meta_Package.html -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
