Coreutils-9.0 downloaded, configured, compiled and installed OK.

So upgrading to coreutils-9.0 fixes part (1) of https://codeberg.org/boud/maneage_dev/commit/8b2cb4bffee09f9b953214e90c747063603cb3a6 , apparently without problems, though see below, and wait another 12-24 hours for confirmation...

The changes in parts (2) and (3) in the commit description, i.e. the changes in reproduce/software/make/high-level.mk , are still needed in Maneage, to handle the other two arm64 portability bugs described in the commit description.

Part (4) does not apply to current Maneage, since fftw2 (which is older than fftw-3.3.8) is not currently in Maneage (it's in elaphrocentre, since mpgrafic depends on fftw2).

The other files in the diff  3a1b96766c..8b2cb4bffe (apart from reproduce/software/make/high-level.mk ) should now be ignored. Adding the fftw target in reproduce/software/config/TARGETS.conf is better done as a private change, without being in any official Maneage commit.

I'm still rebuilding, so there could still be surprises, even though the build looks smooth so far. So far the proglib list is:

-rw-r--r-- 1 james mobian 39 Oct  5 00:00 mpc-1.1.0
-rw-r--r-- 1 james mobian 36 Oct  4 23:59 metastore-1.1.2-23-fa9170b
-rw-r--r-- 1 james mobian 14 Oct  4 23:59 gawk-5.1.0
-rw-r--r-- 1 james mobian 53 Oct  4 23:52 mpfr-4.0.2
-rw-r--r-- 1 james mobian 29 Oct  4 23:30 isl-0.18
-rw-r--r-- 1 james mobian 48 Oct  4 23:22 gmp-6.2.0
-rw-r--r-- 1 james mobian 11 Oct  4 23:22 git-2.28.0
-rw-r--r-- 1 james mobian 18 Oct  4 23:14 diffutils-3.7
-rw-r--r-- 1 james mobian  0 Oct  4 23:09 low-level-links
-rw-r--r-- 1 james mobian 12 Oct  4 23:09 curl-7.71.1
-rw-r--r-- 1 james mobian 20 Oct  4 23:07 findutils-4.7.0
-rw-r--r-- 1 james mobian 14 Oct  4 22:59 libbsd-0.10.0
-rw-r--r-- 1 james mobian 10 Oct  4 22:57 file-5.39
-rw-r--r-- 1 james mobian 15 Oct  4 22:55 which-2.21
-rw-r--r-- 1 james mobian 13 Oct  4 22:54 grep-3.4
-rw-r--r-- 1 james mobian 12 Oct  4 22:52 sed-4.8
-rw-r--r-- 1 james mobian 18 Oct  4 22:46 coreutils-9.0
-rw-r--r-- 1 james mobian 16 Oct  4 22:40 texinfo-6.7
-rw-r--r-- 1 james mobian 16 Oct  4 22:36 bash-5.0.18
-rw-r--r-- 1 james mobian 17 Oct  4 22:33 gettext-0.21
-rw-r--r-- 1 james mobian 24 Oct  4 22:00 libunistring-0.9.10
-rw-r--r-- 1 james mobian 18 Oct  4 21:49 libiconv-1.16
-rw-r--r-- 1 james mobian 18 Oct  4 21:47 pkg-config-0.29.2
-rw-r--r-- 1 james mobian 15 Oct  4 21:08 openssl-1.1.1a
-rw-r--r-- 1 james mobian 12 Oct  4 20:50 perl-5.32.0
-rw-r--r-- 1 james mobian 14 Oct  4 20:38 libxml2-2.9.9
-rw-r--r-- 1 james mobian 17 Oct  4 20:29 readline-8.0
-rw-r--r-- 1 james mobian  9 Oct  4 20:27 less-563
-rw-r--r-- 1 james mobian 18 Oct  4 20:26 libtool-2.4.6
-rw-r--r-- 1 james mobian 16 Oct  4 20:25 ncurses-6.2
-rw-r--r-- 1 james mobian 22 Oct  4 20:21 m4-1.4.18-patched
-rw-r--r-- 1 james mobian 14 Oct  4 20:16 patchelf-0.10
-rw-r--r-- 1 james mobian 13 Oct  4 20:14 tar-1.32
-rw-r--r-- 1 james mobian 15 Oct  4 20:10 xz-5.2.5
-rw-r--r-- 1 james mobian 10 Oct  4 20:08 unzip-6.0
-rw-r--r-- 1 james mobian  8 Oct  4 20:07 zip-3.0
-rw-r--r-- 1 james mobian 12 Oct  4 20:07 bzip2-1.0.6
-rw-r--r-- 1 james mobian 12 Oct  4 20:07 zlib-1.2.11
-rw-r--r-- 1 james mobian 14 Oct  4 20:05 gzip-1.10
-rw-r--r-- 1 james mobian 21 Oct  4 20:03 flock
-rw-r--r-- 1 james mobian 14 Oct  4 20:02 dash
-rw-r--r-- 1 james mobian 13 Oct  4 20:01 make
-rw-r--r-- 1 james mobian 14 Oct  4 19:58 lzip

This is based on two ./project configure commands. A Ctrl-C was used when pkg-config-0.29.2 took too long, appeared to be using one cpu at about 100%, but nothing was being written to the log file. This is quite likely a bug related to the fact that some subtle kernel issues are still being sorted out on the pinephone rather than a Maneage bug. The pinephone is not (yet) ready for the wider public... ;)

PS: Trying to remove only coreutils and then rebuild based on make rules failed, giving a bug in building libbsd :

In file included from setproctitle_ctor.c:27:
../include/bsd/unistd.h: In function 'setproctitle':
../include/bsd/unistd.h:69:2: error: expected declaration specifiers before '__printflike'
   69 |  __printflike(1, 2);
      |  ^~~~~~~~~~~~
setproctitle_ctor.c:52:2: error: parameter 'libbsd_init_func' is initialized
   52 |  __attribute__((__section__(".init_array"))) = setproctitle_init;
      |  ^~~~~~~~~~~~~
setproctitle_ctor.c:51:8: error: section attribute not allowed for 'libbsd_init_func'
   51 | void (*libbsd_init_func)(int argc, char *argv[], char *envp[])
      |        ^~~~~~~~~~~~~~~~
In file included from setproctitle_ctor.c:27:
../include/bsd/unistd.h:68:6: error: old-style parameter declarations in prototyped function definition
   68 | void setproctitle(const char *fmt, ...)
      |      ^~~~~~~~~~~~
setproctitle_ctor.c:52: error: expected '{' at end of input
   52 |  __attribute__((__section__(".init_array"))) = setproctitle_init;
      |
setproctitle_ctor.c: At top level:
cc1: note: unrecognized command-line option '-Wno-nullability-completeness' may have been intended to silence earlier diagnostics

It generally seems that removing and rebuilding one of the basic packages quite often requires a full rebuild, not just a rebuild based on basic.mk rules. In other words, there are hidden dependencies.

If the next official version of Coreutils isn't released by the next Maneage software update, we'll just upload our own tarball to Zenodo. It can be given version number '8.32-a3c04f8'.

Development versions are usually like this. For sxample see Gnuastro's development release tarballs. In Gnuastro I use the git-version-gen script of Gnulib which does this automatically and many other GNU packages also use it, I am not sure if Coreutils also does it, you shiuld be able to see after running 'make dist-lzip'.

Autoconf and automake are built in high-level.mk . Using the host system autoconf (which might not exist) in basic.mk would be a regression in terms of reproducibility.

Alternatively, shifting autoconf into basic.mk and making it a prerequisite for coreutils might work. However, that would imply that autoconf is built with some host system tools instead of those built by coreutils. This would disrupt some of the reproducibility that we currently have. Disrupting this sequence without a lot of testing is probably not a good idea.

Thanks for the nice bug Boud, this is indeed a blocker!

One solution is to simply clone Coreutils and run 'make dist-lzip' and use that tarball in the project (which will contain this and any other bug fixes). Ultimately, if Coreutils 8.33 isn't out before we do a general update, we can just use the same tarball in that general Maneage update.