Extension for improving Guix search?

[Simon Tournier]

p/

8: Re: Mechanism for helping in multi-channels configuration (and Xapian index)
Simon Tournier 
Mon, 06 May 2024 14:05:50 +0200
id:87pltzp2ld@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2024-05
https://yhetil.org/guix/87pltzp2ld@gmail.com

Re: Guix pull: avoiding "Computing Guix derivation"

[Simon Tournier]

Hi Richard,

On lun., 13 mai 2024 at 20:52, Richard Sent  wrote:

> You're correct. This solution wouldn't be sufficient to avoid "Computing
> Guix Derivation" for every possible A or B. To my understanding it could
> reduce the frequency this occurs.

[...]

> Assuming D changes significantly less frequently than A, B, C..., I
> would think this should be something we could feasibly substitute (at
> least for recent D and Z).

Well, the package ’guix’ has changed 14 times over the past year.
Therefore, this D cannot be this package ’guix’, IMHO.

--8<---cut here---start->8---
$ git log --format="%cd %s" --since="1 year ago" | grep 'gnu: guix: Update' 
Mon May 13 18:22:53 2024 +0200 gnu: guix: Update to 7ca9809.
Tue Mar 12 14:27:01 2024 +0100 gnu: guix: Update to 4c94b9e.
Mon Mar 11 23:14:37 2024 +0100 gnu: guix: Update to 8f4ffb3.
Sat Dec 2 15:37:44 2023 +0100 gnu: guix: Update to 1.4.0-16.aeb494322c.
Thu Nov 30 07:15:36 2023 +0100 gnu: guix: Update to 1.4.0-15.e0885fcfbb.
Thu Nov 9 10:42:55 2023 +0200 gnu: guix: Update to a60ff46.
Fri Oct 6 12:26:44 2023 +0200 gnu: guix: Update to e863274.
Thu Sep 28 11:44:08 2023 +0200 gnu: guix: Update to d0438fc.
Mon Sep 18 12:31:52 2023 +0200 Revert "gnu: guix: Update to 
1.4.0-11.658de25e99."
Mon Sep 18 06:49:46 2023 +0200 gnu: guix: Update to 1.4.0-11.658de25e99.
Tue Aug 22 21:30:49 2023 +0200 gnu: guix: Update to 1.4.0-10.4dfdd82210.
Tue Aug 22 11:17:52 2023 +0200 gnu: guix: Update to 30355c1.
Mon Oct 2 09:28:02 2023 +0200 gnu: guix: Update to 1.4.0-12.b9fae146d6.
Mon Aug 21 18:44:49 2023 +0200 gnu: guix: Update to 0e6215a.
Fri Jun 9 22:11:14 2023 +0200 gnu: guix: Update to 44bbfc2.
--8<---cut here---end--->8---

Maybe I have a bad practise but here my “guix pull” history:

--8<---cut here---start->8---
$ guix pull -l | grep Generation
Generation 1nov. 17 2023 13:18:58
Generation 2déc. 11 2023 10:55:51
Generation 3févr. 02 2024 01:56:52
Generation 4mars 25 2024 18:22:25
Generation 5mai 13 2024 19:28:31(current)
--8<---cut here---end--->8---

Therefore, I am not convinced that replacing "Computing Guix derivation"
(build-aux/build-self.scm) by the package ’guix’ would be robust enough.

(Assuming another package ’guix’, lighter e.g., without requiring the
test suite, etc.)

All that said, any experiment – even if it appears at first clunky – is
very welcome!  This part will be improved only if there is a collective
effort / discussion / try, IMHO, i.e., by challenging the status quo. :-)

Cheers,
simon

Re: Guix pull: avoiding "Computing Guix derivation"

[Simon Tournier]

Hi,

On lun., 13 mai 2024 at 17:11, Richard Sent  wrote:

> Instead of A and B building C directly, A and B download the
> substitutable Guix package D, then use D to build C. Because D is a
> reproducible package, it should be substitutable from both A and B.
> Then, because D->C is the same for everyone, we could substitute the
> Guix derivation computation for C.

Maybe I am missing some details.  From my understanding, your D is the
result of the “Computing derivation” dance.  And it is a minimalist
build because it must work for both cases: with or without substitutes.

Somehow, my understanding of the current process is:

  A -> D  -> C
  B -> D* -> C

And, D or D* can be the same script.  Here, the property is a kind of
idempotency.  Hence, C is substitutable.

IIUC, your proposal is to fix D (the intermediary step).  You propose
the package named ’guix’ that changes barely, but it could be something
more minimalist.  The requirements is: susbtitutable.  The problem is
transferred to the first arrow, no?

How can we be sure that A and B points to the same D?

Other said, A lives in the past.  Later, we changed D becoming D*
because some bugs.  The other revision B lives after this change.
Therefore, we have the same picture:

  A -> D
  B -> D*

But then how do we go to C since D and D* does not have a kind of
idempotent property.

>From my understanding, the current situation/process is very similar
with the one for compiling compiler: you have your new Source of
compiler and an OldCompiler binary, so you run:

  OldCompiler(Source) -> Compiler
  and again Compiler(Source) -> NewCompiler

Somehow, whatever the choice of some OldCompiler binary, you get the
same NewCompiler binary (aside trusting trust attack and friends,
obviously ;-))

The story of “guix pull” is not so different; from my understanding.

Again, maybe I am missing something.


Cheers,
simon

Re: Guix pull: avoiding "Computing Guix derivation"

[Simon Tournier]

Hi,

On lun., 13 mai 2024 at 17:04, Edouard Klein  wrote:

> - Why is this step not substitutable ? The inputs are known, a hash can
> be derived, a substitute server could be queried for an output of that
> hash ? What am I missing ? Does the guix derivation not end up in the
> store ? What makes it so special that it can't be served by a substitute
> server ?

Assume we are running two different Guix revisions, say A and B.  And at
the end of our respective “guix pull”, we expect to have the same
revision, say C.  We expect to then run the same Guix.

Other said, how can we “compile” the code of C using one machinery from
A and another potentially different from B and expect to have the same
result?

Somehow, we need an intermediary step: something minimal that is
independent of A and B but produces the same C.  And it’s the aim of
“Computing derivation” with the script build-aux/build-self.scm.

The inputs are known, indeed.  However, the ones from A and from B are
not necessary the sames.  For instance, Guile of A might be different of
Guile of B.  Somehow, that “Computing derivation” is what allows to time
travel.

Well, that’s my understanding and I could have missing something.


For instance, I am running:

$ guix describe
Generation 4mars 25 2024 18:22:25   (current)
  guix 929ddec
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 929ddec8f4a181be653152c7436581c2adc54eee

Assume it is revision A.  From there, let run ’guix pull’.

--8<---cut here---start->8---
$ time guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 6ba29e0 (51 new commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   6ba29e0
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
 module-import  2KiB   305KiB/s 00:00 ▕██▏ 100.0%
 module-import-compiled  1.2MiB306KiB/s 00:04 ▕██▏ 100.0%
 compute-guix-derivation  1015B1.8MiB/s 00:00 ▕██▏ 100.0%
Computing Guix derivation for 'x86_64-linux'... /
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
  /gnu/store/115prkj2rp58gl2lr0qy6higpliw8xpy-profile.drv
  /gnu/store/56dsm4f5snfmnfgkki4x41fj0xcl394m-guix-daemon.drv
  /gnu/store/77r2c33r1cq03qrrrfsf3g6mvmjp0w92-guix-command.drv
  /gnu/store/0y0fq1lmz3dwqi0fpbq4g6swkc9yljmp-guix-cli-modules.drv
  /gnu/store/bbczy39rid3q6j191mj397ak589s1101-guix-system-modules.drv
  /gnu/store/gx3ngbxmb6ayzjpxv9afsigvajc5d7h4-guix-extra-modules.drv
  /gnu/store/i0b6inna8a8bxg75k3dxr4xl6jrn53cm-guix-cli-core-modules.drv
  /gnu/store/iww6bi0ciaqkjjbqp26iclq2ijd1bgck-guix-system-tests-modules.drv
  /gnu/store/x0ai22yrq99kp3il0x3nf1d3yj5fydqy-guix-packages-base-modules.drv

70,7 MB will be downloaded
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%

[...]

 guix-package-cache  872KiB303KiB/s 00:03 ▕██▏ 100.0%
 guix-cli  315KiB  241KiB/s 00:01 ▕██▏ 100.0%
 guix-cli-core  922KiB 194KiB/s 00:05 ▕██▏ 100.0%
 guix-cli-modules  260B253KiB/s 00:00 ▕██▏ 100.0%
 guix-cli-core-modules  261B   450KiB/s 00:00 ▕██▏ 100.0%
 guix-extra  2.8MiB363KiB/s 00:08 ▕██▏ 100.0%
 guix-manual  5.2MiB   273KiB/s 00:19 ▕██▏ 100.0%
 guix-extra-modules  261B  187KiB/s 00:00 ▕██▏ 100.0%
 guix-packages-base  17.4MiB   271KiB/s 01:06 ▕██▏ 100.0%
 guix-system  7.9MiB   264KiB/s 00:31 ▕██▏ 100.0%
 guix-packages-base-modules  265B  279KiB/s 00:00 ▕██▏ 100.0%
 guix-system-modules  262B 282KiB/s 00:00 ▕██▏ 100.0%
 guix-system-tests  921KiB 332KiB/s 00:03 ▕██▏ 100.0%
 guix-system-tests-modules  267B   279KiB/s 00:00 ▕██▏ 100.0%
 guix-6ba29e021-modules  31.2MiB   299KiB/s 01:47 ▕██▏ 100.0%
 guix-module-union  2KiB   385KiB/s 00:00 ▕██▏ 100.0%
 guix-command  655B1.0MiB/s 00:00 ▕██▏ 100.0%
 guix-daemon  402B 711KiB/s 00:00 ▕██▏ 100.0%
 guix-6ba29e021  802B  499KiB/s 00:00 ▕██▏ 100.0%

[...]

real5m8,633s
user1m53,567s
sys 0m1,530s
--8<---cut here---end--->8---

Ok, all is substitutable (wow! 70MiB that’s not nothing… another story)
except the part “Computing derivation”.

Now, from another 

Re: Changing the defaults for --localstatedir and --sysconfdir?

[Simon Tournier]

Hi,

On jeu., 02 mai 2024 at 11:00, Ludovic Courtès  wrote:
> Richard Sent  skribis:
>
>> As everyone who's built Guix from source knows, when running ./configure
>> on a system with an existing Guix installation you must remember to
>> specify --localstatedir=/var and --sysconfdir=/etc. I think we should
>> consider whether those variables should default to those values.
>
> I think it would make sense.

I have always been for changing the defaults but GNU standards…

> Before I advocated that we should preferably stick to the GNU standards
> and have users make informed choices (that’s how we ended up with the
> ‘GUIX_CHECK_LOCALSTATEDIR’ macro that warns users but lets them
> explicitly pass ‘--localstatedir’.)

…and I have never understood this argument. :-)


Well, these GNU Standards read:

  ‘sysconfdir’

 [...]

  This directory should normally be /usr/local/etc, but write it as
  $(prefix)/etc. (If you are using Autoconf, write it as
  ‘@sysconfdir@’.)

  ‘localstatedir’

  [...]

  $(localstatedir) should normally be /usr/local/var, but write it
  as $(prefix)/var. (If you are using Autoconf, write it as
  ‘@localstatedir@’.)

https://www.gnu.org/prep/standards/standards.html#Directory-Variables


As Ricardo pointed, it could be confusing to have some defaults as GNU
Standards recommend and only 2 different.  Especially, $(prefix) might
appear elsewhere as recommendation: ’exec_prefix’ so then ’bindir’,
’sbindir’ etc., ‘datarootdir’ so ’datadir’, ‘sharedstatedir’,
‘includedir’, etc.

Therefore, setting also by default ’prefix’ as /. would mean ’bindir’
equals to /bin.  That’s fine… we need to adjust accordingly
guix-install.sh, to my knowledge.

Well, this ’prefix’ default matters only in one case: other distro
packaging Guix, right?

And I guess these distro do not run “make install” with the default GNU
Standards ’prefix’ recommendation (/usr/local/bin/) and modifies it to
/usr/, I guess.

On foreign distro:

$ ls -a /usr/local/bin/
.  ..  guix

This ’guix’ comes from guix-install.sh.

All in all, the surprise when defaulting ’prefix’, ’localstatedir’ and
’sysconfdir’ should be very limited, no?

Cheers,
simon

3 kinds of bootstrap (was Re: backdoor injection via release tarballs combined with binary artifacts)

[Simon Tournier]

Hi,

I am late to the party…


On mer., 10 avril 2024 at 15:57, Ludovic Courtès  wrote:

>> That has happened to me too.
>> Why not use Git directly always?
>
> Because it create{s,d} a bootstrapping issue.  The
> “builtin:git-download” method was added only recently to guix-daemon and
> cannot be assumed to be available yet:
>
>   https://issues.guix.gnu.org/65866

[...]

> I think we should gradually move to building everything from
> source—i.e., fetching code from VCS and adding Autoconf & co. as inputs.
>
> This has been suggested several times before.  The difficulty, as you
> point out, will lie in addressing bootstrapping issues with core
> packages: glibc, GCC, Binutils, Coreutils, etc.  I’m not sure how to do
> that but…

[...]

> … live-bootstrap can probably be a good source of inspiration to find a
> way to build those core packages (or some of them) straight from a VCS
> checkout.

IMHO, we need to distinguish because there is different types of issues
and thus different potential workarounds. :-)

  1. Bootstrap how to download source code.
  2. Bootstrap how to build core packages.
  3. Bootstrap the driver (say guix-daemon and helpers).

Well, having solutions for #1 and #3 would naturally provide a solution
for #2.  Although the devil is about details. ;-)


About #1


You cannot use the binary ’git’ in order to download the source code of
Git to build the binary ’git’.  Yeah, circular dependency. :-)
Therefore, Git source code is pulled using another method, say from
tarball, such method which also needs to be built from source, so it
also needs yet another method.  The usual chicken-or-the-egg problem.

The current workaround is to “hide” the problem and introduce a
“builtin:download” method: it’s an “opaque” binary that is hard to
inspect.  Roughly, the workaround had been introduced by [1] on
Oct. 2016.  Almost 8 years ago, so it works! :-)

The argument for accepting this “opaque” method is because it is a
fixed-output derivation.  Other said, we know beforehand the SHA256
checksum.  Thus the claim is: being “opaque” does not matter because the
SH256 checksum can be computed independently and all the source code can
be audited.

For cutting another cycle, another “opaque” had be introduced:
“builtin:git-download”.  All applies similarly.

Do not take me wrong with “opaque”.  I mean that the method depends on
the couple user-revision and daemon-revision.  Other said, it is not
straightforward to know when Alice and Bob are using the exact same
method for downloading source code.  Since it is not fully transparent,
it is “opaque”. :-)

Somehow we are applying to all what we need for cutting a specific
circular dependency.  We have some packages named ’foo-bootstrap’ that
are aimed to solve some dependency problem about packages, then we do
not use them for all; we just use them for cutting a circular
dependency.  I think a similar strategy should be applied for the fetch
methods.

We could have “git-fetch” relying on the initial Git method, i.e., a
transparent derivation where it’s straightforward to audit all: the
dependencies and the builder.

And for some specific cases, we could have “git-fetch/bootstrap” relying
on “builtin:git-download”.  It eases to know which packages are very
important to care.

I think that “builtin:download” and “builtin:git-download” applied to
all “url-fetch” and “git-fetch” both downgrade the complete transparency
level for solving very specific bootstrapping problem.

Last about #1, please note that the transparency does not come for free
and has drawbacks: when running say “guix time-machine -C past.scm --
build -S”, all the dependencies for downloading would be the ones of
past.scm.  Other said, for downloading today the source code of a 5
years old package, say using ’hg-fetch’, we need Python and Mercurial as
they were 5 years ago – when we do not expect any difference on the
content with the Python and Mercurial of today.


About #3


That’s the very hard topic!  The bootstrapping story is not fully done
yet.

Assuming trust for #1, the bootstrap of Guix starts with
’bootstrap-seeds’, roughly 232KiB.  Take a moment, that’s impressive, :-)
right?

Obviously, I let aside Haskell, Ocaml@5 etc.

Well, diving further.  These 232K alone are not enough.  It also
requires helpers: tar (1.3MiB), bash (1.3MiB), mkdir (0.7MiB) and xz
(0.844MiB).

More, it requires two drivers: static Guile binary (14MiB) and
guix-daemon.

You get it: How to trust these helpers?  Two approaches: (a) implement
something directly in hex/assembler and/or (b) exploit the Guile binary
(à la Scheme on bare metal).

About guix-daemon, one solution is a daemon directly in Guile, and
compatible with the very Guile binary.  Or at least, a minimalist daemon
with just enough features for building up to guix-daemon.

Or another option is the “Extreme bootstrapping” [3] – my understanding
of live-bootstrap.  Somehow, remove guix-daemon from the picture and
convert the 

Re: Mechanism for helping in multi-channels configuration (and Xapian index)

[Simon Tournier]

Hi,

Sorry for the long delay.

On lun., 18 mars 2024 at 16:05, Christina O'Donnell  wrote:

>> 2: https://issues.guix.gnu.org/issue/39258

> As I said above, [2] is a fairly long thread, but I think I get the 
> general idea. It seems that Xapian was implemented but didn't have the 
> desired speedup. Am I getting the right impression there?

Not really.  From my memories, the first blocker for implementing search
with Xapian was adding Xapian as dependency of Guix.  This addition
would be a bad idea, IMHO.  However…

At the time of discussing Xapian-based “guix search”,
GUIX_EXTENSIONS_PATH was at its infancy.  Therefore, it was not really
on the table.

… Xapian-based “package search” appears to me an option if it is turned
into a Guix extension.  This way, adding Xapian as dependency is not for
all but only for those who want more features. :-)

I have on my TODO list to resume the work:

 1. Benchmark Xapian-based search
 2. Benchmark Xapian index building

Then depending on that, it draws the directions.


Cheers,
simon

Re: Scheduling a new release?

[Simon Tournier]

Re,

On lun., 06 mai 2024 at 13:12, Simon Tournier  wrote:

> Although these days I do not have much free time, let make a new release
> as soon as possible.  WDYT?
>
> Who’s in?

Well, the patch review sessions could be helpful.  Maybe we could run
some online hackathons.  IMHO, having a schedule together would help –
at least me ;-) – to keep the flow until crossing the finish line.

WDYT?

Cheers,
simon

Scheduling a new release?

[Simon Tournier]

Hi all,

Here or there, we have bugs as:

https://issues.guix.gnu.org/70659
https://issues.guix.gnu.org/70726

And our answer looks like:

> Additionally, I strongly advise upgrading guix-daemon, as noted in the
> bug report above.

Well, the bugs appear because the user is upgrading guix-daemon. ;-)

In both cases (#70659 and #70726), it comes from a fresh install (latest
release v1.4.0) and then the first ’guix pull’ aiming to upgrade all
leads to that reported error.

Therefore, I strongly advise upgrading latest Guix release. ;-)


Although these days I do not have much free time, let make a new release
as soon as possible.  WDYT?

Who’s in?

Cheers,
simon

time-bomb and CI? (was bug#69800: kcalendarcore time-bomb)

[Simon Tournier]

Hi,

Reading this message [1]:

 Start of forwarded message 
Subject: bug#69800: kcalendarcore is a time bomb
To: 69...@debbugs.gnu.org
Date: Thu, 14 Mar 2024 20:20:43 +0100
From:  Vivien Kraus via Bug reports for GNU Guix 

Dear Guix,

Kcalendarcore does not build anymore. According to CI, it stopped
working this march, on gnome-team and rust-branch (I can’t build it
either on master).

http://ci.guix.gnu.org/search?query=kcalendarcore

Best regards,

Vivien
 End of forwarded message 

and this fix:

* gnu/packages/kde-frameworks.scm (kcalendarcore) [#:phases]: Add
'disable-failing-test.

My question is: Could we automatically detect by CI such time-related
test?


Other said, would it be possible to have one (or more) node that build
with a date in the future?  Say 3 years.  In Bordeaux?  Or in Berlin?
Using the “Dolorean VM” [2], it could be nice to setup one node.

Some packages would be build by this node.  Somehow, it means some
random-selected packages would be built in the future.  All in all and
considering the rate of building, it would help us to detect problematic
packages.  And fix them now avoid to break “guix time-machine” in the
future.

Well, I am trying to have a more systematic approach here at work – bah
not sure it will see the light –, so still awaiting, having one node in
the future would help, IMHO.

WDYT?

Cheers,
simon

PS: Do we speak about bug of year 2038? ;-)

1: bug#69800: kcalendarcore is a time bomb
Vivien Kraus via Bug reports for GNU Guix 
Thu, 14 Mar 2024 20:20:43 +0100
id:994ee26ab0444037bcc93ee91af18e5a0b389c33.ca...@planete-kraus.eu
https://issues.guix.gnu.org/69800
https://issues.guix.gnu.org/msgid/994ee26ab0444037bcc93ee91af18e5a0b389c33.ca...@planete-kraus.eu
https://yhetil.org/guix/994ee26ab0444037bcc93ee91af18e5a0b389c33.ca...@planete-kraus.eu

2:
https://guix.gnu.org/en/blog/2024/adventures-on-the-quest-for-long-term-reproducible-deployment

Re: Guile CSE elimination of record accessor?

[Simon Tournier]

Hi Andy,

Thanks for the explanations.

On mar., 30 avril 2024 at 16:43, Andy Wingo  wrote:

>> The first question is: is it still correct?  Because this module had
>> been implemented before many Guile compiler improvements.
>
> No, the comment is incorrect.  The type check on whatever accessor is
> called first (unspecified in scheme; probably we should just bite the
> bullet and do predictable left-to-right semantics, as racket does) will
> dominate the rest and eliminate those checks.  The assert-type is
> unnecessary.

Good to know.

> To see this, do ,optimize-cps at the repl, and count the number of
> e.g. struct? checks with and without the assert-vlist.  There is only
> one, either way.

Hum, I am not sure to understand how to use ,optimize-cps at the repl.
Naively, I get:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(ice-9 vlist)
scheme@(guile-user)> ,optimize-cps (vlist-cons 'foo vlist-null)
L0:   ;  at :102:14
  v0 := self
  L1(...)
L1:
  receive()
  v1 := current-module()  ; mod While executing 
meta-command:
In procedure +: Wrong type argument in position 1: #f
--8<---cut here---end--->8---

Since ’,help compile’ reads,

,optimize-cps EXP [,optx] - Run the CPS optimizer on a piece of 
code and print the result.

I assume that I do not feed with the correct expression EXP.  What would
be the invocation?


>   (A type check is a heap-object? check, then struct?,
> then get the vtable, then check against the global variable .
> All of these duplicates get eliminated.)

Ah yeah, it makes sense. :-)

Cheers,
simon

Guile CSE elimination of record accessor?

[Simon Tournier]

Hi,

In Guile module (ice-9 vlist), one reads:

--8<---cut here---start->8---
;; Asserting that something is a vlist is actually a win if your next
;; step is to call record accessors, because that causes CSE to
;; eliminate the type checks in those accessors.
;;
(define-inlinable (assert-vlist val)
  (unless (vlist? val)
(throw 'wrong-type-arg
   #f
   "Not a vlist: ~S"
   (list val)
   (list val

[...]

(define (vlist-head vlist)
  "Return the head of VLIST."
  (assert-vlist vlist)
  (let ((base   (vlist-base vlist))
(offset (vlist-offset vlist)))
(block-ref (block-content base) offset)))
--8<---cut here---end--->8---

Other said, the argument ’vlist’ is “type-checked” with ’assert-vlist’
and thus that is exploited by Guile compiler, if I understand correctly
the comment.

The first question is: is it still correct?  Because this module had
been implemented before many Guile compiler improvements.


The second question, if the comment above is still valid, is: could we
also “win” for some record inside Guix source code?

Concretely, one example about the record , there is some
procedures such that:

--8<---cut here---start->8---
(define* (package->manifest-entry package #:optional (output "out")
  #:key (parent (delay #f))
  (properties (default-properties package)))
  "Return a manifest entry for the OUTPUT of package PACKAGE."
  ;; For each dependency, keep a promise pointing to its "parent" entry.
  (letrec* ((deps  (map (match-lambda
  ((label package)
   (package->manifest-entry package
#:parent (delay entry)))
  ((label package output)
   (package->manifest-entry package output
#:parent (delay entry
(package-propagated-inputs package)))
(entry (manifest-entry
 (name (package-name package))
 (version (package-version package))
 (output output)
 (item package)
 (dependencies (delete-duplicates deps))
 (search-paths
  (package-transitive-native-search-paths package))
 (parent parent)
 (properties properties
entry))
--8<---cut here---end--->8---

which fits the comment above: a record as argument and record accessor
call.

And that could also be applied to other records, I guess.


Any answers, explanations or references are very welcome. :-)

Cheers,
simon

PS: Raining day and weird pastime… diving into Guile source code. ;-)

Re: Adding plumbing subcommand 'derivation'?

[Simon Tournier]

Hi,

On ven., 19 avril 2024 at 16:02, Ludovic Courtès  wrote:

> We should see how that fits into the set of tools we already have, in
> particular the (guix derivations) interface and the REPL meta-commands.
>
> My gut feeling, with a Schemer bias, is that we’d rather enrich the
> Scheme API and/or REPL than add more commands (this is not Nix :-)).
>
> But I don’t know, maybe we can have both?

Yes, I think that’s orthogonal and a good idea.

Maybe a new plumbing generic subcommand, as “guix inspect” or “guix
store”, where showing the fields of a derivation would be a
sub-subcommand.  For instance, diffing two derivations from the
command-line seems helpful when  debugging – I often do that with Emacs
exploiting buffer facilities. :-)

In addition, it could be helpful to improve the readability for the
pretty-printer.  Other said, somehow redesign this:

--8<---cut here---start->8---
(set-record-type-printer! 
  (lambda (drv port)
(format port "# ~a ~a>"
(derivation-file-name drv)
(string-join
 (map (match-lambda
   ((_ . output)
(derivation-output-path output)))
  (derivation-outputs drv)))
(number->string (object-address drv) 16
--8<---cut here---end--->8---

It looks like a plan. ;-)

Cheers,
simon

Re: bug#63267: gcc-toolchain is missing libstdc++.so

[Simon Tournier]

Hi,

On mer., 17 avril 2024 at 05:21, John Kehayias via Bug reports for GNU Guix 
 wrote:

> I've just pushed, as b47ae1ecc43baaf726701ab2d2f810ecfaa75428,

Cool!  Thank you for crossing the finish line.

Cheers,
simon

Adding plumbing subcommand 'derivation'?

[Simon Tournier]

Hi Leo,

On ven., 12 avril 2024 at 20:04, Leo Famulari  wrote:

>> Do you think it would be useful to package it?  Or maybe to include it
>> as another subcommand (or part of some subcommand)?
>
> I'd love for this to be built in to Guix. I'm often struggling to read
> derivations while debugging or analysing something.

So I propose to add the plumbing command ’derivation’.  Any objection?

Cheers,
simon

Guix extension to display derivation (and rewrite fixed-output)

[Simon Tournier]

Hi,

As an Emacs user, exploring Derivation (the .drv files) is easy since
there is an Emacs mode.  However, I have been annoyed with some pipe
through ’sed’ and friends.

Therefore, I wrote a very simple Guix extension [1] that outputs
derivation content using recutils format.

--8<---cut here---start->8---
$ guix drv-show $(guix build hello -d)
name: /gnu/store/qr00sgbh3vwwqswmgjjymg6wkys9r4i2-hello-2.12.1.drv
outputs:
+ /gnu/store/6fbh8phmp3izay6c0dpggpxhcjn4xlm5-hello-2.12.1   [out]
inputs:
+ /gnu/store/3ds56xg6njpw6hnp2w4xpx4psw5mka5q-glibc-2.35.drv
[out]
+ /gnu/store/3zh2qpi897s2x229s93iakji86b08a20-hello-2.12.1.drv  
[out]
+ /gnu/store/5bqhdbbl71r9r936w6w8zzqlk41md3wx-glibc-2.35.drv
[out]
+ /gnu/store/67nh3fzviy3q4s8ar8cg0dzhyzgwrwdd-module-import-compiled.drv
[out]
+ /gnu/store/7fsz44vifdc0ws0amnpwnmig3ra6hb53-gcc-11.3.0.drv
[lib]
+ /gnu/store/fchdaawcrxb35llbl7fj7lcsq5asmk4b-guile-2.0.14.drv  
[out]
+ /gnu/store/ky030dkfkfr3l8xgdbv45j6bs87988lx-gcc-11.3.0.drv
[lib]
+ /gnu/store/n9kblf5cx4lphrydjr90sp3zfvcdr1pb-glibc-utf8-locales-2.35.drv   
[out]
system: x86_64-linux
builder:
+ /gnu/store/4p1l5bdxxbyyqc3wh0d07jv9rp1pdcy7-guile-2.0.14/bin/guile
+ --no-auto-compile
+ -L /gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import
+ -C /gnu/store/yk897hj2p5mdx6hw47s90n8x9pn6s36c-module-import-compiled
+ /gnu/store/fiy8arwqm8vwaqs4h8b361kbmjmd1yra-hello-2.12.1-builder
environment:
+ allowSubstitutes: 0
+ guix properties: ((type . graft) (graft (count . 2)))
+ out: /gnu/store/6fbh8phmp3izay6c0dpggpxhcjn4xlm5-hello-2.12.1
+ preferLocalBuild: 1
--8<---cut here---end--->8---

Do you think it would be useful to package it?  Or maybe to include it
as another subcommand (or part of some subcommand)?

Let me know. :-)

My motivation to do it now is this story:

https://simon.tournier.info/posts/2024-04-11-rewrite-drv.html


Cheers,
simon

1: https://gitlab.com/zimoun/guix-drv

Re: Concerns/questions around Software Heritage Archive

[Simon Tournier]

Hi,

On lun., 18 mars 2024 at 12:38, Ian Eure  wrote:

> They appear to be violating free software licenses on large scale. 
> They are in violation of SWH’s own positions.

[...]

> [1]: https://arxiv.org/html/2402.19173v1
> [2]: 
> https://huggingface.co/spaces/HuggingFaceH4/starchat2-playground
> [3]: https://huggingface.co/datasets/bigcode/the-stack-v2
> [4]: https://github.com/bigcode-project/opt-out-v2/issues

Please note that Software Heritage folks are not co-author of all that;
or I misread.  Do not take me wrong, this is not an attempt to escape
but a query for waiting the feedback of SWH.

As Ludo said, SWH folks are, by the way, also long time Free Software
activists.  For the record, the quality of 10 Years of Guix [1] videos
is the result of tireless work (for free!) by a Debian video team member
(also working for SWH) and one of SWH co-founder had been Debian project
leader.  Let the benefit of the doubt while waiting.

1: https://10years.guix.gnu.org

Cheers,
simon

PS: Thanks for the detailed explanations.  I will provide my reading
later, after some concerns will be separated, eventually.

Re: Concerns/questions around Software Heritage Archive

[Simon Tournier]

Hi MSavoritias,

On lun., 18 mars 2024 at 16:00, MSavoritias  wrote:

> I think you have misunderstood that here we are talking about

> I think you have misunderstood that here we are talking about

What if? Maybe it’s you.  Maybe you, “you have misunderstood that here
we are talking about […]”.

For what my opinion is worth here, I would prefer that you do not assume
on what I might have understood.  Similarly, I am not assuming anything
about your understanding of the various topics at hand.

That’s my last message in this thread.

Cheers,
simon

Re: Concerns/questions around Software Heritage Archive

[Simon Tournier]

Hi MSavoritias,

On lun., 18 mars 2024 at 13:47, MSavoritias  wrote:

> 1.
>
> You seem to be misunderstanding the statement here that was said.
>
> What you can do legally and what you can do socially are not always the 
> same thing.

I do not read where I wrote something like that but anyway.

A program is free software if the program's users have the four
essential freedoms: [1]

  0. The freedom to run the program as you wish, for any purpose.
  1. The freedom to study how the program works, and change it so it does
 your computing as you wish. Access to the source code is a precondition
 for this. 
  2. The freedom to redistribute copies so you can help others.
  3. The freedom to distribute copies of your modified versions to
 others. By doing this you can give the whole community a chance to
 benefit from your changes. Access to the source code is a precondition
 for this.

All is about the philosophy of “free software”.

1: https://www.gnu.org/philosophy/free-sw.en.html


> As advice for the future when somebody says a concern or wish they have, 
> your first statement shouldn't be "but its legal" because that 
> completely dismisses any constructive discussion that could be done.

Again, I am not arguing about “legal” something.  Instead, I am pointing
that this wish does not match the principles of “free software”.

If you accept that the software you create is “free software” then you
cannot complain if this “free software” is used in some contexts that
you consider unethical.

That’s the double sword of “free software”.

Do I consider LLMs as something unethical?  I think yes: most AI appears
to me unethical but that’s another story (rooting my arguments in
arguments about energy [2,3,4]).

2: https://social.sciences.re/@zimoun/112082437445032973
3: https://social.sciences.re/@zimoun/112039562095800532
4: https://social.sciences.re/@zimoun/112038609631116527


> What is in question here is whether Software Heritage respects people 
> enough to do the right thing and respect their wishes without getting 
> lawyers/legal involved.

Again, this is an incorrect frame, IMHO.  Software Heritage (SWH) do the
things you granted them to do.  SWH respects the “ethical” definition of
“free software”.

Again, do I think that feeding LLM after publishing a statement for LLM
code is a good move?  I do not know…  Does it break my ethical values?
Maybe…  Can I complain about my contributions to “free software” reused
in a way that I might consider unethical?  No.

5: https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/
6: https://www.softwareheritage.org/2023/10/19/swh-statement-on-llm-for-code/


> Besides with the way you are framing Free Software as not respecting any 
> social rules then that makes Free Software not attractive which is the 
> opposite of what we are trying to do here :)

I do not know what are the “social rules” of “free software”.  At best,
I understand the social rules of a community working on free software.

And this community is far to be an homogeneous whole with clear social
rules.  These social rules vary and the only shared denominator is the
“free software” principles defined by four freedoms.

The only question might be: by allowing ingested source code to be used
to train LLM, is Software Heritage aligned with the values that the Guix
community promote?

To be honest, I cannot answer to that question in a hurry.


> 2.
>
>  > Somehow, a Content-Addressed system is designed around immutable 
> > content. And if one know how to implement a Content-Addressed system 
> > relying on mutable content, I would be very interested to know more 
> > about it.
>
> Please refrain from doing such remarks. Nobody here suggested anything 
> that you mention here and you effectively devalue the discussion by 
> arguing like this and frame other people as stupid.

I will not refrain to say: Talk is cheap!

Positions about the situation with “rewrite history” cannot be a
discussion about opinions but it needs to be rooted in how it
technically works and what does it mean Content-addressed system.


> 3.
>
> You may disagree with this sure, but shutting down the discussion 
> because nobody wrote the code for you is very elitist of you.

We are speaking about which discussion because I am lost.  About LLM or
about “rewrite history”?

About LLM, see point #1.

About “rewrite history”, see point #2


> 4.
>
>  > This language is not acceptable on Guix channel of communication.
>
> Calling out transphobia it is very much accepted here actually :)

No it is not.  Because it is a bold conclusion.

I am asking that the Guix project rewrite right now its history:
changing my identity ’zimoun’ to my identity ’Simon Tournier’.  Since
the Guix project will take the time to check, then I will claim: the
Guix project is French-phobic!

I a

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[Simon Tournier]

Hi,

On lun., 18 mars 2024 at 12:10, MSavoritias  wrote:

> The right of a trans person to ask a project to not advertise their 
> deadname was never in question.
>
> Guix is a place that supports trans people and anybody else that wants 
> to change their name.

There is a difference between “advertise” and “part of the history”.

Do not take me wrong.  The right to be forgotten is one topic.  However,
as many people are saying: it is not an easy question.  There is legal
questions, technical questions, social questions, etc.

For what it is worth, Guix is built around the concept of immutability.
This is a core concept and deep in Guix internals.

Therefore, it would be more constructive if you come with a
proof-of-concept allowing “history rewrite” and strong “software
identification” property [1].  Else, the discussion is leading nowhere,
IMHO.

1: https://guix.gnu.org/en/blog/2024/identifying-software/

Cheers,
simon

Please hold your horses

[Simon Tournier]

Hi MSavoritias,

Could you please stop to propagate tangential or opinionated views?
Please hold your horses.

You wrote several times, about Software Heritage:

>  being also transphobic.

[…]

> I would go a step further actually. Software Heritage is effectively 
> breaking CoC of Guix now.

[…]

>  Software Heritage 
> implements a process that respects trans rights Software Heritage should 
> not be welcome in Guix Spaces.

[…]

>  Software 
> Heritage is breaking CoC here.

This language is not acceptable on Guix channel of communication.

It appears to me much better to stay open and let the benefit
of the doubt.  Let avoid bold conclusions and prefer constructive
arguments.

For instance, I refrain to qualify your opinion because it would not be
helpful… So I apply my own advice letting you the benefit of the
doubt.

Cheers,
simon

Re: Concerns/questions around Software Heritage Archive

[Simon Tournier]

Hi,

On sam., 16 mars 2024 at 08:52, Ian Eure  wrote:

> They appear to be using the archive to build LLMs: 
> https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/

About LLM, Software Heritage made a clear statement:

https://www.softwareheritage.org/2023/10/19/swh-statement-on-llm-for-code

Quoting:

We feel that the question is no longer whether LLMs for code
should be built. They are already being built, independently of
what we do, and there is no turning back.  The real question is
how they should be built and whom they should benefit.

Principles:

1. Knowledge derived from the Software Heritage archive must be
given back to humanity, rather than monopolized for private
gain. The resulting machine learning models must be made available
under a suitable open license, together with the documentation and
toolings needed to use them.

2. The initial training data extracted from the Software Heritage
archive must be fully and precisely identified by, for example,
publishing the corresponding SWHID identifiers (note that, in the
context of Software Heritage, public availability of the initial
training data is a given: anyone can obtain it from the
archive). This will enable use cases such as: studying biases
(fairness), verifying if a code of interest was present in the
training data (transparency), and providing appropriate attribution
when generated code bears resemblance to training data (credit),
among others.

3. Mechanisms should be established, where possible, for authors to
exclude their archived code from the training inputs before model
training begins.

I hope it clarifies your concerns to some extent.


Moreover, you wrote: « I want absolutely nothing to do with them. »

Maybe there is a misunderstanding on your side about what “free
software” and GPL means because once “free software”, you cannot prevent
people to use “your” free software for any purposes you dislike.

If you want to bound the use cases of the software you create, you need
to explicitly specify that in the license.  And if you do, your software
will not be considered as “free software”.

That’s the double sword of “free software”. :-)

Cheers,
simon

Content-Addressed system and history?

[Simon Tournier]

Hi,

On sam., 16 mars 2024 at 08:52, Ian Eure  wrote:

> I was also distressed to see how poorly they treated a developer 
> who wished to update their name: 
> https://cohost.org/arborelia/post/4968198-the-software-heritag 
> https://cohost.org/arborelia/post/5052044-the-software-heritag

This asks two questions, IMHO.

1. Can the future you decide who were the past you?

2. What is Content-addressed system?


About #1, that’s somehow a philosophical question. :-)

That’s what the question about changing the public identity asks: you
can act on who you are and who you want to be but because the time is
not reversal, sadly, you cannot change who you were.  It is not possible
to collectively rewrite the history.

Allowing such process leads to dangerous consequences, IMHO.  That’s
another story. :-)

Do not take me wrong.  That’s still an open question and the right to be
forgotten is a topic by itself, e.g., legal.  We will not address it in
the Guix project.



About #2, that’s a technical question.

By definition of a Content-Addressed system, the key associated to the
value is computed by a procedure depending only on the content itself.
Therefore, change the content then change the key.

Git [1] is probably the tool that have popularized that.  Consider a
project using Git and you clone it.  Now, you have a complete copy of
many keys associated to many contents, and also many links between the
keys themselves.  For instance, the key of the object ’Git commit’
depends on its content which depends on the key of the object ’Git
tree’.

Now, if you rewrite any content, then it rewrites the key.  As pointed,
this change might propagate.

All the question becomes the authority.  Because I also have another
copy/clone with the initial set of keys and you have now modified ones,
how do we agree what are the right ones?

Well, at the size [2] of linked posts, the Git history rewriting is
affordable.  Now, I am not convinced that the person would try – or even
think of – such if this project would have hundreds of contributors and
thousands of users.  That’s my opinion and I agree it is not an
argument. :-)

At the level of Guix, allowing a mutable history implies a random
availability of binary substitutes.

To be explicit, rewrite the Git history of Guix implies the break of:

 + local Git repositories of Guix developers
 + regular Guix users and the trust mechanism
 
Somehow, a Content-Addressed system is designed around immutable
content.  And if one know how to implement a Content-Addressed system
relying on mutable content, I would be very interested to know more
about it.


Cheers,
simon


1: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
2: https://github.com/rspeer/python-ftfy/graphs/contributors

Re: Helping with abandoned patches

[Simon Tournier]

Hi Greg,

On mer., 17 janv. 2024 at 12:17, Greg Hogan  wrote:
> What is the preferred process for when a patch review is provided
> (often by a committer) but no response is received from the submitter
> (for many weeks or months)?
>
> Is it appropriate to make the recommended changes and submit an updated patch?

Yes because the aim is to improve the code so the review is not lost.

Moreover, in that case of no response after a delay, if the reviewer
does not have commit access, the best (more helpful) seems sending by
the reviewer or anyone else a new version including the recommended
changes.

Cheers,
simon

Re: Check for ANSI compliance

[Simon Tournier]

Hi,

On lun., 29 janv. 2024 at 17:44, Ludovic Courtès  wrote:

> That used to be the case until commit
> 672d3d4a87839b0692c307df0edb66cd16bcbf1a, which enabled colors even when
> ‘INSIDE_EMACS’ is set.
>
> Pierre, do you remember what the rationale was?

I am not Pierre. :-)  The context seems:

Guix search, colors and INSIDE_EMACS
Pierre Neidhardt 
Tue, 04 Feb 2020 16:23:43 +0100
id:87blqeml4w@ambrevar.xyz
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87blqeml4w@ambrevar.xyz

Quoting [1]:

--8<---cut here---start->8---
>  new d7545a6  ui: Only display link in capable terminals.
>  new 672d3d4  ui: Don't disable colors when INSIDE_EMACS is set.

Forgive me if I missed the discussion, but I thought we had reached
rough consensus in favor of the status quo.  What happened?
--8<---cut here---end--->8---

Then quoting [2]:

--8<---cut here---start->8---
I’ve reverted it in c2f9ea2b502a617bb69227d5f858eee9d4288a6a, also
because if was causing a test failure.
--8<---cut here---end--->8---

where c2f9ea2b502a617bb69227d5f858eee9d4288a6a reads,

--8<---cut here---start->8---
Revert "ui: Only display link in capable terminals."

This reverts commit d7545a6b538813e88195d084f75a3e87065c999e.

The commit led to a test failure in 'tests/guix-package-net.sh'.  It
also led to disagreements discussed here:

  https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00353.html

Reverting until these are addressed.
--8<---cut here---end--->8---

and thus 672d3d4 had not been reverted.  Let revert it since it does not
make sense without d7545a6, IMHO.

Cheers,
simon

1: Re: branch master updated (0aa0e1f -> 9b7f9e6)
Ludovic Courtès 
Mon, 24 Feb 2020 16:31:06 +0100
id:87blpom285@gnu.org
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87blpom285@gnu.org

2: Re: 01/03: ui: Only display link in capable terminals.
Ludovic Courtès 
Fri, 28 Feb 2020 00:16:25 +0100
id:87wo87aaeu@gnu.org
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87wo87aaeu@gnu.org

Re: Request to add a go-team branch and set it on CI.

[Simon Tournier]

Hi,

CC: guix-maintainers
CC: guix-sysadmin

On lun., 22 janv. 2024 at 19:58, Sharlatan Hellseher  
wrote:

> May I ask someone with admin rights to the build farm to set up
>  go-team branch, please?

What is the status of this request?  Is it doable?  I do not see the
specification on .  Do I miss something?

Cheers,
simon

Re: Building container images with nix2container

[Simon Tournier]

Hi Antoine,

Reading this blog post:

https://lewo.abesis.fr/posts/nix-build-container-image/

and from my understanding, “guix pack” is currently something similar to
’dockerTools.buildImage’ [1]

On lun., 26 févr. 2024 at 18:33, Simon Tournier  
wrote:

> Well, I have not followed on which strategy Guix relies.  What is the
> one of nix2container?  The one described here:
>
> https://grahamc.com/blog/nix-and-layered-docker-images/

To answer to my question, the way to build the container image is
different, hence it does not make much sense to speak about a
“strategy“. :-)

However, the blog post says:

To address this issue, we could add a nonReproducible option in
the containerTools.buildLayer function. Instead of only storing
the digest, we would also store the tar. Note in practice, an
important part of nixpkgs is bit reproducible and this would
rarely be needed.

And so the question is how do you know beforehand if the flag
’nonReproducible’ must be applied or not?

Indeed, the approach of nix2container could be helpful in addition to
‘guix pack’.  Maybe an extension… :-)

Cheers,
simon

Re: Introduce Cuirass and remove Hydra on https://www.gnu.org/software/devel.html

[Simon Tournier]

Hi,

Well, I do not see if there is a reply.  If no, sorry!  If yes, I am
just adding my own curiosity. :-)

CC: guix-maintainers and guix-sysadmin
CC: Mark Weaver

On lun., 08 janv. 2024 at 13:19, Jing Luo  wrote:

> I am Jing Luo, a new member from the GNU webmaster team. I noticed that 
> gnu.org has a page on "GNU Development Resources" [1], which has a 
> section about "Hydra: Continuous builds and portability testing". As I 
> know, Guix now uses Cuirass for CI. The text [1] has not been updated 
> since 2012. Would anyone on this list be interested in writing something 
> about Cuirass to replace the Hydra section? Or does anyone have other 
> ideas about this page? You can send an email to webmasters@gnu (plural!) 
> or just reply to me.
>
>
> [1] https://www.gnu.org/software/devel.html

AFAIK, Hydra is now down.  IIRC, Mark was in charge.  Mark?

The webpage [1] starts with:

This page describes many of the development resources available
for GNU developers on GNU Project machines.

Jing Luo, could you provide more details on the purpose of this
webpage?  What is the intent of this webpage?

The Guix project relieson two Continuous Integration systems deployed on
two infrastructures, visible at ci.guix.gnu.org and
bordeaux.guix.gnu.org.  One is indeed Cuirass [2].  The other one is
Build Coordinator [3].

AFAIK, GNU Guile is continuously built on ci.guix but there is no other
GNU projects.  And I do not know if the Guix projects has the capacity
or the resource to host more GNU projects on their infrastructure.

Cheers,
simon








2: https://guix.gnu.org/en/cuirass
3: https://git.savannah.gnu.org/cgit/guix/build-coordinator.git

Re: Building container images with nix2container

[Simon Tournier]

Hi lewo,

On lun., 26 févr. 2024 at 11:09, Antoine Eiche  wrote:

> Does your built images contains several layers?

This had recently been introduced.

0cf75c9b2f23869201144917cea7f6ad49683d3d
AuthorDate: Tue Dec 26 03:54:12 2023 +0300
CommitDate: Mon Jan 8 21:04:44 2024 +0300

> nix2container uses an heuristic to group store paths into layers. The
> goal is to share common layers between images and to avoid full image
> rebuild when only a storepath differs.

Well, I have not followed on which strategy Guix relies.  What is the
one of nix2container?  The one described here:

https://grahamc.com/blog/nix-and-layered-docker-images/

> Do you write the image tarball into your store when you build an image?
>
> nix2container is able to build layers on the fly from the Nix store. The
> goal is to reduce IOs and storage. Instead of writing an image tarball
> into the store, it generates a script which stream layers from store
> paths to the destination (a Docker registry, the Docker deamon, Podman
> or a file).

To my knowledge, this is not implemented in Guix.  And indeed, it could
improve the dance.  Currently, it reads:

docker load < $(guix pack -f docker …)


Cheers,
simon

Re: Mechanism for helping in multi-channels configuration

[Simon Tournier]

Hi Attila,

On mar., 06 févr. 2024 at 17:16, Attila Lendvai  wrote:
>> The wishlist is: provide a machine-readable description on guix-science
>> channel side in order to help in finding the good overlap between
>> commits of different channels.
>
> i wrote about a missing abstraction here:
>
> https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00104.html

You wrote in [1]:

it's probably the same thing that causes the discrepancy between
git commits and substitutes: the build servers are not building
every commit of the git repo. they pick an unpredictable (?)
series of commits, skipping some in between.  if i guix pull, or
guix time-machine to the "wrong" commit, then i'll need to build
some stuff locally. sometimes these can be heavy packages.

To my knowledge:

 + ci.guix (Cuirass) fetches every 5 minutes (IIRC) and builds the last
   commit.

 + bordeaux.guix (Build Coordinator) fetches the batch from the mailing
   list guix-commits:
   

About CI, yes it is unpredictable.  About Bordeaux, it is not really. :-)

1: Re: Should commits rather be buildable or small
Attila Lendvai 
Sun, 10 Dec 2023 23:20:25 +
id:SXjFmdTgxwHYE-Z6t7SZOykuXMBiD454EF2uad96jGQemgJ6hXki_f1C7VxVHKHa4b7_j5UwJmffh_FiQqEz_bIYIBn9tpG4s9F7W1eIDAQ=@lendvai.name
https://lists.gnu.org/archive/html/guix-devel/2023-12
https://yhetil.org/guix/SXjFmdTgxwHYE-Z6t7SZOykuXMBiD454EF2uad96jGQemgJ6hXki_f1C7VxVHKHa4b7_j5UwJmffh_FiQqEz_bIYIBn9tpG4s9F7W1eIDAQ=@lendvai.name

> the git commit log is a too fine-grained granularity here. there
> should be something like a 'guix log' above the git log that could be
> used, among other things, to encode inter-channel dependencies.

Considering the current status and how substitutes are GC, the first
step would be the retention of some substitutes.  And thus the
specification for a policy of such retention.  It would allow to build a
database that could be queried by this hypothetical “guix log” – which
should be more something under “guix weather” IMHO.

For the interested readers, thread about retention:

Building and caching old Guix derivations for a faster time machine
Ricardo Wurmus 
Fri, 10 Nov 2023 10:29:28 +0100
id:87o7g29c94@elephly.net
https://lists.gnu.org/archive/html/guix-devel/2023-11
https://yhetil.org/guix/87o7g29c94@elephly.net

Substitute retention
Ludovic Courtès 
Tue, 12 Oct 2021 18:04:25 +0200
id:87y26ytek6.fsf...@inria.fr
https://lists.gnu.org/archive/html/guix-devel/2021-10
https://yhetil.org/guix/87y26ytek6.fsf...@inria.fr

Although I concur with this need, I do not see how it would be help for
detecting compatibility between channels. :-)

Cheers,
simon

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi Clément,

If read correctly, you answered about Gnus (debbugs.el):

>>> --8<---cut here---start->8---
>>> (with-current-buffer gnus-original-article-buffer
>>>   (message-fetch-field "Message-ID"))
>>> --8<---cut here---end--->8---

[...]

>>> May I add too, that you can add "Message-ID" in gnus-visible-headers.

[...]

> You add '%M' in gnus-summary-line-format.

[...]

> Yes it does provide a built-in access, as I showed you.  Just search for
> "Message-id" in `C-h v gnus-summary-line-format`.

And my message was:

  What appears to me “difficult” is that most of the
 tools as Email client are poorly supporting Message-ID.

Somehow, the reader will judge if Message-ID is smoothly supported. :-)

Cheers,
simon

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi Felix,

On jeu., 15 févr. 2024 at 07:32, Felix Lechner via "Development of GNU Guix and 
the GNU System distribution."  wrote:

> To request a feature in Debbugs.el, please file a bug against the
> "debbugs.gnu.org" package on debbugs.gnu.org.

To be clear, my message [1] was not to report a “bug” or request for a
“feature” in debbugs.el.  My message was:

  What appears to me “difficult” is that most of the
tools as Email client are poorly supporting Message-ID.

For instance,

And I took as one example the venerable debbugs.el for making my point:
most of the tools that deal with Emails poorly support one key of Email
heart: Message-ID.

Personally, I rely on the cool piem.el and some custom Emacs lisp
helpers, then for dealing with complex patch or bug thread, I inject and
process them with notmuch.el. :-)

Therefore, open a feature request is low on my list of TODO. ;-)

Cheers,
simon

1: Re: Guix Days: Patch flow discussion
Simon Tournier 
Wed, 14 Feb 2024 16:48:07 +0100
id:87mss3kpxk@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2024-02
https://yhetil.org/guix/87mss3kpxk@gmail.com

Re: Golang check phase skipping some tests?

[Simon Tournier]

Hi,

On jeu., 15 févr. 2024 at 10:10, Sharlatan Hellseher  
wrote:

> I would push go-team branch to check some lower level modifications to
> go-build-system which are queued right now. I need someone with admin access 
> to
> set the branch on CI as well ;-)

Cool!  Thank you.

Cheers,
simon

Re: Mechanism for helping in multi-channels configuration

[Simon Tournier]

Hi Christina,

On sam., 03 févr. 2024 at 15:27, Christina O'Donnell  wrote:

>   1. Have a script that scrapes all the define-public symbols in every 
> file in
>      every package.

I think you mean ’fold-packages’.

>   2. Have a script that determines the symbols needed by each file. (Macros
>      make this more difficult, but.)

Well, this would be difficult, IMHO.  Somehow, it is what the compiler
does. :-)

>   3. Have both scripts have an incremental version that runs on diffs (for
>      performance).
>   4. Run this for every commit on every branch on every channel caching the
>      result.
>   5. Have a CI script keep this updated for new commits.
>   6. Have a server track incompatibilities.

Here, I think the issue is that one server needs to track all the
channels.  And that’s a too strong assumption, IMHO.

I think the design should be something on channel maintainer side.
Somehow, the main Guix channel could be seen as a Git submodule from the
channel side and the issue is that information is not tracked.

There is this ’.guix-channel’ file which allows to describe channel
dependencies.  And the improvements could be to add more there.  The
question is what to add and how to add it.  Keeping in mind the
simplicity and the maintenance burden-free. :-)


> Full disclosure: I've got nothing lined up for the summer yet, so I'm on the
> prowl for GSoC projects :)

Cool!

In that spirit, one tool that is missing is: search packages in all the
history. Somehow the need is described by this message [1]: how to find
which Guix revision provides which version of Foo?

In addition, “guix search” is slow [2].

Well, I have started the embryo of an extension based on Guile-Xapian
for indexing and improving the search.  Really an embryo. :-)

I think this would fit some GSoC. ;-)


Cheers,
simon

1: Re: List available versions of package.
Philippe Veber 
Tue, 11 Jun 2019 09:43:08 +0200
id:CAOOOohSzUezKvm=ro0bxrgh3m0eo2x0cotvd--varxwoqtc...@mail.gmail.com
https://lists.gnu.org/archive/html/help-guix/2019-06
https://yhetil.org/guix/CAOOOohSzUezKvm=ro0bxrgh3m0eo2x0cotvd--varxwoqtc...@mail.gmail.com

2: https://issues.guix.gnu.org/issue/39258

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi Josselin,

On jeu., 15 févr. 2024 at 12:07, Josselin Poiret  wrote:

> I think b4's ML is more active than the GitHub issues, I have already
> sent some bug reports and patches there that were picked up quite fast.

Yeah, Kyle pointed me that out months ago.  Then I have never taken the
time to report there. :-)

Cheers,
simon

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi Clément,

On jeu., 15 févr. 2024 at 12:45, Clément Lassieur  wrote:

>>> 'b4 shazam' is probably the most trouble-free way to apply patches;
>>
>> I agree*!
>
> I don't agree (both Gwene + Gnus or Emacs Debbugs work perfectly too and
> allow to apply a range of n patches at once) but I don't think there is
> a need for competition here, it's good that we have several tools.

Yes for sure it is good to have several tools.  And the ones you like. :-)

No one is advocating to make ’b4 shazam’ THE only one tool.

Instead, I agree with Maxim that exposing Message-ID and relying on ’b4
shazam’ is the most trouble-free and config-less way to apply patches.


>>  What appears to me “difficult” is that most of the
>> tools as Email client are poorly supporting Message-ID.
>>
>> For instance, debbugs.el (Gnus).  To my knowledge, there is not easy way
>> to get the Message-ID when reading an article (bug/patch) from Debbugs.
>> There is other means for applying patches.  But still each time appears
>> to me weird. :-)
>
> It's
>
> --8<---cut here---start->8---
> (with-current-buffer gnus-original-article-buffer
>   (message-fetch-field "Message-ID"))
> --8<---cut here---end--->8---

[...]

> May I add too, that you can add "Message-ID" in gnus-visible-headers.

And what about Summary buffer?

Well, it makes my point, no? :-)

For sure the Message-ID is there and for sure it is possible to extract
it.  However, it appears to me weird that it is not built-in.  I mean
Message-ID is one of the heart of Emails, and Debbugs is just Emails,
but debbugs.el does not provide a built-in access to it.


Cheers,
simon

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi,

On dim., 11 févr. 2024 at 11:38, Maxim Cournoyer  
wrote:

> 'b4 shazam' is probably the most trouble-free way to apply patches;

I agree*!

> it
> even selects the latest revision it finds in the issue thread.  To make
> finding a message-id easier, I've also recently added a 'Copy
> Message-ID' button to the Mumi interface; try it visiting any issue,
> e.g. .  The message-id of any message
> can be easily copied to your clipboard via the new button.

I also agree! :-) What appears to me “difficult” is that most of the
tools as Email client are poorly supporting Message-ID.

For instance, debbugs.el (Gnus).  To my knowledge, there is not easy way
to get the Message-ID when reading an article (bug/patch) from Debbugs.
There is other means for applying patches.  But still each time appears
to me weird. :-)

So thanks for this Mumi addition!

Cheers,
simon

PS: *agree on B4 although there is tricky bugs as reported here:
.

Re: Guix Days: Patch flow discussion

[Simon Tournier]

Hi Steve,

  ( On a side note, the triage of old bugs is a similar problem.  They
are easy to find [2], read, check and send an email to
12...@debbugs.gnu.org does not appear to me an issue with any tool.

For what it is worth and without any willing of being harsh, I am
able to count the people doing this boring task.

What is hard to solve is the incentives for doing the boring, but
necessary, collective tasks.

Bah the usual problem of lengthy discussions with roommates in any
shared apartment: who clean the bathroom? :-) )


On lun., 05 févr. 2024 at 09:39, Steve George  wrote:

> Our goal for the discussion:
>
>   How do we double the number of patches that are *reviewed* and
>   *applied* to Guix in the next six months?

Thanks for these notes and leading the session.  On my side, it was a
fruitful discussion.

Well, let me try to quickly summarize my conclusion of the session:

 1. We have a social/organisational problem.

 2. We have some tooling annoyances.



The easy first: #2 about tools.  The email workflow is often cited as
part of the issue.  That’s a false-problem, IMHO.

Projects that use PR/MR workflow have the same problem.  For instance,
Julia [1] has 896 open PR.  On my browser, it means 36 pages so if I go
to – 25 PRs per page – the still open submitted PRs:

   + the 6th page:  around Sept.2023 and Oct. 2023
   + the 12th page: around Apr. 2023 and Mar. 2023
   + the 18th page: around Jul. 2022 and Mar. 2022
   + the 24th page: around Jun. 2021 and May  2021
   + the 30th page: around Mar. 2020 and Oct. 2019
   + the 36th page: around Mar. 2017 and May. 2014

Obviously, an example is not a proof or an evidence.  It is just a
first clue. :-)

I will not speak about the channel ’nonguix’ but it gives another
clue.

That said, for sure, the tools need more love.  Thanks all the people
for all hard work over the years in this area – no name, you know, I
fear to forget someone. ;-)

So, yeah we need to smooth the technical burden for reviewing in order
to focus on the review itself.

To be clear, the email workflow might add burden on submitter side but I
am doubtful it is really part of the bottleneck for reviewing and
pushing submissions.


Although the tools might add some unnecessary friction, the net of the
issue is IMHO #1: reviewing is just boring and time-consuming.

Who feel accountable?  And for what?  That’s the question, IMHO.

If the number of submission is doubled, how do we increase the number of
people that feel enough accountable for doing the boring work?

  ( Maybe accountable is not the correct word.  Obligation neither.
Well the kind of feeling that is okish if you skip the task but you
know it will be better if you do it. )


Well, the difficult part is not pressing some buttons for merging and
pushing – whatever the tools or workflow.  The difficult part is to
scrutinize the submission.

I think the bottleneck is not the number of people able to push.
Instead, I think the bottleneck is the number of people confident with
the change for then pushing it.

The question is thus: how to build this confidence?


Look, when a committer has some free-time, most of the time, what is the
process: take first the “easy“ submissions for committing them – from
trivial updates to simple updates.  If free-time remains, then engage
with more “complex” submissions… ah no more free-time. :-)

Why starting by the “easy” submission?  Because it is less boring and
time-consuming; somehow it is easier to feel confident with that sort of
change for pushing it.

As a rule of thumb, about the time it takes – on average –, the order of
magnitude for reviewing is similar as the one for submitting.  Well,
from my experience and although I never did stats. :-)


All in all, I see two paths to move forward:

i) Non-committers can help.  On two fronts:

   + Answer to submitter with the changes for being compliant with Guix
 standards.
   
   + Follow-up on patches already commented but without an updated
 revision: upgrade the re-roll count by sending this revision.

 It eases for merging if I do not have to make many tiny edits
 myself.

ii) Create more teams or at least more people should commit to be part
of a team and help in reviewing what they know.

For instance, since Sept. (167 days ago) I have been CC in 108
patches submissions.  Most of them are from ’core’ team that I would
qualify as “complex”. :-)

Many patches assigned to ’core’ team are sent by committers.  The
issue is not being a committer or not.  Instead, being more eyes
commenting would increase the confidence.  Thus it would reduce the
workload.

That’s the same for any team, IMHO.

And I do not speak about patches that are not assigned to any team.


Somehow, we need to think how people would feel “accountable” for doing
the collective tasks with low, no direct or personal reward.

As with many non-technical 

Re: Git-LFS or Git Annex?

[Simon Tournier]

Hi Timothy,

On sam., 27 janv. 2024 at 10:59, Timothy Sample  wrote:

> https://git.ngyro.com/git-annex-remote-clouda/tree/git-annex-remote-clouda/remote.scm

Oh cool, thanks.  Bookmarked.

Cheers,
simon

Re: Golang check phase skipping some tests?

[Simon Tournier]

Hi,

Late to the party. :-)  Processing my backlog…

On jeu., 18 janv. 2024 at 10:25, Sharlatan Hellseher  
wrote:

> I'm currently in review and split some packages from (gnu packages golang) 
> into
> (gnu packages golang-crypto) to simplify the maintenance. I try to play with
> that option and see which packages are missed to satisfy passing all tests.

What is the status of this?  Is all fine?

Cheers,
simon

Re: Committers available for Patch hacking/review meet-up?

[Simon Tournier]

Hi,

On mar., 13 févr. 2024 at 14:48, Steve George  wrote:

> At Guix Days we said we'd organise some patch review sessions.

Cool!


> Anyone available? If you are and can put your name down for a particular 
> date that would be brilliant!

I will do.  Thanks for the initiative!


> Q2: Does anyone have permission on 
> https://libreplanet.org/wiki/Group:Guix to give a user the right to 
> create new pages? I want to document the sessions and how-to's.

Hum, I do not know who did it and how… there is this webpage:

https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024


> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20240213=5416=136=179

Is Annecy time the same as Paris time? ;-)


Cheers,
simon

Google Season of Docs 2024

[Simon Tournier]

Hi,

( It is when my plate is full that I add more in. :-) )

Google is announcing the Season of Docs.  Somehow, it is similar of
Google Summer of Code but for… wait for it… documentation!

https://opensource.googleblog.com/2024/02/announcing-google-season-of-docs-2024.html

I would like that the Guix project applies as an Organization.  Hence my
message.  Before jumping in the boring paperwork, the first questions
are:

 1. Who does volunteer for being potential mentor?
 2. Would one of you readers be interested by being technical writer?
 3. Any for improving the documentation?

Well, shoot any ideas for #3.  It will help in all cases. :-)

It can range from a one line idea to more elaborated idea; as shown here
[1, 2, 3].

Depending on the feedback, I will create a LibrePlanet webpage or else
and go further in the process. :-)

Last, keep in mind the deadline is less than 10 days from now.

1: https://developers.google.com/season-of-docs/docs/project-ideas
2: https://developers.google.com/season-of-docs/docs/case-study-example
3: https://developers.google.com/season-of-docs/docs/2022/participants

Cheers,
simon

Re: bug#63775: git describe on current master says: v1.3.0-38775-g6192acf8b7

[Simon Tournier]

Hi,

On sam., 03 févr. 2024 at 19:43, Giovanni Biscuolo  wrote:

> This is a git bug, not an issue with our repo, and for this reason (I
> hope) I'm closing this bug; please see below.

Here the explanation of the bug of “git describe”:

https://lore.kernel.org/git/20191008123156.gg11...@szeder.dev/

  $ git describe d1a251a1fa
  v2.23.0-135-gd1a251a1fa
  $ git log --oneline v2.23.0..d1a251a1fa | wc -l
  59

Uh-oh, 59 != 135.

This is happening because:

  - Git is too fast ;) and the committer date has a one second
granularity, so scripts can easily create subsequent commits with
the same committer date.  Case in point are the two subsequent
merge commits f3c19f85c5 and 4a3ed2bec6 at the bottom of this
simplified history snippet (kind of a hand-edited 'git log --graph
--format="%h %cd %s"'):

*   d1a251a1fa 2019-09-09 12:26:36 -0700 Merge branch 
'en/checkout-mismerge-fix'
|\
* | ... a big chunk of history simplified away ...
| * acb7da05ac 2019-08-16 09:58:00 -0700 checkout: remove duplicate code
* | a5e4be2f68 2019-04-25 16:41:15 +0900 Merge branch 
'ab/commit-graph-fixes'
* | f3c19f85c5 2019-04-25 16:41:14 +0900 Merge branch 'ab/gc-reflog'
|/
*   4a3ed2bec6 2019-04-25 16:41:14 +0900 Merge branch 'nd/checkout-m'

  - 'git describe' implements its own history traversal: it iterates
over all parents of a commit, adds any yet unseen parents to a
commit list ordered by date, and then continues with the first,
i.e. most recent commit from that list.  While doing so it uses
several bits in 'commit->object.flags' to track reachability
information from several candidate tags at once, and copies these
flags from each commit to its parents; this is important to
compute the correct number of additional commits.  Another
important thing is the implementation detail that
commit_list_insert_by_date() inserts a new commit after all other
commits with the same date that are already in the list.


Thanks Giovanni for pointing this out.

Cheers,
simon

Re: ice-9 match penalty depending on pattern?

[Simon Tournier]

Hi,

On mer., 07 févr. 2024 at 10:41, Carlo Zancanaro  wrote:

>> Why not?  Do I miss something in the implementation of ’match’?
>
> The only reason I can think of would be if these matches are sometimes
> provided improper lists, which need to fail these match conditions. That
> seems unlikely to me, but it should be clear from looking at the other
> match clauses in each case.

Well, I have not pruned the list returned by just grepping. :-)  And I
have just grepped with the term ’head’, ’tail’ and ’\.\.\.’

Somehow, my question is twofold:

1. Is the “expensive” check worth for such case:

  (match paths
((head tail ...)
 (if (visited? head)
 (loop tail visited result)
 (call-with-values
 (lambda ()
   (loop (references store head)
 (visit head)
 result))
   (lambda (visited result)
 (loop tail
   visited
   (cons head result))
(()
 (values visited result)

seen in ’topologically-sorted’ procedure from (guix store) module.

2. Is the “expensive” check worth for such multi-cases:

  (match sexp
((? string? str)
 (let ((prefix "swh:1:dir:"))
   (if (string-prefix? prefix str)
   (cons (string-drop str (string-length prefix)) ids)
   ids)))
((head tail ...)
 (loop tail (loop head ids)))
(_ ids))

seen in ’lookup-disarchive-spec’ from (guix lint).

Well, I am not saying to rely on ’car’ and ’cdr’.  Instead, I am asking
what is the idiomatic Guile pattern matching for Guile?

My main concern is about chasing the unnecessary checks for making Guix
a bit faster. :-)


Cheers,
simon

ice-9 match penalty depending on pattern?

[Simon Tournier]

Hi,

>From Ludo’s mastodon message [1]:

Re ‘match’ penalty: when using ellipses in patterns, the generated
code checks for “proper lists”, which is O(n).  The trick is to
instead match a pair:

✔ (match lst ((head . tail) …))
❎ (match lst ((head tail ...) …))

Therefore I have confused by some patterns.

--8<---cut here---start->8---
28 candidates:
./gnu/services/monitoring.scm:249:((head tail ...)
./gnu/system/file-systems.scm:249:  ((head1 tail1 ...)
./gnu/system/file-systems.scm:251: ((head2 tail2 ...)
./gnu/packages.scm:116:  ((_ file head tail ...)
./gnu/build/activation.scm:85:  ((head tail ...)
./gnu/build/linux-boot.scm:225:  ((head tail ...)
./guix/http-client.scm:255:  ((head tail ...)
./guix/records.scm:604:  ((_ record field offset ((head normal) tail ...))
./guix/records.scm:607:  ((_ record field offset ((head delayed) tail ...))
./guix/records.scm:610:  ((_ record field offset ((head thunked) tail ...))
./guix/read-print.scm:482:  ((head tail ...)
./guix/read-print.scm:750:  ((head tail ...)
./guix/lint.scm:1614:((head tail ...)
./guix/scripts/package.scm:809: ((head tail ...) head
./guix/self.scm:160:  ((head tail ...)
./guix/store.scm:1556:((head tail ...)
./guix/store.scm:1764:  ((head tail ...)
./guix/ui.scm:295:  ((head tail ...)
./guix/ui.scm:2258:   ((head tail ...) head)))
./guix/docker.scm:261:  (((head ...) (tail ...) id)
./guix/build/store-copy.scm:72:((head tail ...)
./guix/build/gremlin.scm:336:  ((head tail ...)
./guix/build/graft.scm:330:  ((head tail ...)
./guix/build/utils.scm:236:  ((head tail ...)
./guix/build/utils.scm:405:  ((head tail ...)
./guix/utils.scm:910:  ((head1 tail1 ...)
./guix/utils.scm:913: ((head2 tail2 ...)
./build-aux/compile-all.scm:71:   ((head tail ...)
--8<---cut here---end--->8---

Maybe for some of them, it changes nothing for the user-visible
performances.  Maybe it does. :-)

Well, I do not know the length of each match.  However, some are part of
some loop.  Therefore, if we could save some cycles by simply replacing
the ellipsis, as

((head tail ...) stuff that use head or tail)

by

((head . tail) stuff that use head or tail)

Why not?  Do I miss something in the implementation of ’match’?

Cheers,
simon

1:
https://social.sciences.re/@civo...@toot.aquilenet.fr/111885442823194970

Re: [fr] Moment de convivialité Guix@Paris en février

[Simon Tournier]

salut,

On jeu., 01 févr. 2024 at 20:51, Tanguy LE CARROUR  wrote:

> Ce jeudi 8 février 2024 à 19h, se tiendra la cinquième édition de Guix@Paris
> ouverte au public.
> Comme les fois précédentes, il sera possible de participer à distance
> (*cf* ci-dessous).

Chouette !  Ayant raté la journée de jeudi des Guix Days, je suis très
intéressé par un petit résumé. :-D  Peut-être pas le seul
d’ailleurs. ;-)

à très tantôt,
simon

[post Guix Days] Guix Common Document (was: Request-For-Comment process)

[Simon Tournier]

Hi all,

I hope that the discussion we had yesterday (Friday 2nd) in Guix Days
has clarified the idea behind this proposal.

I am waiting Ludo’s notes in order to refine this proposal, integrate
many comments and/or ideas, and polish.

Thanks all participants.


The aim of the proposal is to have a process to document our processes
with the least bureaucracy as possible.  Well, Debian project is often
cited as an example (social contract, voting system, etc.).  Indeed,
however there is more bureaucracy in Debian than in French State. ;-)

Instead, let just formalize what we are already doing.

Currently, we are just adding more and more sections to the manual and
for other parts the structure for making decisions is not clear.  For
sure, it works… until now but I think it does not scale and we are
touching the limits about what can be done with this informal structure.

Let me clarify my attempt behind this “RFC proposal”.  First,
pukkamustard proposed the name “Guix Common Document” echoing “greatest
common divisor“ (gcd): the greatest common divisor of two or more
integers is the largest positive integer that divides each of the
integers – other said, that’s the larger integer in common with all.

I like it because it captures well the idea; although such different
name could be confusing from the outside.   Anyway.  That’s an
implementation detail. ;-)

Second, from my point of view, the core components of the proposal are:

 + consensus;
 + co-supporter.

Consensus, because it is how we already collaborate.  Somehow, it
changes almost nothing for our daily operations but having an explicit
formalization will help outsiders.  The definition of “consensus” is
twofold:

 1. can live with;
 2. concerns are actively resolved.

Other said, the definition wording of “consensus” specifies how to avoid
being blocked by disagreements: when one wish to block a proposal then
one bears a special responsibility for finding alternatives, proposing
ideas/code or explaining the rationale for the status quo.

And to make it clear, the first idea for making decision is “voting” but
then we need to define “who” votes.  Well, this appears to me a
counter-measure against something that would be rare and this solution
does not trust in the values of our community (being welcoming,
inclusive, taking care of each other, etc. well as least, trying as much
as possible :-)).

For me, the counter-measure against an hostile takeover is somehow
captured the point #2 above.


Co-supporter, because similarly as the manual section « (guix) Reviewing
the Work of Others » [1], the aim is to cross the final line, make
progress by incremental focused improvements.  Therefore, a proposal
needs the help of someone committed to the project (long-standing
contributor, committer, etc.).

I agree that “contributor sufficiently familiar” is maybe too vague and
needs more specific examples as “contributor sufficiently familiar
(committers or people with X commits)”.  Well, that’s part refining the
proposal. :-)


Last, I think that the time-frame for discussing needs to be bounded.
Somehow this bound will help in the incremental improvement and will
avoid the trap of the perfect-as-the-first-try.


Well, let recover from these awesome Guix Days and from FOSDEM and then
resume this proposal.

Cheers,
simon

1: https://guix.gnu.org/manual/devel/en/guix.html#Reviewing-the-Work-of-Others

Mechanism for helping in multi-channels configuration

[Simon Tournier]

Hi,

Well, using Guix bdab356 from a little bit more than one month old, then
associating the channel guix-science 0b3d4a2f last week, I get the
failure:

--8<---cut here---start->8---
$ guix build /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv
The following derivation will be built:
  /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv
building /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv...
(repl-version 0 1 1)
WARNING: (guix-science build bazel-build-system): imported module (guix build 
utils) overrides core binding `delete'
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value 
(python-nr-stream)) (value #f))
builder for `/gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv' 
failed to produce output path 
`/gnu/store/qzgj4vig3vklbznz1i0pgy11nr3z4rv9-guix-science'
build of /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv failed
View build log at 
'/var/log/guix/drvs/g3/aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv.gz'.
guix build: error: build of 
`/gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv' failed
--8<---cut here---end--->8---

Well, that’s expected!  Guix bdab356 does not contain python-nr-stream
introduced by commit 7dfe41aa71a4a4a9d6065a44e9c6271717215b3e.

The wishlist is: provide a machine-readable description on guix-science
channel side in order to help in finding the good overlap between
commits of different channels.

It could be nice if instead of an hard error, “guix pull” could say:
« the channel ’guix’ needs to be at least at commit 1234abc ».

WDYT?

Cheers,
simon

Re: Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi Ricardo,

On mer., 20 déc. 2023 at 12:49, Ricardo Wurmus  wrote:

> I just got back from travels and finally caught up with important email.
> I read the proposal and it looks good to me.  Thank you for working on
> this!
>
> This would be the first project I contribute to that has an RFC process,
> so I don’t know what to look out for.  My concerns may thus be
> completely out of touch with reality, so beware as you read on.

Thank you for the feedback.  Much appreciated! :-)

I will address your question in another broad message.

Cheers,
simon

Re: Git-LFS or Git Annex?

[Simon Tournier]

Hi Kyle,

On jeu., 25 janv. 2024 at 21:20, Kyle Meyer  wrote:

> Fwiw I think someone could do that outside Haskell, if they preferred,
> via a custom backend:
>
>   https://git-annex.branchable.com/design/external_backend_protocol/
>
> Special remotes can also be written in other languages:
>
>   https://git-annex.branchable.com/design/external_special_remote_protocol/

Thanks!  I did not know.  Indeed, it could be a nice GSoC to implement
some ‘git-annex-backend-nar’. :-)

Cheers,
simon

Re: Git-LFS or Git Annex?

[Simon Tournier]

Hi Ludo, all,

On mer., 24 janv. 2024 at 16:22, Ludovic Courtès  wrote:

> The question boils down to: Git-LFS or Git Annex?

Some months ago, I gave a look for managing some datasets.  My
conclusion is Git-Annex.  The main drawback of Git-LFS is that the
server needs to support the protocol.  On Git-Annex side, the main
drawback is Haskell.

Haskell could seem a detail but it is not when considering other
architectures than x86_64.  Give a look to CI filtering with ’ghc-’:

http://ci.guix.gnu.org/eval/1074397/dashboard?system=i686-linux

Here I pick i686 as an example for making the point of the Haskell
support of non-x86_64.  Aside, I do not speak about the resources that
Haskell requires for being compiled.

Do not take me wrong: it does not mean that’s a roadblock but let keep
that in mind: Git-Annex comes with limitations because of Haskell.

That’s said, Git-Annex seems adapted for the workflow you describe:
backup large files between various servers.  And it would be a bridge
between content and address.  However, the content still needs to be
stored on some servers, IMHO.  Git-Annex supports “special remotes” [1]
but it is not clear for me if the aim is to distribute the workload
between the two main servers or if the aim is just to ease the
maintenance of backups.

Last, you speak about content-addressed and this part is not clear for
me.  In Git-Annex, you have in one hand the Git content-addressed system
and in the other hand the “key-value backends“ [2].  Somehow, Git-Annex
stores the key in a file that is stored in Git itself and the value is
somehow stored outside Git itself.

Recently, support of Git-LFS had been added to git-download with
a4db19d8e07eeb26931edfde0f0e6bca4e0448d3.  In that context, with
content-addressed in mind, are you speaking to add Git-Annex support and
thus distribute the videos as substitutes; probably also easing the
maintenance of backups.  Or is the question unrelated?

On a side note, depending on the size of the videos, it is only possible
to use non-cryptograpgically backends as URL.

All that said, let fix the ideas: a simple example, sync content between
machine-A and machine-B where original content is also kept elsewhere.

Let create a Git repository with a file annexed.

--8<---cut here---start->8---
machine-A$ mkdir example && cd example
machine-A$ git init && git annex init

machine-A$ $ git annex addurl -b MD5 --file sources.json \
 https://guix.gnu.org/sources.json
addurl https://guix.gnu.org/sources.json 
(to sources.json) ok
(recording state in git...)

machine-A$ file sources.json
sources.json: symbolic link to 
.git/annex/objects/jx/1j/MD5-s2697572--a2b17d21f5a209b1763ad537a97d9c5a/MD5-s2697572--a2b17d21f5a209b1763ad537a97d9c5a

machine-A$ git annex add .
machine-A$ git commit -am 'Add sources.json'
[master (root-commit) bdf6bca] Add sources.json
 1 file changed, 1 insertion(+)
 create mode 12 sources.json
--8<---cut here---end--->8---

Let’s backup.

--8<---cut here---start->8---
machine-B$ $ git clone file:///tmp/example backup && cd backup/

machine-B$ file sources.json 
sources.json: broken symbolic link to 
.git/annex/objects/jx/1j/MD5-s2697572--a2b17d21f5a209b1763ad537a97d9c5a/MD5-s2697572--a2b17d21f5a209b1763ad537a97d9c5a
--8<---cut here---end--->8---

As you see, here nothing is really copied.  It is only a symbolic link
pointing to some content outside what Git trackes.

--8<---cut here---start->8---
machine-B$ guix hash -rx .
0x8kiaprmjq6f02pdq155wlznxhzi871mk0la6sp944q854pcpn5

machine-B$ git annex get sources.json
get sources.json (from origin...) 
ok
(recording state in git...)

machine-B$ guix hash -rx .
0x8kiaprmjq6f02pdq155wlznxhzi871mk0la6sp944q854pcpn5

machine-B$ file sources.json
sources.json: symbolic link to 
.git/annex/objects/jx/1j/MD5-s2697572--a2b17d21f5a209b1763ad537a97d9c5a/MD5-s2697572--a2b17d21f5a209b1763ad537a97d9c5a
--8<---cut here---end--->8---

Let’s remove the file on machine-B; for whatever reason.

--8<---cut here---start->8---
machine-B$ git annex drop sources.json
drop sources.json ok
(recording state in git...)

machine-B$ file sources.json
sources.json: broken symbolic link to 
.git/annex/objects/jx/1j/MD5-s2697572--a2b17d21f5a209b1763ad537a97d9c5a/MD5-s2697572--a2b17d21f5a209b1763ad537a97d9c5a
--8<---cut here---end--->8---

And assume that machine-A is now unreachable.   Let’s get again on
machine-B.

--8<---cut here---start->8---
machine-B$ git annex get sources.json
get sources.json (from web...) 
ok
(recording state in git...)

machine-B$ file sources.json
sources.json: symbolic link to 

Re: Collecting Guix talks at FOSDEM

[Simon Tournier]

Hi Steve,

On mer., 17 janv. 2024 at 21:16, Steve George  wrote:

> Hi - initial draft of the post went to Ludo today for review (and commit 
> as I don't have the rights). We'll see what his reaction is to my 
> British English and random punctuation! ;-)

Cool!  Thank you.

For the next time, in order to avoid to put too much on Ludo’s plate, we
have a dedicated email guix-b...@gnu.org.  The emails there are private
and 2-3 people are behind the list.

For example, the recent post [1] had been sent there then a round of
“review“ (mainly typo and links), and published. :-)

1: https://guix.gnu.org/en/blog/2024/building-packages-targeting-psabis/

Cheers,
simon

Re: Collecting Guix talks at FOSDEM

[Simon Tournier]

Hi,

On Tue, 16 Jan 2024 at 15:35, Steve George  wrote:

> We're planning to put up a blog post about Guix (and Guix-related) talks 
> at FOSDEM [0]. I've collected all the talks that that are about Guix (or 
> connected areas). If I've missed any Guix related talks please tell me 
> so I can add them to the blog post:

Thanks for taking care about that.

It could be nice to publish this bog soon.  Is it doable?

Cheers,
simon

Re: Using the pyproject-build-system

[Simon Tournier]

Hi,

On Tue, 16 Jan 2024 at 00:19, Troy Figiel  wrote:

> Although not fully PEP 517-compliant according the documentation, the
> pyproject-build-system does seem to fall back to setuptools.build_meta
> if the pyproject.toml is missing. Contrary to what the name implies to
> me, it can therefore also be used for packages with only a setup.py file.

My understanding is that PEP 517 will be the default buitin way for
building Python project, and pyproject-build-system is an implementation
of such PEP 517.  Somehow, the adoption of PEP 517 by Python projects
will imply more Guix packages using pyproject-build-system.

In addition, one (and tangential) longer term for building Python
packages using Guix is rely on one build-system, namely
pyproject-build-system.  Hence maybe this unclear situation.

Cheers,
simon

Re: An update on ‘core-updates’

[Simon Tournier]

Hi,

On Thu, 11 Jan 2024 at 16:10, Ludovic Courtès  wrote:

> Long story short: I’d like us to freeze and merge the branch ASAP,
> notably because the glibc graft on ‘master’ leads to a bad user
> experience.  I’m happy with the current state of the branch and wouldn’t
> mind postponing remaining upgrades for the next cycle.
>
> Thoughts?

LGTM.  Hoping ASAP will be sooner than later… busy month! :-)

Cheers,
simon

Re: Proposition to streamline our NAR collection to just zstd-compressed ones

[Simon Tournier]

Hi,

On Tue, 09 Jan 2024 at 21:32, Maxim Cournoyer  wrote:

> What do you think?  Should we go ahead and effect the following simple
> change for the Berlin build farm?
>
> --8<---cut here---start->8---
> modified   hydra/modules/sysadmin/services.scm
> @@ -683,7 +683,7 @@ to a selected directory.")
> ;; 
> 
> ;; for the compression ratio/decompression speed
> ;; tradeoffs.
> -   (compression '(("lzip" 9) ("zstd" 19)))
> +   (compression '(("zstd" 19)))
> (cache-bypass-threshold cache-bypass-threshold)
> (workers publish-workers)))
> --8<---cut here---end--->8---

I think it is a good idea but the change is more than just oneline. ;-)

I agree with Ludo: the change requires communication.  Something like:

 1. Blog post.  Something like that [1], a bit extended with a Migration
section.

 2. A news (guix pull --news) announcing the sunset date.  And probably
pointing to the blog post (or elsewhere) for helping the migration.

 3. Optionally emit a warning when the daemon is “too” old.


I agree that the extra space can be annoying.  In the same time, user
experience matters more, IMHO.

Cheers,
simon

1: https://guix.gnu.org/en/blog/2022/sunsetting-gzip-substitutes-availability/

Re: Golang check phase skipping some tests?

[Simon Tournier]

Hi,

CC:
$ ./etc/teams.scm list-members go
Katherine Cox-Buday 
Sharlatan Hellseher 


On Sun, 14 Jan 2024 at 22:12, Troy Figiel  wrote:

> --8<---cut here---start->8---
> (define* (check #:key tests? import-path #:allow-other-keys)
>   "Run the tests for the package named by IMPORT-PATH."
>   (when tests?
> (invoke "go" "test" (string-append import-path "/...")))
>   #t)
> --8<---cut here---end--->8---
>
> For example, if the -v flag is added (which might be a better default?)
> to the check phase of go-github-stretchr-testify, it can be seen that
> only `TestImports' runs, none of the tests in assert, http, etc.
> However, the source code in these subdirectories is still recursively
> copied to out during the install phase.
>
> Is this desired behaviour? I assumed it isn't, because it looks like we
> are skipping a lot of tests during the check phase. However, I might
> also simply be overlooking something here as I am new to packaging
> Golang with Guix.

>From your description, it seems a good idea.  What do Go “experts“
think?

Cheers,
simon

Re: Commit Access: Sharlatan Hellseher

[Simon Tournier]

Hi Oleg,

On Thu, 11 Jan 2024 at 19:56, Sharlatan Hellseher  wrote:

> I am happy to have been granted commit access

Cool!  Welcome.

> If anyone has a good patch review workflow using Emacs, Gnus, and Magit,
> I would appreciate it ;-)

Well, nothing more than what had been already suggested.  Well, somehow
pipe the messages with “git am -3s” and apply the patches to a Git
worktree (named cooking), then rebase this cooking on the top of
master.

Cheers,
simon

Re: $EDITOR and “guix edit”

[Simon Tournier]

On Fri, 12 Jan 2024 at 20:46, Liliana Marie Prikler
 wrote:

> PS: I should probably just write the patch myself at this point, but I
> feel like it'll be misunderstood either way.

Sorry but I do not understand how your proposal would work in tandem
with the current "guix edit".  So yes, please send a patch for helping
me (us?) to understand what you suggest.

Cheers,
simon

RE: [swh-devel] Call for public review - SWH Nix/GNU Guix stack

[Simon TOURNIER]

Hi,

> The initial NixGuix loader (currently in production) lists and loads
> origins from a manifest, ignoring the specific origins mentioned above. The
> new stack will be able to ingest those origins. It will also optionally
> associate, if present, a NAR hash (specific intrinsic identifier to Nix and
> Guix) to what’s called an ExtID (SWH side).

Cool!  Thank you.

> Regarding the SWH API reading side of the ExtID though is a work to be done.

In short, currently Guix relies on SWH API for resolving from
“something” to SWHID, where “something” can be:

 + Git label tag + url
 + Git commit hash
 + plain url

Well, the situation is in good shape IMHO – I do not have recent
numbers, say all is fine for 75% of all Guix packages and for 90% of
Guix packages coming from some Git repositories – but still, we have
examples where “Git label tag + url” fails.  For one instance, see [1]
pointed by [2].

The information – history of history – is there in SWH but it would
require on Guix side to parse the snapshot information and extract as
best as possible; trying several SWH snapshots until a match.  Something
like that.  Chance of success until completion?  Weak. :-)

Moreover, what about the missing 25%?  They are Guix packages coming
from Mercurial repositories or from Subversion repositories or some
others.

Back on October 2020, we had discussion [3] for sending a save request
for packages using SVN checkouts but at the time we did not have a clear
path for retrieving.  Then on March 2023, maybe an path for retrieving
with this discussion [4]… but still many hacks are required [5].

Again, the information is there in SWH but it would require on Guix side
to parse the snapshot information and extract as best as possible;
trying several SWH snapshots until a match.  Something like that.
Chance of success until completion?  Weak. :-)

If only one source is missing, all the castle potentially falls down.  Somehow,
a dictionary from ExtID as nar hash to SWHID would help to have the
castle more robust. :-)

The SWH archive coverage of Guix packages would not be 75% because we, on
Guix side, are not able to know or retrieve these missing 25%.  Such dictionary
could reinforce the bridge between reproducible computational environment 
and archiving, IMHO.

So yeah, we are looking forward to some ExtID interface.  :-)

Cheers,
simon


1: https://issues.guix.gnu.org/66015#0-lineno53
2: 
https://gitlab.softwareheritage.org/swh/devel/swh-loader-git/-/issues/4751#note_148587
3: https://issues.guix.gnu.org/43442#9
4: https://sympa.inria.fr/sympa/arc/swh-devel/2023-03/msg9.html
5: https://issues.guix.gnu.org/43442#13

Re: $EDITOR and “guix edit”

[Simon Tournier]

Hi,

On Fri, 12 Jan 2024 at 18:39, Liliana Marie Prikler
 wrote:

> > Well, I see how to write specific Scheme wrapper around $EDITOR; as I
> > did in [1].
> >
> > Or, I see how to tweak guix/scripts/edit.scm for running specific
> > launcher depending on $EDITOR.
> >
> > Liliana, could you provide a proof-of-concept about « the shell-esque
> > "${LINE}" and "${FILE}" that would get replaced by Scheme code
> > looking for those strings »?  Because I do not see what you mean.
>
> (let* ((editor (getenv "GUIX_EDITOR"))
>(editor (string-replace-substring editor "${FILE}" the-file))
>(editor (string-replace-substring editor "${LINE}" the-line)))
>   editor)
>
> with the-file and the-line being placeholders for the actual variable
> names.  You could obviously do smarter things with gash, but let's not
> go there at the moment.

I do not understand how it is different from the wrapper I already did:

https://gitlab.com/zimoun/advanced-packages-2023/-/blob/main/vscode-wrapper?ref_type=heads#L70-99

Cheers,
simon

Re: $EDITOR and “guix edit”

[Simon Tournier]

Hi,

On Mon, 20 Nov 2023 at 20:33, Liliana Marie Prikler  
wrote:

>>  2. Do we put this code in some etc/vscode-wrapper that user can
>>  install?  (or that we could automatically installl) Or maybe revamp
>> it
>>  for calling this code via some shell function?
>
> With VSCode et al. not being Guix packages, I see little point in
> providing these wrappers through Guix itself.

I do not want to address here where to keep VSCode support and instead I
would like to address $EDITOR which does not follow the good ol’
fashion.

Well, I see how to write specific Scheme wrapper around $EDITOR; as I
did in [1].

Or, I see how to tweak guix/scripts/edit.scm for running specific
launcher depending on $EDITOR.

Liliana, could you provide a proof-of-concept about « the shell-esque
"${LINE}" and "${FILE}" that would get replaced by Scheme code looking
for those strings »?  Because I do not see what you mean.

Cheers,
simon

1: 
https://gitlab.com/zimoun/advanced-packages-2023/-/blob/main/vscode-wrapper?ref_type=heads

PS:

About VSCode.  Somehow, it is a chicken-or-the-eggs problem.  “We“
cannot complain with lengthy threads about the lack of contributor
diversity, or that many Guix tools are Emacs-centric, etc. and in the
same time say no because VSCode is not packaged in Guix proper.

We like it or not – I do not like it and do not use it! – for sure,
VSCode is currently one of the most used editor around.  Being friendly
with VSCode users would help to have more contributions from them.

Re: Building and caching old Guix derivations for a faster time machine

[Simon Tournier]

Hi Maxim,

On Thu, 30 Nov 2023 at 08:28, Maxim Cournoyer  wrote:

> I'd like to have a single archive type as well in the future, but I'd
> settle on Zstd, not lzip, because it's faster to compress and
> decompress, and its compression ratio is not that different when using
> its highest level (19).

When running an inferior (past revision), some past Guile code as it was
in this past revision is launched.  Hum, I have never checked: the
substitution mechanism depends on present revision code (Guile and
daemon) or on past revision?

Other said, what are the requirements for the backward compatibility?
Being able to run past Guix from a recent Guix, somehow.


>>  1. Keep for as longer as we can all the requirements for running Guix
>>  itself, e.g., “guix time-machine”.  Keep all the dependencies and all
>>  the outputs of derivations.  At least, for all the ones the build farms
>>  are already building.
>>
>>  2. Keep for 3-5 years all the outputs for specific Guix revision, as
>>  v1.0, v1.1, v1.2, v1.3, v1.4.  And some few others.
>
> That'd be nice, but not presently doable as we can't fine tune retention
> for a particular 'derivation' and its inputs in the Cuirass
> configuration, unless I've missed it.

That’s an implementation detail, a bug or a feature request, pick the
one you prefer. ;-)

We could imagine various paths for these next steps, IMHO.  For
instance, we could move these outputs to some specific stores
independent of the current ones (ci.guix and bordeaux.guix).  For
instance, we could have “cold” storage with some cooking bakery for
making hot again, instead of keeping all hot.  For instance, we could
imagine etc. :-)

Well, I do not have think much and I just speak loud: Cuirass (and Build
Coordinator) are the builders, and I would not rely on them for some NAR
“archiving“, instead maybe “we” could put some love into the tool
nar-herder.  Somehow, extract specific NAR that the project would like
to keep longer than the unpredictable current mechanism.

Cheers,
simon

Re: Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi,

Well, more than 7 weeks later… Hum, does it mean that the Guix project
is not interested in formalizing some RFC?

WDYT about the proposal?

On Tue, 31 Oct 2023 at 12:14, Simon Tournier  wrote:
> Hi,
>
> This is a proposal for implementing Request-For-Comment process.
> Comment are welcome in #66844 [1]:
>
> 1: https://issues.guix.gnu.org/issue/66844
>
>
> The proposal is highly inspired by Rust RFC:
>
> https://github.com/rust-lang/rfcs
>
> and also by GHC Haskell proposal process [1] and Nix RFC process [2].  Based
> on my understanding of Guix community interactions, I write down this
> text; below the text for easing the reading.
>
> Cheers,
> simon
>
> 1: https://github.com/ghc-proposals/ghc-proposals
> 2: https://github.com/NixOS/rfcs
>
> --
>
> RFC process
> ===
>
> # -*- mode:org -*-
> #+TITLE: Request-For-Comment process
> #+DATE: 2023-10-31
>
> + Issue: 66844
> + Status: pending
> + Supporter: Simon Tournier
> + Co-supporters:
>
> * Summary
>
> The "RFC" (request for comments) process is intended to provide a consistent
> and controlled path for new features to enter the Guix project, so that all
> stakeholders can be confident about the direction it is evolving in.
>
> * Motivation
>
> The freewheeling way that we add new features to Guix has been good for early
> development, but for Guix to become a broadly used system we need to develop
> some more self-discipline when it comes to changing our beloved system.  This
> is a proposal for a more principled RFC process to make it a more integral
> part of the overall development process, and one that is followed consistently
> to introduce substancial features.
>
> There are a number of changes that are significant enough that they could
> benefit from wider community consensus before being introduced.  Either
> because they introduce new concepts, big changes or are controversial enough
> that not everybody will agree on the direction to take.
>
> Therefore, the purpose of this RFC is to introduce a process that allows to
> bring the discussion upfront and strengthen decisions.  This RFC is used to
> bootstrap the process and further RFCs can be used to refine the process.
>
> Note that this process does not cover most of the changes.  It covers
> significant changes, for some examples:
>
>  + change of inputs style
>(Removing input labels from package definitions, #49169)
>  + introduction of =guix shell= and deprecation of =guix environment=
>(Add 'guix shell' to subsume 'guix environment', #50960)
>  + introduction of authentication mechanism (Trustable "guix pull", #22883)
>  + massive Python 2 removal
>(Merging the purge-python2-packages branch, mailing list guix-devel)
>  + collaboration via team and branch-features
>(several places mailing list guix-devel)
>
> * Detail design
>
> ** When you need to follow this process
>
> This process is followed when one intends to make "substantial" changes to the
> Guix project.  What constitutes a "substantial" change is evolving based on
> community norms, but may include the following.
>
>   + Any change that modifies Guix API
>   + Big restructuring of packages
>   + Introduction or removal of subcommands
>
> Certain changes do not require an RFC:
>
>   - Adding, updating packages, removing outdated packages
>   - Fixing security updates and bugs that don't break interfaces
>
> A patch submission to Debbugs that contains any of the afore-mentioned
> substantial changes may be asked to first submit a RFC.
>
> ** How the process works
>
>   1. Clone https://git.savannah.gnu.org/git/guix.git
>   2. Copy rfc/-template.org to rfc/00XY-good-name.org where good-name is
>  descriptive but not too long and XY increments
>   3. Fill RFC
>   4. Submit to guix-patc...@gnu.org
>
> Make sure the proposal is as well-written as you would expect the final
> version of it to be.  It does not mean that all the subtilities must be
> considered at this point since that is the aim of review discussion.  It means
> that the RFC process is not a prospective brainstorming and the proposal
> formalize an idea for making it happen.
>
> The submission of a proposal does not require an implementation.  However, to
> improve the chance of a successful RFC, it might be recommended to have an
> idea for implementing it.  If an implementation is attached to the detailed
> design, it might help the discussion.
>
> At this point, at least one other person must volunteer to be "co-supporter".
> The aim is to improve the chances that the RFC is both desired and likely to
> be implemented.
>
> Onc

RFC (was Re: Shutting down qa.guix?)

[Simon Tournier]

Hi Ludo,

On sam., 09 déc. 2023 at 11:54, Ludovic Courtès  wrote:

> I know this has been discussed several times and it remains unclear to
> me why as a project we never managed to move forward—maybe the comfort
> of the status quo?

It would help if the project would have a process for such move.  Why
not some Request-For-Comment?

Request-For-Comment process: concrete implementation
    Simon Tournier 
Tue, 31 Oct 2023 12:14:42 +0100
id:87h6m7yrfh@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-10
https://yhetil.org/guix/87h6m7yrfh@gmail.com

Cheers,
simon

Re: Shutting down qa.guix?

[Simon Tournier]

Hi,

On sam., 09 déc. 2023 at 11:54, Ludovic Courtès  wrote:

> I think this underlines a collective failure to get our act together.

I do not consider a collective failure considering the payment for the
service.  About the maintenance of such service, that’s another
question, IMHO. :-)


> Anyway, would it be possible for you to transfer billing of the hardware
> (Hetzner?) to Guix Foundation?  Does Guix Foundation know what it would
> cost them?

Just to put context about these questions for transferring billing:

 1. The initial discussion happened on the private mailing list
guix-sysadmin.  Board of Guix Foundation had been CC on July 6th.

 2. Chris provided billing information on July 14th.  Then Andreas
answered that it is sustainable for Guix Foundation, potentially
with the help of Guix Spending Committee.

 3. On July 13th, the Solidary Administration Council of Guix Foundation
had been solicited; as specified by Guix Foundation statutes.

 4. On September 12th, the SAC voted yes about supporting the financial
cost of QA.  Moreover, since it is a recurrent cost, some means for
collecting money had also been discussed.

 5. Then what has been unexpected is the energy that the Board of Guix
Foundation invested in resolving an unrelated but blocking situation
with our bank.  It probably slowed down all the operational part.

Well, from my understanding of the Guix Foundation side, all is ready
for transferring the current billing and, again from my understanding of
the situation, what is missing is the effective operational transfer.
Now, some relationships with our bank are smoothed… somehow. :-)


> The “spending committee” (Tobias, Ricardo, and myself), which oversees
> expenditure from the funds held at the FSF, can also be in the loop to
> provide additional financial support.

Since it is recurrent cost, yes it would nice to discuss between Guix
Foundation’s SAC and Spending Committee how to secure the financial
support of a recurrent cost.


> PS: You’ve done amazing work over the years.  As a contributor, I find
> it super reassuring to know that you’re always available and
> focused, committed to improving patch workflows for many years.
> It’s been a long road already and I admire this level of commitment
> and hard work.

I still remember the first time we met with Chris, it was back on
December 2018, right before Reproducible Build Summit in Paris.  Chris
already presented what could be done for improving the patch workflows.
It’s inspiring to see such commitment and hard work over the years.

Cheers,
simon

Re: Moment de convivialité Guix@Paris en nov… euh… décembre

[Simon Tournier]

salut,

On Fri, 08 Dec 2023 at 08:45, Tanguy LE CARROUR  wrote:

> Rendez-vous début janvier (sûrement le 11, à confirmer) pour la
> prochaine !

Avec des stickers si je ne les oublie pas à nouveau. ;-)

Chouette soirée !

à tantôt,
simon

Re: Doing away with CentOS 6 support (Linux faux-2.6)?

[Simon Tournier]

Hi,

On Thu, 07 Dec 2023 at 23:46, Ludovic Courtès  wrote:

> Back in 2018, this was deemed important for HPC clusters, where CentOS 6
> was then relatively common, as Ricardo explained:

Héhé!  A colleague re-installed CentOS 6 this week; for testing
purpose.  Hum… :-)

> Five years later, it seems reasonable to drop the patch (which is likely
> untested these days).  If you disagree, now’s the time to make your
> voice heard!

Yeah, let drop this patch.  Well, CentOS 7 will be soon end of life so
it seems very reasonable to drop patches for CentOS 6 only.

Cheers,
simon

Re: Moment de convivialité Guix@Paris en nov… euh… décembre

[Simon Tournier]

salut Édouard,

Chouette présentation !  Je pense que cela pourrait sympa de partager
ton canal. :-)

à tantôt,
simon

Re: GNU Mes 0.26 released

[Simon Tournier]

Hi Janneke,

On Sun, 03 Dec 2023 at 13:50, Janneke Nieuwenhuizen  wrote:

> We are happy to announce the release of GNU Mes 0.26.

Cool!

A naive question. :-)  I was randomly roaming and I have seen, for
example, in file module/mescc/x86_64/as.scm:

--8<---cut here---start->8---
;; AMD
(define (x86_64:function-preamble info . rest)
  `(("push___%rbp")
("mov%rsp,%rbp")
("sub$i32,%rbp" "%0x80")
,@(list-head
   '(("mov%rdi,0x8(%rbp)" "!0x10")
 ("mov%rsi,0x8(%rbp)" "!0x18")
 ("mov%rdx,0x8(%rbp)" "!0x20")
 ("mov%rcx,0x8(%rbp)" "!0x28")
 ("mov%r8,0x8(%rbp)" "!0x30")
 ("mov%r9,0x8(%rbp)" "!0x38"))
   (length (car rest)

;; traditional
(define (x86_64:function-preamble info . rest)
  `(("push___%rbp")
("mov%rsp,%rbp")))
--8<---cut here---end--->8---

And my question is: the procedure name is exactly the same therefore how
is the correct one picked?


Thanks for all this!

Cheers,
simon

Re: What's the difference between a shell environment and a profile?

[Simon Tournier]

Hi Konrad,

On Fri, 08 Dec 2023 at 17:24, Konrad Hinsen  wrote:

> First, I tested some Python 2 scripts in a shell environment:
>
> guix time-machine -C ./channels.scm \
> -- shell --container \
>python2 python2-mmtk python2-matplotlib \
>--with-input=python2-numpy=python2-numpy@1.8.2 \
>-- python
>
> Works fine. Next, I wanted to create a Guix profile with the same
> software, mainly to keep it in the store for long-term future use,
> surviving garbage collection:
>
> guix time-machine -C ./channels.scm \
> -- package -p ./python2-profile \
>-i python2 python2-mmtk python2-matplotlib \
>--with-input=python2-numpy=python2-numpy@1.8.2
>
> Guix wasn't happy at all with this:

Guix is not happy with ’shell’ but pass silently the collision; from my
understanding.

Somehow, then the Python script works but by chance, I guess.


>   guix package: error: profile contains conflicting entries for glib
>   guix package: error:   first entry: glib@2.70.2 
> /gnu/store/64bdjb3nwdkadmy5z2wph9cgqr0bwijm-glib-2.70.2
>   guix package: error:... propagated from cairo@1.16.0
>   guix package: error:... propagated from python2-pycairo@1.18.2
>   guix package: error:... propagated from python2-matplotlib@2.2.5
>   guix package: error:   second entry: glib@2.73.3 
> /gnu/store/kf488k7v0lc48ylbs4xxpam0dbl3r4jl-glib-2.73.3
>   guix package: error:... propagated from gobject-introspection@1.73.1
>   guix package: error:... propagated from python2-matplotlib@2.2.5
>   hint: You cannot have two different versions or variants of 
> `python2-matplotlib' in
> the same profile.
>
> In the end I did:
>
> guix time-machine -C ./channels.scm \
> -- shell --container -r ./python2-profile \
>python2 python2-mmtk python2-matplotlib \
>--with-input=python2-numpy=python2-numpy@1.8.2 \
>-- python
>
> which should have the effect I am looking for, but I don't understand
> how this differs from the "guix package" attempt that failed. The
> difference seems to be related to the –with-input transform, because
> I don't see what else could cause the "two different versions of
> python2-matplotlib" to be around.

It does not differ.  What differs is that “guix shell” raises nothing
for the collision – maybe “guix shell” does not check the collision, I
do not remember – when “guix package” raises an error for the same
collision.

Well, since it is a past Guix revision provided by the file
channels.scm, I do not know if this collision could now be fixed.

Cheers,
simon

Re: #$(this-package-input "subversion") in git introduces a cycle

[Simon Tournier]

Hi Maxim,

I am late to the party and maybe it is already solved.

On ven., 06 oct. 2023 at 22:13, Maxim Cournoyer  
wrote:

> I've narrowed the problem down to #$(this-package-input "subversion");
> the following diff allows the build to start:

[...]

> I'm puzzled as to why this happens.  Would someone have an idea?

No idea.  On a side note, on the top of
cd46757c1a0f886848fbb6828c028dd2a2532767, I get this error:

--8<---cut here---start->8---
phase `build' succeeded after 17.4 seconds
starting phase `build-subtree'
error: in phase 'build-subtree': uncaught exception:
unbound-variable #f "Unbound variable: ~S" (native-inputs) #f 
phase `build-subtree' failed after 0.0 seconds
Backtrace:
In srfi/srfi-1.scm:
634:9 19 (for-each # …)
In ice-9/boot-9.scm:
  1752:10 18 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   929:23 17 (_)
In ice-9/boot-9.scm:
142:2 16 (dynamic-wind # …)
In ice-9/eval.scm:
619:8 15 (_ #(#(# (# # …
In ice-9/boot-9.scm:
  1752:10 14 (with-exception-handler _ _ #:unwind? _ # _)
In ice-9/ports.scm:
   433:17 13 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
In guix/build/utils.scm:
   899:26 12 (_ #)
   959:29 11 (loop "\t$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man …")
In srfi/srfi-1.scm:
   460:18 10 (fold # …)
In ice-9/eval.scm:
   202:51  9 (_ #(#(#(#(#(#(# …)) …) …) …) …))
163:9  8 (_ #(#(#(#(#(#(# …)) …) …) …) …))
163:9  7 (_ #(#(#(#(#(#(# …)) …) …) …) …))
159:9  6 (_ #(#(#(#(#(#(# …)) …) …) …) …))
   293:34  5 (_ #(#(#(#(#(#(# …)) …) …) …) …))
   223:20  4 (proc #(#(#(#(#(#(# …)) …) …) …) …))
In unknown file:
   3 (%resolve-variable (7 . native-inputs) #)
In ice-9/boot-9.scm:
  1685:16  2 (raise-exception _ #:continuable? _)
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: native-inputs
--8<---cut here---end--->8---

And it probably comes from:

(search-input-directory
 (or native-inputs inputs)
 (string-append
  "xml/xsl/docbook-xsl-"
  #$(package-version docbook-xsl)))

Maybe it is related to the error you observed later.  Hum, I do not
know… I have not investigated further. :-)

Cheers,
simon

Re: sbcl-py4cl does not appear in --list-dependent output

[Simon Tournier]

Hi,

On mer., 29 nov. 2023 at 13:27, "jgart"  wrote:

> Does anyone happen to know why sbcl-py4cl doesn't appear in this output?
>
> guix refresh --list-dependent python-numpy
>
> Building the following 1490 packages would ensure 3164 dependent packages are 
> rebuilt:

I guess sbcl-py4cl is not part of the 1490 packages but is part of the
3164 ones.

Cheers,
simon

Re: Upgrading Guix's security team

[Simon Tournier]

Hi,

On mer., 22 nov. 2023 at 19:16, Ludovic Courtès  wrote:

> Leo, Tobias, and John: What would be a good end-of-term date for each
> one of you?  As I see it, it wouldn’t mean you cannot do an additional
> term but rather that you’ll have an opportunity to leave and that you’ll
> do your best to be around by then.

I think all this should be encoded in some RFC as proposed in:

Request-For-Comment process: concrete implementation
    Simon Tournier 
Tue, 31 Oct 2023 12:14:42 +0100
id:87h6m7yrfh@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-10
https://yhetil.org/guix/87h6m7yrfh@gmail.com

Well, this RFC proposal appears to me a good opportunity for clarifying
the scope. role. end-of-term, etc. about the Security Team.

Cheers,
simon

Re: guix shell init

[Simon Tournier]

Hi jgart,

On mer., 25 oct. 2023 at 14:12, "jgart"  wrote:

>> Could you explain what “Nix flake” means using Guix terminology?
>
> Here's TLDR list of nix flake features and their guix equivalents
> (maybe):

Thanks for explaining.

If I understand correctly, Guix does not miss some feature from Nix
flakes, right?

If yes, could someone explain what would be such feature?


> There's also some comparison of Guix and Nix flakes here:
>
> https://blog.benoitj.ca/2023-10-23-guix-home-configuration-part1-packages/
> https://blog.benoitj.ca/2023-10-20-how-guix-compare-to-nix-and-vice-versa/

Thanks for the links.

Cheers,
simon

Re: Building and caching old Guix derivations for a faster time machine

[Simon Tournier]

Hi,

On mer., 22 nov. 2023 at 19:27, Ludovic Courtès  wrote:

> For long-term storage though, we could choose to keep lzip only (because
> it compresses better).  Not something we can really do with the current
> ‘guix publish’ setup though.

It looks good to me.  For me, the priority list looks like:

 1. Keep for as longer as we can all the requirements for running Guix
 itself, e.g., “guix time-machine”.  Keep all the dependencies and all
 the outputs of derivations.  At least, for all the ones the build farms
 are already building.

 2. Keep for 3-5 years all the outputs for specific Guix revision, as
 v1.0, v1.1, v1.2, v1.3, v1.4.  And some few others.

Cheers,
simon

Feedback (was Re: Meet Guix at Capitole du Libre in Toulouse)

[Simon Tournier]

Hi,

Thanks all people!  It was a very interesting experience for me and a
very good moment.  I hope that we will do again in the near future.

As a record for the next time, let me mention two points that help:

 1. Demos!  It seems very helpful to have both: Guix System and Guix on
foreign distro.  Depending on the people, some are interested by one
or the other.  Mainly, what mark points (main selling arguments ;-))

Guix on foreign distro:

  a) do not interact with foreign distro
  => good complement and rolling release
  b) containerized  shell
  => please developers

Guix System:

  a) roll-back
  b) transactional
  c) roll-back at GRUB level

 2. An explanation about what makes Guix different compared to X

where X is:

i) classical distro as Arch, Gentoo, Debian, etc.
ii) Nix and NixOS

Sadly, we do not have a clear story for ii) IMHO.

Well, from my point of view, the main difference is the continuous*
approach of Guix – the same “language“ from declaring packages or OS
configuration to Guix core; except the daemon, another story. ;-) Well,
that “language” allows to implement a powerful solution as G-expression
tackling, among other things, string interpolation.

It could be nice if we could collectively draft a short FAQ about what
Guix is and Guix is not, answering such common questions.


Cheers,
simon


*continuous approach: The Emacs Thesis :-)
--

The story of Guile is the story of bringing the development experience
of Emacs to the mass of programs on a GNU system.

   Emacs, when it was first created in its GNU form in 1984, was a new
take on the problem of “how to make a program”.  The Emacs thesis is
that it is delightful to create composite programs based on an
orthogonal kernel written in a low-level language together with a
powerful, high-level extension language.

   Extension languages foster extensible programs, programs which adapt
readily to different users and to changing times.  Proof of this can be
seen in Emacs’ current and continued existence, spanning more than a
quarter-century.

   Besides providing for modification of a program by others, extension
languages are good for _intension_ as well.  Programs built in “the
Emacs way” are pleasurable and easy for their authors to flesh out with
the features that they need.

   After the Emacs experience was appreciated more widely, a number of
hackers started to consider how to spread this experience to the rest of
the GNU system.  It was clear that the easiest way to Emacsify a program
would be to embed a shared language implementation into it.

Re: [maintenance] Compressed JSON files and served file extension?

[Simon Tournier]

Hi,

On mar., 28 nov. 2023 at 16:50, Tomas Volf <~@wolfsden.cz> wrote:

> You could invoke the wget with -E flag I guess.

Thanks.  I will try to apply that consistently. :-)


On mar., 28 nov. 2023 at 21:05, Attila Lendvai  wrote:

>(remember: if it's not backwards, it's not
> compatible! :) 

Thanks for explaining. :-)


Cheers,
simon

Re: [maintenance] Compressed JSON files and served file extension?

[Simon Tournier]

Hi,

On Mon, 20 Nov 2023 at 14:03, Attila Lendvai  wrote:

> TL;DR the filename shouldn't contain the .gz extension, and the HTTP
> standard is crap ("If no Accept-Encoding field is present in a
> request, the server MAY assume that the client will accept any content
> coding.").
>
> use curl --compressed

And if I do not want to use curl but instead another tool as wget? :-)

Cheers,
simon

Re: [maintenance] Compressed JSON files and served file extension?

[Simon Tournier]

Hi Ludo,

On Thu, 16 Nov 2023 at 15:40, Ludovic Courtès  wrote:

> That said, if you become aware of actual breakage, we can revisit this!

The actual breakage is my own interaction with this file. :-)

Again, it happened to me yesterday.  By habits, I do:

$ wget https://guix.gnu.org/sources.json
$ cat sources.json | jq | head

Then,

--8<---cut here---start->8---
parse error: Invalid numeric literal at line 1, column 16
cat: write error: Broken pipe
--8<---cut here---end--->8---

Well, we are 6 days later my last message, 12 days after your message
and more than one month after my report; and again the same mistake.
That’s mistake because it does not jump to my eyes that the file is
compressed.  Yeah, I could do many on my side as change my habits, as
use curl, as have a smarter cat, as write a note, as have a better
memory, as …

However, the simplest still appears to me to have the extension
reflecting the format of the file.  Similarly as it is ’sources.json’
and not just ’sources’.


Cheers,
simon

Re: Moment de convivialité Guix@Paris en nov… euh… décembre

[Simon Tournier]

salut,

On Thu, 23 Nov 2023 at 09:18, Tanguy LE CARROUR  wrote:

> Jeudi 7 décembre à 19h, se tiendra la troisième édition de Guix@Paris
> ouverte au public.
> Comme la dernière fois, il sera possible de participer à distance (*cf* 
> ci-dessous).

Et pour les présents, quelques stickers Guix. :-)

À très tantôt,
simon

Re: Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi Efraim,

Thnaks for your comments.

On Thu, 23 Nov 2023 at 09:04, Efraim Flashner  wrote:

> Actually, in terms of suggestions, I'd add the rfc/ folder in
> etc/teams.scm to set guix-devel as one of the team members.

Good idea!

Cheers,
simon

Re: $EDITOR and “guix edit”

[Simon Tournier]

Hi,

On Thu, 16 Nov 2023 at 17:04, Liliana Marie Prikler  
wrote:

>> It’d be nice to support these as well.  However, how do we know we’re
>> dealing with kate or VSCode?  By checking the basename of $EDITOR?
>> Kinda ugly and brittle, but probably better than nothing.
>
> Maybe we can check for a guix_editor shell function and invoke that
> rather than EDITOR if defined?

Yeah, from my point of view, the two alternatives [1] are:

  1. do we tweak “guix edit” for behaving differently depending on $EDITOR?

or

  2. do we provide some wrappers for the issues that already popped up?

Where #1 is what Ludo suggests and #2 is what Liliana suggests. :-)

Well, see below the code [2] that we concretely need for VSCode.  The
question is:

 1. Do we put this code in guix/scripts/edit.scm?  And trigger on the
 basename of EDITOR?

or

 2. Do we put this code in some etc/vscode-wrapper that user can
 install?  (or that we could automatically installl) Or maybe revamp it
 for calling this code via some shell function?


WDYT?

Cheers,
simon

--8<---cut here---start->8---
#!/usr/bin/env -S guix repl -q --
;; -*- mode: scheme -*-
!#
;;; Copyright © 2023 Simon Tournier 
;;;
;;;
;;; VSCode does not respect the convention:
;;;
;;; $EDITOR +line file
;;;
;;; and instead relies on:
;;;
;;; code --goto file:line
;;;
;;;
;;; This wrapper is a workaround.  It is Scheme but it could be whatever else
;;; as Bash, Python, etc.  It uses "guix repl" although no Guix library is
;;; required.  Because we assume the invokation,
;;;
;;; EDITOR=./vscode-wrapper guix edit foo bar
;;;
;;; relying on "guix repl" allows to easily get Guile.
;;;

(use-modules (ice-9 match)
 ((ice-9 string-fun) #:select (string-replace-substring))
 ((ice-9 ftw) #:select (scandir))
 )

(define %vscode--goto
  (let* ((vscode-server (string-append (getenv "HOME") "/.vscode-server"))
 (code (if (file-exists? vscode-server)
   ;; Maybe Remote-SSH
   (let* ((vscode-server/bin (string-append vscode-server 
"/bin"))
  (hash ;Guess the correct identifier
   (car
(scandir vscode-server/bin
 (lambda (file)
   (not (member file (list "." ".."
 (lambda (x y)
   (> (stat:mtime
   (lstat (string-append 
vscode-server/bin "/" x)))
  (stat:mtime
   (lstat (string-append 
vscode-server/bin "/" y
  (vscode (string-append
   vscode-server/bin "/" hash 
"/bin/remote-cli/code"))
  (run/user/uid (string-append "/run/user/"
   (number->string 
(getuid
  (socket   ;Guess the correct socket, if required
   (car
(scandir run/user/uid
 (lambda (file)
   (string-prefix? "vscode-ipc" file))
 (lambda (x y)
   (< (stat:mtime
   (lstat (string-append run/user/uid 
"/" x)))
  (stat:mtime
   (lstat (string-append run/user/uid 
"/" y)
 ;; : Check VSCode API for something more robust
 (if (getenv "VSCODE_IPC_HOOK_CLI")
 vscode
 (string-append
  "VSCODE_IPC_HOOK_CLI=" socket " " vscode)))
   ;; No Remote-SSH, try to find the local one in PATH
   (search-path (string-split (getenv "PATH") #\:)
"code"
;(format #t "~a~%" code)
(string-append code " --goto ")))

(define +line-files
  (match (command-line)
((wrapper rest ...)
 (if (eqv? 0 (modulo (length rest) 2))
 rest
 (begin
   (write "Error with 'guix edit'")
   (exit 1))

(define files
  (let loop ((files:lines '())
 (lst +line-files))
(if (null? lst)
(reverse files:lines)
(match lst
  ((n file rest ...)
   (loop
(cons (string-append
   file ":" (string-replace-subst

Re: [maintenance] Compressed JSON files and served file extension?

[Simon Tournier]

Hi,

On Thu, 16 Nov 2023 at 15:40, Ludovic Courtès  wrote:

>> However, now I get:
>>
>> $ wget https://guix.gnu.org/sources.json
>
> If you open it in a browser though, it’s fine, because browsers and in
> fact many HTTP clients other than wget, honor ‘Content-Encoding’:

[...]

> That said, if you become aware of actual breakage, we can revisit this!

Could we have a self-consistent name?  The expected extension when a
file is Gziped compressed is .gz.  Why not put it?

1. It costs us nothing.
2. How to read the file is then clearer.


Cheers,
simon

Re: Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi Ludo,

Thanks for giving a look.

On Thu, 16 Nov 2023 at 16:03, Ludovic Courtès  wrote:

> Thanks for starting the discussion!  I think that getting such a process
> in place is key to sustain friction-less development of Guix, giving
> everyone a chance to have their voice heard.

Do you have comments on the current proposal?  About points where you
think they could be improved?  As wording?  Or process?  Or else?

Cheers,
simon

collection of “guix pull“ bug reports

[Simon Tournier]

Hi,

>>> https://issues.guix.gnu.org/issue/62830
>>> https://issues.guix.gnu.org/issue/63451
>>> https://issues.guix.gnu.org/issue/63830
>>> https://issues.guix.gnu.org/issue/64489
>>> https://issues.guix.gnu.org/issue/64659
>>> https://issues.guix.gnu.org/issue/64753
>>> https://issues.guix.gnu.org/issue/64963

More are reported…

>>> Any idea about what could be unexpected or what needs some love?
>>
>> I haven't checked the above links, but I think something that would help
>> in this regard is better handling of network issues.  E.g, don't print a
>> backtrace on the first connection failure; retry maybe 3 times then
>> print a helpful error mentioning the network appears unreliable.
>
> IMHO, this collection raises two questions:
>
>   1. Why does it happen?  To say it explicitly, I am almost sure that
>   something is not smoothly working as expected on server side.  For
>   instance, I had ‘guix pull’ troubles with a machine and I am doubtful
>   that this machine has network issue (this machine is using the fast
>   network link of my Univ. employer :-))
>
>   2. What could be done on client side for reducing the annoyance?  I
>   agree that substitute failures should be better handled.  For example,
>   retry 3 times then display an error message.  Etc.

Well, most of the time, the error is transient so it is hard to debug.
On client side (#2), well I have ideas how to fake a faulty network on
my end.  What could be done on server side?

Cheers,
simon

Re: Turning off tests leads to a different store item

[Simon Tournier]

Hi Maxim,

On Thu, 09 Nov 2023 at 10:04, Maxim Cournoyer  wrote:

>> I agree.  On a side note, one of the issue is the time of some tests.
>> Sometimes, packaging is frustrating: build takes ages, then you fix some
>> tests, think it will be good, re-launch “guix build”, another test
>> failing, repeat.  It could nice to be able to cache the result of the
>> build phase.
>
> I usually end up working in the /tmp/guix-build-* failed build of a
> package for these situations; then I don't need to rebuild the whole
> thing for each test suite run, and can test changes directly without
> proper patches while working toward a fix.

Do you know all the command lines equivalent for each phase run by all
the build systems? ;-)

Well, this workflow seems appealing but it never works for me on
concrete situations.  Most of the time, my issue does not come from
“what to do from command line” but “how to do it inside the Guix
recipe”.

For example, this test suite adjustment:

  (add-before 'install 'disable-network-tests
(lambda _
  (substitute* "test/runtests.jl"
(("\"async.jl") "# \"async.jl")
(("\"client.jl") "# \"client.jl"))
  (substitute* "test/aws4.jl"
(("@testset.*HTTP.request with AWS authentication.*" all)
 (string-append all "return\n")))
  (substitute* "test/insert_layers.jl"
(("@testset.*Inserted final layer runs handler.*" all)
 (string-append all "return\n")))
  (substitute* "test/multipart.jl"
(("@testset \"Setting of Content-Type.*" all)
 (string-append all "return\n"))
(("@testset \"Deprecation of .*" all)
 (string-append all "return\n")))
  (substitute* "test/websockets.jl"
(("@testset.*External Host.*" all)
 (string-append all "return\n")))
  (substitute* "test/messages.jl"
(("@testset.*Read methods.*" all)
 (string-append all "return\n"))
(("@testset.*Body - .*" all)
 (string-append all "return\n"))
(("@testset.*Write to file.*" all)
 (string-append all "return\n")))
  (substitute* "test/cookies.jl"
(("@testset.*Set-Cookie casing.*" all)
 (string-append all "return\n"

To have the correct replacement rules, I almost never get it right at
the very first try, and the feedback loop is poor.  In some case, the
replacement is done after 'unpack, so I can just kill the build process
and check inside /tmp/guix-build-* if the output is the expected one.

However, depending on the test suite, sometimes, it errors at the first
failing test and does not report all the failing cases.  For example, in
the previous snippet, I could have to build then check, fail and repeat
something like 11 times, adding some try-error attempts for the correct
replacement rule.

Cheers,
simon

Re: Turning off tests leads to a different store item

[Simon Tournier]

Hi,

On Wed, 08 Nov 2023 at 22:17, Maxim Cournoyer  wrote:

> I agree it looks tricky to get it right (and even trickier to prove/test
> for it) :-).

Yeah.  I have tried a rough “proof-of-concept” i.e., two derivations:
one which deletes ’check’ phase and the other which deletes ’build’
phase and depends on the former.

Re: Turning off tests leads to a different store item
    Simon Tournier 
Thu, 02 Nov 2023 18:02:18 +0100
id:86y1fgm6lh@gmail.com
https://lists.gnu.org/archive/html/help-guix/2023-11
https://yhetil.org/guix/86y1fgm6lh@gmail.com

In this simple case, it works. :-)

But to have something robust, IMHO, it would probably mean 1. create
other objects (record) different from  and revamp the build
systems.  And then 2. rebuild many packages for 3. evaluate the ratio
between the number of packages that works this way vs the number of
packages that fails this way.  Oof!  That’s a fun project… :-)


> I think the lower fruits are in looking at making the test suite of the
> few common offenders more robust (using libfaketime or the likes) to
> prevent (re)occurrences of time bombs in the future.

I agree.  On a side note, one of the issue is the time of some tests.
Sometimes, packaging is frustrating: build takes ages, then you fix some
tests, think it will be good, re-launch “guix build”, another test
failing, repeat.  It could nice to be able to cache the result of the
build phase.

Cheers,
simon

Stand Guix au Capitole du Libre à Toulouse, nov. 18-19

[Simon Tournier]

Salut,

La date du Capitole du Libre approche... Chouette !

L'organisation Capitole du Libre demande le nombre de personnes qui
aideront pour le stand (une histoire de sécurité et de badge).

Il serait aussi judicieux que l’on puisse avoir une idée entre nous pour
faciliter la journée ou les journées.

Qu’est-ce que cela signifie être au stand ?  Parler de Guix et de
logiciel libre.  Rien de formel et pas besoin d’être un expert. :-) Si
vous lisez cet email, cela signifie que vous êtes suffisamment intéressé
par Guix pour en discuter avec des gens qui ne connaissent pas du tout.

Par exemple, les créneaux qui me conviendraient – rien de fixe non plus
;-) – présence samedi matin pour l’installation jusqu’à 13h, vadrouille
jusqu’à 15h, puis 15h-19h.  J’aimerais arriver le dimanche vers 11h,
puis jusqu’au démontage.  Bref, voilà l’idée quoi. :-)

Vous pouvez m’envoyer un email en privé si vous préférez.  Et cela ne
vous engage pas de manière ferme non plus.

À très vite,
simon

Re: Turning off tests leads to a different store item

[Simon Tournier]

Hi,

On Wed, 8 Nov 2023 at 20:20, Saku Laesvuori  wrote:

> There is another way: simply preventing the tests from changing the
> resulting store item. For example, the package could first be built
> without tests and then that build tree could be copied to the build tree
> of the build with tests enabled.

Somehow, the store would need to keep all the build intermediary
artifacts produced, right?  For instance, consider the extreme case
where the build phase produces .o artifact files and the tests for
whatever reasons relies on these temporary artifacts.

Well, we had a quick chat with Josselin and Andreas about separating
the tests at https://hpc.guix.info/events/2023/workshop/program/
And my understanding of the rough conclusion we had: it is not easy
and the evil are in all the details.  For example autotools: somehow
"make check" is connected in one way or the other to "make" and/or
"make install".  Somehow, the complete build tree (with intermediary
artifacts as .o) should keep in the store.

>From a pragmatical point of view, there is packages where the tests
cannot be totally separated from from the temporary build, therefore
the question seems: how do these cases compare to the other regular
cases?  What is the ratio?  Is the rule about many corner cases
without a clear "regular"?  Or are they just few corner cases?

Cheers,
simon

Re: G-expressions and chroot environment? (was Re: branch master updated: gnu: Add passff.)

[Simon Tournier]

Hi,

On Fri, 03 Nov 2023 at 19:46, Simon Tournier  wrote:

> However, there is still something that I am missing.  The derivations
> tracks all and that’s expected; thanks G-expression machinery. :-)
> However, I miss how the builder works with the chrooted environment if
> nothing is passed to it.

Thanks to chat with civodul, now all is clear. :-)

The isolated environment is populated using the list provided by the
derivation.

Somehow, the G-expression machinery tracks all for helping in
constructing the derivation, then the inputs of that derivation are put
inside the isolated environment where the builder Guile script runs.

Cool!

Cheers,
simon

G-expressions and chroot environment? (was Re: branch master updated: gnu: Add passff.)

[Simon Tournier]

Hi,

On Sat, 28 Oct 2023 at 17:05, Clément Lassieur  wrote:

>>   ./pre-inst-env guix show passff-host
>>   name: passff-host
>>   version: 1.2.3
>>   outputs:
>>   + out: everything
>>   systems: x86_64-linux mips64el-linux aarch64-linux powerpc64le-linux 
>> riscv64-linux
>>   + i686-linux armhf-linux i586-gnu powerpc-linux
>>   dependencies: 
>
> I imagine it's a bug in `guix show`?

It is not a bug of ’guix show’ because ’guix show’ accesses to the
fields of the package record.  And Clément’s patch is an “abuse” of the
G-expressions machinery. :-)

>   As doc says:
>
>• Gexps carry information about the packages or derivations they
>  refer to, and these dependencies are automatically added as inputs
>  to the build processes that use them.

Well, this is correct from my understanding. ;-)

However, there is still something that I am missing.  The derivations
tracks all and that’s expected; thanks G-expression machinery. :-)
However, I miss how the builder works with the chrooted environment if
nothing is passed to it.

The derivation reads,

--8<---cut here---start->8---
Derive
([("out","/gnu/store/0amanwyzx3jylyw7bz5nmszpybxll8ww-passff-host-1.2.3","","")]
 ,[("/gnu/store/070vbkzbs0dn6w9mhz0xw8fi5hfp92rg-make-4.3.drv",["out"])
   ,("/gnu/store/2i4781y3mmnm2jlx3awa4mwbqam2ar80-python-3.10.7.drv",["out"])
   ,("/gnu/store/ax7wdlbxhcz7w8nfyrxkb1pqai80niw6-sed-4.8.drv",["out"])
   ,("/gnu/store/gb247cil5nlnx175dhqmgg67q7ng7n2h-which-2.21.drv",["out"])
   
,("/gnu/store/ghwl0z5ci5sssbrzixxji8l0x3j9i3dv-bash-minimal-5.1.16.drv",["out"])
   
,("/gnu/store/mqmnsly3nm0a7hj46apf2hfm7j8wk56h-module-import-compiled.drv",["out"])
   ,("/gnu/store/raay3plnbzadwqc0yv8yw8pjr929pkqd-coreutils-9.1.drv",["out"])
   
,("/gnu/store/rnphhzpwkz82zf1il1cg52041myvp3d4-password-store-1.7.4.drv",["out"])
   
,("/gnu/store/y6871hl8lklcslvw57wj4bnyysxlv2np-passff-host-1.2.3-checkout.drv",["out"])
   ,("/gnu/store/y9l0jnyxssx1glbyg3cav78js2fm7j50-grep-3.8.drv",["out"])
   ,("/gnu/store/zraigp7miin3vzr5dcbr4i9rvds0i07r-guile-3.0.9.drv",["out"])]
 
,["/gnu/store/8nam67byqnpvbfn4anpgg5pb2qrqhs3v-passff-host-1.2.3-builder","/gnu/store/pj751v3199vmv6i6sf0szp185ryzcfdg-module-import"]
 
,"x86_64-linux","/gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile",["--no-auto-compile","-L","/gnu/store/pj751v3199vmv6i6sf0szp185ryzcfdg-module-import","-C","/gnu/store/2gbsk55kwag577skxwsxrfy3l4cl03xh-module-import-compiled","/gnu/store/8nam67byqnpvbfn4anpgg5pb2qrqhs3v-passff-host-1.2.3-builder"]
 ,[("out","/gnu/store/0amanwyzx3jylyw7bz5nmszpybxll8ww-passff-host-1.2.3")])
--8<---cut here---end--->8---

However the builder reads,

--8<---cut here---start->8---
(begin
  (define %build-inputs
(quote
 (("source" . 
"/gnu/store/fjnkcv14qb61623lm16kq1mgb4bsxivl-passff-host-1.2.3-checkout"
  (define %outputs
(list
 (cons "out"
   ((@
 (guile)
 getenv)
"out"
  (define %output
(assoc-ref %outputs "out"))
  (begin
(use-modules
 (guix build utils))
(setenv "PATH"
(string-join
 (list 
"/gnu/store/yr39rh6wihd1wv6gzf7w4w687dwzf3vb-coreutils-9.1/bin" 
"/gnu/store/ixr7c3jadiqg640b8pz3njqhhm5zzmvj-grep-3.8/bin" 
"/gnu/store/sj794a2709pxsi4mgvi619qdpi1g32aa-password-store-1.7.4/bin" 
"/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/bin" 
"/gnu/store/fyy3wkjkix16sb1ginqw2kbji74cwl2b-sed-4.8/bin" 
"/gnu/store/6vxk0i5j9w8mik4l6gx3cbw33f9x4l24-which-2.21/bin")
 ":"))
(copy-recursively 
"/gnu/store/fjnkcv14qb61623lm16kq1mgb4bsxivl-passff-host-1.2.3-checkout" ".")
(substitute* "src/install_host_app.sh"
  (("#!/usr/bin/env sh")
   "/gnu/store/9vw5slrffp27rzy2i2plnw7xfqjyk7m4-bash-minimal-5.1.16/bin/sh")
  (("(TARGET_DIR_FIREFOX=).*" all var)
   (string-append var
  ((@
(guile)
getenv)
   "out")
  "/lib/icecat/native-messaging-hosts")))
(invoke "/gnu/store/vq4g8390wbz2434m678v010mkpnkjb2w-make-4.3/bin/make"
(string-append "VERSION=" "1.2.3")
"install-unix")))
--8<---cut here---end--->8---

and I would have expect that it fails because of the isolated
environment.

How is it possible that the builder script is able to run that?

For another example using the gnu-build system.

--8<---cut here---start->8---
(define-module (appendix)
  #:use-module (guix packages)
  #:use-module (gnu packages base)
  #:use-module (guix utils)
  #:use-module (guix gexp)
  #:use-module (gnu packages emacs))

(define-public bye
  (package
(inherit hello)
(name "bye")
(arguments
 (list
  #:phases
  #~(modify-phases %standard-phases
  

$EDITOR and “guix edit”

[Simon Tournier]

Hi,

The command “guix edit” returns “+N path/to/file” that is then passed to
$EDITOR.  Therefore $EDITOR needs the command line:

$ $EDITOR +N /path/to/file

Well, that is accepted by many $EDITOR, to my knowledge.  At least,
Emacs, Vi or less are fine with it.

However, some other $EDITOR does not.  I have in mind “kate” or
“VSCode“,

$ kate -l N path/to/file
$ code --goto path/to/file:N

This had been raised in #44272 [1].  The current fix is to wrap $EDITOR
and then make the current correct call.

The question is:

  do we tweak “guix edit” for behaving differently depending on $EDITOR?

or

  do we provide some wrappers for the issues that already popped up?

WDYT?

Cheers,
simon

1: https://issues.guix.gnu.org/44272

Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi,

This is a proposal for implementing Request-For-Comment process.
Comment are welcome in #66844 [1]:

1: https://issues.guix.gnu.org/issue/66844


The proposal is highly inspired by Rust RFC:

https://github.com/rust-lang/rfcs

and also by GHC Haskell proposal process [1] and Nix RFC process [2].  Based
on my understanding of Guix community interactions, I write down this
text; below the text for easing the reading.

Cheers,
simon

1: https://github.com/ghc-proposals/ghc-proposals
2: https://github.com/NixOS/rfcs

--

RFC process
===

# -*- mode:org -*-
#+TITLE: Request-For-Comment process
#+DATE: 2023-10-31

+ Issue: 66844
+ Status: pending
+ Supporter: Simon Tournier
+ Co-supporters:

* Summary

The "RFC" (request for comments) process is intended to provide a consistent
and controlled path for new features to enter the Guix project, so that all
stakeholders can be confident about the direction it is evolving in.

* Motivation

The freewheeling way that we add new features to Guix has been good for early
development, but for Guix to become a broadly used system we need to develop
some more self-discipline when it comes to changing our beloved system.  This
is a proposal for a more principled RFC process to make it a more integral
part of the overall development process, and one that is followed consistently
to introduce substancial features.

There are a number of changes that are significant enough that they could
benefit from wider community consensus before being introduced.  Either
because they introduce new concepts, big changes or are controversial enough
that not everybody will agree on the direction to take.

Therefore, the purpose of this RFC is to introduce a process that allows to
bring the discussion upfront and strengthen decisions.  This RFC is used to
bootstrap the process and further RFCs can be used to refine the process.

Note that this process does not cover most of the changes.  It covers
significant changes, for some examples:

 + change of inputs style
   (Removing input labels from package definitions, #49169)
 + introduction of =guix shell= and deprecation of =guix environment=
   (Add 'guix shell' to subsume 'guix environment', #50960)
 + introduction of authentication mechanism (Trustable "guix pull", #22883)
 + massive Python 2 removal
   (Merging the purge-python2-packages branch, mailing list guix-devel)
 + collaboration via team and branch-features
   (several places mailing list guix-devel)

* Detail design

** When you need to follow this process

This process is followed when one intends to make "substantial" changes to the
Guix project.  What constitutes a "substantial" change is evolving based on
community norms, but may include the following.

  + Any change that modifies Guix API
  + Big restructuring of packages
  + Introduction or removal of subcommands

Certain changes do not require an RFC:

  - Adding, updating packages, removing outdated packages
  - Fixing security updates and bugs that don't break interfaces

A patch submission to Debbugs that contains any of the afore-mentioned
substantial changes may be asked to first submit a RFC.

** How the process works

  1. Clone https://git.savannah.gnu.org/git/guix.git
  2. Copy rfc/-template.org to rfc/00XY-good-name.org where good-name is
 descriptive but not too long and XY increments
  3. Fill RFC
  4. Submit to guix-patc...@gnu.org

Make sure the proposal is as well-written as you would expect the final
version of it to be.  It does not mean that all the subtilities must be
considered at this point since that is the aim of review discussion.  It means
that the RFC process is not a prospective brainstorming and the proposal
formalize an idea for making it happen.

The submission of a proposal does not require an implementation.  However, to
improve the chance of a successful RFC, it might be recommended to have an
idea for implementing it.  If an implementation is attached to the detailed
design, it might help the discussion.

At this point, at least one other person must volunteer to be "co-supporter".
The aim is to improve the chances that the RFC is both desired and likely to
be implemented.

Once supporter and co-supporter(s) are committed in the RFC process, the
review discussion starts.  Advertisement of the RFC on the mailing-lists
guix-devel is mandatory and IRC is recommended.

After a number of rounds of review, the discussion should settle and a general
consensus should emerge.  If the RFC is successful then authors may contribute
to the implementation.  This bit is left intentionally vague and should be
refined in the future.

A successful RFC is not a rubber stamp, and in particular still does not mean
the feature will ultimately be merged; it does mean that in principle all the
major stakeholders have agreed to the feature and are amenable to merging it.

An unsuccessful RFC is *not* a judgment on the value of the work, s

Re: doc: Mention the responsibilities that blocking comes with.

[Simon Tournier]

Hi,

On sam., 14 oct. 2023 at 11:44, Maxim Cournoyer  
wrote:

> I thought I'd advertise this proposed change here:
>  that touches to our common rules, so
> that everyone gets to see it/comment on it.

Here is the change:

--8<---cut here---start->8---
+@url{https://www.seedsforchange.org.uk/consensus}.  It is expected from
+all contributors, and even more so from committers, to help build
+consensus and make decisions based on consensus.  By using consensus, we
+are committed to finding solutions that everyone can live with.  It
+implies that no decision is made against significant concerns and these
+concerns are actively resolved with proposals that work for everyone.  A
+contributor (which may or may not have commit access) wishing to block a
+proposal bears a special responsibility for finding alternatives,
+proposing ideas/code or explain the rationale for the status quo to
+resolve the deadlock.  To learn what consensus decision making means and
+understand its finer details, you are encouraged to read
+.
--8<---cut here---end--->8---

No more comment?  Ready for pushing it?

Cheers,
simon

Re: Moment de convivialité Guix@Paris en octobre

[Simon Tournier]

salut Tanguy,

On Fri, 27 Oct 2023 at 09:04, Tanguy LE CARROUR  wrote:

> Merci à ceux qui ont bravé la pluie pour venir hier soir !
> Et merci à ceux qui ont supporté de nous voir manger et boire *via*
> la vidéo-conférence. 

Chouette soirée !  Merci Tanguy pour la logistique.  

> Vu que l'on a passé une bonne soirée, on va remettre ça ! À priori,
> le jeudi 1er décembre. La date sera confirmée sur ces listes une ou deux
> semaines avant.

Jeudi 7 décembre, c’est noté.

À tantôt,
simon

Re: guix shell init

[Simon Tournier]

Hi,

On Wed, 25 Oct 2023 at 04:29, "jgart"  wrote:
> nix flakes also allows you to create your own custom template for use with 
> `nix flakes init`:
>
> https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake-init#template-definitions
>
> We could do the same with `guix shell init` maybe...

Could you explain what “Nix flake” means using Guix terminology?

Cheers,
simon

Re: guix shell init

[Simon Tournier]

Hi,

On Wed, 25 Oct 2023 at 04:24, "jgart"  wrote:

> It would generate this boilerplate somehow:
>
> https://guix.gnu.org/en/blog/tags/cookbook/sk/html_node/Getting-Started.html

Could you be precise about the boilerplate?  You would like that “guix
shell --init” would generate a template for some “guix.scm” file, right?

Cheers,
simon

Re: guix shell init

[Simon Tournier]

Hi,

On Wed, 25 Oct 2023 at 02:24, "jgart"  wrote:

> What if we had a command like `guix shell init`.
>
> It would create a basic manifest.scm or guix.scm file for the user.

Is

guix shell --export-manifest

not already doing that?  And “guix package --export-channels” is
similar for the channels.scm file.

Well, we could have a command somewhere for exporting both.  Maybe.

Following the idea, you would like:

guix shell --init=python

that generates some guix.scm and channels.scm file where the guix.scm
would be a template for building Python some project.

Right?

Cheers,
simon

Meet Guix at Capitole du Libre in Toulouse, nov. 18-19

[Simon Tournier]

Hi,

Some of us will be in Toulouse, INP-N7, 26 rue Riquet on 18 & 19
november for Capitole du Libre:

https://capitoledulibre.org/

We will stand in Village Associatif.  Let us know if you can help us
at the event.  Well, I do not know exactly what means "a stand" since
it will be the first for me. :-)  I guess it mainly consists to be
around the Guix booth, chat with people about why Guix is awesome! and
maybe demo some Guix features.

Feel free to share your ideas. :-)

Concretely, if you are planning to come, let synchronize and share the
fun.  Andreas and I will be there.  Who is in?  Do not be shy and drop
an email; off-list possibly.

If you are there, please stop at the wonderful Guix kakemono and say hi.

Hope to see you soon.

Cheers,
simon

PS: The event is in French-speaking.