Re: Drafting a Guix blog post on the FHS container

[Development of GNU Guix and the GNU System distribution.]

Hello,


> Hi Guixers!
> 
> I've started working on a little blog post about our new
> --emulate-fhs option for Guix containers. In short, this sets up an
> FHS-like (Filesystem Hierarchy Standard) container which has things
> like /lib and /bin.
> 
> I would like to get some suggestions on good examples to include.
> More general feedback, questions, and other comments are also
> welcome! I've included a rough draft of the beginning of the post,
> leading up to showing some examples.

Hi,

One recent real-life example of `--emulate-fhs` being useful is with
Python's virtualenv. I mentioned it in one help-guix thread which
you can see here[1] :)

Wojtek

[1] https://lists.gnu.org/archive/html/help-guix/2022-11/msg00305.html

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!   #11: saint Jacek Odrowąż
Poznaj świętych krakowskich!  #11: święty Jacek Odrowąż
https://pl.wikipedia.org/wiki/Jacek_Odrowąż
-- (sig_end)


On Mon, 05 Dec 2022 02:32:40 +
John Kehayias  wrote:

> Hi Guixers!
> 
> I've started working on a little blog post about our new --emulate-fhs option 
> for Guix containers. In short, this sets up an FHS-like (Filesystem Hierarchy 
> Standard) container which has things like /lib and /bin.
> 
> I would like to get some suggestions on good examples to include. More 
> general feedback, questions, and other comments are also welcome! I've 
> included a rough draft of the beginning of the post, leading up to showing 
> some examples.
> 
> (I've sent this to the devel and help list as I think input from different 
> types of users will be helpful given the feature being discussed. I'm not 
> currently subscribed to the help list, so please cc the devel list or me 
> directly.)
> 
> One question: what is appropriate or recommended for examples concerning 
> things like pre-built binaries? As an example, I had tested the FHS container 
> by running the Siril appimage, which has since been packaged for Guix (nice 
> work!). There are ones that I don't see that happening for anytime soon, like 
> an Electron-based app. Something like VSCodium is very popular, free (as in 
> freedom and I believe the FSDG sense), but just not something you can package 
> fully from source due to JavaScript as I understand it. It runs in the FHS 
> container.
> 
> Examples I was thinking of including: using rustup (uses pre-build rust 
> binaries) and building a package that depends on newer (nightly) rust, like 
> eww  This builds and nicely is 
> screenshot-able with pretty looking desktop widgets.
> 
> What would be useful examples? What is the right line to toe regarding 
> binaries? I don't want to necessarily advocate for that, yet sometimes we may 
> feel we have no other choice or want to be able to test something. I was 
> thinking to keep it to what we do have packaged in Guix yet may want to run 
> in a different way, or something that would fit if the language ecosystem 
> wasn't so at odds with the Guix approach (and reproducibility more generally).
> 
> Appreciative of any and all thoughts!
> 
> John
> 
> 
> Here is a current (rough!) draft. For the ease of plain text email I've 
> exported from the org source to text with some light edits:
> 
> 
> __
> 
> FHS COMES TO GUIX CONTAINERS
> 
> John Kehayias
> __
> 
> 
> GNU Guix is different from most other GNU/Linux distributions and
> perhaps nowhere is that more obvious than the organization of the
> filesystem: Guix does not conform to the [File Hierarchy Standard]
> (FHS). In practical terms, this means there is no global `/lib'
> containing libraries, `/bin' containing binaries[1], and so on. This is
> very much at the core of how Guix works and some of the convenient
> features, like per-user installation of programs (different versions,
> for instance) and a declarative system configuration where the system is
> determined from a configuration file.
> 
> However, this also leads to a difference in how many pieces of software
> expect their world to look like, relying on finding a library in `/lib'
> or an external tool in `/bin'. When these are hard coded and not
> overcome with appropriate build options, we patch code to refer to
> absolute paths in the store, like
> `/gnu/store/hrgqa7m498wfavq4awai3xz86ifkjxdr-grep-3.6/bin/grep', to keep
> everything consistently contained within the store.
> 
> It all works great and is thanks to the hard work of everyone that has
> contributed to Guix. But what if we need a more FHS-like environment for
> developing, testing, or running a piece of software?
> 
> To that end, we've [recently added] a new option for Guix containers,
> `--emulate-fhs' (or `-F'). This will set up an environment in the
> container that follows FHS expectations, so that libraries are visible
> in `/lib' in the cont

tree-sitter grammars for emacs memo

[Murad Mamedov]

Hi,

Today I spent some time on trying latest emacs with
--with-tree-siter enabled. It enables native support
for tree-sitter. However, language grammars are still
external. I came up with below snippet that makes
grammar packages. But I didn't find it worth committing.
So sharing it here if someone will want to try,
or may be form it to commit.

Current issues related to guix with tree-sitter below:

- Emacs tries to dlopen libraries with grammars.
 Since we are under guix, one has to add grammar
 packages to profile and use treesit-extra-load-path
 variable. In the long run, this will require different
 solution, probably patching emacs it self, idk.

--8<---cut here---start->8---
(use-package treesit
 :demand t
 :init
 (setq treesit-extra-load-path
   '("/home/muradm/.cache/guix-extra-profiles/desktop/lib")))
--8<---cut here---end--->8---

Regards,
muradm

>From c8a8db2d46b5320185aaa5ba4ec9d7e8764af592 Mon Sep 17 00:00:00 2001
From: muradm 
Date: Sun, 4 Dec 2022 13:22:07 +0300
Subject: [PATCH] tree-sitter-module

---
 src/emacs-module.h  | 763 
 src/tree-sitter-lang.in |  79 +
 2 files changed, 842 insertions(+)
 create mode 100644 src/emacs-module.h
 create mode 100644 src/tree-sitter-lang.in

diff --git a/src/emacs-module.h b/src/emacs-module.h
new file mode 100644
index 000..1185c06
--- /dev/null
+++ b/src/emacs-module.h
@@ -0,0 +1,763 @@
+/* emacs-module.h - GNU Emacs module API.
+
+Copyright (C) 2015-2021 Free Software Foundation, Inc.
+
+This file is part of GNU Emacs.
+
+GNU Emacs is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or (at
+your option) any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs.  If not, see .  */
+
+/*
+This file defines the Emacs module API.  Please see the chapter
+`Dynamic Modules' in the GNU Emacs Lisp Reference Manual for
+information how to write modules and use this header file.
+*/
+
+#ifndef EMACS_MODULE_H
+#define EMACS_MODULE_H
+
+#include 
+#include 
+#include 
+
+#ifndef __cplusplus
+#include 
+#endif
+
+#define EMACS_MAJOR_VERSION 28
+
+#if defined __cplusplus && __cplusplus >= 201103L
+# define EMACS_NOEXCEPT noexcept
+#else
+# define EMACS_NOEXCEPT
+#endif
+
+#if defined __cplusplus && __cplusplus >= 201703L
+# define EMACS_NOEXCEPT_TYPEDEF noexcept
+#else
+# define EMACS_NOEXCEPT_TYPEDEF
+#endif
+
+#if 3 < __GNUC__ + (3 <= __GNUC_MINOR__)
+# define EMACS_ATTRIBUTE_NONNULL(...) \
+   __attribute__ ((__nonnull__ (__VA_ARGS__)))
+#elif (defined __has_attribute \
+   && (!defined __clang_minor__ \
+	   || 3 < __clang_major__ + (5 <= __clang_minor__)))
+# if __has_attribute (__nonnull__)
+#  define EMACS_ATTRIBUTE_NONNULL(...) \
+__attribute__ ((__nonnull__ (__VA_ARGS__)))
+# endif
+#endif
+#ifndef EMACS_ATTRIBUTE_NONNULL
+# define EMACS_ATTRIBUTE_NONNULL(...)
+#endif
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* Current environment.  */
+typedef struct emacs_env_28 emacs_env;
+
+/* Opaque pointer representing an Emacs Lisp value.
+   BEWARE: Do not assume NULL is a valid value!  */
+typedef struct emacs_value_tag *emacs_value;
+
+enum { emacs_variadic_function = -2 };
+
+/* Struct passed to a module init function (emacs_module_init).  */
+struct emacs_runtime
+{
+  /* Structure size (for version checking).  */
+  ptrdiff_t size;
+
+  /* Private data; users should not touch this.  */
+  struct emacs_runtime_private *private_members;
+
+  /* Return an environment pointer.  */
+  emacs_env *(*get_environment) (struct emacs_runtime *runtime)
+EMACS_ATTRIBUTE_NONNULL (1);
+};
+
+/* Type aliases for function pointer types used in the module API.
+   Note that we don't use these aliases directly in the API to be able
+   to mark the function arguments as 'noexcept' before C++20.
+   However, users can use them if they want.  */
+
+/* Function prototype for the module Lisp functions.  These must not
+   throw C++ exceptions.  */
+typedef emacs_value (*emacs_function) (emacs_env *env, ptrdiff_t nargs,
+   emacs_value *args,
+   void *data)
+  EMACS_NOEXCEPT_TYPEDEF EMACS_ATTRIBUTE_NONNULL (1);
+
+/* Function prototype for module user-pointer and function finalizers.
+   These must not throw C++ exceptions.  */
+typedef void (*emacs_finalizer) (void *data) EMACS_NOEXCEPT_TYPEDEF;
+
+/* Possible Emacs function call outcomes.  */
+enum emacs_funcall_exit
+{
+  /* Function has returned normally.  */
+

Drafting a Guix blog post on the FHS container

[John Kehayias]

Hi Guixers!

I've started working on a little blog post about our new --emulate-fhs option 
for Guix containers. In short, this sets up an FHS-like (Filesystem Hierarchy 
Standard) container which has things like /lib and /bin.

I would like to get some suggestions on good examples to include. More general 
feedback, questions, and other comments are also welcome! I've included a rough 
draft of the beginning of the post, leading up to showing some examples.

(I've sent this to the devel and help list as I think input from different 
types of users will be helpful given the feature being discussed. I'm not 
currently subscribed to the help list, so please cc the devel list or me 
directly.)

One question: what is appropriate or recommended for examples concerning things 
like pre-built binaries? As an example, I had tested the FHS container by 
running the Siril appimage, which has since been packaged for Guix (nice 
work!). There are ones that I don't see that happening for anytime soon, like 
an Electron-based app. Something like VSCodium is very popular, free (as in 
freedom and I believe the FSDG sense), but just not something you can package 
fully from source due to JavaScript as I understand it. It runs in the FHS 
container.

Examples I was thinking of including: using rustup (uses pre-build rust 
binaries) and building a package that depends on newer (nightly) rust, like eww 
 This builds and nicely is screenshot-able with 
pretty looking desktop widgets.

What would be useful examples? What is the right line to toe regarding 
binaries? I don't want to necessarily advocate for that, yet sometimes we may 
feel we have no other choice or want to be able to test something. I was 
thinking to keep it to what we do have packaged in Guix yet may want to run in 
a different way, or something that would fit if the language ecosystem wasn't 
so at odds with the Guix approach (and reproducibility more generally).

Appreciative of any and all thoughts!

John


Here is a current (rough!) draft. For the ease of plain text email I've 
exported from the org source to text with some light edits:


__

FHS COMES TO GUIX CONTAINERS

John Kehayias
__


GNU Guix is different from most other GNU/Linux distributions and
perhaps nowhere is that more obvious than the organization of the
filesystem: Guix does not conform to the [File Hierarchy Standard]
(FHS). In practical terms, this means there is no global `/lib'
containing libraries, `/bin' containing binaries[1], and so on. This is
very much at the core of how Guix works and some of the convenient
features, like per-user installation of programs (different versions,
for instance) and a declarative system configuration where the system is
determined from a configuration file.

However, this also leads to a difference in how many pieces of software
expect their world to look like, relying on finding a library in `/lib'
or an external tool in `/bin'. When these are hard coded and not
overcome with appropriate build options, we patch code to refer to
absolute paths in the store, like
`/gnu/store/hrgqa7m498wfavq4awai3xz86ifkjxdr-grep-3.6/bin/grep', to keep
everything consistently contained within the store.

It all works great and is thanks to the hard work of everyone that has
contributed to Guix. But what if we need a more FHS-like environment for
developing, testing, or running a piece of software?

To that end, we've [recently added] a new option for Guix containers,
`--emulate-fhs' (or `-F'). This will set up an environment in the
container that follows FHS expectations, so that libraries are visible
in `/lib' in the container, as an example. Additionally, for the more
technically-minded, the [`glibc' used in this container] will read from
a global cache in `/etc/ld.so.cache' contrary to the behavior in [Guix
otherwise].

Here is a very simple example:
,
 guix shell --container --emulate-fhs coreutils -- ls /bin
`

[
b2sum
base32
base64
basename
basenc
cat
catchsegv
chcon
chgrp
chmod
...

Contrast that with `/bin' on a Guix system:
,
 ls /bin -la
`

lrwxrwxrwx  1  root  root   61  Dec  3  16:37  sh  ->  
/gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/sh

There are several uses that spring to mind for such a container in Guix.
For developers, or those aspiring to hack on a project, this is a
helpful tool when needing to emulate a different (non-Guix) environment.
For example, one could use this to more easily follow build instructions
meant for a general distribution, say when a Guix package is not (yet)
available or easy to write immediately. Another usage is to be able to
use tools that don't really fit into Guix's model, like ones that use
pre-built binaries. There are many reasons why this is not ideal and
Guix strives to replace or supplement such tools, but practically
speaking they can be hard to avoid entirely. The FHS container helps
bri

Re: guix emacs package MELPA/ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The packages in GNU ELPA really are part of GNU Emacs.  We get
copyright assignments for them, and we work on them just as if they
were in the Emacs core.  Indeed, we can move them between GNU ELPA and
the core when that is useful.

The packages in NonGNU ELPA are really not part of GNU Emacs, and you
can see that in every aspect of how we treat them.  We do not maintain
them; we do not host their development; we don't deal with their
copyrights.  They can't go into Emacs core.

All we do with them is inform users about the possibility of using
them.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Licence of the Guix blog posts

[John Kehayias]

Hello,

On Mon, Nov 28, 2022 at 06:22 PM, Ludovic Courtès wrote:

> Hello Guix!
>
> You might remember that I started long ago asking people who had
> contributed to the blog whether they would agree to licensing their work
> under CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant
> Sections, no Front-Cover Texts, and no Back-Cover Texts¹.
>
> I did not get replies from Danny Milosavljevic and Laura Lazzati²;
> everyone else agreed publicly.
>
> In the meantime, we got a new blog post³ with lots of contributors,
> thanks to Simon’s work.  Unfortunately I think we did not discuss the
> licensing terms.
>
> Therefore, I propose to apply the following patch, which leaves out a
> couple of posts as “unlicensed”.  From there on, we’ll have consistent
> free licensing by default.
>
> Thoughts?
>
> Simon, what do you think about emailing the authors of the “10 years of
> stories” post asking if they agree with the licensing?  :-)  No rush,
> though the sooner the more likely we are to get an answer.
>

As an author for one of the paragraphs on the "10 years" blog post, consider 
this my agreement with these licensing terms.

Thanks for helping get this sorted!

John Kehayias

Re: GNU Guix 1.4.0rc1 available for testing!

[Julien Lepiller]

For i18n, weblate is still following master. I'll switch when we start string 
freeze, which should be one week before release. When the time comes, please 
someone ping me :)

Le 4 décembre 2022 17:17:38 GMT+01:00, "pelzflorian (Florian Pelz)" 
 a écrit :
>There are some release blockers.  To summarize, IMHO it would be
>regrettable if these bugs were not fixed before release:
>
>* [PATCH v2 2/3] install: Add missing e2fsprogs utility.
>  
>  Otherwise manual installation does not work as advertised.
>
>* [version 1.4.0rc1] reconfigure fails
>  
>  Otherwise users cannot update Guix System once installed
>  unless they take manual action.
>
>* [version 1.4.0rc1] install.sh script should authorize bordeaux
>  
>  Otherwise especially ARM users get far less substitutes
>  unless they take manual action.
>
>Julien Lepiller  writes:
>> Do we string freeze?
>
>About string freeze: I do not know if that is the case, but changes to
>critical parts of doc/guix.texi on master should not be reflected on
>Weblate if they don’t get into 1.4.0.
>
>Regards,
>Florian

Re: GMP GCC C++ Hurd cross-build failure on core-updates

[Joshua Branson]

zamfofex  writes:

> Hello, Guix! I have been trying to update the Hurd packages to their latest
> commits in the hopes that I can eventually get networking with netdde
> functioning.
>
> In , I got something that seemed to be
> working at first (at least it progressed farther than the status quo at the
> time), but eventually I got an error that seemed related to Mig, which I had 
> not
> updated in that patch set.
>
> Updating Mig required a more recent glibc than what was available in Guix at 
> the time, so I worked on  to update glibc.
>
> Now that the recent glibc is on core-updates, I picked up my work once again. 
> I
> updated the packages to the latest commits, and updated Mig! However, I ran 
> into
> an issue while trying to build a system image. The issue is that GMP fails to
> cross‐compile during the ‘configure’ phase becase the cross‐compiling ‘g++’ is
> not functional.
>
> When checking whether ‘g++’ can compile executables during ‘configure’, ‘g++’ 
> is
> unable to link the executables because some ‘pthread_*’ symbols required by
> libstdc++ are missing from libc. And when checking using ‘readelf’, they are
> indeed missing from the cross‐built libc, which instead contains similar
> ‘__pthread_*’ symbols.
>
> I don’t know for sure what the issue is, but I highly suspect libstdc++ is 
> being
> compiled against the native glibc headers, rather than the cross‐built glibc
> headers like it should.
>

I am way out of my depth here, but would it matter that on the hurd
pthread is not in glibc?

https://lists.gnu.org/archive/html/bug-hurd/2022-10/msg00069.html

>
> Note: Currently, trying to cross‐build packages from core‐updates for the Hurd
> will fail while compiling glibc, since the Hurd package is too outdated for 
> that
> version of glibc.
>
> I’ll attach a diff (for core-updates) with the updated Hurd packages to this 
> email. To verify the behavior I’m describing, try running:
>
> - - - - -
> ./pre-inst-env guix build --target=i586-pc-gnu gmp
> - - - - -
>
> Any kind of assistance would be appreciated! Thanks in advance.

Re: File search

[Antoine R. Dumont (@ardumont)]

Hello Guix,

Ludo, \o/, thanks for the iteration ;) Not that I understood everything
yet but indeed, it's faster.

I've iterated over your work to:
- align calls to that new function
- improve some docstrings, and imports, and the help message
- drop dead (or redundant) code
- make sure the (xdg) folder holding the db is created if needed

Please, find enclosed the latest implementation as a patch (somewhat vcs
code ;). I've edited commits to mark Ludo as author with his
started/amended implementations first [0] (that should be in the patch).

For information, I extracted some number from runs to compare our
iterations (see the org-file attachment). The first iteration being
"extracts packages from the store" and the second one "extracts packages
from the system manifest". Those runs happened both on a guixified
debian host and a raw guix host (more packages).

It seems with the new implementation, we find less a bit less packages
but it's faster so i guess it's a tradeoff. It'd be nice to know how it
runs on your build farm machine (if you got the time at some point [1]).

[0] fwiw, yeah git and magit! :D

[1] I noticed (through ml discussions) you all are quite busy at the
moment ;)

Cheers,
--
tony / Antoine R. Dumont (@ardumont)

-
gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8

Ludovic Courtès  writes:

> Yay, nice work!
>
> I toyed a bit with your code and that gave me an idea: instead of the
> costly ‘fold-packages’ + ‘package-derivation’, we can iterate over all
> the manifests on the system and index packages they refer to.  That way,
> no need to talk to the daemon, computer derivations, etc.  Should be
> faster, though of course it still needs to traverse those directories.
>
> Please find attached a modified version that illustrates that.  (We’ll
> need version control at some point.  :-))
>
> Thanks,
> Ludo’.
>
> ;;; GNU Guix --- Functional package management for GNU
> ;;; Copyright © 2022 Ludovic Courtès 
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> ;;; GNU Guix is free software; you can redistribute it and/or modify it
> ;;; under the terms of the GNU General Public License as published by
> ;;; the Free Software Foundation; either version 3 of the License, or (at
> ;;; your option) any later version.
> ;;;
> ;;; GNU Guix is distributed in the hope that it will be useful, but
> ;;; WITHOUT ANY WARRANTY; without even the implied warranty of
> ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ;;; GNU General Public License for more details.
> ;;;
> ;;; You should have received a copy of the GNU General Public License
> ;;; along with GNU Guix.  If not, see .
>
> (define-module (guix extensions index)
>   #:use-module (guix config)  ;; %guix-package-name, ...
>   #:use-module (guix ui)  ;; display G_
>   #:use-module (guix scripts)
>   #:use-module (sqlite3)
>   #:use-module (ice-9 match)
>   #:use-module (guix describe)
>   #:use-module (guix store)
>   #:use-module (guix monads)
>   #:autoload   (guix combinators) (fold2)
>   #:autoload   (guix grafts) (%graft?)
>   #:autoload   (guix store roots) (gc-roots)
>   #:use-module (guix derivations)
>   #:use-module (guix packages)
>   #:use-module (guix profiles)
>   #:use-module (guix sets)
>   #:use-module ((guix utils) #:select (cache-directory))
>   #:autoload   (guix build utils) (find-files)
>   #:autoload   (gnu packages) (fold-packages)
>   #:use-module (srfi srfi-1)
>   #:use-module (srfi srfi-9)
>   #:use-module (srfi srfi-71)
>   #:export (guix-index))
>
> (define debug #f)
>
> (define schema
>   "
> create table if not exists Packages (
>   idinteger primary key autoincrement not null,
>   name  text not null,
>   version   text not null,
>   unique(name, version) -- add uniqueness constraint
> );
>
> create table if not exists Directories (
>   idinteger primary key autoincrement not null,
>   name  text not null,
>   package   integer not null,
>   foreign key (package) references Packages(id) on delete cascade,
>   unique (name, package) -- add uniqueness constraint
> );
>
> create table if not exists Files (
>   name  text not null,
>   basename  text not null,
>   directory integer not null,
>   foreign key (directory) references Directories(id) on delete cascade
>   unique (name, basename, directory) -- add uniqueness constraint
> );
>
> create index if not exists IndexFiles on Files(basename);")
>
> (define (call-with-database file proc)
>   (let ((db (sqlite-open file)))
> (dynamic-wind
>   (lambda () #t)
>   (lambda ()
> (sqlite-exec db schema)
> (proc db))
>   (lambda ()
> (sqlite-close db)
>
> (define (insert-files db package version directories)
>   "Insert files from DIRECTORIES as belonging to PACKAGE at VERSION."
>   (define stmt-select-package
> (sqlite-prepare db "\
> SELECT id FROM Packages WH

Re: GNU Guix 1.4.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

There are some release blockers.  To summarize, IMHO it would be
regrettable if these bugs were not fixed before release:

* [PATCH v2 2/3] install: Add missing e2fsprogs utility.
  
  Otherwise manual installation does not work as advertised.

* [version 1.4.0rc1] reconfigure fails
  
  Otherwise users cannot update Guix System once installed
  unless they take manual action.

* [version 1.4.0rc1] install.sh script should authorize bordeaux
  
  Otherwise especially ARM users get far less substitutes
  unless they take manual action.

Julien Lepiller  writes:
> Do we string freeze?

About string freeze: I do not know if that is the case, but changes to
critical parts of doc/guix.texi on master should not be reflected on
Weblate if they don’t get into 1.4.0.

Regards,
Florian

Re: GNU Guix 1.4.0rc1 available for testing!

[Development of GNU Guix and the GNU System distribution.]

Thank you, Kaelyn. I appreciate how friendly and helpful this commuity is.

For testing documentation purposes, this is the hardware that the release
candidate is running smoothly on for me so far:

OS: Guix System x86_64 
Host: X570 AORUS XTREME -CF 
Kernel: 6.0.10-gnu 
Uptime: 1 day, 56 mins 
Packages: 60 (guix-system), 91 (guix-user) 
Shell: fish 3.5.1 
Resolution: 3840x1080 
DE: exwm
Terminal: urxvt 
Terminal Font: Iosevka 
CPU: AMD Ryzen 9 5900X (24) @ 3.700GHz 
GPU: NVIDIA 0c:00.0 NVIDIA Corporation Device 2206 
Memory: 3109MiB / 32031MiB

Re: Winding down of Fosshost

[Tobias Geerinckx-Rice]

Hi Jonathan,

indieterminacy 写道：

Given Fosshost's place in the ecosystem: is this something which
requires mitigating at the Guix end?


I'm aware of two dealings with Fosshost in the past, neither of 
them crucial:
- They hosted a Big Blue Button instance[0] only for the duration 
 of our COVID Days[1].

- They donated and hosted[2] two x86_64 machines.

fosshost1. responds to pings; fosshost2. does not.  I never had 
SSH access to either.  The machines may have been shut down and 
the fosshost1 IP repurposed.  They might never have made it to 
production at all.


Chris Baines[3], CC'd, will know.

Kind regards,

T G-R

[0]: (dead link) https://guixbbb.fosshost.org
[1]: 
https://lists.gnu.org/archive/html/guix-europe/2020-12/msg00012.html

[2]: https://guix.gnu.org/fr/donate/
[3]: https://logs.guix.gnu.org/guix/2020-11-07.log#141750


signature.asc
Description: PGP signature

Re: Release progress, week 8

[Mathieu Othacehe]

Hey,

Thanks for your hard work to publish the RC1!

> Now we need reports from users to act upon.  I’d say we can decide next
> week whether we need an RC2 or not.  I can handle the next release
> candidate or the release itself, but I’ll be unavailable on Dec. 12–15.

I noticed that we have failing tests on the version-1.4.0-tests
specification.

- docker-system (https://ci.guix.gnu.org/build/215380/details)
- prosody (https://ci.guix.gnu.org/build/215424/details)

that fail both on Berlin and on my machine and,

- fail2ban-extension (https://ci.guix.gnu.org/build/215447/details)

that only fails on Berlin.

There is also an issue with the system images. The following images are
failing on Berlin:

- novena-barebones-raw-image (https://ci.guix.gnu.org/build/215363/details)
- pine64-barebones-raw-image (https://ci.guix.gnu.org/build/215361/details)
- pinebook-pro-barebones-raw-image 
(https://ci.guix.gnu.org/build/215362/details)

It seems that those failures are caused by an issue during info-reader
build. I cannot reproduce it locally though.

Having an RC2 with all the tests passing and images buildable could be
nice.

On the other hand, I don't have much bandwidth to fix those issues and
they should not prevent us from releasing I guess.

Mathieu

Re: Help with G-expression

[zimoun]

Hi Ludo,

Thanks for the help.


On Sat, 03 Dec 2022 at 18:43, Ludovic Courtès  wrote:

> Fixed in 9672db290a35f59113682a7f0c17c050a4ae2578.

Well, the main issue was that I hit this bug. :-)

I tried to see if this trivial example is covered by the test suite but
I have not found it.  Something like,

--8<---cut here---start->8---
(define (something)
  (with-extensions (list guile-gcrypt)
(with-imported-modules (source-module-closure
'((guix build utils)
  (guix profiles))) ;import it
  (computed-file "empty-tree"
 #~(begin
 ;; Put it in scope.
 (use-modules (guix build utils))

 ;; Happily use its 'mkdir-p' procedure.
 (mkdir-p (string-append #$output "/a/b/c")))
,build (something)
--8<---cut here---end--->8---

where ’something’ would be a better name and ’,build’ the real function
call.  Well, maybe it could help to detect some regression. :-)  As
people tell: one bug closed, one test added. ;-)

Although it requires to talk with the daemon and I do not remember if it
is a good idea to add such test.


> It’s annoying, but I don’t see how this could be avoided.

Well, the error message is not super clear…

--8<---cut here---start->8---
building 
/gnu/store/rh1ii1cjlc0jhkz2aspxcw1mdkr7b2nf-module-import-compiled.drv...
 20% [# 
]builder for 
`/gnu/store/rh1ii1cjlc0jhkz2aspxcw1mdkr7b2nf-module-import-compiled.drv' failed 
with exit code 1
build of /gnu/store/rh1ii1cjlc0jhkz2aspxcw1mdkr7b2nf-module-import-compiled.drv 
failed
View build log at 
'/var/log/guix/drvs/rh/1ii1cjlc0jhkz2aspxcw1mdkr7b2nf-module-import-compiled.drv.gz'.
cannot build derivation 
`/gnu/store/cznhm1wzdv60jwi7fz96cilq925j54i1-empty-tree.drv': 1 dependencies 
couldn't be built
While executing meta-command:
ERROR:
  1. &store-protocol-error:
  message: "build of 
`/gnu/store/cznhm1wzdv60jwi7fz96cilq925j54i1-empty-tree.drv' failed"
  status: 100
--8<---cut here---end--->8---

…but the log somehow is:

--8<---cut here---start->8---
[ 1/56] Loading './guix/base16.scm'...

[...]

[11/56] Loading './guix/derivations.scm'...
;;; Failed to autoload make-zlib-input-port in (zlib):
;;; no code for module (zlib)
;;; Failed to autoload make-zlib-input-port in (zlib):
;;; no code for module (zlib)
;;; Failed to autoload make-zlib-output-port in (zlib):
;;; no code for module (zlib)
;;; Failed to autoload make-zlib-output-port in (zlib):
;;; no code for module (zlib)
Backtrace:

[...]

   222:17  1 (map1 (((gcrypt hash)) ((guix profiling)) ((rnrs #)) # ?))
   3329:6  0 (resolve-interface (gcrypt hash) #:select _ #:hide _ # _ ?)

ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
no code for module (gcrypt hash)
--8<---cut here---end--->8---

Well, it seems reasonable, IMHO, to assume that an user diving into such
internal would be able to parse this information.


Cheers,
simon

Re: Release progress, week 8

[zimoun]

Hi,

On Sun, 04 Dec 2022 at 00:32, Maxim Cournoyer  wrote:

>> It reminds me that,
>>
>> https://othacehe.org/wsl-images-for-guix-system.htm
>>
>> could fit a Guix blog post.  Mathieu, WDYT?
>
> Mathieu wrote one already, it's published on their personal blog.  I've
> read it recently, it was interesting [0]
>
> [0]  https://othacehe.org/wsl-images-for-guix-system.html

Sorry to not have been clear, I am proposing to convert the already
published Mathieu’s post on their personal blog as a post on the Guix
blog.

I agree it is an interesting read and it appears to me worth for
communicating. :-)

It could be published “as is“ or could be a bit polished by proofreaders
(people behind the alias guix-b...@gnu.org; which includes myself :-)).

Mathieu, WDYT?


Cheers,
simon

Winding down of Fosshost

[indieterminacy]

Unfortunately Fosshost is being wound down, due to organistional 
failings at the executive level.


https://fosshost.org/

Given Fosshost's place in the ecosystem: is this something which 
requires mitigating at the Guix end?


--
Jonathan McHugh
indieterminacy@libre.brussels