Re: [PATCH guix-artwork v4] website: posts: Add Dissecting Guix, Part 1: Derivations.

[(]

On Mon Jan 9, 2023 at 11:13 AM GMT, Ludovic Courtès wrote:
> Yay!  That can even be parts 2 and 3.  :-)

Probably, yeah.  It might take me longer to write the monads post, since i 
didn't
understand Guix's monads when I started :) (I do understand them a bit now, 
though.)

-- (


signature.asc
Description: PGP signature

Re: Golang go-updates feature branch?

[Leo Famulari]

On Sun, Jan 08, 2023 at 10:32:36PM +, John Kehayias wrote:
> Heartily agree here. This has come up a few times on #guix and generally with 
> support (don't let me speak for everyone though). I think the idea of smaller 
> and more frequent feature branches is a great idea: less code changes coming 
> to master to review at once (compared to big core-updates merges), 
> substitutes and closer to master to be easier for people to pull the branch 
> and test, and some areas despite the number of builds would work nicely as a 
> branch than just pushed (and lingering) into core-updates for much later.

I agree with all your points. We used to work this way back in the day
when there weren't very many Guix packages. There was always a
'core-updates' job, but if it was limited to packages that truly are
"core". Then, for several years, the build farm was underpowered
relative to the number of packages and it became impractical. I think we
are past that now.

I've attached a couple patches to get started but I need help getting
them to work.

There is 'etc/go-manifest.scm', which does work with `guix package -m
etc/go-manifest.scm --dry-run`.

And there is a diff for 'build-aux/cuirass/evaluate.scm', so that I can
test it with `make cuirass-jobs`.

But, `make cuirass-jobs` crashes with this manifest and I don't know
why:

--
$ make cuirass-jobs
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
rm -rf "cuirass-jobs"
  GEN  cuirass-jobs
Computing Guix derivation for 'x86_64-linux'... /
In thread:
uncaught throw to %exception: (#< arguments: (wrong-type-arg 
"primitive-load" "Wrong type argument in position ~A (expecting ~A): ~S" (1 
"string" #f) (#f)) inferior: # stack: ((#f 
("ice-9/boot-9.scm" 1779 13)) (raise-exception ("ice-9/boot-9.scm" 1682 16)) 
(raise-exception ("ice-9/boot-9.scm" 1684 16)) (primitive-load (#f #f #f)) 
(save-module-excursion ("ice-9/boot-9.scm" 2835 4)) (#f (#f #f #f)) (map1 
("srfi/srfi-1.scm" 585 17)) (append-map ("srfi/srfi-1.scm" 672 15)) (#f 
("gnu/ci.scm" 449 8)) (map1 ("srfi/srfi-1.scm" 585 17)) (append-map 
("srfi/srfi-1.scm" 672 15)) (cuirass-jobs ("gnu/ci.scm" 489 4)) (#f 
("ice-9/eval.scm" 158 9)) (with-exception-handler ("ice-9/boot-9.scm" 1751 10)) 
(call-with-prompt ("ice-9/boot-9.scm" 723 2)) (#f (#f #f #f)) (#f 
("guix/repl.scm" 98 21)) (with-exception-handler ("ice-9/boot-9.scm" 1751 10)) 
(with-exception-handler ("ice-9/boot-9.scm" 1746 15)) (#f ("guix/repl.scm" 125 
7)))>)
In thread:
uncaught throw to %exception: (#< arguments: (wrong-type-arg 
"primitive-load" "Wrong type argument in position ~A (expecting ~A): ~S" (1 
"string" #f) (#f)) inferior: # stack: ((#f 
("ice-9/boot-9.scm" 1779 13)) (raise-exception ("ice-9/boot-9.scm" 1682 16)) 
(raise-exception ("ice-9/boot-9.scm" 1684 16)) (primitive-load (#f #f #f)) 
(save-module-excursion ("ice-9/boot-9.scm" 2835 4)) (#f (#f #f #f)) (map1 
("srfi/srfi-1.scm" 585 17)) (append-map ("srfi/srfi-1.scm" 672 15)) (#f 
("gnu/ci.scm" 449 8)) (map1 ("srfi/srfi-1.scm" 585 17)) (append-map 
("srfi/srfi-1.scm" 672 15)) (cuirass-jobs ("gnu/ci.scm" 489 4)) (#f 
("ice-9/eval.scm" 158 9)) (with-exception-handler ("ice-9/boot-9.scm" 1751 10)) 
(call-with-prompt ("ice-9/boot-9.scm" 723 2)) (#f (#f #f #f)) (#f 
("guix/repl.scm" 98 21)) (with-exception-handler ("ice-9/boot-9.scm" 1751 10)) 
(with-exception-handler ("ice-9/boot-9.scm" 1746 15)) (#f ("guix/repl.scm" 125 
7)))>)
In thread:
uncaught throw to %exception: (#< arguments: (wrong-type-arg 
"primitive-load" "Wrong type argument in position ~A (expecting ~A): ~S" (1 
"string" #f) (#f)) inferior: # stack: ((#f 
("ice-9/boot-9.scm" 1779 13)) (raise-exception ("ice-9/boot-9.scm" 1682 16)) 
(raise-exception ("ice-9/boot-9.scm" 1684 16)) (primitive-load (#f #f #f)) 
(save-module-excursion ("ice-9/boot-9.scm" 2835 4)) (#f (#f #f #f)) (map1 
("srfi/srfi-1.scm" 585 17)) (append-map ("srfi/srfi-1.scm" 672 15)) (#f 
("gnu/ci.scm" 449 8)) (map1 ("srfi/srfi-1.scm" 585 17)) (append-map 
("srfi/srfi-1.scm" 672 15)) (cuirass-jobs ("gnu/ci.scm" 489 4)) (#f 
("ice-9/eval.scm" 158 9)) (with-exception-handler ("ice-9/boot-9.scm" 1751 10)) 
(call-with-prompt ("ice-9/boot-9.scm" 723 2)) (#f (#f #f #f)) (#f 
("guix/repl.scm" 98 21)) (with-exception-handler ("ice-9/boot-9.scm" 1751 10)) 
(with-exception-handler ("ice-9/boot-9.scm" 1746 15)) (#f ("guix/repl.scm" 125 
7)))>)
In thread:
uncaught throw to %exception: (#< arguments: (wrong-type-arg 
"primitive-load" "Wrong type argument in position ~A (expecting ~A): ~S" (1 
"string" #f) (#f)) inferior: # stack: ((#f 
("ice-9/boot-9.scm" 1779 13)) (raise-exception ("ice-9/boot-9.scm" 1682 16)) 
(raise-exception ("ice-9/boot-9.scm" 1684 16)) (primitive-load (#f #f #f)) 
(save-module-excursion ("ice-9/boot-9.scm" 2835 4)) (#f (#f #f #f)) (map1 
("srfi/srfi-1.scm" 585 17)) (append-map ("srfi/srfi-1.scm" 672 15)) (#f 
("gnu/ci.scm" 449 8)) (map1 ("srfi/srfi-1.scm" 585 

Re: bug#58813: can't substitute etc/teams.scm command as doc suggests

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Simon Tournier  writes:
>>
>>> Hi Ludo,
>>>
>>> On Tue, 03 Jan 2023 at 23:29, Ludovic Courtès  wrote:
>>>
 The manual recommends this (info "(guix) Teams"):

   git send-email --to issue_num...@debbugs.gnu.org $(./etc/teams.scm cc 
 mentors) *.patch

 where:

 --8<---cut here---start->8---
 λ ./etc/teams.scm cc mentors
 --add-header="X-Debbugs-Cc: r...@raghavgururajan.name"
 --add-header="X-Debbugs-Cc: zimon.touto...@gmail.com" …
 --8<---cut here---end--->8---

 I believe this cannot work because the shell will split words on each
 whitespace; IOW, the double quotes above do not have the desired effect.
>>
>>> Well, IIUC, this part is tracked by #58813 [1].
>>>
>>> 1: 
>>
>> Indeed (CC'd).
>>
>> I thought about not using whitespace in the generated output, but I'm
>> not sure if Debbugs or email clients in general would care, plus it's a
>> dirty fix.
>
> Right.
>
> How about just outputting a line like:
>
>   X-Debbugs-Cc: ma...@example.org, l...@example.org
>
> that people would paste in their cover letter?

Yes, that's better.

> How do Linux’s scripts work?

I think the scripts just print stuff at the terminal and expect the user
to copy paste.  Patman can be used to provide automation on top of that.

>> With the recent patman integration merged (though do apply #60576 as a
>> fixup commit), I'm tempted to remove the mentions of git send-email
>> $(etc/teams.scm cc-members ...) and replace that by 'Further automation
>> of git send-email and etc/teams.scm is possible via the patman package'.
>>
>> What do you think?
>
> This is the first time I hear about patman.  :-)
>
> The “Submitting Patches” section mentions ‘git send-email’; I don’t
> think this is about to change, is it?

It wouldn't change; patman would be hinted at briefly with a reference
to its documentation (info '(u-boot) Patman patch manager' from the
u-boot-documentation package) as a nice way to stay organize with
submissions and automate a few things on top of git send-email.

-- 
Thanks,
Maxim

Re: git-fetch without a hash

[Stephen Paul Weber]

Once we update the ‘guix’ package, the daemon will no longer accept
‘url-fetch’ downloads with hash = #f.


Ok.  Is there something like (git-checkout) we can use that will work 
instead of an (origin) here for url downloads?

Re: adding motif to guix

[David Pirotte]

> ...
> Thanks for the clarification. My interest in this package is because
> openmotif is the best of the X window managers that do not suffer from
> a rather infamous and longstanding GTK bug which will bring down
> Emacs.

Fwiw, debian has an 'emacs-lucid' package (maintained by the debian
guile packages maintainer) that does not depends on Gtk (which i didn't
find on https://packages.guix.gnu.org/)

David

[1]
https://packages.debian.org/search?keywords=emacs-lucid=names=all=all



pgphsTkelZkQG.pgp
Description: OpenPGP digital signature

Re: Should a Guix Channel Have a Description?

[Ludovic Courtès]

Hi!

"jgart"  skribis:

> What do you think of this proposal:
>
> https://issues.guix.gnu.org/60630

Just replied.  :-)

> Here's a user story:
>
> WhereIsEveryone is developing a webring as an API for discovering Guix 
> channels and their contents.
>
> With a growing* channels.scm file, IWBN to have a description about each 
> channel as part of the data about that channel in the same way that users get 
> a description about a package.
>
> WDYT

I think that would be useful to package registries.  For example, we set
up  but had to provide all the metadata
locally.  Not ideal!

Ludo’.

Re: bug#58813: can't substitute etc/teams.scm command as doc suggests

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Simon Tournier  writes:
>
>> Hi Ludo,
>>
>> On Tue, 03 Jan 2023 at 23:29, Ludovic Courtès  wrote:
>>
>>> The manual recommends this (info "(guix) Teams"):
>>>
>>>   git send-email --to issue_num...@debbugs.gnu.org $(./etc/teams.scm cc 
>>> mentors) *.patch
>>>
>>> where:
>>>
>>> --8<---cut here---start->8---
>>> λ ./etc/teams.scm cc mentors
>>> --add-header="X-Debbugs-Cc: r...@raghavgururajan.name"
>>> --add-header="X-Debbugs-Cc: zimon.touto...@gmail.com" …
>>> --8<---cut here---end--->8---
>>>
>>> I believe this cannot work because the shell will split words on each
>>> whitespace; IOW, the double quotes above do not have the desired effect.
>
>> Well, IIUC, this part is tracked by #58813 [1].
>>
>> 1: 
>
> Indeed (CC'd).
>
> I thought about not using whitespace in the generated output, but I'm
> not sure if Debbugs or email clients in general would care, plus it's a
> dirty fix.

Right.

How about just outputting a line like:

  X-Debbugs-Cc: ma...@example.org, l...@example.org

that people would paste in their cover letter?

How do Linux’s scripts work?

> With the recent patman integration merged (though do apply #60576 as a
> fixup commit), I'm tempted to remove the mentions of git send-email
> $(etc/teams.scm cc-members ...) and replace that by 'Further automation
> of git send-email and etc/teams.scm is possible via the patman package'.
>
> What do you think?

This is the first time I hear about patman.  :-)

The “Submitting Patches” section mentions ‘git send-email’; I don’t
think this is about to change, is it?

Thanks,
Ludo’.

Setting up the release team

[Ludovic Courtès]

Hello!

Simon Tournier  skribis:

>> I think we should start thinking about the next release, forming a
>> small release team, and I’ll be happy to mentor!
>
> Definitively!  Count on me to candidate on such team. :-)

Yay, thank you!!

Who else is able and willing to dedicate time to this?  I think work
could actually start real soon.

As I see it, people on the release team will *not* do all the work.
Rather, they will keep track of things and make sure we together tackle
the relevant tasks so we converge towards a release.  It does not have
to be very technical.

> From my point of view, this team will be a rotating effort.  For
> instance, from 2 to 4 people will be part.  The duty is to be part for 2
> releases; 1-2 person step downs for welcoming 1-2 new person after each
> release.  Well, something similar to NixOS release management.
>
> As usual, the question is about the bootstrap. ;-)
>
> 5: 
> 6: 

Agreed, that would be ideal.

I think we should formalize it at some point along the lines of what
NixOS did, presumably with a section in the manual.

Thanks,
Ludo’.

Re: git-fetch without a hash

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> scheme@(guile-user)> ,lower (origin
> (method url-fetch)
> (uri "mirror://gnu/hello/hello-2.12.1.tar.gz")
> (sha256 #f))
> $6 = # /gnu/store/lz34lhyxhq5wxj87fnd465hmwbhv17bn-hello-2.12.1.tar.gz.drv => 
> /gnu/store/xfc7gsn10j09bi89ldbpfbppfkcldfy9-hello-2.12.1.tar.gz 7f3ff487c000>
> scheme@(guile-user)> (derivation-outputs $6)
> $7 = (("out" . #< path: 
> "/gnu/store/xfc7gsn10j09bi89ldbpfbppfkcldfy9-hello-2.12.1.tar.gz" hash-algo: 
> sha256 hash: #f recursive?: #f>))
> scheme@(guile-user)> (fixed-output-derivation? $6)
> $8 = #f
>
> As it turns out, guix-daemon turns off the chroot for all built-in
> builders, fixed-output or not; quoth ‘build.cc’:
>
> /* Note: built-in builders are *not* running in a chroot environment so
>that we can easily implement them in Guile without having it as a
>derivation input (they are running under a separate build user,
>though).  */
> useChroot = settings.useChroot && !isBuiltin(drv);
>
> I was actually surprised to see this, this wasn’t really intended.  The
> good news is that this is safe AFAICS: there’s only one built-in builder
> to date, and that’s “download”.

After investigating, I found that ‘guix perform-download’ already has a
check in place:

  (unless (and algo hash)
(leave (G_ "~a is not a fixed-output derivation~%")
   (derivation-file-name drv)))

The check wasn’t working because ‘hash’ was #vu8() instead of #f.  This
is fixed in 5d24e57a611b43ff68700379338b899f62d198cc.

Once we update the ‘guix’ package, the daemon will no longer accept
‘url-fetch’ downloads with hash = #f.

Thanks again for reporting this oddity!

Ludo’.

Re: 01/09: services: base: Add extra-env support to guix-configuration.

[Mathieu Othacehe]

Hey,

> Nitpick: To stick to existing naming conventions, could we rename it to
> ‘environment-variables’ or ‘environment’?

I changed to environment and pushed.

Thanks,

Mathieu

Re: Command consistency: suggestion

[Joshua Branson]

Paul Jewell via "Development of GNU Guix and the GNU System
distribution."  writes:

> Good morning!
>
> It struck me this weekend that there is some difference in the command 
> structure
> for the different guix sub commands. For example:
>
> guix package --list-generations
>
> and
>
> guix system list-generations
>
> guix package has everything as an flag, but guix system (and guix home) uses 
> the
> concept of ACTION with options and arguments.
>
> Perhaps the latter is clearer, and guix package should also follow the same
> model?

+1

Re: unacknowledged patches

[Csepp]

Csepp  writes:

> (asking this here as well, in addition to IRC)
>
> Hey, I sent a large patch set last night (39 patches) but only recieved
> confirmation for 13 of them.  What do I need to do to get the rest
> acknowledged?
> Here are the ones that made it to debbugs:
> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;include=originator%3Acsepp
> It's part of my thesis project for getting MirageOS unikernels deployed
> with Guix, so it would help if they were accepted sooner rather than
> later.
> Either way I'll be adding more code during January, so it's not a
> showstopper if it's not merged, but I'd rather be upstreaming things
> early, so I don't have to rework huge chunks of it later.

Thanks to nckx, I managed to merge the accepted ones, but now it looks
like all (?) have been merged into
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60673
even the ones that did not get an issue number before.

So I think the mystery has been solved.

Re: advanced?

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

Ludovic Courtès  writes:

> Hello,
>
> (Cc: Luis, for the web site design.)
>
> Simon Josefsson  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Or if we do want to explain more, then perhaps we need a list of
>>> features that would also include things like Docker/VM image generation,
>>> declarative home environments, etc.  But that’s broader topic.
>>
>> Yes, that makes sense.  I'm not the best person to summarize it, but
>> starting pointers if someone wants to take it further:
>>
>> * Dedication to free software goals and the GNU community
>>
>> * Shepherd init system written in Guile
>>
>> * Declarative stateless system configurations
>>
>> * Transactional upgrades and roll-backs
>>
>> * Reproducible build environments
>>
>> * Designed towards bootstrappable builds
>>
>> Maybe this fits better directly in the Introduction section of the
>> manual?  https://guix.gnu.org/manual/en/html_node/Introduction.html
>
> I guess we should rework the “Introduction” and “Features” sections,
> which were written in the early days.
>
> The points you list above are a great starting point, and I guess that
> would also be a good fit for the front page; currently there’s no
> “feature list” there.  That old “Guix in action” video also ought to be
> replaced.

Reflecting on the feature list, I think we should mention that Guix is a
_rolling_ distribution and package manager, and maybe explain what that
means.  I don't think this is clear from the web site or manual now, but
I may be missing it.

Perhaps the release and update model of Guix could use some dedicated
new documentation?  The relationship between the rolling master branch,
the core-updates branch, the security graft mechanism, the substitute
build servers and the versioned installer releases is not terribly clear
to me as a new user, and having an understanding of these concepts helps
to make contributions.  I have a feeling there may be more nuances that
are useful to know about that I'm not familiar with; for example, the
intended use of the version-X.Y.Z branches.

/Simon


signature.asc
Description: PGP signature

unacknowledged patches

[Csepp]

(asking this here as well, in addition to IRC)

Hey, I sent a large patch set last night (39 patches) but only recieved
confirmation for 13 of them.  What do I need to do to get the rest
acknowledged?
Here are the ones that made it to debbugs:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;include=originator%3Acsepp
It's part of my thesis project for getting MirageOS unikernels deployed
with Guix, so it would help if they were accepted sooner rather than
later.
Either way I'll be adding more code during January, so it's not a
showstopper if it's not merged, but I'd rather be upstreaming things
early, so I don't have to rework huge chunks of it later.

Re: Some team related thoughts and questions...

[Simon Tournier]

Hi Vagrant,

On ven., 06 janv. 2023 at 10:42, Vagrant Cascadian  wrote:

> More I wanted to look through the patch text rather than the package
> descriptions. It would ideally catch things like "reproducible" or
> "deterministic" in comments in patches as well as git commit summary.

Well, IIUC, your point would be to have teams based on “topic“ referred
by search term in patches.  Why not, although it is far to be
implemented, I guess. ;-)

BTW, I would recommend to give a look at lei [1,2] from the Guix package
public-inbox.  For instance, over the last 12 months, all patches
containing the terms ’r-build-system’ and ’reproducible’,

1. Extract from a public-inbox instance:

guix shell public-inbox \
 -- lei q --threads --dedupe=mid \
 -I https://yhetil.org/guix-patches/ -o /tmp/Mail/patches \
 'dfn:gnu/packages AND b:r-build-system AND b:reproducible AND 
rt:12.months.ago..'

2. Read it with a mail reader support Maildir:

guix shell neomutt -- neomutt -f /tmp/Mail/patches


where

   dfn: match filename from diff
   b:   match within message body, including text attachments
   rt:  match date-time range, git "approxidate" formats supported
Open-ended ranges such as `d:last.week..' and `d:..2.days.ago'
are supported

1: 
2: 

Cheers,
simon

Command consistency: suggestion

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

Good morning!

It struck me this weekend that there is some difference in the command 
structure for the different guix sub commands. For example:


guix package --list-generations

and

guix system list-generations

guix package has everything as an flag, but guix system (and guix home) 
uses the concept of ACTION with options and arguments.


Perhaps the latter is clearer, and guix package should also follow the 
same model?

Re: Packaging OCaml repositories that define multiple packages?

[Csepp]

pukkamustard  writes:

> Csepp  writes:
>
>> But there are packages that were added by others that already
>> specify
>> which subpackage they build, and yet seem to be accepted as
>> subpackages.
>
> Do you have an example?
>
> And maybe send in your patches, that may provide more context around
> this discussion.

I submitted them last night, but only 13 out of the 39 got acknowledged.
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;include=originator%3Acsepp
The one with the aliases is among the unacknowledged ones.

Re: advanced?

[Julien Lepiller]

Already fixed in weblate for French. Will push the update shortly :)

Le 9 janvier 2023 12:12:27 GMT+01:00, "Ludovic Courtès"  a écrit :
>Hey,
>
>A heads-up for Julien and the translators:
>
>Ludovic Courtès  skribis:
>
>> Simon Josefsson via "Development of GNU Guix and the GNU System
>> distribution."  skribis:
>>
>>> From aac8f6d1fb382b9f9120b7cd51dc80e8ef07cc03 Mon Sep 17 00:00:00 2001
>>> From: Simon Josefsson 
>>> Date: Sat, 26 Nov 2022 22:35:15 +0100
>>> Subject: [PATCH] website: Reduce use of 'advanced' term.
>>>
>>> ---
>>>  website/apps/base/templates/about.scm | 4 ++--
>>>  website/apps/base/templates/home.scm  | 6 +++---
>>>  2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> It’s been a month and it looks like there wasn’t any opposition to this
>> change, so I went ahead and pushed it.
>
>Unsurprisingly, removing the one word invalidated all translations,
>as can be seen at the top of the front page:
>
>  
>
>Ludo’.

Re: git-fetch without a hash

[Ludovic Courtès]

Simon Tournier  skribis:

> Maybe my question is naive but what is the use case for this (sha256 #f)
> in the first place?  Because maybe it could just error using some
> ’sanitize’ for the hash record field.

There’s a couple of uses: Chromium, IceCat, and Linux-libre (IIRC).

I don’t like that, but I’m not sure what it would take to change these
to  or something like that.

Ludo’.

Re: Builds of https://guix.gnu.org/{packages,sources}.json

[Ludovic Courtès]

Hi!

zimoun  skribis:

> On Wed, 04 Jan 2023 at 23:30, Ludovic Courtès  wrote:
>
>> Thus I moved the former (apps packages builder) module of the web site
>> to a script in maintenance.git, and had it run as a periodic mcron job
>> populating /srv/package-metadata, with nginx serving these two files
>> from that directory:
>>
>>   5664984 * hydra: web: Add mcron job to build /packages.json and 
>> /sources.json.
>>   318db3e * hydra: Add 'build-package-metadata.scm' script.
>
> Cool!  Thank you.
>
> I still have a WIP about turning this into manifest and then build
> sources.json via CI (Cuirass).  Well, I do not know if it would be
> useful or better compared to this new Guix REPL script.

I initially considered making it a manifest, as you had proposed a while
back, but all the “computation” (turning metadata into JSON) happens on
the “host side”, so I figured there’s no need for derivations and all.

Thanks,
Ludo’.

Re: [PATCH guix-artwork v4] website: posts: Add Dissecting Guix, Part 1: Derivations.

[Ludovic Courtès]

"("  skribis:

> On Wed Jan 4, 2023 at 12:00 PM GMT, Ludovic Courtès wrote:
>> Finally pushed!  It should show up online soon.  Looking forward to
>> part 2.  :-)
>
> \o/
>
> Next part will be about monads and G-expressions :)

Yay!  That can even be parts 2 and 3.  :-)

Ludo’.

Re: advanced?

[Ludovic Courtès]

Hey,

A heads-up for Julien and the translators:

Ludovic Courtès  skribis:

> Simon Josefsson via "Development of GNU Guix and the GNU System
> distribution."  skribis:
>
>> From aac8f6d1fb382b9f9120b7cd51dc80e8ef07cc03 Mon Sep 17 00:00:00 2001
>> From: Simon Josefsson 
>> Date: Sat, 26 Nov 2022 22:35:15 +0100
>> Subject: [PATCH] website: Reduce use of 'advanced' term.
>>
>> ---
>>  website/apps/base/templates/about.scm | 4 ++--
>>  website/apps/base/templates/home.scm  | 6 +++---
>>  2 files changed, 5 insertions(+), 5 deletions(-)
>
> It’s been a month and it looks like there wasn’t any opposition to this
> change, so I went ahead and pushed it.

Unsurprisingly, removing the one word invalidated all translations,
as can be seen at the top of the front page:

  

Ludo’.

Re: Improving how NGINX modules are used and built

[Ludovic Courtès]

Hello!

mirai  skribis:

> An oddity of how nginx modules are packaged in guix is that they all place
> the .so file under /etc/nginx/modules which is an odd directory to place 
> library object files.

To me that should be treated as a bug.  Those .so files should go to
$PKG/lib/nginx instead, or something similar.

> Looking at how network-manager-configuration handles its vpn-plugins field, 
> it seems doable
> that a similar approach can be used here.
> The existing nginx-modules should be changed to install their .so files under 
> lib{64}/nginx
> instead and they should drop a etc/nginx/modules/foo_module.conf file 
> responsible for loading
> the module from the .so file. Including modules through a .conf should be 
> preferred as
> there's no guarantee that a module is a .so file or that it is always a
> _single_ .so file but in general this file should typically be a one-line 
> .conf file containing:
>
> load_module 
> "/gnu/store/..nginx-foo-module/usr/lib64/nginx/ngx_foo_module.so";
>
>
> And nginx-configuration should serialize the modules field as a series of 
> lines including
> the module .conf files, that is:
>
> include 
> "/gnu/store/..nginx-foo-module/etc/nginx/modules/ngx_foo_module.conf";
> include 
> "/gnu/store/..nginx-bar-module/etc/nginx/modules/ngx_bar_module.conf";
> ...
>
> (note: a directory union could be used here as an alternative)

I’d say that ideally, one could extend  with
modules, and that would automatically create the ‘load_module’
statements.

> On a related note, given how nginx-modules are expected to be built and 
> linked against the
> same nginx build, a new nginx-build-system for nginx modules could be 
> considered as the few
> existing nginx modules in guix are for the most part a copy-paste of each 
> other with some
> modifications here-and-there.

That would be an improvement, indeed!

Thanks,
Ludo’.

Re: 01/09: services: base: Add extra-env support to guix-configuration.

[Ludovic Courtès]

Hi,

guix-comm...@gnu.org skribis:

> commit 78a9b4f996ba18b4460ba380b87e9538007c27e0
> Author: Mathieu Othacehe 
> AuthorDate: Sat Jan 7 19:12:30 2023 +0100
>
> services: base: Add extra-env support to guix-configuration.
> 
> * gnu/services/base.scm ()[extra-env]: New field.
> (guix-shepherd-service): Honor it.
> * doc/guix.texi (Base Services): Document it.

[...]

> +@item @code{extra-env} (default: @code{'()})
> +Environment variables to be set before starting the daemon, as a list of
> +@code{key=value} strings.

Nitpick: To stick to existing naming conventions, could we rename it to
‘environment-variables’ or ‘environment’?

Ludo’.

Re: monero-gui-wallet does not show up in GNOME

[Guillaume Le Vaillant]

"jgart"  skribis:

> Hi,
>
> Even after logging out and in I still can't see `monero-wallet-gui` 
> executable show up when I press the "windows" key in the GNOME desktop.
>
> See this screenshot:
>
> https://up.nixnet.services/vyv1z6ia.png
>
> I installed monero-gui like this:
>
> https://git.sr.ht/~whereiseveryone/confetti/tree/gnome/item/home.scm
>
> WDYT

Hi,
It looks like there is no "monero-gui.desktop" file in the sources of
monero-gui; we could add a phase creating one in "share/applications/"...


signature.asc
Description: PGP signature