Re: Guix Days: Patch flow discussion

[Edouard Klein]

Skyler Ferris  writes:

> On 2/6/24 05:39, Steve George wrote:
>> I agreed to organise some 'patch review' online sessions in the next couple 
>> of
>> weeks.
>>
>> Organising a basic process is a good topic for that online session. For
>> example, elsewhere in the thread someone mentions some tags we could use
>> consistently so maintainers can find patches that have been reviewed easily. 
>> It
>> would be great to agree those - try them for a bit - and document them in a
>> 'howto' so that everyone uses the same process.
> Have these been announced somewhere yet (eg, with url & exact time)? If
> not will being subscribed to the help-guix list and/or checking the Guix
> blog be sufficient to receive notification? As someone who has sent
> patches in the past and intends to continue sending more in the future,
> I'd like to do my part to keep the project in a good state. However, I
> am new to interacting with large FLOSS projects so I'm nervous about
> causing more problems than I solve if I just start doing things.

Same here.

Re: Guix Days: Patch flow discussion

[Edouard Klein]

I, for one, would be willing to review patches, hoping that in turn my
patches would be reviewed instead of staying in limbo forever, which is
a drag on me submitting more patches.

Is there a procedure to follow, or do I just start replying "LGTM" to
patch email threads ?

Cheers,

Edouard.
Steve George  writes:

> Hi,
>
> 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?
>
> Patch flow is a pipeline, to change it we could:
>
> a. Increase the number of committers - more people to do the
> work
> b. Increase the efficiency of existing committers
> c. Open the gates by decreasing the quality expected from patches
>
> We essentially decided to focus our discussion on (b). We looked at
> things that 'hinder' and 'help' patch review:
>
>
> Hinders
> 
>
> - All our patch reviewers are volunteers doing it in their spare time.
>
> - For a volunteer reviewing someone else's work is not very rewarding, most
>  would prefer to use that precious time to scratch their own itch.
>
> - Can feel like an Sisyphean task: no matter how many patches someone reviews
>  there are more, exacerbated by the number of Guix packages.
>
> - Sense of responsibility: the minute that a reviewer looks at the patch they
>  are now stuck with it
>
> - Repetitive and boring: often patches have minor issues, but it's the same
>  sorts of issues time and time again.
>
> - Risk of negative social interaction: having to tell someone that their patch
>   is incorrect, or that their contribution cannot be used is difficult and
>   draining. Some people felt it was better to say nothing, rather than to
>  respond to a patch.
>
>
> Helps
> ==
>
> This led us to the focus on the fact that **reviewing and applying
> patches can be different people**
>
> We looked for ideas to create more reviewers, make reviewing easier and
> more fun:
>
>
> - Share in the work
> 
>
> 1. encourage new reviewers to step forward - making it more known that 
> reviewing
> patches helps to get them applied. Anyone can review patches.
>
> 2. create directed 'how-to' documentation for reviewing and connect it to QA 
> so
> that 'new reviewers' know what to do
>
> 3. create documentation about 'when' and 'how' it's appropriate to send a 'v2'
> version of a patch so that the QA system builds and accepts it. Sometimes,
> patches rot because non-committers don't want to be seen as 'stealing' 
> someone's
> work with a v2 patch - but making the small changes and resubmitting to QA is
> what is required.
>
> 4. Pay someone else to do it. Noted but out of scope.
> 5. Remove old packages overhead. Old untouched packages create mental 
> overhead,
> and make the task of maintaining the repository in a good state more 
> difficult.
> We could remove old 'untouched' packages and ones that no-longer compile. We
> have methods to hide and notify.
>
>
> - Make it more fun
> ---
>
> 1. do online sessions around reviews, some sprints or pairing - both social 
> and
> a way to spread skills
> 2. find ways to recognise and appreciate reviewers - 'reviewer of the month'
> 3. make it a game - we could have a 'Guix London' vs 'Guix Paris' leader board
> for reviews. Make it a group goal 'can we beat januarys reviews number'
> 4. create some graphs / leaderboard so we know how many patches are being
> reviewed and we can recognise the contribution
>
>
> - Automate it away
> ---
>
> 1. Chris is continuing to try and automate away the boring work - general
> agreement in the group that QA has made a lot of difference.
>
> 2. general discussion about create a 'guix review' command (Nix has one) which
> would download a branch with the appropriate patch and build it locally. This 
> is
> for instances where some adjustment is needed or to check a build. While this
> can be done today, it's a number of steps and quite involved.
>
>
> Agreed Actions
> ==
>
> * [Chris]: continuing his work to improve QA automation. Implication was we'll
>  need some reports / graphs - but these were not discussed in detail.
>
> * [Futurile]: organise a **patch review online sessions**. To run every 13 
> days
>   (so it rotates through the week) - for 3 months to see if it has any 
> traction.
>   Co-ordinate with maintainers so that patches that are reviewed can be
>  committed
>
>
> Actions looking for someone - you?
> 
>
> * Carry forward the 'guix review' command idea
>
> * Write an RFC and discuss the idea of removing older 'bit-rot' packages
>
> * write 'how-to' documentation for reviews and when it's socially
> acceptable to do a v2 patch. A checklist-like approach.
>
>
> If you were in the discussion and I've misrepresented your point, or forgotten
> an important aspect please please reply and correct me.
>
> Also, if you would like to help on any of the tasks please email back to the
> group so 

Re: Installing software inside containers

[Edouard Klein]

Wojtek, Caleb, I found the solution :) !!!

So, if you share /var/guix with a guix system container, you'll have two
guix daemons trying to mess with the socket, and that's not good (it
even breaks the host's daemon, which has to be restarted).

It works for guix shell --container, because it does not spawn a guix daemon.

So for this to work in a guix system container, you need to:
- remove guix-service-type from the %base-services,
- add guix as a package otherwise the guix command won't be there,
- share /var/guix with the host (whose daemon will actually do the job).

Here is the code, using beaverlabs' channel functional syntax (otherwise
it's a matter of modify-services 'delete etc.):

mwe.scm-
(use-modules
 (beaver system)
 (beaver functional-services)
 (gnu services base)
 (gnu packages version-control))

(define very-minimal-container
  (-> minimal-container
  (remove-service guix)
  (package guix)))

very-minimal-container

--


Then run:
sudo $(guix system container --network --share=/var/guix mwe.scm)

And in the shell you're dropped into, you can run guix shell or guix
install hello, for example.

I hope this solves your problem. It solved mine: I had a quite complex
OS configuration to try out before deploying it on a VPS, and running
VMs is cumbersome a requires a lot of disk space. The OS configuration I
want to try implies running containers inside of containers, now it is
possible :)

Cheers,

Edouard.


Edouard Klein  writes:

> Hi !
>
> If you create you containers with guix shell, you can use the --nesting
> option, or alternatively, use:
>
> guix shell --container --network --expose=/gnu/ --share=/var/guix/ guix
>
> Maybe similar options with a 'guix system'-generated container would
> work.
>
> Alternatively, if your own guix has a non standard configuration, you
> can create a profile from outside the container:
>
> guix install --profile=/whatevs some-software
>
> and then, from inside the container, use guix shell --profile=/whatevs
>
> it will make the software available, even if the container's guix has no
> knowledge of it.
>
> Cheers,
>
> Edouard.
>
>
> Wojtek Kosior via  writes:
>
>> [[PGP Signed Part:Undecided]]
>> Hi Caleb, nice to meet folks from Trisquel forum here :)
>>
>>> Also, how do I map arbitrary directories?  With Podman, I would do
>>>
>>> /home/$USER/.container/home/user:/home/user
>>
>> You can pass `--share="/home/$USER/.container/home/user"=/home/user` :)
>>
>> I can't help much with nesting Guix in a system container, tho — I'd
>> myself like to know if it is supported. I merely recall it's possible
>> with `guix shell -C` container. But a simple shell won't do in all
>> cases, I know
>>
>> Wojtek
>>
>> -- (sig_start)
>> website: https://koszko.org/koszko.html
>> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> follow me on Fediverse: https://friendica.me/profile/koszko/profile
>>
>> ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ 
>> c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
>> ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? 
>> U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
>> -- (sig_end)
>>
>>
>> On Sun, 26 Nov 2023 15:42:28 -0600 Caleb Herbert  wrote:
>>
>>> Hi Guix,
>>>
>>> I can't install software inside a Guix System container.  I need this to
>>> use Guix Home inside a container.
>>>
>>> $ guix install hello
>>> guix install: error: remounting /gnu/store writable: Operation not permitted
>>>
>>> Do I need to --share=/gnu/store?
>>>
>>> I tried sharing a blank ./gnu directory, but it complained that there
>>> were no programs to run the system.
>>>
>>> (Is sharing the host's /gnu/store with a container safe?)
>>>
>>> I created the container with
>>>
>>>  guix system container --network --share=home container.scm
>>>
>>> Also, how do I map arbitrary directories?  With Podman, I would do
>>>
>>> /home/$USER/.container/home/user:/home/user
>>>
>>> Thanks,
>>>
>>> Caleb
>>>
>>
>> [[End of PGP Signed Part]]

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

[Edouard Klein]

Merci d'avoir organisé tout ça :)
Tanguy LE CARROUR  writes:

> Bonjour Guix,
>
> Merci à ceux qui ont bravé les intempéries et les transports parisiens
> pour venir hier soir ! Et, surtout merci à ceux qui, présents ou à
> distance, on partagé leur travail, leurs découvertes ou leurs problèmes,
> et ont contribué à faire de cette soirée un moment très… convivial ! 
>
> Rendez-vous début janvier (sûrement le 11, à confirmer) pour la
> prochaine !
>
> En attendant, je vous souhaite à tou·tes une excellente journée, fin de
> semaine et… fin d'année !

Re: Installing software inside containers

[Edouard Klein]

Hi !

If you create you containers with guix shell, you can use the --nesting
option, or alternatively, use:

guix shell --container --network --expose=/gnu/ --share=/var/guix/ guix

Maybe similar options with a 'guix system'-generated container would
work.

Alternatively, if your own guix has a non standard configuration, you
can create a profile from outside the container:

guix install --profile=/whatevs some-software

and then, from inside the container, use guix shell --profile=/whatevs

it will make the software available, even if the container's guix has no
knowledge of it.

Cheers,

Edouard.


Wojtek Kosior via  writes:

> [[PGP Signed Part:Undecided]]
> Hi Caleb, nice to meet folks from Trisquel forum here :)
>
>> Also, how do I map arbitrary directories?  With Podman, I would do
>>
>>  /home/$USER/.container/home/user:/home/user
>
> You can pass `--share="/home/$USER/.container/home/user"=/home/user` :)
>
> I can't help much with nesting Guix in a system container, tho — I'd
> myself like to know if it is supported. I merely recall it's possible
> with `guix shell -C` container. But a simple shell won't do in all
> cases, I know
>
> Wojtek
>
> -- (sig_start)
> website: https://koszko.org/koszko.html
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> follow me on Fediverse: https://friendica.me/profile/koszko/profile
>
> ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ 
> c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
> ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? 
> U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
> -- (sig_end)
>
>
> On Sun, 26 Nov 2023 15:42:28 -0600 Caleb Herbert  wrote:
>
>> Hi Guix,
>>
>> I can't install software inside a Guix System container.  I need this to
>> use Guix Home inside a container.
>>
>> $ guix install hello
>> guix install: error: remounting /gnu/store writable: Operation not permitted
>>
>> Do I need to --share=/gnu/store?
>>
>> I tried sharing a blank ./gnu directory, but it complained that there
>> were no programs to run the system.
>>
>> (Is sharing the host's /gnu/store with a container safe?)
>>
>> I created the container with
>>
>>  guix system container --network --share=home container.scm
>>
>> Also, how do I map arbitrary directories?  With Podman, I would do
>>
>>  /home/$USER/.container/home/user:/home/user
>>
>> Thanks,
>>
>> Caleb
>>
>
> [[End of PGP Signed Part]]

Re: Moment de convivialité Guix@Paris en octobre

[Edouard Klein]

Je souhaite venir également :) J'avais raté l'annonce pour octobre.

J'aurais deux trucs à présenter:
- Du sucre syntaxique pour instancier, étendre, modifier, ou supprimer
des services,
- Comment monter des systèmes de fichier 9P au sein d'un guix container.

C'est pas super formel, ce sont des recherches en cours, mais si je peux
rétroprojeter mon écran et blablater pendant environ 20 minutes (en
tout), ça serait super.

Il faut apporter à manger/boire pour partager ?

++

Edouard.

Tanguy LE CARROUR  writes:

> Quoting Tanguy LE CARROUR (2023-10-27 09:04:26)
>> 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.
>
> Erreur ! Il fallait lire « le jeudi 7 décembre ».
>
> Bonne journée,

Re: guix shell readline issue with R

[Edouard Klein]

Credit where credit is due, the shebang's idea comes from guix's manual.

You can also do the following:

#+begin_src bash
#!/usr/bin/env bash
# Autowrap self in guix shell
if [ -z "${GUIX_ENVIRONMENT:-}" ]
then
guix shell YOUR DEPENDENCIES HERE -- "$0" "$@"
exit 0
fi
ACTUAL CONTENTS OF THE SCRIPT HERE
#+end_src

Cheers !

Edouard

Kyle Andrews  writes:

> Edouard Klein  writes:
>
>> Here is a script that restores the ctrl-C behaviour of R, whithin a guix 
>> shell.
>>
>> I must admit I don't exactly understand the finer points of why it works, 
>> but just trapping SIGINT in the script is enough for R to behave.
>>
>> My intuition is SIGINT is sent to the whole group. The script
>> interrupts R. If we trap it in the script, it does nothing. R gets it as 
>> well and acts on it like you expect.
>
> Thanks, Edouard!
>
> Your script worked perfectly just as you described. I was sorely missing that 
> `set -m' call and passing true from the bash function. I also really like 
> your idea for the shebang line.
>
> Best Regards,
> Kyle

Re: guix shell readline issue with R

[Edouard Klein]

Hy Kyle,


Here is a script that restores the ctrl-C behaviour of R, whithin a guix
shell.

I must admit I don't exactly understand the finer points of why it
works, but just trapping SIGINT in the script is enough for R to behave.

My intuition is SIGINT is sent to the whole group. The script interrupts
R. If we trap it in the script, it does nothing. R gets it as well and
acts on it like you expect.

Let me know if the problem still persists.

Here is the script:

#!/usr/bin/env -S guix shell r -- bash
set -m
R&
function ctrlc(){
# Doing nothing
true
}
trap ctrlc SIGINT
fg

Cheers,

Edouard.


Kyle Andrews  writes:

> Edouard Klein  writes:
>
>> Hi Kyle,
>>
>>
>> Running
>> guix shell r
>>
>> and then
>> R
>>
>> will get you the C-c handling you want.
>
> Hi Edouard,
>
> I wrote another reply, but forgot to comment on this because I feel like I am 
> missing something here.
>
> It would be really convenient if I could just write a shell script like that.
> For me the first command hijacks the execution so that the script cannot 
> invoke
> R. Is there a workaround avoiding -- which would let me automate that with a
> script?
>
> Cheers,
> Kyle

Re: guix shell readline issue with R

[Edouard Klein]

Hi Kyle,


Running
guix shell r

and then
R

will get you the C-c handling you want.

There is indeed readline support with guix shell r -- R:
up arrow to get history, c-E, c-A for end of line, start if line, etc.

I think maybe the problem lies not with readline but with the way
signals are handled. I can't seem to understand exactly how, but I would
look into that direction.

Cheers,

Edouard.

Kyle Andrews  writes:

> Dear Guix,
>
> When I run `guix install r` and then start an R process I get a 
> readline-enabled
> REPL where I can abort commands with C-c C-c while keeping the process alive
> afterwards. When I run R from `guix shell r -- R` I don't get any readline
> support in R. Pressing C-c immediately aborts the process. This is 
> inconvenient
> for interactive exploration. Is there a way to make guix shell work the same 
> way
> as if the R command was installed into a profile?
>
> Thanks for your help,
> Kyle

Re: lookup which file can be found in which package

[Edouard Klein]

My usual method is first: guix search, then: grep -ri in a checkout of
the source, and last searching the web for the package name in other
distros, and a bit of guesswork. It usually endup in a *-utils or
*-tools package.

>From a computer science standpoint this is an interesting problem.

The content of the store is the output of a program, so
discovering what it is reduces to the Halting Problem, which can't be
solved by automatic means for all packages.

Of course most packages are nicely coded, and grep usually find the
answer. Nevertheless, the only way to solve this for all packages would
be to install all packages and grep the store... i.e. run all programs
to completion and look at the output.

If you build a program to analyze the package code before it is
executed, one can always build a pathological package that will make it
fail (the canonical example would be a package that incorporates the
code of the checker, runs the checker on itself, and chose the answer
that makes the checker fail, but one can make a package whose output
depends on the Riemann conjecture being false, for example).

Cheers,



Soren Stoutner via  writes:

> [[PGP Signed Part:Undecided]]
> This would be a nice feature that I hope gets implemented some day.
>
> On Friday, June 2, 2023 2:45:28 PM MST W. T. Meyer wrote:
>> "W. T. Meyer"  writes:
>> > Is there a quick way in Guix to figure out which package provides which
>> > file similar to what other package managers provide with dnf
>> > provides/apt-file search/nix-locate etc.?
>>
>> There's an open patch for a guix index command mention on the
>> guix-patches mailing list:
>> https://lists.gnu.org/archive/html/guix-patches/2023-03/msg01210.html
>>
>> I guess this answers my question.
>>
>> - Wilko

Re: Message by a novice

[Edouard Klein]

Hi !

First, drop sudo, guix can be run by unprivileged users once installed,
and will only affect them. Great for shared environments !

anguriamelone--- via  writes:

> Hi to everyone.
>
> I am a novice in GNU Guix, so far I used Trisquel GN-Linux 9.0.2 (i686), but 
> at the end of April the support for the i686 version has been discontinued. 
> Nevertheless I want to continue using free (as in freedom) software and, 
> getting set to install the iso image, if I don't ask for too muchas an 
> abosulte beginner, I would like to know what are the basic command lines 
> corresponding to those of Trisquel GNU-Linux below:
>
> sudo apt update
>

guix pull

> sudo apt upgrade
>

For the system:
sudo guix system reconfigure /etc/config.scm

For your user packages
guix package --upgrade

> sudo apt install (package name)
>

guix install 

>
> sudo apt remove --purge (package name)
>

guix remove 

Subtle differences with '--purge'. The package will be removed from your
profile, but still be available in the store, and local conf (typically
in ~/.conf/...) will still be there, and need to be removed manually.
But it would have been put manually by you if it exists there, so guix
is consistent.


> sudo apt search (package name)
>

Don't use sudo for apt search.

guix search ...

> sudo apt autoremove
>
> sudo apt purge
>
> sudo apt autoclean
>
> sudo apt clean
>

Guix is very different from apt, there is no direct mapping for those
last four.

To reclaim disk space, run guix gc more or less aggressively.

Here is the doc:
https://guix.gnu.org/manual/en/guix.html#Invoking-guix-gc
Here are some notes on very aggressively reclaiming disk space:

  See how much space the store uses
  : du -h -d0 /gnu/store
  : 26G /gnu/store
  See all the roots that you have
  : guix gc --list-roots | sort
  : ...  a lot of generations from my different profiles
  : guix gc --list-roots | wc -l
  : 107
  Delete previous generations, you may be more or less aggresive with
  the options. Giving no options deletes all generations but the 0th one and 
the current one. Do this for every profile.
  List all existing profiles
  : guix gc --list-roots | sed 's/-[0-9]*-link$//' | sort | uniq
  Delete the maximum amount of generations from all the profiles
  : for profile in $(guix gc --list-roots | sed 's/-[0-9]*-link$//' | sort | 
uniq)
  : do
  : echo deleting generations in "$profile";
  : guix package --profile="$profile" --delete-generations;
  : done
  WARNING: you may want to keep all the genrations from =current-guix= (see 
[[sec:default-profiles]]), because they don't take up much space, and they will 
allow you to rebuild the packages from a previously installed and known-good 
version of guix, instead of having to bisect your way to a working version with 
=guix time-machine= as we did in [[sec:bisect]].
  You can also delete the profiles you are no longer interested in. Delete with 
=rm= the =guix_profile= (or whatever you called it) link and the 
=guix_profile-NN-link= that guix added. These will no longer appear in the 
roots, and therefore the packages they were referencing will be deleteable by 
the garbage collector.
  Then, run =guix pull=, and update the packages in all your profiles:
  : for profile in $(guix gc --list-roots | sed 's/-[0-9]*-link$//' | sort | 
uniq); do echo upgrading packages in  "$profile"; guix package 
--profile="$profile" --upgrade; done
  This will allow all common packages between your profiles to be de-duplicated 
in the store, because they will be at the same exact version, whereas if one 
was more recent than the other, both versions would be kept in the store, using 
up disk space. FIXME(ref the section that explain the store and the 
deduplication).
  Once all of this is done, the garbage collector can now be launched:
  : guix gc
  : du -h -d0 /gnu/store
  : 6,6G/gnu/store

There are also some directories in .cache that you can remove manually.

Hope that helps.

Cheers,

Edouard.


>Thanks for the attention and kind regards.
>
>   Piriponzolo
>
>

Can't setuid-program to a custom user

[Edouard Klein]

Dear Guix,

I am trying to install a program that requires its own user, and to
create a suid binary that will launch as this user, no matter who
launches it.

See lines 119 on of this file:
https://gitlab.com/edouardklein/guix/-/blob/6ae4c66bde1927aaae041311888c35105595a83e/beaver/packages/plan9.scm#L119

The creation of the account is successful, e.g. when I run a container
like so:
$(guix system container -e "(begin (use-modules (beaver system) (beaver
packages plan9)) (sucf minimal-container))")

I can check /etc/passwd and the user "suc" is in there.
I can launch guile, and type  (getpw "suc") and get in response:
"$1 = #("suc" "x" 1000 30001 "" "/home/suc"
"/gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/bash")"

I can check that the directory /var/lib/suc exists and is owned by the
user:
ls -l /var/lib/
total 4
-rw--- 1 root root 512 Apr 11 14:46 random-seed
drwxr-xr-x 2 suc  suc   40 Apr 11 14:46 suc/

However, when I try to setuid the suc binary to user suc:
#+begin_src scheme
(setuid-programs
  (cons (setuid-program (program (file-append suc "/bin/suc"))
(user "suc"))
#+end_src

Then when I launch my container I get:
"ERROR: In procedure getpw:
In procedure getpw: entry not found"

Which is very astonishing given that the user exists !

Does the setuid binaries service try to do its stuff before the accounts
are created ?

Does anybody have the slightest idea of why the user is not found ?

BTW, it works if I setuid to root by removing the `(user "suc")`.

Thanks in advance,

Edouard.

Re: Using an alternative python to build python modules

[Edouard Klein]

Hi !

I am not an expert, and your question definitively is in somewhat new
territory to me, if a real expert comes by, listen to them instead. From
what I gather, transitive inputs are only directs inputs and then
propagated inputs (from the docstring of the package-transitive-inputs
func).

However, package-input-rewriting, as per the doc:

replaces its direct and indirect dependencies, including implicit inputs
when deep? is true, according to replacements

I'm not sure of the precise meaning of indirect dependencies, but I
would expect the Python interpreter to be one of them (and also the
compiler that would build this interpreter, for example).

Therefore, adding #:deep #t may suffice.

However, Simon's solution with package-with-explicit-python looks more
appropriate to me.

Reading its source, I see that python packages have a #:python package
argument, so in the package definition of python-apted, adding

(arguments
 `(#:python ,your-old-python))

my be enough, but that is just a guess and if I were you I'd try simon's
snippet first.

Good luck,

Cheers,

Edouard


Kyle Andrews  writes:

> Dear Edouard and Wojtek,
>
> Thank you very much for your generous suggestions!
>
> I would like to give you an update to share the state of my still
> incomplete understanding after thinking about them.
>
> With regards to this sort of thing:
>
> ```
> (package-input-rewriting/spec
>  `(("python-prompt-toolkit" . ,(const python-prompt-toolkit-2)
> ```
>
>
> I did not try this yet because I don't understand it yet. My confusion
> stems from the fact that python is not in the transitive inputs of any
> python package.
>
> ```
> (use-modules (gnu packages) (gnu packages python))
> ,pretty-print (package-transitive-inputs python)
> ```
>
> How could modifying the graph have any effect?
>
> Instead I tried to go down the package-with-python2 route since it APTED
> claimed it was tested on python 2.7. Unfortunately, I ran into many
> other errors where different python packages in the transitive inputs of
> python-numpy failed because they were using various python 3 syntaxes.
>
> Now I am trying to figure out how to best go about trying with python 3
> instead. One issue I am not sure how to get around is the
> python?-variant property convention. It is not clear to me how to write
> one for an inferior python for use with
> `package-with-explicit-python'.
>
> I will keep you posted if I make any breakthroughs. I'm really eager to
> be able to replace conda with guix.
>
> Best Regards,
> Kyle
>
> Edouard Klein  writes:
>
>> As an example in this line of thought, a long time ago I submitted a
>> patch (since then reverted as it broke a lot of things) to use an
>> obsolete version of a python module, which was the only one that worked
>> with a specific module that hadn't updated its dependencies:
>>
>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=32ba87c14fd5e5b54d95211cd9a159d568ce7c67
>>
>> Look at the following lines:
>>
>> #+begin_src scheme
>> (define-public prompt-toolkit-2-instead-of-prompt-toolkit
>>   (package-input-rewriting/spec
>>`(("python-prompt-toolkit" . ,(const python-prompt-toolkit-2)
>> #+end_src
>>
>> If instead of replacing "python-prompt-toolkit" with
>> python-prompt-toolkit-2, you could replace "python" with the version of
>> python you want to use, package-input-rewriting would then handle the
>> work of changing the python package anywhere it appears in any
>> dependency of your manifest.
>>
>> You can then end your manifest with
>> (python-3.6-instead-of-python python-apted)
>>
>> Cheers,
>>
>> Edouard.
>>
>>
>> Wojtek Kosior via  writes:
>>
>>> [[PGP Signed Part:Undecided]]
>>> Hi Kyle,
>>>
>>> Have you looked at the (package-input-rewriting) procedure described
>>> towards the bottom of "Defining Package Variants"[1]?
>>>
>>> You might also like to look at the not-exported
>>> (package-with-explicit-python) proc defined in
>>> guix/build-system/python.scm[2]. It is used to produce python2 variants
>>> of packages but I suppose it would also work for swapping the minor
>>> versions of python3.
>>>
>>> Good luck with your task :)
>>>
>>> Wojtek
>>>
>>> [1] https://guix.gnu.org/manual/en/html_node/Defining-Package-Variants.html
>>> [2] 
>>> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/python.scm?id=b544f460989a6189af111bb3ff6752cabdf23abc#n82
>>>
>>> -- (sig_start)
>>&

Re: Using an alternative python to build python modules

[Edouard Klein]

As an example in this line of thought, a long time ago I submitted a
patch (since then reverted as it broke a lot of things) to use an
obsolete version of a python module, which was the only one that worked
with a specific module that hadn't updated its dependencies:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=32ba87c14fd5e5b54d95211cd9a159d568ce7c67

Look at the following lines:

#+begin_src scheme
(define-public prompt-toolkit-2-instead-of-prompt-toolkit
  (package-input-rewriting/spec
   `(("python-prompt-toolkit" . ,(const python-prompt-toolkit-2)
#+end_src

If instead of replacing "python-prompt-toolkit" with
python-prompt-toolkit-2, you could replace "python" with the version of
python you want to use, package-input-rewriting would then handle the
work of changing the python package anywhere it appears in any
dependency of your manifest.

You can then end your manifest with
(python-3.6-instead-of-python python-apted)

Cheers,

Edouard.


Wojtek Kosior via  writes:

> [[PGP Signed Part:Undecided]]
> Hi Kyle,
>
> Have you looked at the (package-input-rewriting) procedure described
> towards the bottom of "Defining Package Variants"[1]?
>
> You might also like to look at the not-exported
> (package-with-explicit-python) proc defined in
> guix/build-system/python.scm[2]. It is used to produce python2 variants
> of packages but I suppose it would also work for swapping the minor
> versions of python3.
>
> Good luck with your task :)
>
> Wojtek
>
> [1] https://guix.gnu.org/manual/en/html_node/Defining-Package-Variants.html
> [2] 
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/python.scm?id=b544f460989a6189af111bb3ff6752cabdf23abc#n82
>
> -- (sig_start)
> website: https://koszko.org/koszko.html
> PGP: https://koszko.org/key.gpg
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ 
> c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
> ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? 
> U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
> -- (sig_end)
>
>
> On Fri, 17 Feb 2023 21:27:39 +
> Kyle Andrews  wrote:
>
>> Dear Guix,
>>
>> I want to use the python-apted package in my manifest. That package is
>> not in Guix, but can readily be fetched from:
>>
>> ```
>> guix import pypi APTED > python-apted.scm
>> ```
>>
>> I just had to prefix the following modules to turn that into a package
>> definition as well as a manifest.
>>
>> ```
>> (use-modules (guix packages)
>>   (guix download)
>>   (guix licenses)
>>   (guix profiles)
>>   (gnu packages)
>>   (guix build-system python))
>> ```
>>
>> During my original testing of my scientific workflow I discovered that
>> there was a bug introduced to the APTED package which was caused by a
>> change in how python worked under the hood. As a result, the APTED
>> package only advertises compatibility with python versions less than
>> 3.7. So, I would like to use python 3.6 to be on the safe side.
>>
>> I also want to include 60+ other packages in my manifest which are
>> "current" with the Guix repository and included within it. For
>> situations like this it would be really convenient if it were possible
>> to pass a version of python to python-build-system. Then, I hope all I
>> would have to do is pass another another defined variant of the python
>> package (e.g. called python-3.6) into that build-system argument.
>>
>> For example:
>>
>> ```
>> (build-system python-build-system #:python python-3.6)
>> ```
>>
>> That would be quite convenient and in line with the level of complexity
>> I was faced with when I took the conda approach before trying to use
>> Guix. Unfortunately, this functionality doesn't seem to be provided out
>> of box and I am seeking help in the hopes that there is an easy way to
>> do it.
>>
>> Am I thinking about this right?
>>
>> Thanks,
>> Kyle
>>
>> P.S.
>>
>> APTED claims to also be able to run on top of python-2.7 so maybe that
>> fact could be used to simplify this specific issue. I just wanted to
>> discuss the general problem first because I really want Guix to gain
>> broad traction within the scientific community.
>>
>> P.P.S.
>>
>> Here is a pretend manifest where I would love guidance on how to make
>> python-apted get built in the context of python-2.7 or ideally
>> python-3.6 even though the latest version of python is python-3.9 (where
>> APTED doesn't always work).
>>
>> ```
>> (use-modules (guix packages)
>>   (guix download)
>>   (guix licenses)
>>   (guix profiles)
>>   (gnu packages)
>>   (guix build-system python))
>>
>> (define-public python-apted
>>   (package
>> (name "python-apted")
>> (version "1.0.3")
>> (source (origin
>>   (method url-fetch)
>>   (uri (pypi-uri "apted" version))
>>   (sha256
>>(base32
>>  "1sawf6s5c64fgnliwy5w5yxliq2fc215m6alisl7yiflwa0m3ymy"
>> (build-system 

Re: Sourcing a script in phases

[Edouard Klein]

Hi,

It's probably not the right answer, but for lack of time to find the
actual solution when I faced the same problem as you, here is what I
did:

https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/packages/python-xyz.scm#L191

#+begin_src scheme
#:builder
  (begin
(use-modules (guix build utils))
(let* ((bash (assoc-ref %build-inputs "bash"))
   (requisomatic (assoc-ref %build-inputs "requisomatic"))
   (dir (string-append (assoc-ref %outputs "out") "/bin"))
   (fname (string-append dir "/requisomatic-server")))
  (mkdir-p  dir)
  (with-output-to-file fname
(lambda _
  (display (string-append "#!" bash "/bin/bash\n"))
  (display "source /run/current-system/profile/etc/profile\n")
  (display "REQUISOMATIC_DB_FILE=$1 gunicorn --bind=$2 --pid=$3 
requisomatic:app\n")))
  (chmod fname #o755)
  #t
#+end_src

Basically this creates a shell script that sources whatever you want to
source, and then call the executable you want to call.

This is not exactly what you want to do, but you can use this technique
to create a script that will run the build commands you want to run, and
then call it during the build phase.

Again, this is probably not the right answer.

Cheers,

Edouard.
phodina via  writes:

> Hi,
>
> is there a way to source a script in the phases?
> I tried to do:
>
> (invoke "source" "env.sh")
> or
> (invoke "." "env.sh")
>
> But it didn't work since they are builtin in the shell.
>
> 
> Petr

Re: Trivia question: What does the "G" in G-expressions stand for?

[Edouard Klein]

My bet would be on "Guix" ?


jgart  writes:

> Hi,
>
> What does the "G" in G-expressions stand for?
>
> all best,
>
> jgart

Re: bug#55359: How do I extend openssh-service-type ?

[Edouard Klein]

Thank you both for solving this. I used a workaround for a while
(rsyncing the keys to /home/user/.ssh/authorized_keys). Now I can
confirm that the fixes work and I'm back to a declarative configuration
of my server, which is awesome !

Cheers,

Edouard.
Ludovic Courtès  writes:

> Hi,
>
> Oleg Pykhalov  skribis:
>
>>> (service-extension openssh-service-type
>>>(const `(("charlie"
>>>  ,(local-file "charlie.pub")
>>> #+end_quote
>>
>> […]
>>
>> Seems like extend-openssh-authorized-keys procedure does not use keys
>> argument. We could fix it like:
>
> For the record, this bug (dismissing the ‘keys’ argument) was introduced
> in b4b2bbf4fb74c9f3e93d64863ab9b38957494b49 (Oct. 2021).
>
> How come nobody noticed then?
>
> The reason is that starting from
> b4b2bbf4fb74c9f3e93d64863ab9b38957494b49, ‘authorized-key-directory’
> would create an empty directory.  That directory would then be copied by
> ‘openssh-activation’ to /etc/ssh/authorized_keys.d; since
> /etc/ssh/authorized_keys.d would typically already contain the relevant
> keys, nothing bad would happen.
>
> Oleg’s commit 1f29ed4a812f86c45e2d9c37fd9f80f6d0418293 introduced
> another bug though: we’d create an authorized-key directory that
> included keys brought by extensions, but each of these files would be
> empty (because ‘extend-openssh-authorized-keys’ would dismiss key files
> associated with user names), which could lock yourself out.
>
> Fixed in 0dc63ce519c5f98b2186d1871176e2fac3a6926b.  Reconfiguration
> recommended before you’re locked out!
>
> Thanks,
> Ludo’.

How do I extend openssh-service-type ?

[Edouard Klein]

Hi !

I'm trying to make sense of:
https://guix.gnu.org/manual/en/guix.html#index-openssh_002dservice_002dtype

#+begin_quote
This service can be extended with extra authorized keys, as in this example:

(service-extension openssh-service-type
   (const `(("charlie"
 ,(local-file "charlie.pub")
#+end_quote

My goal is to do exactly that: add a public key to a user of an
operating system whose openssh-service-type is already configured
elsewhere.

I can do it by going to this "elsewhere" and adding the

("charlie"  ,(local-file "charlie.pub"))

in the authorized-keys field of the openssh-configuration, but when I
try to extend the service, the key is just ignored and does not appear
in /etc/ssh/authorized-keys.d/

I've tried adding a simple-service to the operating-system declaration
like so:

#+begin_src scheme
  (simple-service
   (format #f "ssh keys for user ~a" "toto")
   openssh-service-type
   (list
`("toto" ,(local-file "toto.pub"
#+end_src

I also tried the verbose version:

#+begin_src scheme
 (service (service-type
  (name 'tamereenslip)
  (extensions
   (list
(service-extension openssh-service-type
   (const `(("toto"
 ,(local-file 
"toto.pub" #f)
#+end_src

I'm at my wit's end. I could not find any examples online or by grepping
the source code.

Has anybody ever been successful in extending the openssh-service ? If
so, could I please see your code ?

Thanks,

Edouard.

Re: A package search engine for a curated list of channels

[Edouard Klein]

That's a great idea :)

I can lend a VPS with guix installed on it for testing and initial
deployment, if you need it.

I can't promise to help with development because of time constraints,
but I'll follow this with eagerness.

Unless I'm mistaken (which I very well my be), pulling from a channel
basically gives the channel authors code execution privileges on the
pulling machine, so as you said in the subject line, hand curation would
be in order.

Cheers,

Edouard

Mekeor Melire  writes:

> Hello,
>
> it would be nice to be able to search for a package (and/or a service)
> by name or description etc. through many channels. AFAIK, there's no
> such search engine yet. Please correct me if I'm wrong.
>
> I'm considering to implement it. I'd suggest to approach it with a
> server where (1) Guix is installed; (2) a long list of channels is
> activated; (3) a cron-job or so which regularly runs `guix pull`; (4) a
> web-api-service written in Guile which leverages the Guix-library in
> order to search for packages (-- I guess it'd be calling the
> `guix-package*` function from /guix/scripts/package.scm?); (5) a
> simplistic front-end web-site which talks to the web-api.
>
> I post this to help-guix instead of the devel-mailing-list because this
> is not about development on Guix itself.
>
> Kindly
> Mekeor

Re: was I hacked?

[Edouard Klein]

Hi,

I diffed the git log of both https://git.sr.ht/~whereiseveryone/pjmkglp
and guix official repo and could not find any difference (apart from the
most recent commits on the official repo of course). I also confirmed,
as had already been said, that commit 950f3e4f98 is indeed a descendant
of 42679e3f81, so the error message makes no sense :/

I have absolutely no idea what went wrong. I'm still very much
interested in the answer, but I've reached the edge of my ability to
investigate.

Let's hope that somebody can find out what went wrong.

Cheers,

Edouard.

Christine Lemmer-Webber  writes:

> Well good news, jgart pushed them elsewhere in the thread:
>
> jgart  writes:
>
>> Here are the repos of interest:
>>
>> https://git.sr.ht/~whereiseveryone/pjmkglp
>>
>> https://git.sr.ht/~whereiseveryone/authentification-channels
>>
>> wdyt?
>
>
> Edouard Klein  writes:
>
>> Hi,
>>
>> Sorry about the noise, but I'm curious about this as well, and I think
>> if this is indeed an attack that it would be brilliant to see that guix
>> protected against it. I would like to document it.
>>
>> @jgart I can open a git repo for you and lend a hand if you need help
>> pushing the strange branch somewhere.
>>
>> Cheers,
>>
>> Edouard
>>
>> Jack Hill  writes:
>>
>>> On Thu, 14 Apr 2022, jgart wrote:
>>>
>>>> What I not sure of is what path on my system to find the suspicious
>>>> branch/git repo pulled down by `git/guix pull` so I can push it somewhere.
>>>>
>>>> In other words, where does `guix pull` clone the git repo to?
>>>
>>> ~/.cache/guix/checkouts
>>>
>>> ~/.cache/guix/authentication may be interesting as well.
>>>
>>> (I bet (hope?) it's actually XDG_CACHE_DIR/guix but you get the idea)
>>>
>>> Sorry I don't have insight in to what went wrong.
>>>
>>> Take care,
>>> Jack

Re: was I hacked?

[Edouard Klein]

Hi,

Sorry about the noise, but I'm curious about this as well, and I think
if this is indeed an attack that it would be brilliant to see that guix
protected against it. I would like to document it.

@jgart I can open a git repo for you and lend a hand if you need help
pushing the strange branch somewhere.

Cheers,

Edouard

Jack Hill  writes:

> On Thu, 14 Apr 2022, jgart wrote:
>
>> What I not sure of is what path on my system to find the suspicious
>> branch/git repo pulled down by `git/guix pull` so I can push it somewhere.
>>
>> In other words, where does `guix pull` clone the git repo to?
>
> ~/.cache/guix/checkouts
>
> ~/.cache/guix/authentication may be interesting as well.
>
> (I bet (hope?) it's actually XDG_CACHE_DIR/guix but you get the idea)
>
> Sorry I don't have insight in to what went wrong.
>
> Take care,
> Jack

Re: I think thunked fields are breaking my previously working code

[Edouard Klein]

Thank you so much Ricardo, you have no idea how big of a thorn you
removed from my side. I owe you one.

Ricardo Wurmus  writes:

> e...@beaver-labs.com writes:
>
>> For example, given that "minimal-container" is an operating system, I
>> can do the following:
>>
>> (set-fields minimal-container ((operating-system-host-name) "toto"))
>>
>> But not:
>>
>> (set-fields minimal-container ((operating-system-label) "toto"))
>
> In Guile we usually try to avoid mutation like that.  The records API
> allows you to use inheritance instead:
>
>   (operating-system
> (inherit minimal-container)
> (label "toto"))
>
> Thunking just means that the field is a procedure that returns a value
> when called with no arguments.  The records in (guix records) are not
> plain SRFI9 records, so I would not expect set-fields to work at all.

Re: Running graphical apps with guix shell --container

[Edouard Klein]

It does work ! Thank you very much :)
Luis Felipe  writes:

> [[PGP Signed Part:Undecided]]
> Hi Edouard,
>
> On Friday, January 28th, 2022 at 10:11 AM, Edouard Klein  
> wrote:
>
>> I won't be specifically helpful, but I never managed to get chromium to
>> run in a container. It crashes almost immediately. If you ever manage
>> it, I'd be happy to know the magic command that allows it.
>
> Could you try the command shared by Daniel in
> https://lists.gnu.org/archive/html/help-guix/2022-01/msg00167.html ? It worked
> for me. At least chromium runs and I could browse a couple of websites without
> crashes (didn't test for too long, though).
>
> [2. application/pgp-keys; publickey - luis.felipe...@protonmail.com - 
> 0x12DE1598.asc]...
>
> [[End of PGP Signed Part]]

Re: Running graphical apps with guix shell --container

[Edouard Klein]

I won't be specifically helpful, but I never managed to get chromium to
run in a container. It crashes almost immediately. If you ever manage
it, I'd be happy to know the magic command that allows it.


Cheers,

Edouard.
Luis Felipe  writes:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> I'm trying to run a GTK application in an isolated environment, but the 
> application seems to fail when trying to be displayed. I'm running these 
> commands:
>
> EXAMPLE:
> $ guix shell -C --preserve='^DISPLAY$'
> $ python3 mazo
> INFO: No database found. Creating it.
> INFO: Database created.
> Unable to init server: Could not connect: Connection refused
> Unable to init server: Could not connect: Connection refused
> Unable to init server: Could not connect: Connection refused
>
> (mazo:2): Gtk-WARNING **: 23:24:28.154: cannot open display: :1
> END EXAMPLE
>
> Also, trying the following example from Guix manual, the browser does not 
> start:
>
> EXAMPLE:
> $ guix shell --container --network --no-cwd ungoogled-chromium 
> --preserve='^DISPLAY$' -- chromium
> Authorization required, but no authorization protocol specified
> END EXAMPLE
>
> I'm using Guix System 037c2b6.
>
>
> ---
> Luis Felipe López Acevedo
> https://luis-felipe.gitlab.io/
>
> [2. application/pgp-keys; publickey - luis.felipe...@protonmail.com - 
> 0x12DE1598.asc]...
>
> [[End of PGP Signed Part]]

Re: password-store is broken in master but builds in version-1.4.0 (utf8 problem)

[Edouard Klein]

Wow. Talk about a rabbit hole. I'd never would have found that alone.

I'll wait for the "tree-1" patch to appear on master.

Thank you all for tracking and sidestepping this bug.

Guix's cleanliness really is a canary for the quality of the whole
ecosystem. That's awesome.

Cheers

Tobias Geerinckx-Rice  writes:

> [[PGP Signed Part:Undecided]]
> Hullo Edouard,
>
> e...@beaver-labs.com 写道：
>> I can't build password-store.
>
> See .
>
> Kind regards,
>
> T G-R
>
> [[End of PGP Signed Part]]

Re: GNU Guix maintainer rotation

[Edouard Klein]

Thank you Ludovic and Marius :)

And good luck to Efraim !


Maxim Cournoyer  writes:

> Hello Guix!
>
> I'd like to bring your attention to a change to the current Guix
> maintainers collective; in a nutshell, Ludovic and Marius are stepping
> down from maintainer-ship while Efraim is joining.
>
> I won't write more as you can find all the details in this blog post:
> https://guix.gnu.org/en/blog/2022/gnu-guix-maintainer-rotation/.
>
> Many thanks to Ludovic and Marius for their past roles as Guix
> co-maintainers, and a warm welcome to Efraim!
>
> Happy hacking!
>
> Maxim

Re: Guix Home Entertainment SoC Media Server?

[Edouard Klein]

Hi !

It depends on how easy and integrated you want your experience to be ;)

The raspberry pi is classic SoC to use for such a purpose, there are a
lot of software and guides that you can use and take inspiration from
for your project.

In particular, the Retro-pi project will let you play classic games on a
raspberry pi, and Kodi is a nice integrated media center distribution.

Sadly:
- the raspberry pi still uses some proprietary components that GNU Guix
can not take into account (yet ?)
- some features, especially games, are closed-source, so outside of the
scope of GNU Guix.

My advice would be to look at what people are doing on raspberry pies,
and replicate what you need.

>From a purely function over form perspective, I think you can replicate
90% of the features of Kodi with VLC. It can do streaming, can read any
media format, and is globally awesome.

Also take a look at https://gitlab.com/guix-gaming-channels/games for
(sadly closed source, but what can you do ?) integrating video games in
your Guix setup.

Please post somewhere about what you do, this is an itch I intend to
scratch someday and I'll be happy to read about your efforts,

Happy hacking :)

Edouard.

Blake Shaw  writes:

> Hiya Guix!
>
> I just got a TV and want to put together a little SoC home media server for
> it (perhaps with beaglebone black, as that appears to be the recommended
> SoC for Guix). Has anyone had any experience with this? Thoughts?
> I figure it could be a fun use of `Guix Deploy`, but I've never put
> together a SoC media server before, so I'm not sure what packages to
> peek at, or what "out of the box" (re: raspbian etc) options are
> available.
>
> Seems like this could be some cool shoes for Guix to fill!
>
> ez,
> blake

Re: Loading Common Lisp Libraries with GNU/Guix in a REPL

[Edouard Klein]

Hi !

I don't know the "correct" way to do it, but the way I do things is:

Create a manifest.scm or guix.scm file in the directory. Here is an
example manifest.scm file:

#+begin_src scheme
(define-module (osef)
  #:use-module (guix packages)
  #:use-module (gnu packages)
  #:use-module (guix profiles)
  #:use-module (gnu packages lisp)
  #:use-module (gnu packages lisp-xyz)
  #:use-module (gnu packages readline)
  )


(packages->manifest
 (list sbcl sbcl-numcl rlwrap))
#+end_src

Then I run guix shell, which will automatically load this manifest.scm
file.

Then, same as you, I run rlwrap sbcl.

Finally I invoke the following in sbcl:

#+begin_src lisp
(load "~/.emacs.d/elpa/27.2/develop/slime-20211021.507/swank-loader.lisp")  
;; Found using find .emacs.d/ -iname '*swank*'
(swank-loader:init)
(swank:create-server)
#+end_src

This allows my emacs instance, which lives outside the guix shell, to
communicate with the sbcl instance which lives inside. I don't want to
pollute each project with my emacs config, which is done once and for
all for all projects.

To connect: M-x slime-connet, enter, enter.

Then I just (require :numcl) (for example). I did not need to use asdf,
although this may be package-specific. I remember being unable to load a
package once, but I don't rememder which or why (sorry).

So basically, the same as you already do.

If there is a more canonical way, I'd be happy to know :)


Cheers,

Edouard.



jgart  writes:

> On Fri, 10 Dec 2021 05:44:58 -0500 jgart  wrote:
>
> Alternatively, I was able to also load code this way also after running
> the following:
>
> ```
> $ guix shell sbcl sbcl-cl-str rlwrap
>
> CL-USER(2):
> jgart@gac ~ [env] λ rlwrap sbcl
> This is SBCL 2.1.9, an implementation of ANSI Common Lisp.
> More information about SBCL is available at .
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses.  See the CREDITS and COPYING files in the
> distribution for more information.
> CL-USER(1): (asdf:make "str") 
> WARNING: System definition file
> #P"/gnu/store/aljfy13phr526w0iqmqz0cf2cnxkjxlb-sbcl-cl-ppcre-unicode-2.1.1/share/common-lisp/sbcl/cl-ppcre-unicode/cl-ppcre-unicode.asd"
> contains definition for system "cl-ppcre-unicode-test". Please only
> define "cl-ppcre-unicode" and secondary systems with a name starting with
> "cl-ppcre-unicode/" (e.g. "cl-ppcre-unicode/test") in that file.
>
> ;;; Computing Hangul syllable names
> T
> CL-USER(2): (in-package :str)
>
> #
> STR(3): (trim "  rst  ")
>
> "rst"
> STR(4): (join " " '("foo" "bar" "baz"))
>
> "foo bar baz"
> STR(5): (concat "f" "o" "o")
>
> "foo"
> STR(6): (split "+" "foo++bar")
>
> ("foo" "" "bar")
> ```

Re: Question about scripts in guix-home

[Edouard Klein]

Hi,

Sorry I can't be more precise due to lack of time, but maybe invoking
chmod on the .sh files in a gexp would work ?

https://www.gnu.org/software/guile/manual/html_node/File-System.html

#+begin_quote

Scheme Procedure: chmod object mode
C Function: scm_chmod (object, mode)

Changes the permissions of the file referred to by object. object
can be a string containing a file name or a port or integer file
descriptor which is open on a file (in which case fchmod is used as
the underlying system call). mode specifies the new permissions as a
decimal number, e.g., (chmod "foo" #o755). The return value is
unspecified.

#+end_quote.


Fredrik Salomonsson  writes:

> Hi guix,
>
> I decided to try out guix home. But I hit a bit of a snag. I'm trying to
> port my waybar config over to it, but cannot figure out how to set the
> execution bit on my two custom scripts I have.
>
> This is what I currently have:
>
> #+begin_src scheme
>   (define-module (plt home waybar)
> #:use-module (gnu services)
> #:use-module (gnu home services)
> #:use-module (gnu packages wm)
> #:use-module (guix gexp)
> #:use-module (guix utils)
> #:use-module (ice-9 format))
>
>   (define-public packages
> (list
>  waybar
>  ))
>
>   (define %source-dir (current-source-directory))
>
>   (define-public (get-services host)
> "Return services for HOST."
> (list
>  (simple-service 'plt-waybar-config
>  home-files-service-type
>  `(
>("config/waybar/config"
> ,(local-file (format #f "~a/files/waybar/~a.conf" 
> %source-dir host)))
>("config/waybar/style.css"
> ,(local-file (format #f 
> "~a/files/waybar/~a-style.css" %source-dir host)))
>("config/waybar/modules/mic.sh"
> ,(local-file "files/waybar/modules-mic.sh"))
>("config/waybar/modules/storage.sh"
> ,(local-file "files/waybar/modules-storage.sh"))
>
> #+end_src
>
>
> Which generates the config but the mic.sh and storage.sh bash scripts
> are missing their execution bit.
>
> The bash scripts are really basic, for example here's the mic.sh:
>
> #+begin_src bash
>   #! /usr/bin/env bash
>
>   mic_mute=$(pactl get-source-mute @DEFAULT_SOURCE@| cut -d" " -f2)
>   if [[ "$mic_mute" == "yes" ]]
>   then
>   echo '{"text": "",  "class": "muted", "percentage": 0 }'
>   else
>   echo '{"text": "",  "class": "unmuted", "percentage": 100}'
>   fi
> #+end_src
>
>
> I played around with gexp but didn't get anything working. Closest I got
> what by using program-file
>
> #+begin_src scheme
>   (define-public (get-services host)
> "Return services for HOST."
> (let ((mic-script (program-file
>"mic.sh"
>#~(execl #$(local-file "files/waybar/modules-mic.sh") 
> "mic.sh")))
>   (storage-script (program-file
>"storage.sh"
>#~(execl #$(local-file 
> "files/waybar/modules-storage.sh") "storage.sh"
>   (list
>(simple-service 'plt-waybar-config
>home-files-service-type
>`(
>  ("config/waybar/config"
>   ,(local-file (format #f "~a/files/waybar/~a.conf" 
> %source-dir host)))
>  ("config/waybar/style.css"
>   ,(local-file (format #f 
> "~a/files/waybar/~a-style.css" %source-dir host)))
>  ("config/waybar/modules/mic.sh"
>   ,mic-script)
>  ("config/waybar/modules/storage.sh"
>   ,storage-script)
>  )
> #+end_src
>
> But it's still trying to execute the original scripts and fail due to
> the execution bit.
>
> I'm probably missing something obvious, but I haven't used gexp before.
>
> How do you set the execution bit on a file-like object? 
>
> Or is there a better approach for dealing with these? Package them up
> perhaps? As I just realized when writing this that I also need to patch
> the shebang to point to the bash guix-home is using.
>
> Thanks

Re: setting up my own channel (for some personal packages)

[Edouard Klein]

Hi,

I am not sure, but here is my try:

I cloned your channel2 repo, and saw in emacs-hide-comnt.scm:

(define-module (gnu packages emacs-hide-comnt)

Modules names in Guile (in all schemes ?) must match the path, so either
put emacs-hide-comnt.scm in gnu/packages, or change the above line to:

(define-module (emacs-hide-comnt)

See that urweb.scm starts with:
(define-module (urweb)

My interpretation is that the error message means that the
emacs-hide-comnt module was not found where it was looked for, i.e. in
gnu/packages.

This may not be the only problem, but it is worth a try.

Good luck :)

Cheers,

Edouard.


Andreas Reuleaux  writes:

> Hi,
>
> I am trying to set up my own channel for some personal packages,
> and I do have some success to that end, but I am still experiencing
> issues:
>
>
> TL;dr - short summary:
>
>   my package: emacs-hide-comnt.scm (below) breaks my setup for "guix pull"
>   (which otherwise works just fine without that package)
>   my package emacs-hide-comnt.scm cannot be too bad either:
>   I can build+install it just fine by hand.
>   
>
>
> I am following the guix guide, and have stolen two packages from
>
> --8<---cut here---start->8---
> https://github.com/jsoo1/guix-channel
> --8<---cut here---end--->8---
>
>
> namely emacs-dump.scm (which provides my-emacs-dump), and
> urweb.scm.
>
> I have set up my own git repo (with just these two packages for now) at:
>
> --8<---cut here---start->8---
> http://git.a-rx.info/channel
> --8<---cut here---end--->8---
>
>
> and (with a git-url) in my ~/.config/guix/channels.scm:
>
> --8<---cut here---start->8---
> (cons (channel
>(name 'my-stuff)
>
>
>(url "git://git.a-rx.info/channel")
>
>(introduction
> (make-channel-introduction
>"56384c65b5d57606cd7ff3e2a4db1c99c24d7adf"
>  (openpgp-fingerprint
>   "99BB E77D 73AE 07B9 D4B0  CA2E 3384 11E5 6E09 31B5")
>  ))
>
>)
>   %default-channels)
> --8<---cut here---end--->8---
>
>
>
> I can "guix pull" (I am using "--allow-downgrades" the first time here, as I 
> have used
> channel my-stuff with a different inital commit before), anyway this
> works fine so far - guix pull does not complain about the my-stuff channel.
>
> --8<---cut here---start->8---
> rx@dell ~$ guix pull --allow-downgrades
> Updating channel 'my-stuff' from Git repository at 
> 'git://git.a-rx.info/channel'...
> guix pull: warning: moving channel 'my-stuff' from 
> 12ac4ab75c0b9dc247af3a65179c566e198d908d to unrelated commit 
> 56384c65b5d57606cd7ff3e2a4db1c99c24d7adf
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from these channels:
>   guix  https://git.savannah.gnu.org/git/guix.git 63fec9f
>   my-stuff  git://git.a-rx.info/channel   56384c6
> Computing Guix derivation for 'x86_64-linux'... /
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
> The following derivations will be built:
>/gnu/store/dsb3bcmddgsvn34wxh0g2mbm4lyq1haz-profile.drv
>/gnu/store/d227lqkghmg48b34b81si8hdmz3vba64-my-stuff.drv
>/gnu/store/mcp30c79gi9cdnckg4ghahkaygn85ykk-inferior-script.scm.drv
>/gnu/store/d84yrjgr6bkg7c6h9i0bxjz7cfxhisp2-profile.drv
>/gnu/store/vrr8flhvf06xprqm6n9q45pj10h7r10g-inferior-script.scm.drv
>
> building 
> /gnu/store/mcp30c79gi9cdnckg4ghahkaygn85ykk-inferior-script.scm.drv...
> building /gnu/store/d227lqkghmg48b34b81si8hdmz3vba64-my-stuff.drv...
> building CA certificate bundle...
> listing Emacs sub-directories...
> building fonts directory...
> building directory of Info manuals...
> building database for manual pages...
> building profile with 2 packages...
> building 
> /gnu/store/vrr8flhvf06xprqm6n9q45pj10h7r10g-inferior-script.scm.drv...
> building package cache...
> building profile with 2 packages...
> New in this revision:
>   2 new packages: lsofgraph, urweb
>
> rx@dell ~$ guix pull 
> Updating channel 'my-stuff' from Git repository at 
> 'git://git.a-rx.info/channel'...
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from these channels:
>   guix  https://git.savannah.gnu.org/git/guix.git 63fec9f
>   my-stuff  git://git.a-rx.info/channel   56384c6
> Computing Guix derivation for 'x86_64-linux'... /
> nothing to be done
>
> rx@dell ~$
> --8<---cut here---end--->8---
>
>
> and "urweb" is available, for example
>
> --8<---cut here---start->8---
> rx@dell ~$ guix package -A urwe
> urweb 20190217out urweb.scm:15:2
> rx@dell ~
> 

Re: creating a profile

[Edouard Klein]

Hi !

You can pass the --profile option to most guix subcommands.

To install guile-commonmark in a profile, it would be a simple:

guix install --profile=/tmp/toto guile-commonmark

To install only its dependencies, the following bash one liner will do:

guix install --profile=/tmp/toto $(guix show guile-commonmark | grep
dependencies: | sed -e 's/dependencies://')


Enjoy !

Cheers,

Edouard.

Adriano Peluso writes:

> I'd like to create a profile containing the dependencies of guile-
> commonmark and I'm a bit confused about how to

Setting TZDIR (was Re: A single reference to installed non-binaries)

[Edouard Klein]

Leo Famulari writes:

> On Tue, Aug 17, 2021 at 04:01:15PM +0200, Edouard Klein wrote:
>> See e.g.
>> https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/packages/scheme-xyz.scm#L68
>> 
>> Here, xlsxio and tzdir will be expanded to their full install path in
>> the store.
>
> I'm going off-topic, but you should not patch TZDIR like this.

I appreciate you going off-topic to warn me about a mistake ! Thanks :)

>
> The time zone database should be found dynamically at run-time via an
> environment variable set by the system. Otherwise, your built package
> will eventually "go stale" as the time zone database is updated, which
> happens several times per year.
>
> Does that make sense?

It does, thanks, but I'm in a bit of a pickle there because this
packagge needs, for reasons outside of my control, to be deployable on
a multitude of host (non-GuixSD) linux distributions, and as a docker
container. In those cases, I can't expect the timezone data to be up to
date or to be there at all.

Even if I list tzdata as a dependency, the host system's TZDIR will not
point to it.

I understand that if I regularly guix pull and guix package -u, then the
tzdata package will be kept up to date. Is that correct ?

If it is, then I need to rebuild the .tar.gz and the docker image every
so often, and this problem would be solved for the foreing distros as well.

Thanks for alerting me about this !

Cheers,

Edouard.

Re: A single reference to installed non-binaries

[Edouard Klein]

Phil writes:

> Thanks for comments Edouard!  Responses inline.

:)

>
>
> Edouard Klein writes:
>
>
>> See e.g.
>> https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/packages/scheme-xyz.scm#L68
>
> Ahh so wrap-program creates a script that sets the two env vars
> LD_LIBRARY_PATH and TZDIR before calling the original script?

Yes, it is exactly what it does, with the added cleverness that if the
original script is already a wrap, it edits the wrap instead of re-wrapping.
>
>> It has the advantage of not needing to integrate any guix-realted stuff
>> in package-y, which I would consider an abstraction leak.
>
> Yes it's nicer for the underlying program not to have to know about
> Guix.
>
> There is one small wrinkle with this in my particular case.  Whilst I
> can wrap the main entry point to the program easily enough, there is a
> second entry point via the unit tester (pytest), which is obviously an
> external tool so not so easy to wrap.
>
> I could patch the source code of the unit test itself as an alternative.
>

As you can see a bit below where I linked before, you can redefine the test
stage in order to set the correct environment variables before calling
your test command. It will be a bit redundant with the wrapping phase,
but it would allow you not to edit your application code.


> Another slightly more leftfield idea is to change (or add) package-x to be a
> python package which holds the original data files and a very thin API
> client that can serve those files up to Python.
>
> Then package-x's python module will be self-aware of its location, relative
> to the text files and we can serve up either a file path or file
> object to package-y just by importing package-x, and calling a function.
>

I don't know the particulars of your code, but package-x and package-y
seem to be quite coupled together, so I would question the assumption
that they belong in separate packages.

Maybe they do, nobody is better placed than you to judge. But putting
them both in the same package would make your problems disappear.


> The disadvantage of this would be if we had non-python clients
> too, but we could keep two different build systems for the same source -
> one copies the files, and the other installs a python module.
>
> I'll give this a whirl.


Good luck !

Cheers,

Edouard.

Re: A single reference to installed non-binaries

[Edouard Klein]

Hi !

I side-step this kind of things by adding a stage in package-y that will
find and replace all references to "bar" with the complete path to the
installation path of package-x, or that will set the needed environment
variable to the full path of the dependency.

See e.g.
https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/packages/scheme-xyz.scm#L68

Here, xlsxio and tzdir will be expanded to their full install path in
the store.

It has the advantage of not needing to integrate any guix-realted stuff
in package-y, which I would consider an abstraction leak.

I hope this helps :)

Cheers,

Edouard.

Phil Beadling writes:

> Hi all,
>
> I have some platform independent files I have created a package for using
> copy-build-system.  This works great but I've come across situation I don't
> know how to handle.
>
> Let's call the package I've made package-x, and let's say that package-y
> (which is for arguments sake is a python build system) lists package-x as a
> propagated-input.
>
> package-x is installing a directory, let's say "bar" from the source into
> "share/foo/"
>
> '(#:install-plan '(("bar" "share/foo/")))
>
> Now whenever we install package-y, I should expect it's "share" directory
> to contain foo/bar - and I find it to be the case.
>
> No suprises so far.
>
> The problem comes when I want to reference a file under "bar" in the source
> code of package-y.
>
> Depending on whether I install package-y via "guix install package-y -p
> /path/to/profile" or via "guix environment --ad-hoc package-y" there is no
> single reference to the bar directory that covers every use-case.
>
> When I "install" the package - I can reference it using $GUIX_PROFILE
> But as for example a developer when I'm coding package-y I would reference
> it using $GUIX_ENVIRONMENT
>
> This means that any source that references it must presumably attempt to
> read it from $GUIX_ENVIRONMENT, and then on failure fallback to
> $GUIX_PROFILE.
>
> This feels a bit brittle to me, and I'm hoping I've missed a trick, and
> there's a better way to singluarly reference the location of a share
> directory from any GUIX profile or environment?
>
> Note the problem doesn't happen with binaries as the order of precedence in
> the PATH variable avoids the issue.
>
> Any ideas?
>
> Thanks,
> Phil.

Re: Docker image sizes

[Edouard Klein]

Hi !

You can use guix graph to see what depends on what, and find out why a
specific dependency is needed:

https://guix.gnu.org/manual/en/html_node/Invoking-guix-graph.html

I just invoked:
guix graph elixir > /tmp/toto.dot

and by manually inspecting the dot file I can see that e.g. webkit is needed
by wxWidgets, whether you need those or not is up to you.

You can generate the visual graph with
dot -T pdf < /tmp/toto.dot > /tmp/toto.pdf

I'm looking at it right now, and I see that elixir depends on erlang and
git, and that git is pulling perl with it.

I doubt that's needed, so maybe you can create a new package
"lean-elixir", and forego the dependency on git somehow ? If you cut a
branch early in the DAG you may get huge returns on investment,
size-wise.


This may not be the best approach, maybe some wizards here will have
better ideas.

Cheers,

Edouard.
TJ writes:

> Hi,
>
> I was trying to package a project in docker and to start I did a fairly
> straightforward command:
>
> $ guix pack --format=docker elixir
>
> It generated an image quite a bit larger than I expected.
>
> -r--r--r--2 root  root  461M Dec 31  1969 
> gfnqg760z22vr8kbvyzdzhs1hc5766c9-elixir-docker-pack.tar.gz
>
> After uncompressing, this is taking 1.5GB and is including quite a few
> unnecessary packages for a minimal image - see below for the top 30.
>
> $ du -s * |sort -g -r | head -n 30
> 155804  g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0
> 145164  m59c9hj9d4n65maimbpmx2xq56d2mvqs-mesa-20.2.4
> 111708  q233v022vziq8ry18y8q959k110vclvf-webkitgtk-2.32.1
> 110840  cgqj7xswlpvhzxwri3mcqfs1fhbgnka8-erlang-23.2.1
> 103940  qk5v5vzwfl066zch67nxlv4x7aspf0fx-samba-4.13.4
> 93972   cw8brvxkzp4kmdqldsv1wkvi2cv4kq4x-python-3.8.2
> 64620   8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2
> 56300   18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2
> 52748   nscar35x261xky08qih2ddxq1b105qwd-gtk+-3.24.24
> 41092   fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31
> 39544   2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1
> 35848   fi1mdh30b5q6zvplvayn68lb575xcd1k-ghostscript-with-cups-9.52
> 34768   01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib
> 34188   wjmydimw608k61qxmsifkam11jwgpric-wxwidgets-3.0.5.1
> 24224   jv6v8p8jbjf6hpscgp3dgdfylrdhldi1-gdk-pixbuf+svg-2.40.0
> 18488   n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-8.32
> 18464   57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32
> 16596   jsqxxnaj5p8a22mrsvl679gi7jl26z4j-glib-2.62.6
> 16400   aza259fsrb841zwb4rjzfzs2nrsf28f1-eudev-3.2.9
> 16060   9z185s19zp2p9yq8gdayxgibaphxfcps-cups-2.3.3
> 15604   4l2il4wcxjb443xwc2arwixpq28pbfvl-cups-minimal-2.3.3
> 14140   02z5vgdhgxw4gcjvhx51mvy1ax4lzxmp-fftwf-3.3.8
> 13912   zzkly5rbfvahwqgcs7crz0ilpi7x5g5p-ncurses-6.2
> 13096   lv92cmzqjpb8mxygpqdvh0mkkkfi9vmz-libxcb-1.14
> 10876   n3pjsbpd51x6vqikfglmrdbijflammf6-gst-plugins-base-1.18.2
> 10588   sayvymkqjl328rsivzlp9r46337rvdmz-pulseaudio-14.0
> 10084   7y3lvk3xf4im8n44337mc6y0ccysvfia-font-dejavu-2.37
> 9888hr1p9l1waam8lk2csdwbzaipf14h9n33-gstreamer-1.18.2
> 9576a45p39mgqvfd8kjwibyr0q42k1mw7gmf-util-linux-2.35.1-lib
> 8812z3vbqvpgcz7lag9qci074hjry4j3120i-shared-mime-info-1.15
>
> I wouldn't expect to need llvm, mesa, webkit, samba, python, perl, gtk, cups, 
> pulseaudio, etc, etc. in a production image.
>
> What would be the recommended way to minimize the derivation?
>
> Thanks,
>
> TJ

Re: package manager guix on Windows and OSX

[Edouard Klein]

>
> Why Plan 9? May I ask?

Plan 9 is awesome. What the whole industry is barely managing to achieve
with containers and VMs, Guix does somewhat correctly with namespaces,
but Plan 9 had all this in its DNA, in a cleaner implementation 30
years ago !

By default, a process in Plan 9 only has a partial view of the system,
and is truly isolated from the other processes. No network, user,
filesytem namespace bullshit, everything (yes everything is a file), so
there is only one namespace, the filesystem namespace, and you mount
only what your process needs to see.

e.g . your process does not need to access the internet, then don't mount
/net !

e.t. your process need to access only one host: the connect to the host,
and mount the relevant /net/tcp/n/ directory, but not /net/tcp/clone,
and so your process will not be able to connect anywhere else !

Also, any file could be managed by a process running on another machine,
transparently.

Anyway, Guix reminds me of Plan9 because it achieves like 10% of what
Plan9 could do, but on a Kernel that actually runs on modern hardware,
and with a sane API, and so it's 10 times better than anything else. Yet
I wish Linux was more plan9ish.


> And I do really like the Hurd, but I use the
> dvorak keyboard layout.  My understanding is that the Hurd does not
> support variant keyboard layouts yet...  :(

I don't think that the kernel is the part where your keyboard layout is
implemented, but I don't know the Hurd at all so I may well 

>
> I actually think that the Guix developers may want to consider a port to
> the OpenBSD kernel, provided that the Hyperbola developers get
> HyperbolaBSD working.  Though I guess the Debian guys sort of did
> already.  :)

OpenBSD is really good too. The pledge() function is a really nice API
that is much easier to use than the mess we got on Linux...

Re: package manager guix on Windows and OSX

[Edouard Klein]

Hi !

The real problem will not be the languages (guile or C++), but the
system calls used by Guix.

Guix makes use of some recent (less than 2 decades) and somewhat
advanced features of the Linux kernel, such as namespaces.

To port Guix to another operating system such as BSD (including OSX),
one would have to translate these calls.

For example, Guix is the only software I've actually encountered that
can not run in SmartOS' emulation of Linux, because the system calls it
uses are not implemented there.

I would love for Guix to be a Multi Kernel package manager (I mean it
works on the Hurd also, but I have never encountered a Hurd user in real
life). My dream would be to port Guix to Plan 9 ;-)




jbra...@dismail.de writes:

> June 24, 2021 2:26 PM, "Patricio Martínez"  wrote:
>
>> Do anyone know the posibilities about install Guix on another system
>> diferent of Linux?
>
> Awesome! I love speculating on topics I know virtually nothing about!  Most
> of my information comes from a mailing list thread that is about a year old.
> So the situation may be better than I describe it.  :)
>
> The easiest way is to use GNU Guix on Windows is WSL (Windows subsystem
> for Linux):
>
> https://www.mail-archive.com/guile-user@gnu.org/msg12167.html
>
> I'm not a big fan of that, because of Window's history of "embrace, extend,
> extinguish."  And that only lets you run Guix in Windows...what about Mac? 
> The Hurd?  React Os?  Redox Os?
>
> https://www.mail-archive.com/guile-user@gnu.org/msg12173.html
>
>
> GNU Guix runs entirely on GNU Guile with some C++ for the build daemon.
>
> C++ is fairly portable. That bit should be possible to port, though I
> believe that the development plan is to eventually rewrite the C++ build
> daemon in GNU Guile.
>
> GNU Guile is the tricky bit.  To the best of my knowledge, the newer
> versions of GNU Guile run exclusively on GNU/Linux, which is NOT the
> fault of the Guile developers!  It's REALLY HARD to port things to all
> OSes.  None of the Guile developers are paid for their fabulous work.
> And it's not like Windows or Mac make it easy to port to their platform.
>
> https://www.mail-archive.com/guile-user@gnu.org/msg12172.html
>
> Though, the Lilypond developers did get guile 2.2 version working on Windows.
>
> https://www.mail-archive.com/guile-user@gnu.org/msg12163.html
>
> So did the gnucash guys for GNU Guile 2.2, but it is fairly tough to
> get it to build:
>
> https://www.mail-archive.com/guile-user@gnu.org/msg12164.html
>
> Also, it's a 32-bit GNU Guile that was ported to windows and it does
> not supports thread.
>
> Also Guile 3.0's JIT works on lightening, which is a C library (program ?).
> And I do not know if that supports Windows.  But C is really portable.  :)
>
>> Thanks you very much and sorry for my english
>
> It was marvelous English! You should teach it!

Systemd guix containers: unable to execute Permission denied

[Edouard Klein]

Hi,

I'm running a container using a systemd unit. This unit calls a script
that call guix system container and calls the returned script.

When I launch this script by itself, everything works as expected.

When I launch this script with systemd, I can launch any command except
as root in the container.

For example, once I get a shell in the container with guix container
exec, I can do:
sudo -u nginx echo toto

And it will succeed when the container is launched by hand, but failed
when launched with systemd.

Any idea, even far fetched, will be appreciated. I have a burning hatred
for systemd (not my choice) that this incident is fueling.

I've tried everything I could think of:
- activating and deactivating various systemd flags
- changing the uid of nginx to match a user on the host system
- changing the uid of nginx to avoid matching a user on the host system
- stopping nscd on the container,

etc.

I'm looking into other means of achieving what I want, but this SHOULD
work, and it WOULD if it wasn't for effing systemd.

Cheers,

Edouard.

Re: Find location of installed package in /gnu/store

[Edouard Klein]

Hi !

This is where G-expressions will help you :)

Basically the path you need does not exist in the same "strata" as the
code of the package.

The following code will define a build-gexp function that evaluates a
G-expression and prints the resulting directory in the store. You can
try it in "guix repl" or with "guix build -f FILE"

https://guix.gnu.org/manual/en/guix.html#G_002dExpressions

A G-exp begins with #~ and withing the following expr, any piece of code
prefixed by #$ is recursively replaced by its value, but only if this
value is a primitive value (string, int,...) or a package.

If it is a package, it gets replaced by the path in the store of that
package.

So to give a short answer, run the following into the REPL to get your
path:
  (use-modules
 (guix gexp)
 (guix store)
 (guix derivations)
 (gnu packages java))
(define (build-gexp gexp)
  "Build GEXP using the local daemon."
  (let ((derivation 
 (run-with-store (open-connection)
   (gexp->derivation
"noname"
gexp
(build-derivations
 (open-connection)
 (list derivation))
(derivation-output-path (assoc-ref (derivation-outputs derivation) 
"out"

(build-gexp
 (with-imported-modules '((guix build utils))
   #~(begin
   (use-modules (guix build utils))
   (mkdir-p  (string-append #$output "/bin"))
   (with-output-to-file (string-append #$output "/bin/helloworld.sh")
 (lambda _
   (display (string-append "Iced tea lives at:" #$icedtea-8)))


This wil output a path, in my case
/gnu/store/vv5sc5l488xxysyz88aadjj3fwnqr2xa-noname

and in it you'll have the file:
/gnu/store/vv5sc5l488xxysyz88aadjj3fwnqr2xa-noname/bin/helloworld.sh

which contains
Iced tea lives at:/gnu/store/vaqdvsqdv5mads38dp6pc5827pdgnmb3-icedtea-3.7.0

Given your stated use case, you may be interested in the following
upcoming patch:
https://issues.guix.gnu.org/48277

It will let you wrap any executable in the appropriate env vars, so I
guess you will be able to do something like
#$(wrap-in-search-paths #~(string-append #$output "/bin/your-script")
(list icedtea-8))

Hopefully icedtea-8 sets the correct search paths, but I believe it
does.

Cheers,

Edouard.

Phil Beadling writes:

> Hi,
>
> Given a package definition, eg icedtea-8's JDK, how can can I determine the
> location of the installed package in my /gnu/store?
>
> There doesn't seem to be anything on the package module itself, presumably
> because this is static data, and what I need is something to calculate the
> hash of the resulting install specific to my Guix?
>
> eg
> scheme@(guix-user) [3]> (package-outputs icedtea-8)
> $8 = ("out" "jdk" "doc")
> scheme@(guix-user) [3]>
>
> I'd like to return this location using the package name or definition as an
> input:
> /gnu/store/i3vf1a49m0abcjqza19mb4mkjmc6k60n-icedtea-3.7.0-jdk/
>
> The aim is to use this to derivive the JDK include directories in a generic
> way for some scripts I'm writing, such that I don't need to update them
> each time the JDK hash changes after a guix pull.
>
> Cheers,
> Phil.

Re: How to lower a record to the build code ?

[Edouard Klein]

Dear Christopher,

I can't thank you enough, your idea of "ungexp[ing] the record access
bits" is what got me out of the tarpit.

You can see the resulting code here, which will hopefully clear the
misunderstandings generated by my oversimplification of the minimal
nonworking example:
https://issues.guix.gnu.org/issue/48277

Thanks again !

Cheers,

Edouard.


Christopher Baines writes:

> e...@beaver-labs.com writes:
>
>> I've been stuck for a few days on the following:
>> Let's say I have a record type:
>>
>> (define-record-type*  my-record make-my-record
>>   my-record?
>>   this-record
>>  (first-field my-record-first-field)
>>  (second-field my-record-second-field))
>>
>> And a function that uses such a record, but needs to run on the build
>> side, because it also needs the store path of a package (I can't edit
>> this function):
>>
>> (define (function-of-a-record-and-a-build-time-path rec path)
>>   "Concatenate the path, first, and second field"
>>   (string-append path " " (my-record-first-field rec) " " (car
>>   (my-record-second-field rec)) " " (cdr (my-record-second-field rec
>>
>> How can I use this record in the build side. For example, I'm unable to
>> build the following G-exp:
>> (define a-record (my-record
>>   (first-field "first")
>>   (second-field '("second" . "third"
>>
>>
>> #~(with-output-to-file (string-append #$output "/file.txt")
>>  (lambda _
>>(display (function-of-a-record-and-a-build-time-path #$a-record
>>  #$bash)
>
> Could you ungexp the record access bits? So something like:
>
>   (string-append #$path " " #$(my-record-first-field rec) " " #$(car
> (my-record-second-field rec)) " " #$(cdr (my-record-second-field
> rec)))
>
> Obviously, then the handling of rec would just be on the build side.
>
> I'm not quite sure quite what your code looks like, in the example you
> give, you've got a number of problems.
>
> Ignoring the #$a-record, you'll need to (mkdir #$output) before trying
> to write to a file within that directory.
>
> Secondly, function-of-a-record-and-a-build-time-path isn't defined on
> the build side.
>
> If you want to define function-of-a-record-and-a-build-time-path on the
> host side, then you could have it return a gexp, something like:
>
>   (define (function-of-a-record-and-a-build-time-path rec path)
> "Concatenate the path, first, and second field"
> #~(string-append #$path " " #$(my-record-first-field rec) " " #$(car 
> (my-record-second-field rec)) " " #$(cdr (my-record-second-field rec
>
>   (build-gexp
>#~(begin
>(mkdir #$output)
>(with-output-to-file (string-append #$output "/file.txt")
>  (lambda _
>(display #$(function-of-a-record-and-a-build-time-path  a-record 
> bash))
>
> With these changes, the example you give works for me.

Re: Can't bind to port 80 from inside a Guix container

[Edouard Klein]

Dear all,

I solved my problem by simply unpriviledging all ports on the system:
# echo 'net.ipv4.ip_unprivileged_port_start=0' > 
/etc/sysctl.d/50-unprivileged-ports.conf
# sysctl --system


Now anybody can bind to any port.

I wish we were on Plan 9 where filesystem permissions applies to the
network too, but we have to use a half-a-century old API instead. I hate
port numbers with a passion.

Anyway. That works, I'm happy. I hope it can be useful to somebody else.

Cheers,

Edouard.
e...@beaver-labs.com writes:

> Dear fellow Guixers,
>
> I'm trying to run nginx with `guix system container --network toto.scm`,
> and I get the following error:
>
> nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)
>
> despite the container script being launched with sudo.
>
> I got a root shell inside the container, checked that the corresponding
> process also belongs to root from outside the container, and still don't
> have the right to bind to port 80, with any software (this is not an
> nginx error).
>
> netcat lets me launch `nc -l 80` but I can't reach it, I don't think it
> is actually binding.
>
> Is this a known problem or limitation of guix containers ?
>
> What do you suggest to try to troubleshoot this issue ?
>
> Cheers,
>
> Edouard.

Re: Environment of a shepherd service

[Edouard Klein]

Thank you Maxime for your answer :)

Maxime Devos writes:

> e...@beaver-labs.com schreef op zo 11-04-2021 om 21:31 [+0200]:
>> Dear fellow Guixers,
>
>> [...]
>> But, when I try to run it with shepherd, it fails because it can't find
>> flask (a dependency of the software, which I've put as a
>> propagated-input, and is indeed installed in the container).
>
> Propagated inputs can be inconvenient at times.  I would advise
> looking where requisomatic is referring to flask, and replacing
> flask --> (string-append (assoc-ref inputs "flask") "/bin/flask")
> using substitute*.

OK, I understand this part :) The executable is gunicorn, so I'll just
use its full path in the script that launches the service.

My previous solution was to source the profile beforehand:

https://gitlab.com/edouardklein/requisomatic/-/blob/baf3fe51ad8bbabbcbc467dff92ec02c43e6daf1/guix.scm#L200

I do agree that a rich profile feels dirty and I too don't like
propagated inputs too much, but with Python I don't understand what the
best way to do it is ?

For example, in order to package a Python application in a way that does
not break the host system, I had to put all the search-paths in a
wrapper script and change all propagated inputs as just inputs. I find
the resulting code quite ugly, and I don't think I'm doing things right:
https://gitlab.com/edouardklein/gendscraper/-/blob/980f2597cc36bc79a9be7af5814e0fcf2313b677/gendscraper.scm#L1176

I wouldn't like to have to this for every service. If propagated inputs
are inconvenient, and if services run in an environment where the
search-paths of the installed packages are not available, how can we
easily tell the software where to find its dynamically-loaded parts ?


>
>> But, when I try to run it with shepherd, it fails because it can't find
>> flask (a dependency of the software, which I've put as a
>> propagated-input, and is indeed installed in the container).
>> [...]
>
> Some advice (warning: I'm not familiar with gunicorn or requisomatic
> at all).

I used flask and gunicorn in this project, but I'm not familiar with
them either ;)

>
>> 
>> -extract from my operating-system declaration file---
>> (define requisomatic-shepherd-service
>>   ([...] (shepherd-service
>> [...]
> (documentation "Run the requisomatic server")
>> (start #~((make-forkexec-constructor
>> ;;   (append
>> ;;(if db-file
>> ;;  `("env"
>> ;;,(string-append "REQUISOMATIC_DB_FILE=" 
>> db-file))
>> ;;  '())
>> '("gunicorn" "requisomatic:app")
>
> Normally, services refer by absolute path to the binary to run, and not rely
> on the PATH (the latter would require polluting the system profile).
> Idiomatically, one would write
>
>   '(#$(file-append gunicorn "/bin/gunicorn")
> #$(file-append requisomatic) "/wherever/the/binary/is")
>
I did not know about file-append even though it is in the manual. Thanks :)


>>#:directory (string-append #$requisomatic 
>> "/bin/requisomatic/")
>
> Why are you changing the working directory to
> (string-append #$requisomatic "/bin/requisomatic/"),

because . is by default where flask will look for the code it needs.

>and why is "/bin/requisomatic" a
> directory and not an executable?

Because flask/jinja/etc. are normative about where they want stuff to be
and I put everything in a single dir. As most of the assets is code
(some are html templates) I put it in bin/... but I could put them in
/lib of wherever. This is not the cleanest, but I really wanted to get a
guix operating system declaration to work before I did things cleanly.

> Is that a gunicorn thing?

More like flask, but yeah, it's a framework thing.

>
>> Why is the PYTHONPATH (and the other env vars, for that matter) not
>> propagated from the package to the shepherd service by default ?
>
> How is the shepherd service supposed to automagically know which packages
> to include in the environment variables?
>

I realised afterwards that by extending the profile-service-type,
services can say what packages they need (I currently add them to the
operating-system definition). I would expect the shepherd
command to run in an environment where the search-paths of those package
is set. I have no idea if this is complicated to do, but as a service
writer I would enjoy it very much.

>> And how can I make it so ?
>
> Use the #:environment-variables option, see e.g.
> bitlbee-shepherd-service

I see the concept, but the list is hardcoded, and for even moderately
complex Python application (or any other dynamic language) the list of
env variables to set will become huge.

> Or create a wrapper.  See e.g. wrapped-dbus-service.

This looks like a clean version of what I did for gendscraper, but the
problem remains of which variable to set. This information exists in
each individual package. Some 

Re: Running LAMP under Guix on a foreign distro - Debian

[Edouard Klein]

Hi,

I'm working on something similar, but with nginx. Basically you want to
make an operating-system definition, where you can orchestrate all the
layers of your stack, and then you can run it using `guix system
container` with the added benefit of container isolation.

I'll make a quick writeup and share the source code as soon as I am
successful. See my other messages on this list to see what I'm currently
struggling with.

Cheers,

Edouard.
白い熊 writes:

> Hello:
>
> I'd like to run the LAMP stack under Guix, running from a binary install on a 
> Debian system - I'm not sure this is possible when not running on Guix 
> system, i.e. without reconfiguring the system with httpd etc service. Is it 
> possible?
>
> The reason I'd like to do this, is I'd like to use Learning with texts
> https://sourceforge.net/projects/learning-with-texts/
> but am not sure how to get MySQL, Apache and PHP set up in Guix, so they'd 
> work.
>
> Could someone give me guidance on setting up a full LAMP stack in Guix on a 
> foreign distro?
>
> Many thanks.

Re: Environment of a shepherd service

[Edouard Klein]

Hi !

I did, thanks :) But this post talks only about shepherd, not its
integration with guix. It is indeed a very good resource for creating
shepherd services, and I was able thanks to it to write a shepherd
service.

What I would like to do is create a shepherd service, using some
facilities offered by the "operating-system declaration" concept of
guix.

In this instance I have trouble setting the env of the service to the
search paths of the installed packages.

The final goal is to orchestrate multiple services (typically multiple
web services and an instance of nginx to reverse-proxy them all) in one
operating-system declaration.

Here are the resources I have found on this topic


  - https://www.gnu.org/software/shepherd/manual/shepherd.html#Services
  - https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/
  - 
https://archive.fosdem.org/2017/schedule/event/composingsystemservicesinguixsd/attachments/slides/1794/export/events/attachments/composingsystemservicesinguixsd/slides/1794/guix_service_composition.pdf
  - https://www.mndet.net/2016/05/04/guixsd-system-service.html
  - https://guix.gnu.org/en/manual/en/guix.html#Defining-Services

The documentation is scarce (not an attack, I understand writing docs is
harder than writing code), and I have trouble getting used to the source
because I'm unable to get a guile repl at the level at which I'm trying
to run code, so I have to make edits, build the container, try, repeat.
If there is an error I have no stack trace or debug information.

Cheers,

Edouard.

Jonathan McHugh writes:

> Did you read this blog post?:
> https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/
>
> == START 
> The GNU Shepherd manual suggests putting all the services inside a monolithic 
> init.scm file, located by default at $XDG_CONFIG_DIR/shepherd/init.scm. While 
> this does make it easy to keep everything in one place, it does create one 
> glaring issue: any changes to the file mean that all the services need to be 
> stopped and restarted in order for any changes to take place.
>
> Luckily there's a nice function called scandir hiding in ice-9 ftw which 
> returns a list of all files in a specified directory (with options for 
> narrowing down the list or sorting it). This means that our init.scm can 
> contain a minimum of code and all actual services can be loaded from 
> individual files.
>
> First the minimal init.scm:
>
> (use-modules (shepherd service)
>  ((ice-9 ftw) #:select (scandir)))
>
> ;; Load all the files in the directory 'init.d' with a suffix '.scm'.
> (for-each
>   (lambda (file)
> (load (string-append "init.d/" file)))
>   (scandir (string-append (dirname (current-filename)) "/init.d")
>(lambda (file)
>  (string-suffix? ".scm" file
>
> ;; Send shepherd into the background
> (action 'shepherd 'daemonize)
>
> Let's take a sample service for running syncthing, as defined in 
> $XDG_CONFIG_DIR/shepherd/init.d/syncthing.scm:
>
> (define syncthing
>   (make 
> #:provides '(syncthing)
> #:docstring "Run `syncthing' without calling the browser"
> #:start (make-forkexec-constructor
>   '("syncthing" "-no-browser")
>   #:log-file (string-append (getenv "HOME")
> "/log/syncthing.log"))
> #:stop (make-kill-destructor)
> #:respawn? #t))
> (register-services syncthing)
>
> (start syncthing)
>
> As with any other shepherd service it is defined and registered, and in
> this case it will start automatically. When the file is loaded by
> shepherd after being discovered by scandir everything works exactly as
> though the service definition were located directly inside the init.scm.
>
>  END ===
>
>
> HTH
>
>
> Edouard Klein  writes:
>
>> Hi,
>>
>> So I looked at the source and I understand that there's no way around
>> having only PATH=/run/current-system/profile/bin as the sole environment
>> of a service (which makes me wonder how anyone is running any service in
>> GuixSD, don't you need any env variables ?).
>>
>> I tried to define a trivial package that would use wrap-program to
>> create a script that would set the environment variables to all the
>> search-paths of my requisomatic package, but I don't know how to access
>> those !
>>
>> In the code that is executed by the daemon, all references to the
>> package are lost, it is not in the same strata as the package.
>>
>> I can get the store path to the package but that does not help me.
>>
>> I really could use some guidance here.
>>
>> Cheers,
>>
&

Re: Environment of a shepherd service

[Edouard Klein]

Hi,

So I looked at the source and I understand that there's no way around
having only PATH=/run/current-system/profile/bin as the sole environment
of a service (which makes me wonder how anyone is running any service in
GuixSD, don't you need any env variables ?).

I tried to define a trivial package that would use wrap-program to
create a script that would set the environment variables to all the
search-paths of my requisomatic package, but I don't know how to access
those !

In the code that is executed by the daemon, all references to the
package are lost, it is not in the same strata as the package.

I can get the store path to the package but that does not help me.

I really could use some guidance here.

Cheers,

Edouard.
e...@beaver-labs.com writes:

> Dear fellow Guixers,
>
> I'm trying to create an operating system declaration, so that I can run
> a piece of software of mine in a container with =guix system container=.
>
> I wrote a package for the software. The package works: the tests pass
> and when the package is installed I can run the software.
>
> I wrote a shepherd service for the software (it's called requisomatic).
> I copied the relevant part at the end of the email.
>
> When I run the container script created by =guix system container=, and
> get a shell in the container, I can run the software (I added the software's
> package to the globally installed packages in the operating-system 
> definition).
>
> But, when I try to run it with shepherd, it fails because it can't find
> flask (a dependency of the software, which I've put as a
> propagated-input, and is indeed installed in the container).
>
> I replaced the software invocation in the shepherd service with just
> "env", and saw that the whole env in the service is:
>
> PATH=/run/current-system/profile/bin
>
> whereas in the shell I get when I connect to the container, the env
> contains many other variables, including a correctly set PYTHONPATH,
> which allows the finding of flask.
>
> So I now know why my software is not starting, but my question is:
>
> Why is the PYTHONPATH (and the other env vars, for that matter) not
> propagated from the package to the shepherd service by default ? And how
> can I make it so ? I would have expected the shepherd service to run
> with the global profile active.
>
> Follow up question, can shepherd services be specified to run in a
> specific profile ? So that I can have two services with incompatible
> dependencies running at the same time in the same operating-system ?
>
> Thanks in advance,
>
> Cheers,
>
> Edouard.
>
>
>
> -extract from my operating-system declaration file---
> (define requisomatic-shepherd-service
>   (match-lambda
> (($  user group db-file)
>  (list (shepherd-service
> (provision '(requisomatic))
> (requirement '(user-processes networking))
> (documentation "Run the requisomatic server")
> (start #~((make-forkexec-constructor
> ;;   (append
> ;;(if db-file
> ;;  `("env"
> ;;,(string-append "REQUISOMATIC_DB_FILE=" 
> db-file))
> ;;  '())
> '("gunicorn" "requisomatic:app")
>;;   '("env")
>;;)
>#:directory (string-append #$requisomatic 
> "/bin/requisomatic/")
>#:log-file "/var/log/requisomatic.log")))
> (stop #~(make-kill-destructor)))

Re: Error with guile function format

[Edouard Klein]

Dear François, Ricardo and divoplade,

This was indeed the issue, and the correct fix. Thank you for your
explanations. I'm not familiar with the notion of ports, coming from
languages that don't have them, but I see now how useful they are !
They're like the standard input/output of the shell, with redirections,
but for any function inside the program. Awesome :)

Thank you very much !

I've submitted a patch upstream (and also played quake 3 for the first
time in ~15 years :) oh the memories)

Cheers,

Edouard.


e...@beaver-labs.com writes:

> Dear Guixers,
>
> In a channel-that-should-not-be-named, there is the following snippet
>
>(apply invoke "7z" "e" (assoc-ref %build-inputs "patch-data")
>   (map (cut format "quake3-latest-pk3s/baseq3/pak~a.pk3" <>)
>(iota 8 1)))
>
> Which, as far as my limited knowledge of Guile goes, is correct.
>
> Yet the build fail with the following error message:
>
> In ice-9/format.scm:
>  43:8  0 (format "quake3-latest-pk3s/baseq3/pak~a.pk3" 1)
>
> ice-9/format.scm:43:8: In procedure format:
> format: expected a string for format string 1
>
>
> The first argument to format is a string, so I don't understand the
> fuss.
>
> Any idea would be welcome :)
>
> Thanks !
>
> Edouard.

Re: Running Substitute Server over https

[Edouard Klein]

Hi phil,

Not answering your question directly, but last time I wanted to secure
the connection between a client and a substitute I used an ssh tunnel:


# On the server
guix archive --generate-key
ssh root@client guix archive --authorize < /etc/guix/signing-key.pub
guix publish&
ssh -N -R 8081:localhost:8080 root@client&

# On the client
guix build --substitute-urls=http://localhost:8081 whatever

This may or may not be amendable to your situation, and may or may not
lend itself to tlstunnel instead of ssh.

Good luck :)


Phil writes:

> Hi all,
>
> I have a substitute server running trivially using http, but there
> doesn't seem to be anything in the manual about how/where to configure
> my certificate file, etc, to run a server over https.
>
> Can anyone advise on https setup for 'guix publish'?
>
> Thanks,
> Phil.

Re: ebook reader recommendations?

[Edouard Klein]

Pierre Neidhardt writes:

> Hi John,
>
> Thanks for the hint.
> I suppose this is the product you were talking about:
>
>   https://remarkable.com/
>
> Can you expand on how "hackable" it is?  Can we replace the software?
> If not, what kind of access to the OS do we have?  Any link?

You basically can SSH into it. It's running Linux on ARM. As far as I know the 
UI and support
software is closed source, but there is a great community building open
source tools for the device.

https://github.com/reHackable/awesome-reMarkable

>
> Cheers!

Re: Port forwarding for Guix containers

[Edouard Klein]

zimoun writes:

> Hi,
>
> On Fri, 20 Nov 2020 at 19:26, Christopher Baines  wrote:
>> Zhu Zihao  writes:
>>
>>> I found guix container "created by `guix environment --container` or
>>> `guix system container`" is very useful to isolate some service. But
>>> it only supports fully isolated network namespace or just share with
>>> host, it's not so safe IMO.
>>
>> I'll assume that a fully isolated network namespace is safer in whatever
>> way you're referring to than a shared network namespace. However, for a
>> shared network namespace, what threats is that not safe in respect to?
>>
>> In the shared network namespace scenario, you are free to use a
>> firewall, which could help protect against threats coming from other
>> machines, for example by creating a list of IP addresses which are
>> allowed to connect, and dropping any other traffic.
>
> I do not know about the initial motivation and I do not know either if
> it makes sense in the context of “guix environment”.  One point is that
> Docker [1] provides a way to specify the firewall rules.  Well, somehow,
> something similar as ’--share’ but for network.
>
>
> 1: 
>

My .02€:

I am in the camp of letting the container do the job with an operating
system declaration, and keeping guix simple. That way, one can choose
e.g. nginx to do the proxying, or an actual firewall, etc. The right
tool for the right job.

Sure it's not as easy as docker's -p option, but it's more secure and
cleaner.



> All the best,
> simon

Re: warning: failed to install locale

[Edouard KLEIN]

I had the same problem, which was solved by installing glibc-utf8-locales
in root's profile and adding the export line to root's ~/.profile, which
fits Ricardo's explanations.

Le jeu. 17 janv. 2019 à 21:56, Quiliro Ordonez  a
écrit :

> Thank you for this straightforward answer Ricardo. I post some insights
> below.
>
> El 2019-01-17 09:24, Ricardo Wurmus escribió:
> > This is in your environment.  But what about the daemon’s environment?
> > It is not started in your environment where GUIX_LOCPATH is set.  How do
> > you start the daemon?  If it’s via systemd you may want to look at the
> > service file to see where GUIX_LOCPATH points.
>
> In fact:
> echo $GUIX_LOCPATH
> gives no output as root (which runs the Guix daemon, presumably).
>
> Where is the service file supposed to be and how to include GUIX_LOCPATH
> in it?
>
> I also ran the script to install Guix. Perhaps this script should do all
> the setup.
>
>

Data dirs and shepherd services

[Edouard KLEIN]

Hi guys !

I'm packaging a piece of software that is due in the next few days and I'm
cutting corners everywhere. I'll come back to it later and clean things up,
in the process I've packaged some free software lacking from the
distribution, that I'll send the patches for.

In the meantime, I have some questions:

- My software needs to serve a bunch of static files. Those belong to a
package that is 'propagated-input' installed with the big metapackage of
the whole software.
By using
$guix package list-installed
I can see the store directory of the metapackage, but the propagated-inputs
packages are not listed, and I don't know how to find their store
directories. The question here is multifold:
- Those static files are linked in .guix-profile: is referring to those
links the correct way of referring to them ? Because I need to serve them
via a webserver and I don't want to serve my whole .guix-profile dir, it
may prove cumbersome.
- Is there a way of knowing the store dir of an arbitrary package ? Would
this be the correct way of referring to those static files ?
- Can I specify an out-of-store static dir (such as e.g. /opt/var/www)
where to copy or link the files when installing the package ? Ideally I'd
like to do that in the package description, but a command line switch would
be OK as well.


Next, my software needs a temp zone where to store user files (those can be
destroyed across reboots). This zone should be organized with multiple
dirs, some static files, etc. I assume the store dir of the package is not
the correct place to put these dirs, yet it is the only directory in which
I know how to create things in the package description.
- Is it OK to use the store dir as a user-provided data storage place ? I
assume not.
- How can I specify an out-of-store storage place (e.g.
/opt/share/my_software)  in the package description ?
- Failing that, how can I specify it as a command line flag ?


Finally, I hope to use GNU shepherd to start my software, but the
documentation on how to write a service is not there yet:
https://www.gnu.org/software/shepherd/manual/shepherd.html#Service-Examples

Do you know of any examples I could draw inspiration from ?


Cheers, and thanks in advance for the help :)

Re: Using 'guix system disk-image' on a non-GuixSD OS

[Edouard KLEIN]

Hi Gábor,

Indeed, the command now finishes without errors. I slightly changed the
config.scm in the meantime. For reference here is the one where it worked.
I see no changes that could have had an impact but don't trust me on this.

Thanks for the help,

Edouard.



--config.scm

;; This is an operating system configuration template
;; for a "bare bones" setup, with no X11 display server.

(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules screen ssh)

(operating-system
  (host-name "GuixSD_Base")
  (timezone "UTC")
  (locale "en_US.utf8")

  ;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
  ;; target hard disk, and "my-root" is the label of the target
  ;; root file system.
  (bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")))
  (file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
  %base-file-systems))

  ;; This is where user accounts are specified.  The "root"
  ;; account is implicit, and is initially created with the
  ;; empty password.
  (users (cons (user-account
(name "edouard")
(comment "boudoir")
(group "users")

;; Adding the account to the "wheel" group
;; makes it a sudoer.  Adding it to "audio"
;; and "video" allows the user to play sound
;; and access the webcam.
(supplementary-groups '("wheel"
"audio" "video"))
(home-directory "/home/edouard"))
   %base-user-accounts))

  ;; Globally-installed packages.
  (packages (append (map specification->package
 '("tmux" "openssh"))
%base-packages))

  ;; Add services to the baseline: a DHCP client and
  ;; an SSH server.
  (services (cons*
 ;; (dhcp-client-service)
 (static-networking-service
  "ens3"
  "192.168.50.58"
  #:netmask "255.255.0.0"
  #:gateway "192.168.50.1"
  #:name-servers '("8.8.8.8" "8.8.4.4"))
 (service openssh-service-type
  (openssh-configuration
   (authorized-keys
`(("edouard" ,(local-file "edouard.pub"))
  ("root" ,(local-file "edouard.pub"
 (permit-root-login 'without-password)
   (port-number 22)))
 %base-services)))


On Thu, 25 Oct 2018 at 16:13 Gábor Boskovits  wrote:

> Hello Edouard,
>
> Edouard KLEIN  ezt írta (időpont: 2018. okt.
> 25., Cs, 15:34):
> >
> > Hi all,
> >
> > I do not know whether the "guix system disk-image" command is supposed
> to work on a non GuixSD system.
> >
> > If it is, then I'm running into an error while trying to create a disk
> from a system declaration on my Arch Linux OS.
> >
> > I run:
> > $ guix system disk-image --fallback config.scm
> >
> > with config.scm copied at the end of this email.
> >
> > I get the error message at the end of this emai.
> >
> > I do not really know where to start looking. It appears that the error
> is in the qemu package, which is necessary for grub. I tried removing the
> bootloader part of the system declaration, as I can boot from the ext4
> partition directly, but it seems necessary to have one such part in the OS
> declaration.
> >
> > Any help would be appreciated. In the meantime I'm running the command
> in a GuixSD VM, but it's taking forever and it's way more cumbersome than
> being able to run it on any system.
> >
> > Thanks in advance,
> >
> > Edouard.
> >
> >
> >
> > ---config.scm
> >
> > ;; This is an operating system configuration template
> > ;; for a "bare bones" setup, with no X11 display server.
> >
> > (use-modules (gnu))
> > (use-service-modules networking ssh)
> > (use-package-modules screen ssh)
> >
> > (operating-system
> >   (host-name "GuixSD_Base")
> >   (timezone "UTC")
> >   (locale "en_US.utf8")
> >
> >   ;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
> >   ;; target hard disk, and "my-root" is the label of 

Using 'guix system disk-image' on a non-GuixSD OS

[Edouard KLEIN]

Hi all,

I do not know whether the "guix system disk-image" command is supposed to
work on a non GuixSD system.

If it is, then I'm running into an error while trying to create a disk from
a system declaration on my Arch Linux OS.

I run:
$ guix system disk-image --fallback config.scm

with config.scm copied at the end of this email.

I get the error message at the end of this emai.

I do not really know where to start looking. It appears that the error is
in the qemu package, which is necessary for grub. I tried removing the
bootloader part of the system declaration, as I can boot from the ext4
partition directly, but it seems necessary to have one such part in the OS
declaration.

Any help would be appreciated. In the meantime I'm running the command in a
GuixSD VM, but it's taking forever and it's way more cumbersome than being
able to run it on any system.

Thanks in advance,

Edouard.



---config.scm

;; This is an operating system configuration template
;; for a "bare bones" setup, with no X11 display server.

(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules screen ssh)

(operating-system
  (host-name "GuixSD_Base")
  (timezone "UTC")
  (locale "en_US.utf8")

  ;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
  ;; target hard disk, and "my-root" is the label of the target
  ;; root file system.
  (bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")))
  (file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
  %base-file-systems))

  ;; This is where user accounts are specified.  The "root"
  ;; account is implicit, and is initially created with the
  ;; empty password.
  (users (cons (user-account
(name "edouard")
(comment "boudoir")
(group "users")

;; Adding the account to the "wheel" group
;; makes it a sudoer.  Adding it to "audio"
;; and "video" allows the user to play sound
;; and access the webcam.
(supplementary-groups '("wheel"
"audio" "video"))
(home-directory "/home/edouard"))
   %base-user-accounts))

  ;; Globally-installed packages.
  (packages (append (map specification->package
 '("tmux" "openssh"))
%base-packages))

  ;; Add services to the baseline: a DHCP client and
  ;; an SSH server.
  (services (cons* (dhcp-client-service)
   (service openssh-service-type
(openssh-configuration
 (authorized-keys
  '(("edouard" ,(local-file "edouard.pub"))
("root" ,(local-file "edouard.pub"
   (permit-root-login 'without-password)
 (port-number 22)))
   %base-services)))
error message
c++
-I/gnu/store/pslvw8b4r0m5vmbz2ml7whcv2wbdpa57-pixman-0.34.0/include/pixman-1
-I/tmp/guix-build-qemu-minimal-2.10.2.drv-0/qemu-2.10.2/dtc/libfdt -pthread
-I/gnu/s[14/1947]
cagl47zbb6krfpmwm31m70s9pk00-glib-2.56.0/include/glib-2.0
-I/gnu/store/x9lfcagl47zbb6krfpmwm31m70s9pk00-glib-2.56.0/lib/glib-2.0/include
-DNCURSES_WIDECHAR -D_GNU_SOURCE -D_D
EFAULT_SOURCE -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef
-Wwrite-strings -Wmissing-p
rototypes -fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security
-Wformat-y2k -Winit-self -Wignore
d-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits
-fstack-protector-strong
 -I/gnu/store/8679cp88yg5jrq2q1944xf14ibyp1kp7-libpng-1.6.34/include/libpn
g16 -I/tmp/guix-build-qemu-minimal-2.10.2.drv-0/qemu-2.10.2/tests -O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2  -Wl,--warn-common -Wl,-z,relro
-Wl,-z,now -pie -m64 -Wl,--warn-co
mmon -Wl,-z,relro -Wl,-z,now -pie -m64 -lrt -o tests/test-replication
tests/test-replication.o block.o blockjob.o qemu-io-cmds.o replication.o
block/raw-format.o block/qcow.o
 block/vdi.o block/vmdk.o block/cloop.o block/bochs.o block/vpc.o
block/vvfat.o block/dmg.o block/qcow2.o block/qcow2-refcount.o
block/qcow2-cluster.o block/qcow2-snapshot.o
block/qcow2-cache.o block/qcow2-bitmap.o block/qed.o block/qed-l2-cache.o
block/qed-table.o block/qed-cluster.o block/qed-check.o block/vhdx.o
block/vhdx-endian.o block/vhdx-
log.o block/quorum.o block/parallels.o block/blkdebug.o block/blkverify.o
block/blkreplay.o block/block-backend.o block/snapshot.o block/qapi.o
block/file-posix.o block/linux
-aio.o block/null.o block/mirror.o block/commit.o block/io.o
block/throttle-groups.o block/nbd.o