You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A tracking issue? Roadmap? TODO list? Notes? of sorts for things that need to be handled in order to get Nixpkgs¹ working natively on powerpc64-linux (the big-endian variant, not powerpc64le-linux). I could immediately bulk-submit PRs for all of these (and some more issues I already debugged a year ago during a previous effort), but submitting fixes for a not-yet-functioning stdenv feels abit silly.
The following things need to be addressed for stdenv to build & work. I would consider this issue "done" and closable once these are done, as anything after stdenv can just be fixed incrementally. No need to keep this ticket open for all eternity. 🙂
These are some additional problems I've encountered after reaching stdenv and attempting to build my way up so some graphical applications. I'll document things here as I encounter them while the above list isn't done, just so I don't forget about them. Once stdenv works on master, I'll just submit PRs for these & future problems.
llvmPackages*.llvm: All MCJIT and OrcMCJIT tests fail.
(I haven't actually tested any llvm other than the default one due to long compile times, but with a failure this massive I don't see how this could be version-specific.)
Currently just disabling doCheck, not sure about the why's & how's on this.
openexr & openexr_3: Hitting all the same test failures as Fedora: Some tests fail for s390x arch AcademySoftwareFoundation/openexr#1175, and ones reported in other upstream issues over the years.
Will disable the tests since it doesn't look like full fixes for these are in sight, although I wonder if openexr* in general is broken on big-endian and should instead just be marked as such?
tpm2-tss: Same unit tests failures as reported upstream on s390x (s390x test failures tpm2-software/tpm2-tss#2531), but additionally all integration tests get stuck in a retry loop and eventually time out.
Haven't looked into what's going on with the integration tests yet, but same thoughts on this as with openexr: Disabling tests for now, but possibly more of a broken situation.
Example of a failing integration test
ERROR: test/integration/sys-asymmetric-encrypt-decrypt
======================================================
Trying to start simulator mssim
Starting simulator on port 2218
successfully started daemon: tpm_server with PID: 95717
/build/source
simulator PID: 95717
Port conflict? Cleaning up PID: 95717
./script/int-log-compiler-common.sh: line 246: kill: (95717) - No such process
Failed to start simulator: port 2218 or 2219 probably in use. Retrying in 2.
Starting simulator on port 15806
successfully started daemon: tpm_server with PID: 95767
/build/source
simulator PID: 95767
Port conflict? Cleaning up PID: 95767
./script/int-log-compiler-common.sh: line 246: kill: (95767) - No such process
Failed to start simulator: port 15806 or 15807 probably in use. Retrying in 4.
Starting simulator on port 30400
successfully started daemon: tpm_server with PID: 95799
/build/source
simulator PID: 95799
Port conflict? Cleaning up PID: 95799
./script/int-log-compiler-common.sh: line 246: kill: (95799) - No such process
Failed to start simulator: port 30400 or 30401 probably in use. Retrying in 8.
Starting simulator on port 31390
successfully started daemon: tpm_server with PID: 95831
/build/source
simulator PID: 95831
Port conflict? Cleaning up PID: 95831
./script/int-log-compiler-common.sh: line 246: kill: (95831) - No such process
Failed to start simulator: port 31390 or 31391 probably in use. Retrying in 16.
Starting simulator on port 6842
successfully started daemon: tpm_server with PID: 95863
/build/source
simulator PID: 95863
Port conflict? Cleaning up PID: 95863
./script/int-log-compiler-common.sh: line 246: kill: (95863) - No such process
Failed to start simulator: port 6842 or 6843 probably in use. Retrying in 32.
Starting simulator on port 59214
successfully started daemon: tpm_server with PID: 95895
/build/source
simulator PID: 95895
Port conflict? Cleaning up PID: 95895
./script/int-log-compiler-common.sh: line 246: kill: (95895) - No such process
Failed to start simulator: port 59214 or 59215 probably in use. Retrying in 64.
TPM20TEST_TCTI_NAME=socket
TPM20TEST_DEVICE_FILE=
TPM20TEST_SOCKET_ADDRESS=127.0.0.1
TPM20TEST_SOCKET_PORT=59214
TPM20TEST_TCTI=mssim:host=127.0.0.1,port=59214
WARNING:tcti:src/util/io.c:262:socket_connect() Failed to connect to host 127.0.0.1, port 59214: errno 111: Connection refused
Failed to initialize tcti context: 0xa000a
TPM_StartUp failed
./script/int-log-compiler-common.sh: line 195: kill: (95895) - No such process
failed to kill daemon process with PID: 95895
ERROR test/integration/sys-asymmetric-encrypt-decrypt.int (exit status: 99)
¹: My dream would be NixOS on powerpc64-linux via a USB installer image, but that's definitely a separate thing to tackle (and something I've never dabbled into before).
A tracking issue? Roadmap? TODO list? Notes? of sorts for things that need to be handled in order to get Nixpkgs¹ working natively on
powerpc64-linux(the big-endian variant, notpowerpc64le-linux). I could immediately bulk-submit PRs for all of these (and some more issues I already debugged a year ago during a previous effort), but submitting fixes for a not-yet-functioningstdenvfeels abit silly.The following things need to be addressed for
stdenvto build & work. I would consider this issue "done" and closable once these are done, as anything afterstdenvcan just be fixed incrementally. No need to keep this ticket open for all eternity. 🙂powerpc64-linuxis broken, preventing cross-compiledfreshBootstrapTools.bootstrapFilesfrom being usable.Waiting for bintools-wrapper: fix dynamic linker for powerpc64 big-endian #247682 to fix this.
bootstrapFilesto be added forpowerpc64-linuxso native bootstrapping can begin.Previous attempt: pkgs/stdenv/linux: add powerpc64 bootstrap files #177001
Current attempt: pkgs/stdenv/linux: Add powerpc64 bootstrap-files #255451
opensslneeds aconfigureScriptentry to be added forpowerpc64-linux, otherwise it warns about & attempts to do a 32-bit build.Required
configureScript:"./Configure linux-ppc64"openssl: Add configureScript entry for powerpc64-linux #295268
pcreneeds a patch from Void Linux for its tests to pass for me: void-linux/void-packages:srcpkgs/pcre/patches/ppc-icache-flush.patchFrom the patch comments, this one might be due to the age of my CPU (POWER4)? Haven't checked if
pcre2has the same problem.pcre: Fetch patch for powerpc64-linux #295442
These are some additional problems I've encountered after reaching
stdenvand attempting to build my way up so some graphical applications. I'll document things here as I encounter them while the above list isn't done, just so I don't forget about them. Oncestdenvworks on master, I'll just submit PRs for these & future problems.llvmPackages*.llvm: AllMCJITandOrcMCJITtests fail.(I haven't actually tested any
llvmother than the default one due to long compile times, but with a failure this massive I don't see how this could be version-specific.)Currently just disabling
doCheck, not sure about the why's & how's on this.openexr&openexr_3: Hitting all the same test failures as Fedora: Some tests fail for s390x arch AcademySoftwareFoundation/openexr#1175, and ones reported in other upstream issues over the years.Will disable the tests since it doesn't look like full fixes for these are in sight, although I wonder if
openexr*in general isbrokenon big-endian and should instead just be marked as such?tpm2-tss: Same unit tests failures as reported upstream on s390x (s390x test failures tpm2-software/tpm2-tss#2531), but additionally all integration tests get stuck in a retry loop and eventually time out.Haven't looked into what's going on with the integration tests yet, but same thoughts on this as with
openexr: Disabling tests for now, but possibly more of abrokensituation.Example of a failing integration test
¹: My dream would be NixOS on
powerpc64-linuxvia a USB installer image, but that's definitely a separate thing to tackle (and something I've never dabbled into before).