Re: Starting 'core-updates'?

[Mathieu Othacehe <m.othacehe@gmail.com>]

Hello Marius,

Thanks for your great work. Concerning the first point about
cross-compilation, we are almost there, but I still have a few patches
to apply:

* Remove canonical-packages calls[1].

* Use a default target in most (guix gexp) procedures[2].

* Fix Guix itself cross-compilation. This means make sure that all
guile-* libraries that Guix depends on are cross-compilable. This is
almost done, it's just a matter of updating some package definitions.

As the second point is a bit tricky, I'd like to discuss it during Guix
Days.

Thanks,

Mathieu

[1]: https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00044.html
[2]: https://lists.gnu.org/archive/html/guix-patches/2019-12/msg00751.html

Marius Bakke writes:

> Hello Guix,
>
> The 'core-updates' branch is starting to look pretty good, and I am
> happy to report that it "works for me".  :-)
>
> Some of the big changes include:
>
> * Large parts of Guix can now be cross-compiled, allowing building Guix
>   System for foreign architectures without emulation.
>
> * Python was updated to 3.8.1, and most of the popular packages such as
>   Pytest are at the latest available versions.
>
> * The 'libjpeg' library has been deprecated in favor of 'libjpeg-turbo'.
>
> * 'util-linux' gained a "lib" output, decreasing the closure size of
>   packages that only need the libraries by ~11.5 MiB.
>
> * 'boost' now uses Python 3 by default.
>
> * 'sqlite-with-column-metadata' has been merged with 'sqlite'.
>
> * The quest to remove static libraries from core packages is ongoing.
>   Many packages are a tiny bit smaller for that reason.  On the flip
>   side, the closure size of some packages increased, because they are
>   forced to use the shared library instead of embedding a static copy.
>
> * cmake-build-system's support for cross-compilation is significantly
>   improved.  CMake itself also no longer bundles any of its dependencies
>   (even if they were mostly unused).
>
> * Of course we have the latest versions of core packages such as glibc,
>   make, sed, binutils, etc.
>
> I suggest that we set a "freeze" date shortly after FOSDEM to start
> integrating it.  Are there other branches that should be included?
> Maybe wip-bootstrap or GNOME 3.34?