| Message ID | cover.1617711307.git.efraim@flashner.co.il |
|---|---|
| Headers | show |
| Series | Add 32-bit powerpc support | expand |
Hi! Efraim Flashner <efraim@flashner.co.il> skribis: > https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-ppc > > The wip-ppc branch on Savannah is currently in a good state. With the > recent rapid churn on core-updates I haven't been very quick about > rebasing on core-updates but I can confirm that building out to mesa > works. Building is slow, it took 6 days to build from guile-final to > mesa without stopping. > > The patches start with adding the bootstrap binaries for powerpc. Woohoo! > gnu/build/vm.scm | 1 + > gnu/local.mk | 2 + > gnu/packages/base.scm | 11 +- > gnu/packages/bootstrap.scm | 37 +- > gnu/packages/commencement.scm | 21 +- > gnu/packages/debug.scm | 2 + > gnu/packages/disk.scm | 44 + > gnu/packages/gl.scm | 18 +- > gnu/packages/guile.scm | 21 +- > gnu/packages/nss.scm | 7 +- > .../patches/mac-fdisk-gentoo-patchset.patch | 866 +++++++ > gnu/packages/patches/mac-fdisk-p18.patch | 2070 +++++++++++++++++ > gnu/packages/version-control.scm | 6 +- > guix/packages.scm | 4 +- > m4/guix.m4 | 4 +- > 15 files changed, 3096 insertions(+), 18 deletions(-) > create mode 100644 gnu/packages/patches/mac-fdisk-gentoo-patchset.patch > create mode 100644 gnu/packages/patches/mac-fdisk-p18.patch I haven’t looked into details so I’ll just share thoughts from a maintenance viewpoint: 1. Those fdisk patch file names will make ‘guix lint’ unhappy. :-) 2. Apart from mac-fdisk-p18.patch, which looks relatively big, the changes seem to be rather non-intrusive, so it’s tempting to merge them (on ‘core-updates’ I guess?). 3. OTOH, what will be the status of this architecture? I don’t think new 32-bit PPC hardware is being made (right?), so I guess we probably won’t have substitutes for that architecture. That means it won’t be supported at the same level as other architectures and may quickly suffer from bitrot. I’m torn between #2 and #3. What do people think? Thanks, Ludo’.
Hi, On Sat, Apr 17, 2021 at 6:04 PM Ludovic Courtès <ludo@gnu.org> wrote: > 3. OTOH, what will be the status of this architecture? I don’t think > new 32-bit PPC hardware is being made (right?), so I guess we > probably won’t have substitutes for that architecture. That means > it won’t be supported at the same level as other architectures and > may quickly suffer from bitrot. > > I’m torn between #2 and #3. I don't think we have checked that ppc64 is unable to build this in a similar way that x86_64 is able to build 32 bit x86 without virtualization. But that may be possible, so all hope is not lost.
On Sat, Apr 17, 2021 at 06:04:02PM +0200, Ludovic Courtès wrote: > Hi! > > I haven’t looked into details so I’ll just share thoughts from a > maintenance viewpoint: > > 1. Those fdisk patch file names will make ‘guix lint’ unhappy. :-) I'll make sure to touch them up. I was also not happy about the supported-architectures field of the package, I took that from Debain (or was it Gentoo?) but I'm not sure of a technical reason why it can't be built from other architectures. > 2. Apart from mac-fdisk-p18.patch, which looks relatively big, the > changes seem to be rather non-intrusive, so it’s tempting to merge > them (on ‘core-updates’ I guess?). Before I found some of the patches I played around with fixing the package. Without looking at the patches too closely some of them fix warnings and some of them actually make it compile correctly. > 3. OTOH, what will be the status of this architecture? I don’t think > new 32-bit PPC hardware is being made (right?), so I guess we > probably won’t have substitutes for that architecture. That means > it won’t be supported at the same level as other architectures and > may quickly suffer from bitrot. I don't know about new 32-bit powerpc hardware, I think it's only being newly created for the embedded and networking space. As far as operating systems with support¹ Adélie Linux is the only one I know that's actually targeting the machines. I found that emulation on my desktop (Ryzen 3900XT, 24 threads) is faster than building on native hardware (1 core, 1.5GB of RAM, original 4200 RPM disk), edging it out on single threaded compiling and doing great when it comes to using multiple cores and parallel builds. Ignoring how to create an OS image if we just targeted, say, mesa and maybe one or two other packages, we could have a core set which doesn't change regularly and won't take up too much emulated build time but will save days of compile time. > I’m torn between #2 and #3. > > What do people think? The fear of bit-rot is real and I think we should mention in the manual (when I actually write the section) that support is best-effort with minimal substitutes. > Thanks, > Ludo’. ¹ https://en.wikipedia.org/wiki/PowerPC#Operating_systems_with_native_support
Hi, On Sat, Apr 17, 2021 at 9:44 PM Efraim Flashner <efraim@flashner.co.il> wrote: > As far as operating systems with support¹ Adélie Linux is the only > one I know that's actually targeting the machines. There's also a void port being worked on, but not upstreamed yet (https://voidlinux-ppc.org) gentoo, openbsd & netbsd also still have support too.
This looks to be about 2 weeks worth of time since the last email, with about 10 days of continuous building and is based on commit 76fc36d0a7215979bb74c05840f5a4de4ab5ea93 which changes the default gcc to 8. I'll inline my comments in the top of each of the patches. Some of the patches are going straight to core-updates but I've included them anyway since the patchset is available in the official repo in the wip-ppc branch and that's where I developed them. Efraim Flashner (12): gnu: bootstrap: Add support for powerpc-linux. gnu: guile-3.0: Fix building on powerpc-linux. gnu: gcc-boot0: Use 128-bit long-double on powerpc-linux. gnu: binutils: Fix bug in test suite in libiberty. gnu: mesa: Add support for powerpc-linux. gnu: Add mac-fdisk. gnu: american-fuzzy-lop: Add support for powerpc-linux. build: qemu-command: Add support for powerpc. gnu: mercurial: Skip tests on powerpc-linux. gnu: nss: Skip tests on powerpc-linux. gnu: zstd: Adjust test suite for 32-bit architectures. gnu: glib: Disable failing test. gnu/build/vm.scm | 1 + gnu/local.mk | 4 + gnu/packages/base.scm | 3 +- gnu/packages/bootstrap.scm | 37 +- gnu/packages/commencement.scm | 12 +- gnu/packages/compression.scm | 4 +- gnu/packages/debug.scm | 2 + gnu/packages/disk.scm | 43 + gnu/packages/gl.scm | 33 +- gnu/packages/glib.scm | 16 +- gnu/packages/guile.scm | 17 +- gnu/packages/nss.scm | 7 +- .../binutils-libiberty-endianness-bug.patch | 36 + .../patches/glib-skip-failing-test.patch | 27 + .../patches/mac-fdisk-gentoo-patchset.patch | 866 +++++++ gnu/packages/patches/mac-fdisk-p18.patch | 2070 +++++++++++++++++ gnu/packages/version-control.scm | 6 +- guix/packages.scm | 4 +- m4/guix.m4 | 4 +- 19 files changed, 3157 insertions(+), 35 deletions(-) create mode 100644 gnu/packages/patches/binutils-libiberty-endianness-bug.patch create mode 100644 gnu/packages/patches/glib-skip-failing-test.patch create mode 100644 gnu/packages/patches/mac-fdisk-gentoo-patchset.patch create mode 100644 gnu/packages/patches/mac-fdisk-p18.patch base-commit: f08b070019a3c1697bb0b4a783dcd4f31243715a prerequisite-patch-id: b98fc3a62ea8cceddca93361a4621026cebdb8e9 prerequisite-patch-id: 349889c70ebae8711909e6dfc0329235fee1a319 prerequisite-patch-id: dd3b6fe2e61b8588333468e597efec90314e482e prerequisite-patch-id: 9ffff5964df281b3feb46795c5875c1091136fb9 prerequisite-patch-id: c150ac2fb2988685f28d788f4924b74a6264dce7 prerequisite-patch-id: a08c6f0dd727f598ef1258bb4233cfcec78913ee prerequisite-patch-id: e36e1a27ce5055e53d5638f7139b4cf8c1ee68bf prerequisite-patch-id: e59cdf3bd91cdba9e39d79d32c650eefea1749fd prerequisite-patch-id: 2a1b37ff2e9b6f6787f4f3262d71cc26a005ccab prerequisite-patch-id: 5cf027408739a4b2661cdf2709abdb8f1f06ce81 prerequisite-patch-id: 6deb5fd40689a243b1cce2c2fa5cca298bce253b prerequisite-patch-id: 4c113e2088ef2674d35d985024c2a41daa8c679c prerequisite-patch-id: edd89720757f9d3cedab3f3832abb4a8ec8bd83f prerequisite-patch-id: 01258be2f32995622720bbc2eac1874282033604 prerequisite-patch-id: ed2fbb545f52e3ae813dc1b27e91e7ce2c84bce7 prerequisite-patch-id: 3523cc33853e2ff01d7b2916f5c481b052a674b5 prerequisite-patch-id: 92482c9dff576aa675e96a15bd02bd7471be517b prerequisite-patch-id: f51d60f4622d9badefacdbb419d26c92a9387286 prerequisite-patch-id: dd2f7be90323949247ee684840ceea90ab2aed30 prerequisite-patch-id: f5f2f3cad462eb3c42df531f4b7fb0b2dc11959d prerequisite-patch-id: ca605868541fdc9d2521c9bad0135a7a6e0b25b0 prerequisite-patch-id: 5ea5961816f5e60b38dbbacc6986860585d5b5c4 prerequisite-patch-id: 6d1cf903247a8ba700eb7b160b58d9b30b012a85 prerequisite-patch-id: 9d2c5115e7e6d19a06019cce74b58d036bc8f0d8 prerequisite-patch-id: b3699959ce306c85c4ed4756746e5273044f175a prerequisite-patch-id: c587c3ca1d6bc31b1ff7f242066a8dd1603d3268 prerequisite-patch-id: 8fb15f1844dfe713c745b8095750912e03449d64 prerequisite-patch-id: fa64eb7a3a6312c0351e3452ad0300014a1cb2a0 prerequisite-patch-id: 84d9c39b89b986e096677904a5328b34e0072d30 prerequisite-patch-id: 0a0b1370f74ade7fcb989bd7e35520e9adac625e prerequisite-patch-id: db9f94813d400e6734a1c80e40ad90aa7c1dd195 prerequisite-patch-id: db6b99cbc6e931613643690b3f72b41d73acf1b7 prerequisite-patch-id: 8441973a4f8c0f1713939fcd489274b7d30f44e4 prerequisite-patch-id: 9dd81d9a919ec6ca7f4bf07affdb7606f216cf44 prerequisite-patch-id: 88e793b3c2f41f4736b0867aaa5359a1a2f5df8f prerequisite-patch-id: 7182f001b5ebaa7aafccf5d4c7e02e086ac6d25a prerequisite-patch-id: fc8ca96ac1c7eb95a9326b2c2489f767c3f3184d prerequisite-patch-id: 317a9f00e31e3a5a85542139bb70bfdadb9d7839 prerequisite-patch-id: 99da8e1149653fa8c9ebd12195940648a47ca239 prerequisite-patch-id: 9b7227eb2f7dea6df29ed65052b5ae5f1c27d3d6 prerequisite-patch-id: f6c62975dd823d0197d0448b321d9c86ffc84b34 prerequisite-patch-id: d4b83cb1b38074aa3d2387e11da261903e2cf367 prerequisite-patch-id: ccd7ad8358c6ad36f674fe0e428e39685c78273a prerequisite-patch-id: 1a75e1a0ecb0704ee733d5a0c101439ffb2cf2f8 prerequisite-patch-id: c92f71717b9ac1f3cc0d3e3ef98cc3b215053fa0 prerequisite-patch-id: 96ef523637cc7c065baf5934ea97c3f9d9cc4fbd prerequisite-patch-id: 4afe0a36b064e1cf3f2186aa82dd830ec0c4075d prerequisite-patch-id: 04bb17b224108c967be9bf425e444166d60ae0d1 prerequisite-patch-id: 5989f8f80ebf89425e30335706fae8e6571d7704 prerequisite-patch-id: 287cec50edcb5977b5f089d261745aaaf25b4e23 prerequisite-patch-id: 74f085d5031248badc83d12703eb8840d6fe8c75 prerequisite-patch-id: 3a6fcb618b2aa5d0548d98c4694446f4c1f9c45e prerequisite-patch-id: 60bcfce7e808bef835d33c2b03a57b97a8c4f5e4 prerequisite-patch-id: 5cab60c438ece58b487aabbb0020bed2f0aa9837 prerequisite-patch-id: 5ba37e25c99ee90f827559545a5de7b14b740fdb prerequisite-patch-id: 08781a4ce6406ff3e6e77314a7f38cda224e53fd prerequisite-patch-id: 97811dc54e939ad5f05e2674efa27b3d9e13ebe4 prerequisite-patch-id: 5767c6bcff0882bdb91173876267ad1e02e075c2 prerequisite-patch-id: 34eead0bbcfe35ab963dbca72fcf12d487bb10ed prerequisite-patch-id: bdf335e34ad2f7bd0632948a80fc444d0ab87f95 prerequisite-patch-id: 122ea8bf2231509cd21b00b76e6ed29e81f60d05 prerequisite-patch-id: 39a9eb29306335aa9b21c91e1f1b949befc195bc prerequisite-patch-id: 2a68b5c031515eb80c79ab164afcfcad4e4db686 prerequisite-patch-id: e2480a38e8ae1141e0c5ee6a6cbfcdb60869ebfd prerequisite-patch-id: 670ea22337ed7b3e1dc0dbb9d558c3fbeee5c393 prerequisite-patch-id: 5bc422641d1fa42ae961c18759b98e42d0e87411 prerequisite-patch-id: 5f9d23b2160e9c4730b97eac9d83585d137a6340 prerequisite-patch-id: 32ac81500f66e943b897aacc38c9b694193e0cbd prerequisite-patch-id: c01a7ebb021d3d5339dae34c53334469b4eb0ea8 prerequisite-patch-id: 979bf86e2b60977f775d1de3d5b348e41c14c9f8 prerequisite-patch-id: 207abe4eb96b2f9cebbd2a4ebb3911b77a13ca74 prerequisite-patch-id: 07949fcfa28749a8b73f9033511cc42698e36c47 prerequisite-patch-id: 6e115911af90f407f17a94bde1d3265cfd8b0767 prerequisite-patch-id: 3c9f7b47f6bb95233325276b6ff77a9beaa72903 prerequisite-patch-id: 754b43b96c795e89a2da0fd89b5d28d84d044244 prerequisite-patch-id: c9a4a6e8fe9844ec392a995aa34aae60c71062d7 prerequisite-patch-id: 9c625e3f1ec42a564d5b3a8bb51b9b75205305d1 prerequisite-patch-id: 5ce446eedeb1238a0a685a58a4474261d519668b prerequisite-patch-id: 09823d52c7eef498be46c4a599ba94f3d31831de prerequisite-patch-id: 702437fe76379b414be5b77ba9859b197cab0ecb prerequisite-patch-id: 4b6518a6b25710d148b5bed0cb931007d6e704dc prerequisite-patch-id: 1300550f8e26d5416f84746b8cce3ea0220d2221 prerequisite-patch-id: fafdf724b78452dd891bc67131c7f3c16617215c prerequisite-patch-id: 320e5c513ba2e06cee78a41cced5c45a3cb9e888 prerequisite-patch-id: b5d9198ff528164c3d2567cd9b85eb57daad6892 prerequisite-patch-id: 6e49ae2ca0f012d6ff9f8cb61034fc16f4eb2933 prerequisite-patch-id: 29da52f6598e814c4f4ef232f84c9893ef564164 prerequisite-patch-id: cbb895a8131195e7da3022e96bd8aab2d95a24b4 prerequisite-patch-id: c58b9927e1f99256fbb200bba682cc31067c3ead prerequisite-patch-id: b73af976df008d3787c11690c3745f37f00a8c8f prerequisite-patch-id: 4452dd5bedc65bd8c4d473856bb2d3cdd6776b4e prerequisite-patch-id: cf282c8a789324b29db1645ae5b245edd617fe94 prerequisite-patch-id: 5c7f5118a348c01d77e58c0a59a5ba30d827e53f prerequisite-patch-id: 2bd603257c52572635e3e829d7901608ce8acb5c prerequisite-patch-id: 4e3c07341eba2c84f9cb8d2e33623b8541046e70 prerequisite-patch-id: efdfe2c2e632c4bcd78f271343027c9d4b112480 prerequisite-patch-id: b2c8771587903b70e23436e5fa7ce015c13fd70c prerequisite-patch-id: 15865b3b51be96caa18b557e3de15470961ebc27 prerequisite-patch-id: 3b52098277d9dd6ed04cc7baf7d1089de2de6e9c prerequisite-patch-id: 51d806708cc8466c641b24a530f3e7ceaea2e927 prerequisite-patch-id: 31ad01ee26a4dd175ebb7e064314a73bfadb382f prerequisite-patch-id: f698bb634c291314a7c3db1c0d9b2210573931f1 prerequisite-patch-id: ed709433df1d77faa1f9edd025b389eaa2a5dee8 prerequisite-patch-id: c5b73bb4adf652d4b580449ff636c336e8bc1862 prerequisite-patch-id: 7c06d72c9f66556536d01761cd29326cf3edee0f prerequisite-patch-id: c8e0302276a04975a2ebf6ea150464361c570c8b prerequisite-patch-id: 546afe29c7bfba304dddf7bf6b094b25022ac4b1 prerequisite-patch-id: 08956d855b447a63392241943e1d29770607f6b1 prerequisite-patch-id: 15d22d6f99d331cc637067d4957057cc6c30a693 prerequisite-patch-id: 8c5bd9499822e81fe3a066ca0a7992881a4d7978 prerequisite-patch-id: eefc1514601ea7b3c3bfeaf1347a0d05f4a12069 prerequisite-patch-id: d47ca0800f62044ad605e2879206b8870278d0b8 prerequisite-patch-id: aa2c489dab9d8e76273c9c98000325d1f0e90b07 prerequisite-patch-id: f8c1392070d1660d542d61fa9e79c5fed4dfa10c prerequisite-patch-id: b8f87e738f1573ed0311b3620a0bec4940e09774 prerequisite-patch-id: d5c432d1de511ab2039006c69803e1ddafd767e6 prerequisite-patch-id: 449bcf88e0ae6452a70f1191d586b31c17a0e1eb prerequisite-patch-id: 11df912cbf3ac10b67b8f0cecbceca22ac9acf92 prerequisite-patch-id: 3871ffac0263cfb3135fd27f5cf996a981bece38 prerequisite-patch-id: 3f39044038be4c5e621a912678dc931eabc4b4a5 prerequisite-patch-id: fc027117b2a51947b71000ac20727d43b5f90aed prerequisite-patch-id: 01aeadeccd40b410c48c8fada9ba16ff4ab43889 prerequisite-patch-id: 49021465ac74420d6836b57cf87c816a4bdd336f prerequisite-patch-id: 6c9b73c9af737071c8b8f74f578dd39bda46bda1 prerequisite-patch-id: cb1ab1be4c1883354a8d83fa6ecd9d525322703f prerequisite-patch-id: a9f2b81a5b02d3011481ba63c78bd4a7c3ba50ea prerequisite-patch-id: 1d2ac40285d3452f93a1ac8107e36619a4558f71 prerequisite-patch-id: c728d1f8a1f11dfed4d4790f0982adb06882c8db prerequisite-patch-id: 225539dd6e6acc851839c6894f33cb84d532056e prerequisite-patch-id: 001c2f22271d77565119cfe81398c24e4f7ee3d2 prerequisite-patch-id: 6f224a1aae34b74e4c6e8a0c457e5a1741ad5444 prerequisite-patch-id: 0b2f2bd1ed1175b339f39dbbd0ca70514892984f
Hi Efraim, Efraim Flashner <efraim@flashner.co.il> skribis: > On Sat, Apr 17, 2021 at 06:04:02PM +0200, Ludovic Courtès wrote: [...] >> 3. OTOH, what will be the status of this architecture? I don’t think >> new 32-bit PPC hardware is being made (right?), so I guess we >> probably won’t have substitutes for that architecture. That means >> it won’t be supported at the same level as other architectures and >> may quickly suffer from bitrot. > > I don't know about new 32-bit powerpc hardware, I think it's only being > newly created for the embedded and networking space. As far as operating > systems with support¹ Adélie Linux is the only one I know that's > actually targeting the machines. > > I found that emulation on my desktop (Ryzen 3900XT, 24 threads) is > faster than building on native hardware (1 core, 1.5GB of RAM, original > 4200 RPM disk), edging it out on single threaded compiling and doing > great when it comes to using multiple cores and parallel builds. > Ignoring how to create an OS image if we just targeted, say, mesa and > maybe one or two other packages, we could have a core set which doesn't > change regularly and won't take up too much emulated build time but will > save days of compile time. [...] > The fear of bit-rot is real and I think we should mention in the manual > (when I actually write the section) that support is best-effort with > minimal substitutes. I feel like “best-effort with minimal substitutes” is already more than I’d be willing to commit to as a maintainer. We just added POWER9, for which we have actual hardware, and even getting to this minimal state where we provide a binary tarball required quite some effort. Doing the same with 32-bit PowerPC would require us to set up emulation; we wouldn’t even have real hardware. All in all, my preference would be to take the patches but not mention PowerPC 32-bit support anywhere, or at least, not provide substitutes and binary installation tarball. IOW, few people would know whether it actually works :-) but tinkerers could still play with it. WDYT? Ludo’.
On Thu, May 06, 2021 at 04:38:38PM +0200, Ludovic Courtès wrote: > Hi Efraim, > > Efraim Flashner <efraim@flashner.co.il> skribis: > > > On Sat, Apr 17, 2021 at 06:04:02PM +0200, Ludovic Courtès wrote: > > [...] > > >> 3. OTOH, what will be the status of this architecture? I don’t think > >> new 32-bit PPC hardware is being made (right?), so I guess we > >> probably won’t have substitutes for that architecture. That means > >> it won’t be supported at the same level as other architectures and > >> may quickly suffer from bitrot. > > > > I don't know about new 32-bit powerpc hardware, I think it's only being > > newly created for the embedded and networking space. As far as operating > > systems with support¹ Adélie Linux is the only one I know that's > > actually targeting the machines. > > > > I found that emulation on my desktop (Ryzen 3900XT, 24 threads) is > > faster than building on native hardware (1 core, 1.5GB of RAM, original > > 4200 RPM disk), edging it out on single threaded compiling and doing > > great when it comes to using multiple cores and parallel builds. > > Ignoring how to create an OS image if we just targeted, say, mesa and > > maybe one or two other packages, we could have a core set which doesn't > > change regularly and won't take up too much emulated build time but will > > save days of compile time. > > [...] > > > The fear of bit-rot is real and I think we should mention in the manual > > (when I actually write the section) that support is best-effort with > > minimal substitutes. > > I feel like “best-effort with minimal substitutes” is already more than > I’d be willing to commit to as a maintainer. I have also learned that 'best effort' is a grey area in other circles; does it mean you'll move mountains and spare no expense (The Best Effort!™) or that you'll give it a shot but make no promises. I definitely meant the second. > We just added POWER9, for which we have actual hardware, and even > getting to this minimal state where we provide a binary tarball required > quite some effort. > > Doing the same with 32-bit PowerPC would require us to set up emulation; > we wouldn’t even have real hardware. > > All in all, my preference would be to take the patches but not mention > PowerPC 32-bit support anywhere, or at least, not provide substitutes > and binary installation tarball. IOW, few people would know whether it > actually works :-) but tinkerers could still play with it. > > WDYT? > > Ludo’. How about changing the mips64el documentation to say that there is minimal support for the two architectures, with no substitutes, and may be fun for tinkerers with the hardware. Then we could also change the check in the guix.m4 to add mips64el-linux as supported in case anyone does actually want to play with it. Current text: @item mips64el-linux (deprecated)¬ little-endian 64-bit MIPS processors, specifically the Loongson series, n32 ABI, and Linux-Libre kernel. This configuration is no longer fully supported; in particular, there is no ongoing work to ensure that this architecture still works. Should someone decide they wish to revive this architecture then the code is still available. Proposed text: @item Alternative architectures In addition to architectures which are actually supported there are a few formally unsupported architectures which may be of interested to tinkerers. Namely mips64el-linux, little-endian 64-bit MIPS processors, specifically the Loongson series, n32 ABI, and powerpc-linux, big-endian 32-bit POWER processors, specifically the PowerPC 74xx series. There are no installation tarballs, substitutes or promises that these architectures are functional. And then I'd move it lower than the powerpc64le-linux entry.
Hi! Efraim Flashner <efraim@flashner.co.il> skribis: > How about changing the mips64el documentation to say that there is > minimal support for the two architectures, with no substitutes, and may > be fun for tinkerers with the hardware. Then we could also change the > check in the guix.m4 to add mips64el-linux as supported in case anyone > does actually want to play with it. No, not as “supported”, I surely don’t want to deal with mips64el-linux bugs. :-) > Current text: > > @item mips64el-linux (deprecated)¬ > little-endian 64-bit MIPS processors, specifically the Loongson series, > n32 ABI, and Linux-Libre kernel. This configuration is no longer fully > supported; in particular, there is no ongoing work to ensure that this > architecture still works. Should someone decide they wish to revive this > architecture then the code is still available. > > Proposed text: > > @item Alternative architectures > In addition to architectures which are actually supported there are a > few formally unsupported architectures which may be of interested to > tinkerers. Namely mips64el-linux, little-endian 64-bit MIPS processors, > specifically the Loongson series, n32 ABI, and powerpc-linux, big-endian > 32-bit POWER processors, specifically the PowerPC 74xx series. There are > no installation tarballs, substitutes or promises that these > architectures are functional. > > And then I'd move it lower than the powerpc64le-linux entry. Maybe it’s more readable to keep it as a bullet list, like: @item mips64el-linux (@emph{unsupported}) … @item powerpc-linux (@emph{unsupported}) … with a sentence explaining what “unsupported” means. IMO guix.m4 should either require --with-courage or emit a prominent warning for these. WDYT? Thanks, Ludo’.
On Tue, May 11, 2021 at 10:24:03PM +0200, Ludovic Courtès wrote: > Hi! > > Efraim Flashner <efraim@flashner.co.il> skribis: > > > How about changing the mips64el documentation to say that there is > > minimal support for the two architectures, with no substitutes, and may > > be fun for tinkerers with the hardware. Then we could also change the > > check in the guix.m4 to add mips64el-linux as supported in case anyone > > does actually want to play with it. > > No, not as “supported”, I surely don’t want to deal with mips64el-linux > bugs. :-) > > > Current text: > > > > @item mips64el-linux (deprecated)¬ > > little-endian 64-bit MIPS processors, specifically the Loongson series, > > n32 ABI, and Linux-Libre kernel. This configuration is no longer fully > > supported; in particular, there is no ongoing work to ensure that this > > architecture still works. Should someone decide they wish to revive this > > architecture then the code is still available. > > > > Proposed text: > > > > @item Alternative architectures > > In addition to architectures which are actually supported there are a > > few formally unsupported architectures which may be of interested to > > tinkerers. Namely mips64el-linux, little-endian 64-bit MIPS processors, > > specifically the Loongson series, n32 ABI, and powerpc-linux, big-endian > > 32-bit POWER processors, specifically the PowerPC 74xx series. There are > > no installation tarballs, substitutes or promises that these > > architectures are functional. > > > > And then I'd move it lower than the powerpc64le-linux entry. > Ah, I didn't see your email. > Maybe it’s more readable to keep it as a bullet list, like: > > @item mips64el-linux (@emph{unsupported}) > … > > @item powerpc-linux (@emph{unsupported}) > … > > with a sentence explaining what “unsupported” means. That was kind-of my idea with grouping them together > IMO guix.m4 should either require --with-courage or emit a prominent > warning for these. > > WDYT? > > Thanks, > Ludo’. > The problem then becomes whoever tinkers with it will have to keep either a custom guix.m4 for their guix package or a custom guix package with "--with-courage" as a configure-flag.
First few patches pushed. I'm still working on getting guile-3.0.7 to pass its test suite and then I'll push that patch too. Thanks everyone for the support!
Hi, Efraim Flashner <efraim@flashner.co.il> skribis: > On Tue, May 11, 2021 at 10:24:03PM +0200, Ludovic Courtès wrote: [...] >> Maybe it’s more readable to keep it as a bullet list, like: >> >> @item mips64el-linux (@emph{unsupported}) >> … >> >> @item powerpc-linux (@emph{unsupported}) >> … >> >> with a sentence explaining what “unsupported” means. > > That was kind-of my idea with grouping them together Yes, but people who just skim through that page may just see that ‘powerpc-linux’ is listed, without noticing that there’s a sentence ten line above that says “The following arches are not supported”. Having “unsupported” next to it should avoid that (yes, I’ve learned to be super cautious. :-)). >> IMO guix.m4 should either require --with-courage or emit a prominent >> warning for these. [...] > The problem then becomes whoever tinkers with it will have to keep > either a custom guix.m4 for their guix package or a custom guix package > with "--with-courage" as a configure-flag. True. In that case, let it go without ‘--with-courage’ but emit a warning with AC_MSG_WARN that points to the relevant section of the manual. Deal? Thanks! Ludo’.