Summary: this commit will not affect your project's software or analysis. Until now, the ending copyright years of all files in Maneage were 2025. But we have already entered 2026 so it is important to update them. With this commit, the ending copyright year of all files is changed to 2026.
Summary: The Apptainer script's option names have been renamed: '--sif' and
'--base-sif' are new names for the old '--project-name' and '--base-name'.
Until now the options that took SIF files in the Apptainer script were not
too clear (in their name): ending in '-name' (not clearly mentioning that
it needs a file name). Also, in the same script, we had forgot to add an
option to allow the user to choose a different base operating system!
With this commit, both the issues above have been fixed: the options end in
'-sif' (clearly informing the user that a SIF file is expected) and we now
have a new '--base-os' option. In the process, a few other parts of Maneage
were also polished:
- README-hacking.md: the newly published J-PLUS PSF paper was added to
the list of Maneage'd papers and the final journal information for the
NASIM paper has been added. Some typos here and there were also fixed.
- The curretnly used VIM needed the the '-std=gnu17': necessary now that
the default Maneage GCC 15.2.0 for the high-level software which
defaults to C23.
Summary: this commit involves a major version update of many basic software
and Gnuastro's major dependencies. So it may affect your configuration and
analysis.
Until now, the most recent software updates weren't properly tested on
MacOS, causing the software configuration step to fail. In particular, the
'prep-source.sh' (that corrects any hard-coded '/bin/sh' within the
unpacked tarballs of all software) as well as some issues in the 'tar',
'util-linux' and 'ghostscript' programs. These portability issues were
found and fixed by Raul Infante-Sainz and Giacomo Lorenzetti.
With this commit, those portability issues have been addressed while
updating the following software. Also see notes below the list.
High-level software:
CFITSIO 4.5.0 --> 4.6.3
Ghostscript 10.04.0 --> 10.06.0
Gnuastro 0.23 --> 0.24
Util-linux 2.40.4 --> 2.41.3
WCSLIB 8.4 --> 8.5
Basic software:
cURL 8.11.1 --> 8.17.0
GNU Bash 5.2.37 --> 5.3.9
GNU Binutils 2.43.1 --> 2.45.1
GNU Coreutils 9.6 --> 9.9
GNU Diffutils 3.10 --> 3.12
GNU AWK 5.3.1 --> 5.3.2
GNU GCC 14.2.0 --> 15.2.0
GNU Gettext 0.23.1 --> 0.26
GNU Grep 3.11 --> 3.12
GNU Gzip 1.13 --> 1.14
GNU Libunistring 1.3 --> 1.4.1
GNU M4 1.4.19 --> 1.4.20
GNU MPFR 4.2.1 --> 4.2.2
GNU Nano 8.3 --> 8.7
GNU Readline 8.2.13 --> 8.3.3
Git 2.48.1 --> 2.52.0
Less 668 --> 685
Libxml2 2.13.1 --> 2.15.1
OpenSSL 3.4.0 --> 3.6.0
Perl 5.40.1 --> 5.42.0
The latest versions of Bash and M4 were prepared for the new default C
standard of GCC 15.*, so the '-std=gnu17' was removed for them. Also, while
a new version of Dash was available, it would cause an issue when building
in Apptainer, so it has been described in 'versions.conf' to be aware in
the future updates.
Libgit2 has been removed as a dependency of Gnuastro. The reason is fully
described in the comment on top of Gnuastro's build rule in
'high-level.mk'.
Summary: will not affect existing configuration or analysis. Until this commit, if the Maneage readline library (used by the shell) did not match the local readline library, the 'pdflatex' command would crash when building the template Maneage branch. This was because PGFPlots uses the local shell and we do not build TeXLive from source within Maneage yet. Previously, we had added a modification to 'LD_LIBRARY_PATH' before the 'pdflatex' command to use 'sys_library_sh_path', but the variable was never initilized (because it was only available within the configuration phase)! With this commit, the problem is solved by adding that variable within 'LOCAL.conf' so it is available in the analysis phase of a Maneage'd project also. In order to do so, the set of commands that set the 'sys_library_sh_path' variable within 'configure.sh' was brought up before the creation of 'LOCAL.conf'. In case you have had this problem, the solution is to delete '.build/software/config/LOCAL.conf' and re-configure your project by manually setting the necessary directories. In this way, the 'LOCAL.conf' is created again with the new variable. This bug was found with the help of Faezeh Bidjarchian.
Summary: after merging this commit into your project, it should be
re-configured since the location of software installation files like
'LOCAL.conf' or the LaTeX macros of the software environment have
changed. But it should not affect the analysis phase of your project.
Until this commit, it was not possible to run a pre-built Maneage'd project
(in a container) on a newly cloned Maneage'd project source. This was
because the containers should be read-only, but during the various checks
of the configuration (to verify that we are using the same software
environment in the container and the source), we were writing/testing many
things in the build directory, and 'LOCAL.conf' which was actually in the
source directory!
Furthermore, the '.local' and '.build' were built at configure time, making
it hard to run the same container from a newly cloned Maneage'd project. To
make things harder for the scenario above, the 'configure.sh' script would
pause on every message and didn't have a quiet mode (making it practically
impossible to run './project configure' before './project make' on every
container run).
With this commit, all these issues have been addressed and it is now
possible to simply get a built container, clone a Maneage'd project and run
the analysis (using the built environment of the container that is verified
on every run). The respective changes/additions are described below:
- The high-level container scripts ('apptainer.sh' and 'docker.sh', along
with their READMEs) have been moved to the 'reproduce/software/shell'
directory and the old 'reproduce/software/containers' directory has been
deleted. This is because we have classified the software files by their
language/format and the container scripts are scripts in the end.
- The './project' script:
- Now has two extra options: '--quiet' and '--no-pause'. Both are
directly passed to the 'configure.sh' script. They will respectively
disable any informative printed message or any pause after that
message (if it is printed).
- The '--build-dir' option is now also relevant for './project make':
when it is given, it will re-create the two '.build' and '.local'
symbolic links at the top source directory in all scenarios
('configure', 'make' or 'shell'). This will allow both the
configuration, analysis and shell phases to safely assume they exist
and match the user's desire at run-time.
- The build/analysis directory's sub-directories that need to be built
before 'top-make.mk' are now built in a separate function to help in
readability.
- The 'configure.sh' script:
- For developers: a new 'check_elapsed' variable has been defined that
will enable the newly added 'elapsed_time_from_prev_step'
function. This function should be used from now on at the end of
every major step to help find bottlenecks.
- The targets of the software in 'pre-make-build.sh' now also have the
version of the software in their file name. Until now, they didn't have
the version, so there was no way to detect if the software has been
updated or not in the source. For Lzip and Make (that also get built
after GCC), the ones in this script have a '-pre-make' suffix also.
- 'Local.conf.in' now has descriptions for every variable.
- The '-std=gnu17' option is now used instead of '-std=c17' for basic
software that cannot be built without specifying the C standard in GCC
15.1 (described in previous commit: 2881fc0a6205). See [1] for more
details; in summary: '-std=gnu17' is also supported on macOS's Clang and
has some features that 'pkg-config' needs
- Generally: some longer code lines have been broken or indentation
decreased to fit the 75 character line length. This has not reduced
readability however. For example the long 'echo' commands are now
replaced by multiple 'printf's, or the indentation is still clearly
visible.
The seeds of the work on this commit started by a branch containing three
commits by Giacomo Lorenzetti (133 insertions, 100 deletions). Upon merging
with the main 'maneage' branch, they were generalized and re-organized to
become this commit.
The following issues have also been addressed with this commit:
- The LaTeX calls (during the building of 'paper.pdf') do not contain
Maneage'd dynamic libraries. This is because we don't build the LaTeX
binaries from source, an TeXLive manager uses the host environment.
- The 'docker.sh' script:
- Adds the '--project-name' option: its internal variable existed, but
the option for the user to define it at run-time was not.
- Ported to macOS: it does not check being a member of the 'docker'
group, and finds the number of threads using macOS-specific tools.
- The 'apptainer.sh' script:
- Now installs 'wget' in the base container also (necessary when the
user doesn't have the tarballs).
[1] https://savannah.nongnu.org/bugs/?67068#comment2
Summary: this will not affect already built/configured projects, only improving the portability of future builds. Until this commit, no specific C standard version was given during the build of Basic software (which use the host's c compiler, culminating in the building of GCC within Maneage). On the other hand, GCC 15.1 was recentely released and made available on some operating systems. GCC 15.1 has made C23 its standard C version (from C17), as a result, some of the basic software crashed and didn't allow Maneage to built on those operating systems. With this commit, the '-std=c17' flag has been added to software that crashed when the host GCC was 15.1. Also, they have been grouped with a description of this problem in 'versions.conf' so we check the need for this option in future version updates. In parallel, some minor edits/clarifications were made in the two 'README-apptainer.md' and 'README-docker.md' files to be more useful.
Summary: this will not affect any analysis. Until this commit, the old version of 'setuptools-rust' did not install with the updated Python version (see [1]). With this commit, 'setuptools-rust' is upgraded to version 1.10.2 (from 1.1.2) and 'semantic-version' 2.10.0 (needed by 'setuptools-rust') is added. In addition this commit: - removes a duplicate rule for building 'cycler' in 'python.mk'. - comments all the un-commented '*-url' variables of 'urls.conf'. [1] https://savannah.nongnu.org/bugs/?61731
Summary: this will not affect your high-level projects Until this commit, the 'reproduce/software/config/TARGETS.conf' included both Gnuastro and Astropy. But the default analysis does not use Astropy, therefore to avoid taking too much time for a default build, it should only be added when the user needs it. It was present because of the tests in the previous commit to update the Python environment, but I forgot to remove it before pushing. With this commit, TARGETS.conf only contains Gnuastro.
Summary: this is software update that involves Astropy and its
dependencies. In case you are using any of those, it is recommended to
reproduce the analysis of your project to make sure that the calls to the
various packages have not changed. If you are not using Astropy or its
dependencies, this commit will not affect your analysis.
Until this commit, Astropy and the whole Python environment of its
prerequisites were last updated more than 2 years go. So after the update
of the Basic and some high-level (Gnuastro dependencies) software, it was
necessary to update Astropy and its dependencies (for those who use it).
With this commit, the software listed in the last item below have been
updated as well as the following minor technical fixes:
- Support bug 110738 (https://savannah.nongnu.org/support/?110738): when
the build directory had the same base-name as the source directory (for
exapmle '/PATH/proj' and /PATH/proj-build'), Maneage would complain and
not continue.
- The Python software are now built using the wheels system with
'gpep517' (https://pypi.org/project/gpep517). Python packages that are
not required by astropy/matplotlib/scipy have mostly not been updated,
but updating their dependencies and adding the build method as
'GPEP517' should be straightforward.
- Updated software (dependencies of Astropy). Those with 'N/A' in their
previous version string weren't in Maneage prior to this commit.
High-level software (not written in Python):
boost 1.77.0 1.87.0
ninja build system n/a 1.12.1
openblas 0.3.21 0.3.29
Python packages:
python 3.10.6 3.13.2
astropy 5.1 7.0.1
astropy-iers-data n/a 0.2025.2.24.0.34.4
contourpy n/a 1.3.1
cppy n/a 1.3.1
cycler 0.11.0 0.12.1
cython 0.29.24 3.0.12
extension-helpers 0.1 1.2.0
features n/a 0.5.12
flit-core n/a 3.11.0
fonttools n/a 4.56.0
gpep517 n/a 16
kiwisolver 1.0.1 1.4.8
matplotlib 3.3.0 3.10.0
meson n/a 1.7.0
meson-python n/a 0.17.1
numpy 1.21.3 2.2.3
packaging 21.3 24.2
pillow 8.4.0 11.1.0
pybind11 2.5.0 2.13.6
pyerfa-version 2.0.0.1 2.0.1.5
pyproject-metadata n/a 0.9.0
pyparsing 3.0.4 3.2.1
python-dateutil 2.8.0 2.9.0.post0
python-installer n/a 0.7.0
pyyaml 5.1 6.0.2
setuptools 58.3.0 75.8.0
setuptools_scm 3.3.3 8.2.0
scipy 1.7.3 1.15.2
six 1.16.0 1.17.0
wheel 0.37.0 0.45.1
SUMMARY: no change is necessary for your pipeline after upgrading to this
commit.
Until this commit, the following noteworthy portability problems existed
that have been fixed as described in each item.
- In commit 8908587 (titled "IMPORTANT: 73 software upgrades and added
offline mode"; committed on 2025-02-11); the versions of all (except
those that were not updated upstream) basic software as well as the
high-level software necessary for Gnuastro were updated. This included
Python. However, the update of Python could cause crashes in the
Python-related software that are also in Maneage but not tested for
that commit.
-- With this commit, Python has been revered back to 3.10.6 (from
3.13.2) and it has been taken to a dedicated part of 'versions.conf'
(reminding the reader that the version of Python should only be
updated by the Python maintainer: to ensure it doesn't conflict with
Python-based builds).
- Following the update of XZ Utils in 8908587, the custom build recipe
that was necessary is no longer necessary. This was reported by Boud
Roukema (see https://savannah.nongnu.org/bugs/index.php?62700).
-- With this commit, XZ Utils uses our basic high-level build scripts.
- CMake could use out-of-Maneage libraries for those that we already had
in Maneage on some systems. This was reported by Boud Roukema (see
https://savannah.nongnu.org/bugs/?63043)
-- With this commit, CMake is built with '--no-system-libs'; so it
builds and statically links to all its necessary libraries
internally (not confusing between Maneage and the host).
- Building Binutils 2.39 was likely to fail on older GCC versions due to
special features (such as the 'gprofng' feature when building with GCC
6.2.0). This was reported by Boud Roukema in
https://savannah.nongnu.org/bugs/index.php?63242.
-- With this commit, the 'gprofng' feature of Binutils has been
disabled by default to allow reproducibility on older systems. If
you need it, remove the '--enable-gprofng=no' option in the build
recipe of Binutils.
- The Maneage tarball repository is now also kept in 'gitlab.cefca.es'.
-- With this commit, a new server URL has been added for this.
- The list of TeXLive packages included some packages that get installed
in the basic scheme that we do for the initial setup of TeXLive.
-- With this commit, the extra packages have been removed.