I found a similar issue every time I tried the full build! Can you please post it as a bug? I doubt we'll have time to address it before this merge ;-).

I am just trying to find some time to do the final checks, write the final commit message and merge it (but in the last few days, I haven't even found 1 hour for doing this!)

Thanks for the hint on forgetting to remove those R packages from 'TARGETS.mk'! They have been removed.

> I think its best to not merge that part into the main 'maneage' branch.

Yes, I fully agree. That's why I described the hack as obsolete :). It's also, in principle, harmless in case we forget to remove it later on in the particular project that uses it.

Sorry for the ambiguity. I meant through, inclusively, to the verify checksums, and producing the pdf. Everything looks OK. :)

Just as an aside on the difficulties in reproducibility for the final LaTeX stages, see this temporary hack [1] that was needed in the 'gevcurvtest' project [2].  It happened that a minor bug in one texlive program blocked full LaTeX compilation, and the CTAN mirrors had a README announcing a fix in version 1.701 of newtx, but were - as of a few days ago - still distributing 1.7. In my check of 5255a48, I see that .build/software/installed/texlive/maneage/texmf-dist/tex/latex/newtx/newtxtext.sty is version 1.701, so my hack is (happily) obsolete (but should do no harm).

I spent a long time trying to trace where we had introduced a LaTeX error, but it was not our fault. It was a coincidence of downloading a LaTeX package at the moment in between the introduction of a fatal (though minor) bug and it being fixed. Sooner or later we should think of seeing if there's a way to handle version-frozen and checksummed texlive packages, rather than the current situation of live updates. Users will not always realise that this sort of bug is "low priority" and "easy to fix" and "not the user's fault"...

[1] https://codeberg.org/boud/gevcurvtest/commit/74ff0f2f5801857a1ecf28bf605b38ec4ae499d7
[2] https://codeberg.org/boud/gevcurvtest

5255a48 works fully through to the verify checksums for me on one Debian system.

It would be nice to include the R system... ;) https://savannah.nongnu.org/task/?15772

Thanks for reporting this Boud! I just committed it into our software repository in Commit 915ad273.

If you run the script again, it should be downloaded properly ;-).

Most of software used in Maneage have been updated in the 'version-update' branch of this repository. I have tested it on an Arch GNU/Linux, Ubuntu 20.04, and on Debian-slim (within Docker) and all software (with '--all-highlevel') get installed successfully.
 
I plan to merge it into the 'maneage' branch in one week (by Friday January 7th, 2022). So it would be great if anyone can try it on their various OSs and report any crashs or failures so we can fix them before the merge.

I'll also be looking into recently submitted bugs/tasks about the various software-building phases and including them if necessary.

All the work in this development branch will be squashed into a single commit to avoid complicating the history of the 'maneage' branch which goes into all Maneage'd projects.

Since the software in Maneage are increasing, updating their versions is very time-consuming (it took more more than two months to do it anytime I had some time). To help simplify the process, we can have Maneage software releases coded with a format of 'YYYY-N', where YYYY is the year, and 'N' is the release in that year. So this one will be 2022-1.

We will then start a new branch and gradually (as new software versions are released), we'll add them until they reach a sufficient level to justify a next release (and testing!).

Also, from the next release, I can only commit to maintaining the "default" Maneage software (due to time constraints)! There are too many complexities and dependencies for other software (in particular, the Python packages!). So if you need them, please keep updating them in the development branch yourself, and we'll test them all together when the next release is necessary.