Re: Capitole du Libre at Toulouse

[bokr]

Hi Andreas, Vagrant, et al

On +2022-09-25 10:37:52 -0700, Vagrant Cascadian wrote:
> On 2022-09-25, Andreas Enge wrote:
> > I am not quite sure how one presents a distribution at a booth, since
> > there is not really much to attract the eye, or is there?
> 
> I know Debian used to have an automated debian-installer running on a
> screen looping through all the supported languages of the installer.
> Would be cool to implement something similar for Guix someday, but
> probably not in a few weeks...
> 
> Maybe just a screen capture with large fonts of someone doing some guixy
> things and play it on a loop?
> 
> 
> live well,
>   vagrant

There is a nice guix web entry point at [0]
[0] https://guix.gnu.org/

┌───┐
│ NB: If your camera doesn't recognize the qr code, try │
│ reversing the video so the pattern is black on white. │
└───┘

Anyway I thought I'd grab the good words there and suggest
making a poster for a booth wall, like

--8<---cut here---start->8---
█
█
 ▄ █▄ █▄ ▀ ███ ▄ 
 █   █ █▄ ▄ ▄ ▀▀██ █   █ 
 █▄▄▄█ █▀█ █▀ ██ █ █▄▄▄█ 
▄▄▄█▄█ █ █▄█ █▄▄▄
 ▀ █▀▀▄▄█▀ ▄ ██ ▀▀▀ █▀▄▀ 
  █ █ ▄█ ▄▀███▀  ▀▄▀█ ▄█▄
▄██ ▀▄▄▄▀▀█▄ ▀▄▀ █  ███▀ 
▄▄▀█▀▄▄ █  ▀ █▀ ▀ █▀▀ ▄█▄
▄▄██▄▄▄█▀▀███ ▄▄ ▄▄▄ ██▄▀
 ▄ █▄▄█▄█▀█▀ █▄█ ██▀▄
 █   █ ██ ▀▄ ▄█▄  ▄▄ █▀▀▄
 █▄▄▄█ █▄██▀ ▄ █▀█▀  ▄█▄▄
▄▄▄█▄▄▄██▄▄██▄██▄
█
█

Liberating. Guix is an advanced distribution of the GNU
operating system developed by the GNU Project---which
respects the freedom of computer users.

Dependable. Guix supports transactional upgrades and
roll-backs, unprivileged package management, and more. When
used as a standalone distribution, Guix supports declarative
system configuration for transparent and reproducible
operating systems.

Hackable. It provides Guile Scheme APIs, including
high-level embedded domain-specific languages (EDSLs) to
define packages and whole-system configurations.

If you don't use GNU Guix as a standalone GNU/Linux
distribution, you still can use it as a package manager on
top of any GNU/Linux distribution. This way, you can benefit
from all its conveniences.

Guix won't interfere with the package manager that comes
with your distribution. They can live together. TRY IT OUT!
Blog Celebrating 10 years of Guix in Paris, 16--18
September

It's been ten years of GNU Guix ! To celebrate, and to
share knowledge and enthusiasm, a birthday event will take
place on September 16--18th, 2022 , in... 10 years of
stories behind Guix

It's been ten years today since the very first commit
to what was already called Guix---the unimaginative name
is a homage to Guile and Nix , which... Keeping
one's home tidy

How much effort to recreate your work environment when you
switch to a new machine? What would it take to roll back to
your previous environment once you've noticed... ALL
POSTS Contact IRC Channel

Join the #guix channel on the Libera Chat IRC network to
chat with the community about GNU Guix or to get help in
real-time. ... Info Mailing List

Subscribe to the info-guix low-traffic mailing list to
receive important announcements sent by the project
maintainers (in English). ... Help Mailing List

Subscribe to the Help mailing list to get support from the
GNU Guix community via email. You can post messages in
English though we also accept other languages ALL
CONTACT MEDIA Made with  <3 :-))  by humans and powered by GNU
Guile. Source code under the GNU AGPL.

--8<---cut here---end--->8---

and then trim the above down to just the qr code and
maybe the first three paragraphs of the above, and format it
to fit 2^N images on an A4 that could be cut into small handouts
and spread around at other booths that might have counter room
for a little stack or mini-poster.

Or business card size could be cool for scattering guix seeds :)

Of course, going by the guix booth with a smart-phone in hand,
all you need to do is point the camera at the qr code and save
a bookamrk.

I would have made a pdf, but pdflatex needs something to handle
utf8, so I'm way past the time I was going to spend on this :)

The text above is now ascii (after hacking some filters :)
but the qrcode is utf8.

I see contributing.texi has some utf8 characters:
--8<---cut here---start->8---
$ ord < doc/contributing.texi \
> | ord < doc/contributing.texi|tr ' ' $'\n' \
> | sort -n|uniq -c |pr -t -4; \
> 

Re: Emacs integration for 'guix shell'

[Maxim Cournoyer]

Hi,

Olivier Dion via "Development of GNU Guix and the GNU System
distribution."  writes:

[...]

> I have the following in my .dir-locals.el for my library libpatch.  The
> idea is the same, but without direnv:
>
> ((nil
>   . ((eval .
>   (let ((root (locate-dominating-file
>default-directory ".dir-locals.el")))
> (when root
>   (let ((real-root (directory-file-name (expand-file-name root
> (setq-local geiser-guile-binary (concat real-root 
> "/.geiser-guile"))
> (setq-local projectile-project-compilation-cmd
> (concat real-root "/.projectile-compile"))
> (setq-local projectile-project-test-cmd
> (concat real-root "/.projectile-test")
>

It seems to me it'd help everyone if Geiser should handle the above by
itself.  It'd be cool to have the above functionality merged into Geiser
itelf.  Just saying; thank you for sharing!

Maxim

Re: Follow Ten Years of Guix remotely

[Maxim Cournoyer]

Hello!

Ludovic Courtès  writes:

> Hello Guix!
>
> The Ten Years of Guix event will start in just a couple of days:
>
>   https://10years.guix.gnu.org
>
> If you’re not coming to Paris, we have some good news: talks will be
> recorded and the event will be live-streamed!
>
>   https://10years.guix.gnu.org/live/
>
> Many thanks to Nicolas Dandrimont and the Debian video team for making
> it possible, and to Leo Famulari and Luis Felipe for their hard work
> putting everything into place!

I could follow in the time window that was reasonable for my timezone,
and it was enjoyable to watch the talks with a great video/sound
quality!

Thanks to everyone involved!

Maxim

Re: Capitole du Libre at Toulouse

[zimoun]

Hi Andreas,

On Sun, 25 Sep 2022 at 11:30, Andreas Enge  wrote:

> Julien pointed out that the Capitole du Libre is going to take place
> in Toulouse on the weekend of November 19 and 20:
>https://capitoledulibre.org/
> and wondered whether we should ask for a booth. Time for this is running
> out, we have until tomorrow, Monday, evening...

I did a proposal for a talk.  If it is accepted, then I will be
there. :-)

Did you do a proposal for a booth or something else?


Cheers,
simon

Re: What happens when you build a Guix package at every step?

[jbranso]

September 25, 2022 3:18 PM, "david larsson"  
wrote:

> On 2022-09-25 19:28, jgart wrote:
> 
>> What would be the best way to illustrate the levels of nesting and code
>> paths that get traversed when building a Guix package?
>> I'd like to make some sequence diagram notation or something else to
>> better understand what happens in a visual way.
>> wdyt
> 
> I like your idea! I'm probably not the most qualified person to answer it, 
> since I am (also?)
> mainly using guix as a sparetime "hobby", but still very interested in 
> learning more about it on a
> deeper level, which is a challenge. Some visual aids would definitely be 
> helpful.
> 
> I think a shell of an answer would be to link together the following things 
> in such a diagram:
> 
> 1. gexps
> 2. the store
> 3. derivations
> 4. build systems
> 5. a package
> 
> Building a package in the repl, kind of illustrates the code paths via code 
> modules used:
> 
> scheme@(guix-user)> ,use (guix gexp)
> scheme@(guix-user)> ,use (guix store)
> scheme@(guix-user)> ,use (guix derivations)
> scheme@(guix-user)> ,use (gnu packages bash)
> 
> However, in my opinion, the reason we look for the diagram is partially bcs 
> of that the concepts of
> the related things are relatively high level so that it takes a while to 
> grasp them, just like
> monads or maybe higher order functions.
> 
> However, to continue the repl example:
> 
> scheme@(guix-user)> (define (sh-symlink)
> (gexp->derivation "sh"
> #~(symlink (string-append #$bash "/bin/bash")
> #$output)))
> scheme@(guix-user)> (build-derivations (open-connection) `(,(run-with-store 
> (open-connection)

I think you can also do a
,build derivation

This link has more info:

https://issues.guix.gnu.org/56114

> (sh-symlink
> $1 = #t
> 
> Now if you run just the (run-with-store (open-connection) (sh-symlink)) you 
> will see the derivation
> path output, and if you then open a new terminal you can cat
> /gnu/store/shcvi6d1vgry26sq1i3qdmgsmh0n6wmi-sh.drv to see the build script 
> without building it.
> 
> Now, to build a "package" after above code is loaded:
> scheme@(guix-user)> ,use (guix packages)
> scheme@(guix-user)> (build-derivations (open-connection) 
> `(,(package-derivation (open-connection)
> bash)))
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> fetching path `/gnu/store/vk4r0x7baig8jnmsqrgrqpyq8qxr4gm3-bash-5.0.16-doc'...
> Downloading 
> https://ci.guix.gnu.org/nar/lzip/vk4r0x7baig8jnmsqrgrqpyq8qxr4gm3-bash-5.0.16-doc...
> bash-5.0.16-doc 290KiB 750KiB/s 00:00 [##] 100.0%
> $2 = #t
> 
> And to only "inspect" it (so you can cat the /gnu/store/paths):
> scheme@(guix-user)> (package-derivation (open-connection) bash)
> $4 = # =>
> /gnu/store/vk4r0x7baig8jnmsqrgrqpyq8qxr4gm3-bash-5.0.16-doc
> /gnu/store/v1xc4405s7xilmwhhkdj8z55wa2wlr8y-bash-5.0.16-include
> /gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16 7fc3d283e500>
> 
> Concepts:
> - code staging or "delayed evaluation" concepts
> - what is the store and what is a build environment
> - what is a derivation
> - and finally build systems (normal build steps) and a package (incl. 
> dependency graphs).
> 
> The start reference point: 
> https://guix.gnu.org/manual/en/html_node/Defining-Packages.html
> 
> I hope above helps.
> 
> Best regards,
> David

Re: git guix checkout automation for contributors

[Josselin Poiret]

Hello everyone,

zimoun  writes:

> Hi,
>
> On dim., 25 sept. 2022 at 21:40, kiasoc5  wrote:
>> Isn't there a checkout cache in ~/.cache/guix? Can guix edit be pointed
>> to the git repo in the cache as opposed to the system's?
>
> This checkout* is used by “guix time-machine” and it does not always
> point to what “guix describe” returns.  Modulo this minor warning
> (easily fixable by moving HEAD to the correct commit), it appears to me
> a good idea to rely on it for easing some contributions.

It would be a good idea to reuse the cache, however I don't think that
edits should be made directly there.  Maybe we could either suggest or
provide a command that would copy the git repository there to another
place.

> When running “guix time-machine” (inferiors), all the machinery
> “./bootstrap && ./configure --localstatevar=/var && make” is
> transparently done.  We discussed that at the 10 Years event with
> Josselin.

Yes!  Although FTR none of bootstrap, configure or make are actually run
when using time-machine, it's a totally different way of building :).
The upshot is that we could even provide a flag like `guix time-machine
--issue=N` that would provide the corresponding guix branch at
https://git.guix-patches.cbaines.net/guix-patches/, and benefit from the
built substitutes if there are.  It would need some more formal URL and
discussion around this feature, but everything's in place for it to
happen.

> Therefore, we could imagine something similar for helping people to
> contribute:
>
>  1. use (test?) unmerged patches
>  2. update and/or create new patches

I think the second part would need a bit of work though, refer to Chris'
mail [1] for what would need to be done (namely, making `git send-email`
easier and refactoring the contribution guidelines).

[1] 87a66wfzeh@cbaines.net
https://yhetil.org/guix-devel/87a66wfzeh@cbaines.net

Best,
-- 
Josselin Poiret

Re: Emacs integration for 'guix shell'

[pinoaffe]

Hi!

This looks like a really nice script!

A while back, I wrote a bit of elisp that does some of the same stuff
that your program does, but which is aimed at a workflow based on profiles
rather than on `guix shell`, see [0].

I have previously used said script to set up directory-specific
paths/environment variables, but currently I only use it to globally
enable/disable certain profiles at runtime.

Back when I wrote it, I was planning on rewriting it and integrating it
into emacs-guix, but I never got around to it.  In general, it would be
nice to refactor it to use emacs-guix's `guix-repl' function rather than
manually running shell commands.

A caveat of my script: it sets the `load-path` variable, which is useful
at times but greatly increases the foot-shoot-ability.

Kind regards,
pinoaffe

[0] 
https://git.pixie.town/pinoaffe/emacs-config/src/branch/master/lisp/guix-profile-manager.el

"Thompson, David"  writes:

> Hello all,
>
> I recently wrote a little blog post titled "Guix for development" [0]
> and in it I mentioned using a tool called direnv and emacs-direnv as a
> way to integrate 'guix shell' with Emacs. This integration has vastly
> improved my Emacs experience. I can open a shell buffer and the
> environment variables are automatically configured the way I want. I
> can run M-x compile and simply enter 'make' as the command instead of
> 'guix shell -D -f guix.scm -- make'.
>
> It's very cool that it works, and I should have done this years ago,
> but direnv is an unnecessary middleman for me because I don't use it
> for any other purpose.  It would be *even cooler* if Emacs could call
> 'guix shell --search-paths' directly, parse the result, and update the
> buffer environment.  Furthemore, it could integrate with project.el
> (thus requiring Emacs 28) so that per-project search paths "just
> work." The emacs-guix-shell [1] project attempts to do this.
>
> I'm not an experienced elisp programmer so I'm sure there's stuff to
> fix, and there are no customizable variables yet, but the essentials
> seem to work OK for me.  If you'd like to try it out, eval
> guix-shell.el and then M-x guix-shell-global-mode to enable it
> everywhere, or M-x guix-shell-mode to enable it just for the current
> buffer.
>
> Whether through direnv or guix-shell.el, integrating Emacs with 'guix
> shell' has been a game changer for my development workflow and I
> highly recommend it!
>
> That's all for now,
>
> - Dave
>
> [0] https://dthompson.us/guix-for-development.html
> [1] https://git.dthompson.us/emacs-guix-shell.git/

Re: Emacs integration for 'guix shell'

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

On Mon, 26 Sep 2022, "Thompson, David"  wrote:
> Hello all,
>
> I recently wrote a little blog post titled "Guix for development" [0]
> and in it I mentioned using a tool called direnv and emacs-direnv as a
> way to integrate 'guix shell' with Emacs. This integration has vastly
> improved my Emacs experience. I can open a shell buffer and the
> environment variables are automatically configured the way I want. I
> can run M-x compile and simply enter 'make' as the command instead of
> 'guix shell -D -f guix.scm -- make'.
>
> It's very cool that it works, and I should have done this years ago,
> but direnv is an unnecessary middleman for me because I don't use it
> for any other purpose.  It would be *even cooler* if Emacs could call
> 'guix shell --search-paths' directly, parse the result, and update the
> buffer environment.  Furthemore, it could integrate with project.el
> (thus requiring Emacs 28) so that per-project search paths "just
> work." The emacs-guix-shell [1] project attempts to do this.

Interesting I'll have a look at it!

> I'm not an experienced elisp programmer so I'm sure there's stuff to
> fix, and there are no customizable variables yet, but the essentials
> seem to work OK for me.  If you'd like to try it out, eval
> guix-shell.el and then M-x guix-shell-global-mode to enable it
> everywhere, or M-x guix-shell-mode to enable it just for the current
> buffer.

I have the following in my .dir-locals.el for my library libpatch.  The
idea is the same, but without direnv:
--8<---cut here---start->8---
((nil
  . ((eval .
  (let ((root (locate-dominating-file
   default-directory ".dir-locals.el")))
(when root
  (let ((real-root (directory-file-name (expand-file-name root
(setq-local geiser-guile-binary (concat real-root "/.geiser-guile"))
(setq-local projectile-project-compilation-cmd
(concat real-root "/.projectile-compile"))
(setq-local projectile-project-test-cmd
(concat real-root "/.projectile-test")
--8<---cut here---end--->8---

.projectile-compile:
--8<---cut here---start->8---
#!/bin/sh
./dev-env make -j $(nproc)
--8<---cut here---end--->8---

.projectile-test:
--8<---cut here---start->8---
#!/bin/sh
./dev-env make -j $(nproc) check-nocolor
--8<---cut here---end--->8---

.geiser-guile:
--8<---cut here---start->8---
#!/bin/sh
here=$(pwd)
./dev-env guile -L "$here" -x "$here" $@
--8<---cut here---end--->8---

dev-env:
--8<---cut here---start->8---
#!/bin/sh
guix shell\
 --pure   \
 dyninst  \
 gdb  \
 git  \
 guix \
 lcov \
 guile-quickcheck \
 perf \
 lttng-ust\
 lttng-tools  \
 --development libpatch   \
 -- $@
--8<---cut here---end--->8---

Note the latest script where I have development packages for libpatch,
but also other utitilies that are good to have for developer.

Regards,
old

-- 
Olivier Dion
oldiob.dev

Re: Proposal: A new build-system API

[Mája Tomášek]

zimoun  writes:

Hi,

Thanks for your reply, I appreciate you taking time to respond to my
silly message <3.

> Hi,
>
> Thanks for your comments.
>
> On lun., 26 sept. 2022 at 10:39, Mája Tomášek  
> wrote:
>
>> (package
>> ...
>> (inputs list-of-inputs)
>> (build-system some-build-system)
>> (arguments (list-of-quoted #:key value))
>> ...
>> )
>
> [...]
>
>> (package
>> ...
>> (inputs list-of-inputs)
>> (build-system
>> (some-build-system
>> (phases new-list-of-phases)
>> (strip-binaries? #f)))
>> ...
>> )
>
> Hum, from the surface, your proposal is to just move the arguments.
> Currently, ’arguments’ are related to ’build-system’ – therefore, I do
> not the difference between your proposal and the current situation.

The main point was to define a more ergonomic and sanitized way to
configure the build system. For example, there's currently no guarantee
that #:phases will contain list of functions and the error from that
will be cryptic. Contrast that with the service-configuration API. There
are field sanitizers that ensure that the configuration is propper and
easily one can introspect what the build system accepts and what are the
defaults.

>
> However, this…
>
>> (define-build-system some-build-system
>>  (inherit gnu-build-system)
>>  (name 'some)
>>  (description "Some build system")
>>  (phases %standard-phases)
>>  (strip-binaries? #t)
>>  ...
>>  (builder (thunked)
>>   (build-system->builder this-build-system))
>> )
>>
>> The build-system->builder method would generate the build, with
>> arguments properly adjusted, records translated into keyword arguments,
>> for a standard build system, the alternative,
>> would be to provide a (lambda (build-system)
>> some-code-that-returns-derivation).
>>
>> The current system is good, but when you need to write your own build
>> system, you needlessly need to write thins like ungexping arguments,
>> running gexp->derivation, which is really the system by which the guix
>> daemon operates, but which could really be abstracted away from the
>> build system developer. The code writing for a complete build system is 
>> repetetive
>> and complicated.
>
> …is something different.  Yeah, maybe some glue helpers could ease the
> creation of new build-system.  Nevertheless, please note that a
> build-system somehow needs some plumbing and I am not convinced that
> it would be doable to define a new build-system without diving in some
> G-exp here or there.
>
> I agree that the composition of existing bricks is not always
> straightforward and it could be improved, eventually. :-)

I understand that some gexps are nescessary, and I really do love gexps
:D. Yet my point was mostly on that as a build system developer, I need
to concern myself with store-monad and derivations, even though I am
more concerned with the package build steps.

Best regards,
Maya

Emacs integration for 'guix shell'

[Thompson, David]

Hello all,

I recently wrote a little blog post titled "Guix for development" [0]
and in it I mentioned using a tool called direnv and emacs-direnv as a
way to integrate 'guix shell' with Emacs. This integration has vastly
improved my Emacs experience. I can open a shell buffer and the
environment variables are automatically configured the way I want. I
can run M-x compile and simply enter 'make' as the command instead of
'guix shell -D -f guix.scm -- make'.

It's very cool that it works, and I should have done this years ago,
but direnv is an unnecessary middleman for me because I don't use it
for any other purpose.  It would be *even cooler* if Emacs could call
'guix shell --search-paths' directly, parse the result, and update the
buffer environment.  Furthemore, it could integrate with project.el
(thus requiring Emacs 28) so that per-project search paths "just
work." The emacs-guix-shell [1] project attempts to do this.

I'm not an experienced elisp programmer so I'm sure there's stuff to
fix, and there are no customizable variables yet, but the essentials
seem to work OK for me.  If you'd like to try it out, eval
guix-shell.el and then M-x guix-shell-global-mode to enable it
everywhere, or M-x guix-shell-mode to enable it just for the current
buffer.

Whether through direnv or guix-shell.el, integrating Emacs with 'guix
shell' has been a game changer for my development workflow and I
highly recommend it!

That's all for now,

- Dave

[0] https://dthompson.us/guix-for-development.html
[1] https://git.dthompson.us/emacs-guix-shell.git/

Re: git guix checkout automation for contributors

[zimoun]

Hi,

On dim., 25 sept. 2022 at 21:40, kiasoc5  wrote:
> Isn't there a checkout cache in ~/.cache/guix? Can guix edit be pointed
> to the git repo in the cache as opposed to the system's?

This checkout* is used by “guix time-machine” and it does not always
point to what “guix describe” returns.  Modulo this minor warning
(easily fixable by moving HEAD to the correct commit), it appears to me
a good idea to rely on it for easing some contributions.

*checkout:
~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/


For instance,

--8<---cut here---start->8---
$ guix describe
Generation 9août 31 2022 14:51:40   (current)
  guix 23152ff
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 23152ff70f0ed4966d8207846f54c793d7cb4f86

$ git -C 
/home/simon/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/
 log -1 --oneline
2e8b4f9bfa (HEAD -> master) installer: Exit console-services page with 
abort-to-prompt.

$ guix time-machine 
--url=file:///home/simon/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/
 -- describe
  guix 2e8b4f9
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 2e8b4f9bfa00489fd3acff305837a79af236e183
--8<---cut here---end--->8---

When running “guix time-machine” (inferiors), all the machinery
“./bootstrap && ./configure --localstatevar=/var && make” is
transparently done.  We discussed that at the 10 Years event with
Josselin.


Therefore, we could imagine something similar for helping people to
contribute:

 1. use (test?) unmerged patches
 2. update and/or create new patches


Cheers,
simon

Re: Proposal: A new build-system API

[zimoun]

Hi,

Thanks for your comments.

On lun., 26 sept. 2022 at 10:39, Mája Tomášek  wrote:

> (package
> ...
> (inputs list-of-inputs)
> (build-system some-build-system)
> (arguments (list-of-quoted #:key value))
> ...
> )

[...]

> (package
> ...
> (inputs list-of-inputs)
> (build-system
> (some-build-system
> (phases new-list-of-phases)
> (strip-binaries? #f)))
> ...
> )

Hum, from the surface, your proposal is to just move the arguments.
Currently, ’arguments’ are related to ’build-system’ – therefore, I do
not the difference between your proposal and the current situation.


However, this…

> (define-build-system some-build-system
>  (inherit gnu-build-system)
>  (name 'some)
>  (description "Some build system")
>  (phases %standard-phases)
>  (strip-binaries? #t)
>  ...
>  (builder (thunked)
>   (build-system->builder this-build-system))
> )
>
> The build-system->builder method would generate the build, with
> arguments properly adjusted, records translated into keyword arguments,
> for a standard build system, the alternative,
> would be to provide a (lambda (build-system)
> some-code-that-returns-derivation).
>
> The current system is good, but when you need to write your own build
> system, you needlessly need to write thins like ungexping arguments,
> running gexp->derivation, which is really the system by which the guix
> daemon operates, but which could really be abstracted away from the
> build system developer. The code writing for a complete build system is 
> repetetive
> and complicated.

…is something different.  Yeah, maybe some glue helpers could ease the
creation of new build-system.  Nevertheless, please note that a
build-system somehow needs some plumbing and I am not convinced that
it would be doable to define a new build-system without diving in some
G-exp here or there.

I agree that the composition of existing bricks is not always
straightforward and it could be improved, eventually. :-)


Cheers,
simon

Re: OCaml 5.0 and Guix

[zimoun]

Hi,

On lun., 26 sept. 2022 at 10:11, pukkamustard  wrote:

> A new major release of OCaml (5.0) is planned and I've started some work
> of packaging it in Guix:
>
> https://inqlab.net/git/guix.git/log/?h=wip-ocaml-5.0

Cool!


> Still very much WIP, but a way to give OCaml 5.0 with multicore support
> a try.

What is the status of OCaml bootstrapping for this new version?

Can we have a chain from camlboot -> OCaml 4.07 -> ?? -> v5.0?


Cheers,
simon

Re: What 'sh' should 'system' use?

[Maxime Devos]

On 26-09-2022 09:04, Philip McGrath wrote:

[...]
(Very occasionally, a program really does want to invoke the shell, such
as when shell expansion is part of an existing API.)

From a different perspective, this is part of why I've recently been
thinking we should find 'sh' dynamically: most programs/environments
don't, and shouldn't, need bash{-minimal,-static}, so it seems wrong to
make it a mandatory dependency of libc.


In another thread, I proposed replacing 'system' by a macro 'system' 
that looks for for a, say, GUIX_BIN_SH preprocessor definition and then 
calls _guix_system(GUIX_BIN_SH,...) or such, and remove the 'system' 
function.


That way, glibc does not use bash-whatever anymore, but we still avoid 
doing things dynamically, avoiding the problems that dynamic finding 
entails.


For packages that use 'system', we would need to then resolve the build 
resulting build failure by passing -DGUIX_BIN_SH (maybe we could have a 
libc-system-function package that overrides the header containing 
'system' and automatically sets GUIX_BIN_SH)?



See (1) (reproducibility) -- also, you would need to modify the daemon for 
that, so there are compatibility concerns, and then we're
 stuck with the /bin/sh special case forever (unless breaking compatibility 
would later be considered acceptable).



I don't think there's a reproducibility problem.


You are proposing 'weak references' -- weak references are automatically 
broken if the thing referred to is GC'ed (the weak reference is weak, so 
it doesn't count as a reference that keeps it from being GC'ed).


That means that the build process depends on whether bash-whatever is in 
the store or not.


Even if not, the compatibility concerns remain, and incompatible daemons 
sound like a form of irreproducibility to me.



Guix already can create
reproducible containers with "/bin/sh" (e.g. 'guix shell coreutils
--container -- ls /bin') and without "/bin/sh" (as in package build
environments).

I haven't investigated whether adding the ability to create "/bin/sh" in
build containers would require modifying the daemon or just sending the
daemon different instructions. However, AIUI, Nix *always* creates
"/bin/sh" in build containers, which makes me further expect that any
change needed to the daemon would be small.

>

To be clear, I'm not proposing that we always create "/bin/sh" in build
containers. At a low level, I'm suggesting that we add the ability to
create "/bin/sh" when desired. I can imagine one possibility for a
high-level interface would be to create "/bin/sh" by default when an
input provides "bin/sh", and it might turn out that we end up wanting
"/bin/sh" in most or all build containers in practice, but I see those
as secondary questions.


Again, I don't see how special-casing /bin/sh even further is desirable.


There are a few dimensions here that I want to try to pick apart.

When you say:


a plain "sh" looked up in the $PATH (like other binaries) and substitute*-ed by 
Guix should suffice >

there are a few different things that might mean. > I think you're probably referring to 
the status quo, where "sh" is
looked up in the 'inputs' or a G-expression equivalent and an absolute
reference to that particular "sh" is embedded into the package being
built. (But, when cross-compiling, that "sh" would not be in the $PATH
in the build environment.)


Yes -- to be clear, the looking up in $PATH is for upstream, in Guix it 
would be patched with the absolute reference to something in 'inputs' 
instead.



There's a different question about $PATH vs. _CS_PATH that I'll address
later.

I see at least two reasons to prefer finding "sh" dynamically at run-time.

First, we have other POSIX-like shells packaged in Guix, such as dash,
zsh, and gash. Currently, to create an environment where one of these
shells is used to run 'system'-like functions (e.g. because dash is
supposed to be faster than bash), you would have to recompile everything
that depends on glibc. (Maybe you could craft a very ugly graft.)


dash, zsh and gash are incompatible, so you can't simply replace things 
-- looking it up dynamically would potentially introduce bugs. 
Additionally, 'sh' might not exist in /bin/sh or $PATH, so possibly it 
couldn't be found dynamically, and possibly the version it finds is 
incompatible (reproducibility).


If dash is faster than bash and sufficiently compatible, you can propose to


Second, sometimes people may want to create environments, images, etc.
without an "sh" available.


You can do this without dynamic finding and its downsides, see e.g. the 
preprocessor thing mentioned in the beginning.



In some sense this is a special case of using
an alternate shell, but the consequences of the status quo are
especially notable. Currently, practically any environment or image Guix
creates will include bash-static, because glibc refers to it.

For an especially ironic example, consider this note from `info
"(guix)Invoking guix pack"`:

OCaml 5.0 and Guix

[pukkamustard]

Hello Guix,

A new major release of OCaml (5.0) is planned and I've started some work
of packaging it in Guix:

https://inqlab.net/git/guix.git/log/?h=wip-ocaml-5.0

This currently includes:

- The OCaml 5.0.0-alpha1 compiler
- A `package-with-ocaml5.0` transformation
- Some custom ocaml5.0 packages (mostly unreleased versions with fixes
  for OCaml 5.0)
- The eio effects based IO library (ocaml-eio): eio is designed around
  capability-based security and might be of interest to Scheme hackers
  who are following the work on projects such as Spritely.

Still very much WIP, but a way to give OCaml 5.0 with multicore support
a try.

Best regards,
pukkamustard

Re: What 'sh' should 'system' use?

[Liliana Marie Prikler]

Hi,

Am Montag, dem 26.09.2022 um 04:07 -0400 schrieb Philip McGrath:
> Hi,
> 
> On 9/19/22 03:07, Liliana Marie Prikler wrote:
> > Am Sonntag, dem 18.09.2022 um 20:13 -0400 schrieb Philip McGrath:
> > > On the other hand, even Nix puts '/bin/sh' at its usual path: we
> > > are really quite an outlier in this respect. (IIUC, Nix also has 
> > > '/usr/bin/env', but no other utilities at FHS paths.)
> > We are not.  We provide both /bin/sh and /usr/bin/env.  If you're 
> > talking about the build container then that's a much smaller 
> > distinction.
> > 
> 
> Yes, I'm talking about the build container. But for the build
> container, programs/libraries that use "/bin/sh" would work
> unmodified.
I think there's limited value in having them work unmodified; see
‘patch-source-shebangs’.

> > > More broadly, I now think it would be better in we embedded zero 
> > > references to copies of Bash in libc.
> > I don't think we can do that without breaking system.
> > 
> 
> When "/bin/sh" is not available at runtime, I think libc's `system`
> ought to return 127, and other `system`-like functions should raise
> exceptions or whatever the idiomatic way is to signal failure. Of
> course, we will presumably need to make "/bin/sh" available in many
> more places, but don't think it's surprising for programs that need
> to run shell commands to fail in the absence of a shell.
Au contraire, I'd argue that people who use system will be the most
surprised when it actually does fail.

> > > However, giving every program using Glibc a hard dependency on 
> > > Bash—and on a particular Bash executable—seems like a much bigger
> > > imposition.
> > We're talking 1.7 MiB here.  Certainly a "big" imposition, but
> > nothing in comparison to the things you need in the store for
> > bootstrapping purposes.  Also note that bash-minimal, while only
> > taking up 1.0 MiB for itself, requires both glibc and gcc:lib,
> > which apart from creating a cycle does blow up its closure size
> > quite a bit.
> > 
> 
> I'm less concerned with the literal size than with the significance
> of putting a specific shell so near the root of most dependency
> graphs: I tried to give examples in my reply to Maxime, like creating
> containers without a shell.
What is this significance?  From the examples you gave Maxime, I find
it insignificant.

> > > 
> > It is therefore permissible for the system() function on such a
> > system to implement the behavior specified by the ISO C standard as
> > long as it is understood that the implementation does not conform
> > to POSIX.1-2017 if system(NULL) returns zero.
> 
> I understand that to mean that `system(NULL)` returning zero
> indicates that the program is not (currently) running in a POSIX.1-
> 2017 environment.
This test is severely broken.  It fails to account for non-POSIX.1-2017
systems, that nevertheless return 1.

>From the GNU coding standards [1]:
> The GNU Project regards standards published by other organizations as
> suggestions, not orders. We consider those standards, but we do not
> “obey” them. In developing a GNU program, you should implement an
> outside standard’s specifications when that makes the GNU system
> better overall in an objective sense. When it doesn’t, you shouldn’t.
Here, conforming to POSIX makes sense: it improves portability at
little cost.

> Guix creates many environments that do not conform to POSIX.1-2017:
> for example, any environment without `vi`.
Here it doesn't.  The convenience of vi is highly debatable.

Cheers

Re: What 'sh' should 'system' use?

[Liliana Marie Prikler]

Hi

Am Montag, dem 26.09.2022 um 03:04 -0400 schrieb Philip McGrath:
> I definitely advocate 'system*'-like functions in general. Still,
> 'system'-like functions exist: I'm advocating that Guix should should
> have a consistent answer for how such functions should behave.
How is the current answer inconsistent?

> From a different perspective, this is part of why I've recently been
> thinking we should find 'sh' dynamically: most programs/environments
> don't, and shouldn't, need bash{-minimal,-static}, so it seems wrong
> to make it a mandatory dependency of libc.
Wrong in which sense?  Technically, morally, philosophically?  I don't
think any of the values upheld by the GNU project, such as the four
freedoms or the FSDG, nor our code of contract are violated by having
bash-static in libc.

> I think you're probably referring to the status quo, where "sh" is
> looked up in the 'inputs' or a G-expression equivalent and an
> absolute reference to that particular "sh" is embedded into the
> package being built. (But, when cross-compiling, that "sh" would not
> be in the$PATH in the build environment.)
You still get an implicit bash-minimal in native-inputs.  It's just not
a regular input.

> First, we have other POSIX-like shells packaged in Guix, such as
> dash, zsh, and gash. Currently, to create an environment where one of
> these shells is used to run 'system'-like functions (e.g. because
> dash is supposed to be faster than bash), you would have to recompile
> everything that depends on glibc. (Maybe you could craft a very ugly
> graft.)
The performance benefits of dash are irrelevant when you compare it to
fork and exec.  Thus I highly question the point you're trying to make.

> Second, sometimes people may want to create environments, images,
> etc. without an "sh" available. In some sense this is a special case
> of using an alternate shell, but the consequences of the status quo
> are especially notable. Currently, practically any environment or
> image Guix creates will include bash-static, because glibc refers to
> it.
And yet, this bash-static will only be inside the container; with even
its exact file name unknown and outside of PATH (and even _CS_PATH
while we're at it).  If your concern is that an attacker might break
your containerized application and do arbitrary code execution in bash
afterwards, I think you got your priorities mixed up; said attacker
could probably side-load a static bash anyway.  And I hardly doubt that
any concern not related to security is critical either.

> Programs in practice seem to look at "/bin/sh", and environments 
> configuring it by choosing what (possibly nothing) to put at
> "/bin/sh" from the perspective of programs in that environment.
I mean, both are valid solutions.  You're not going to put an
unreliable shell as /bin/sh or attempt to shadow sh in your $PATH. 
confstr and _CS_PATH are for paranoid people who believe you might (and
even if you do use it, how sure are you that you're not just getting
/bin/sh).

> > > I think we should document the decision (for example, why 
> > > 'bash-static' vs. 'bash- minimal'?)
> > 
> > Because cycles -- bash-minimal is linked to a (shared) glibc, which
> > is a separate package from bash-minimal, so glibc cannot use 
> > bash-minimal, it uses bash-static instead which is linked to a 
> > (static) glibc (which might use a bootstrap bash (not 100% sure),
> > but it's statically linked, so no reference to the bootstrap bash
> > remains IIUC).
> > 
> > Also, why?  This is an implementation detail.  Who would the target
> > audience be for this documentation?
> > 
> 
> I don't mean "document the decision" to necessarily imply something 
> elaborate or formal, but I think the next person packaging a language
> with a function like 'system' in its standard library shouldn't have
> to reevaluate these questions from scratch. Also, if we decided the
> right thing were to advocate for upstreams to do something
> differently for the sake of portability (e.g. trying to get people to
> use _CS_PATH---which I'm not suggesting), it would help to have a
> rationale to point to.
> 
> Specifically with respect to bash-minimal vs. bash-static, I'm still
> not clear on when I should use which. 
You're not going to need bash-static.  For most intents and purposes,
you can ignore its existence.  In fact, if it bothers you that much, I
suggest hiding it like gcc.

> The package descriptions are identical, and I haven't found a clear
> (to me, at least) explanation in the source code comments. For
> example, if bash-static is needed to avoid a cycle as you say, what
> is the benefit of also having bash-minimal?
bash-minimal is to be used in shell wrappers, as they don't need a
full-blown bash (with among others the ability to load extensions,
which bash-minimal lacks).  Unlike bash-static, bash-minimal can be
grafted (both itself and its dependents), so fixing a safety-critical
bug in any of those does not cause a world rebuild.

Fwd: git guix checkout automation for contributors

[Nathan Dehnel]

-- Forwarded message -
From: Nathan Dehnel 
Date: Mon, Sep 26, 2022 at 3:52 AM
Subject: git guix checkout automation for contributors
To: 


It would be cool if you provided "guix edit " with the path
to an empty directory and it automatically created a local channel in
that directory and copied the package to it and then opened that up in
your editor. (Maybe channels.scm could specify the location for your
default "guix edit" channel so you don't have to specify it every
time.)

Proposal: A new build-system API

[Mája Tomášek]

Hello guix,

I have been lately trying to write a build system or two. And I have
found myself in a weird situation. The current API documentation is
lackluster and the API itself isn't really ergonomic.

First, I need to clarify that I understand that there is a lack of
documentation, it is completely acceptable, but as I didn't really get
the build system API, it was hard for me to grasp the intrices.

Second, I appologize if I am touching on a conversation that already
happened before, but I couldn't find it in the guix devel mailing list,
as there were too many hits when I searched.

Third, this API change would cause breakage of the old, so it isn't
without a compromise, I think it could be done with a deprecation, but
it would be, in my opinion, difficult.

Currently the package and build system APIs don't mesh together well.

(package
...
(inputs list-of-inputs)
(build-system some-build-system)
(arguments (list-of-quoted #:key value))
...
)

What would I propose? To design the build system API similiarly as the
package API. With records.

For a simple package, almost nothing would change:

(package
...
(inputs list-of-inputs)
(build-system (some-build-system))
...
)

But for a more complex package:

(package
...
(inputs list-of-inputs)
(build-system
(some-build-system
(phases new-list-of-phases)
(strip-binaries? #f)))
...
)

This would be the user-facing API, as for the build system developer
API for a simple build system:

(define-build-system some-build-system
 (inherit gnu-build-system)
 (name 'some)
 (description "Some build system")
 (phases %standard-phases)
 (strip-binaries? #t)
 ...
 (builder (thunked)
  (build-system->builder this-build-system))
)

The build-system->builder method would generate the build, with
arguments properly adjusted, records translated into keyword arguments,
for a standard build system, the alternative,
would be to provide a (lambda (build-system)
some-code-that-returns-derivation).

The current system is good, but when you need to write your own build
system, you needlessly need to write thins like ungexping arguments,
running gexp->derivation, which is really the system by which the guix
daemon operates, but which could really be abstracted away from the
build system developer. The code writing for a complete build system is 
repetetive
and complicated.

I don't know, if I have missed some things, this could be a really bad
proposal, and if it is, feel free to ignore it. I have tried to come up
with something new, and I am not the most profficient with either guix
or guile. This was my shot at trying to be helpful in something bigger
than updating packages or fixing small service bugs.

With wishes of the best of luck,
Maya

PS. I appologize for spelling errors.

Re: GNU Guix on iPad2 (A1395)

[Jacob Hrbek]

It seems to be guix specific as the usbmuxd seems to work fine on other 
distros, but has issues on NixOS and Guix thus why asking here

-- Jacob "Kreyren" Hrbek

Sent with Proton Mail secure email.

--- Original Message ---
On Sunday, September 25th, 2022 at 11:11 PM, Csepp  wrote:


> Jacob Hrbek krey...@rixotstudio.cz writes:
> 
> > Context: I have this iPad 2 that I got as a gift from a friend who was 
> > upgrading on the newer version to try
> > to get me to like Apple. I hate it and it was in my storage unused for many 
> > years so now I am trying to get
> > GNU Guix on it with GNOME.
> > 
> > To achieve this I merged the required packages in guix 
> > (https://issues.guix.gnu.org/57902 and
> > https://issues.guix.gnu.org/57871) and thanks to the jailbreaking community 
> > i can use Checkm8 exploit
> > (https://github.com/axi0mX/ipwndfu) to get full write access to the device 
> > and unlock the bootloader to
> > boot unsigned OS and linux-libre seems to have all required drivers to run 
> > on the device, see the current
> > progress in https://git.dotya.ml/kreyren/kreyren/issues/30
> > 
> > The issue is that i can't get libusbmuxd (the daemon used to communicate 
> > with iDevices from Linux) to
> > work on GNU Guix likely due to a configuration error in guix to perform the 
> > exploit and install guix, can
> > someone help? 
> > https://github.com/libimobiledevice/ideviceinstaller/issues/147
> > 
> > Any relevant info on how to get iPad 2 or other iDevices to work with GNU 
> > Guix also appreciated.
> > 
> > -- Jacob "Kreyren" Hrbek
> 
> 
> Not a real answer, but have you tried contacting projects like
> postmarketOS? They have much more experience with this sort of thing
> and might be able to help with configuration issues.

Re: What 'sh' should 'system' use?

[Philip McGrath]

Hi,

On 9/19/22 03:07, Liliana Marie Prikler wrote:

Am Sonntag, dem 18.09.2022 um 20:13 -0400 schrieb Philip McGrath:

On the other hand, even Nix puts '/bin/sh' at its usual path: we
are really quite an outlier in this respect. (IIUC, Nix also has 
'/usr/bin/env', but no other utilities at FHS paths.)
We are not.  We provide both /bin/sh and /usr/bin/env.  If you're 
talking about the build container then that's a much smaller 
distinction.




Yes, I'm talking about the build container. But for the build container,
programs/libraries that use "/bin/sh" would work unmodified.

More broadly, I now think it would be better in we embedded zero 
references to copies of Bash in libc.

I don't think we can do that without breaking system.



When "/bin/sh" is not available at runtime, I think libc's `system`
ought to return 127, and other `system`-like functions should raise
exceptions or whatever the idiomatic way is to signal failure. Of
course, we will presumably need to make "/bin/sh" available in many more
places, but don't think it's surprising for programs that need to run
shell commands to fail in the absence of a shell.

However, giving every program using Glibc a hard dependency on 
Bash—and on a particular Bash executable—seems like a much bigger 
imposition.

We're talking 1.7 MiB here.  Certainly a "big" imposition, but
nothing in comparison to the things you need in the store for
bootstrapping purposes.  Also note that bash-minimal, while only
taking up 1.0 MiB for itself, requires both glibc and gcc:lib, which
apart from creating a cycle does blow up its closure size quite a
bit.



I'm less concerned with the literal size than with the significance of
putting a specific shell so near the root of most dependency graphs: I
tried to give examples in my reply to Maxime, like creating containers
without a shell.


In versions of glibc before 2.1.3, [...] system() always returned
1 [...].

Note that always returning non-zero is required by POSIX 2017.



To quote the whole paragraph from
:


Note that, system(NULL) is required to return non-zero, indicating
that there is a command language interpreter. At first glance, this
would seem to conflict with the ISO C standard which allows
system(NULL) to return zero. There is no conflict, however. A system
must have a command language interpreter, and is non-conforming if
none is present. It is therefore permissible for the system()
function on such a system to implement the behavior specified by the
ISO C standard as long as it is understood that the implementation
does not conform to POSIX.1-2017 if system(NULL) returns zero.


I understand that to mean that `system(NULL)` returning zero indicates 
that the program is not (currently) running in a POSIX.1-2017 
environment. Guix creates many environments that do not conform to 
POSIX.1-2017: for example, any environment without `vi`.


-Philip

Re: What 'sh' should 'system' use?

[Philip McGrath]

Hi,


On 9/19/22 08:55, Maxime Devos wrote:
(4) Stop using 'system' in applications -- instead use whatever the 
language's equivalent of Guile's system*, execl ... or Guix' 
'invoke'. Why?  Because 'system'-like functions requires quoting the

 command line arguments whereas in 'system*'-like functions you could
 just pass a list of command line arguments, and it's easy to get the
 quoting wrong, especially if some of the arguments are generated 
dynamically.


As a bonus, this could often remove a dependency on 
bash{-minimal,-static,}.




I definitely advocate 'system*'-like functions in general. Still,
'system'-like functions exist: I'm advocating that Guix should should
have a consistent answer for how such functions should behave.

(Very occasionally, a program really does want to invoke the shell, such
as when shell expansion is part of an existing API.)

From a different perspective, this is part of why I've recently been
thinking we should find 'sh' dynamically: most programs/environments
don't, and shouldn't, need bash{-minimal,-static}, so it seems wrong to
make it a mandatory dependency of libc.

On 9/19/22 08:55, Maxime Devos wrote:


On 19-09-2022 02:13, Philip McGrath wrote:
1) If we want to continue to hard-code a specific shell into 
Glibc,


We do, for reproducibility -- otherwise, the behaviour of the 
'system' function depends on whatever is the current /bin/sh, and 
sometimes /bin/sh is updated (and on some foreign systems it might 
not even be the bash we are used to).


[...]



2) If we want to make 'sh' a weak/dynamic reference, I think we 
should strongly consider arranging to make it available at 
'/bin/sh' when present. I expect this option would require less 
patching of other packages*by far*  than any other approach.


See (1) (reproducibility) -- also, you would need to modify the 
daemon for that, so there are compatibility concerns, and then we're
 stuck with the /bin/sh special case forever (unless breaking 
compatibility would later be considered acceptable).




I don't think there's a reproducibility problem. Guix already can create
reproducible containers with "/bin/sh" (e.g. 'guix shell coreutils
--container -- ls /bin') and without "/bin/sh" (as in package build
environments).

I haven't investigated whether adding the ability to create "/bin/sh" in
build containers would require modifying the daemon or just sending the
daemon different instructions. However, AIUI, Nix *always* creates
"/bin/sh" in build containers, which makes me further expect that any
change needed to the daemon would be small.

To be clear, I'm not proposing that we always create "/bin/sh" in build
containers. At a low level, I'm suggesting that we add the ability to
create "/bin/sh" when desired. I can imagine one possibility for a
high-level interface would be to create "/bin/sh" by default when an
input provides "bin/sh", and it might turn out that we end up wanting
"/bin/sh" in most or all build containers in practice, but I see those
as secondary questions.

and recommendations for how packages should use it: '_PATH_BSHELL' 
is the best mechanism I've heard of so far, though I wish it were 
standardized, and the fact that it can't be portably assumed to be

a string constant could be surprising.


I consider _not_ using it, and using (4) instead, to be best. If not
 suitable (for example, because a shell is needed to run an actual 
shell script), then a plain "sh" looked up in the $PATH (like other 
binaries) and substitute*-ed by Guix should suffice.




As I said above, I agree that 'system*' should be preferred over
'system' when possible.

There are a few dimensions here that I want to try to pick apart.

When you say:

a plain "sh" looked up in the $PATH (like other binaries) and 
substitute*-ed by Guix should suffice


there are a few different things that might mean.

I think you're probably referring to the status quo, where "sh" is
looked up in the 'inputs' or a G-expression equivalent and an absolute
reference to that particular "sh" is embedded into the package being
built. (But, when cross-compiling, that "sh" would not be in the $PATH
in the build environment.)

There's a different question about $PATH vs. _CS_PATH that I'll address
later.

I see at least two reasons to prefer finding "sh" dynamically at run-time.

First, we have other POSIX-like shells packaged in Guix, such as dash,
zsh, and gash. Currently, to create an environment where one of these
shells is used to run 'system'-like functions (e.g. because dash is
supposed to be faster than bash), you would have to recompile everything
that depends on glibc. (Maybe you could craft a very ugly graft.)

Second, sometimes people may want to create environments, images, etc.
without an "sh" available. In some sense this is a special case of using
an alternate shell, but the consequences of the status quo are
especially notable. Currently, practically any environment or image Guix
creates will include bash-static, because