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

2023-01-05 Thread 宋文武
"("  writes:

> 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 :)
>

Great, I enjoy read Part 1, and waiting for next...  Thank you!



Re: Separate packages for wayland variants

2023-01-05 Thread Josselin Poiret
Hi Jonathan,

Jonathan Brielmaier  writes:

> Happy new year fellow Guix hackers,
>
> I wonder how we usually deal with package variants for wayland support.
>
> In my case I want to make keepassxc working more nicely on sway. It is
> as simple as adding `qtwayland-5` to its input list. Increasing its size
> from 1271.8 MiB to 1303.5 MiB.

My opinion is that those packages should work out of the box on wayland,
and we shouldn't duplicate CI effort by having duplicate packages.

The qt 5 base package should probably include qtwayland-5 somehow,
although I don't really know if that is doable without cycles.  We can
probably have a minimal package and one with qtwayland-5 included. I
don't think it is manageable to add qtwayland-5 to every single
application.

Best,
-- 
Josselin Poiret



Re: Expanding service procedure to accept additional arguments

2023-01-05 Thread Ryan Sundberg
Hi Bruno,

I have written some useful macros for transforming services as you describe 
here. You may find them useful:

https://lab.arctype.co/poseidon/poseidon-os/-/blob/master/poseidon/services/base.scm

Sincerely,
Ryan Sundberg

Dec 28, 2022 8:48:15 AM mirai :

> It is occasionally desired to have a service depend on additional shepherd 
> services
> than the defaults listed in their definition.
> 
> Examples where this can be seen is the shepherd-requirement field provided by
> nginx-configuration and opensmtpd-configuration, but these fields are 
> record-type
> specific and not available for the other service types (unless patched in).
> 
> An alternative to patching the original record-type is to define a custom 
> service-type
> record-type and inheriting it which is somewhat clunky for what amounts to a 
> setup-specific
> single line change:
> 
> --8<---cut here---start->8---
>   (shepherd-service
>     ...
> -   (requirement `(...))
> +   (requirement `(... ,@shepherd-requirement))
> --8<---cut here---end--->8---
> 
> Another type of extensibility that should be considered is the capability to 
> add extra
> service-extensions to existing service-type records.
> These can be useful for setup-specific (i.e. not applicable in general to be 
> included with Guix) scenarios,
> for example, to add an extra activation-service-type extension or have a 
> special-files-service-type
> extension that the service-type usually does not have.
> 
> The current approach that I'm aware of to achieve something similar is through
> simple-service, drawbacks being extra boilerplate code and a "disjoint" 
> service
> whose connection to the "parent service" is not immediately apparent.
> 
> --8<---cut here---start->8---
> ;; Ideally this should go in radicale-service-type
>   (simple-service 'chmod-radicale shepherd-root-service-type
>   (list (shepherd-service (requirement '(user-homes))
>   (provision '(radicale-home))
>   (documentation "chmod g+rwx 
> to user 'radicale' home.")
>   (one-shot? #t)
>   (start #~(lambda _
>  (chmod 
> (passwd:dir (getpw "radicale")) #o770)
>  #t)
> --8<---cut here---end--->8---
> 
> 
> Instead, what if the service procedure could be changed to accept optional 
> keyword arguments?
> Then one could express the extensions and dependencies as:
> 
> --8<---cut here---start->8---
> (services
>   (service foo-service-type
>    #:requirements '(networking nscd smtpd)
>    #:extensions (list (service-extension bar-service-type (lambda _ 
> ...))
>   (service-extension activation-service-type 
> (lambda _ ...
> --8<---cut here---end--->8---
> 
> Thoughts?
> 
> 
> Regards,
> Bruno



Re: ️ Install every Guix package ️

2023-01-05 Thread Eric Brown
kiasoc5  writes:

> I just realized that this downloads all packages into the store, which not the
> same as installing all the packages into one or many profiles. I wonder what 
> the
> minimum set of profiles to install all packages while avoiding collisions 
> might
> be?

Correct, my reply was about building everything rather than installing
everything.

But--as a case merely to prove a point--if you include the kernel in the 
required set
of packages, then the single set of non-colliding packages can not be
defined because there are several mutually-exclusive kernels.

A valid "maximum coverage" set must have some additional constraints.



Re: ️ Install every Guix package ️

2023-01-05 Thread kiasoc5

On 1/4/23 21:50, Eric Brown wrote:

"jgart"  writes:


Hi Guixers,

How would you approach writing a script that installs every Guix package 
exhaustively for your current revision?

I'm thinking of something similar to `all-packages` on PyPi but for every Guix 
package (the whole wide ️).

https://pypi.org/project/all-packages/


guix package -A | cut -f 1 | sort -u | xargs guix build --keep-going

can accomplish this. The `--keep-going' flag is useful in case a package
does not build.

Occasionally, I will sandwich in a negated grep to
exclude packages:

guix package -A | cut -f 1 | sort -u | grep -v "emacs-guile" | xargs guix build 
--keep-going

(Aside: emacs-guile-on-guix-system is the pinnacle of GNU, IMO but it failed to
build--appearing to be abandoned--and was removed.)

One may also select just the packages they want, perhaps by using a
scripting language such as python to make larger selections more
convenient.

This can be combined with a substitute server and an offload build
machine to make an on-site cache. One can choose whether to employ the
Guix substitute servers if that would be beneficial.

I just realized that this downloads all packages into the store, which 
not the same as installing all the packages into one or many profiles. I 
wonder what the minimum set of profiles to install all packages while 
avoiding collisions might be?




Re: Updating Guix's packaged GNU/Hurd

2023-01-05 Thread Maxim Cournoyer
Hi,

Joshua Branson  writes:

> Hey Guix,
>
> I follow bug-h...@gnu.org pretty religiously (it's super entertaining),
> and there has been work on a new cross-hurd branch, which are some
> scripts for cross-compiling and creating an up-to-date Hurd system:
>
> https://github.com/flavioc/cross-hurd
>
> Anyone who is interested in updating Guix's GNU Hurd package recipe
> might be interested in the above repo.

Thanks for sharing.

-- 
Thanks,
Maxim



Re: Has ci.guix.gnu.org stopped building?

2023-01-05 Thread Mathieu Othacehe


> This was fixed with commit 658c09333da095edf6e1b3c5e351a7bfa3c87354

Builds have restarted!

Good catch, thanks!

Mathieu



Re: Bogus ‘etc/teams.scm’ usage recommendations?

2023-01-05 Thread Maxim Cournoyer
+CC 58...@debbugs.gnu.org

Hi,

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.

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?

-- 
Thanks,
Maxim



Re: Bogus ‘etc/teams.scm’ usage recommendations?

2023-01-05 Thread Maxim Cournoyer
+CC 58...@debbugs.gnu.org

Hi,

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.

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?

-- 
Thanks,
Maxim



Re: Search in One Channel

2023-01-05 Thread david larsson

On 2022-12-29 00:45, jgart wrote:

[..]



Any thoughts or ideas on how I should approach implementing
search/filter search in one channel only?


I think something like this would be a start where the "pkg-dir" 
argument is the path to a package directory in a channel:


(define (packages-i-want mypkgname pkg-dir)

  (fold-packages (lambda (package result)

   (if (mypkg? package mypkgname)

   (cons package result)

   result))

 '()

 (fold-modules cons '() `(,pkg-dir

Best regards,
David Larsson



Re: ️ Install every Guix package ️

2023-01-05 Thread Eric Brown
kiasoc5  writes:

> Surely if there are outstanding questions that could be answered by installing
> all packages, they could be answered in another way?

I do this to keep packages as reasonably close to "locked and loaded" as
possible (including all external channels) so that when I need them
interactively, they are ready on my system.

It's easier and less trouble than Cuirass, in my view.



Re: ️ Install every Guix package ️

2023-01-05 Thread Eric Brown
"jgart"  writes:

> Hi Guixers,
>
> How would you approach writing a script that installs every Guix package 
> exhaustively for your current revision?
>
> I'm thinking of something similar to `all-packages` on PyPi but for every 
> Guix package (the whole wide ️).
>
> https://pypi.org/project/all-packages/

guix package -A | cut -f 1 | sort -u | xargs guix build --keep-going

can accomplish this. The `--keep-going' flag is useful in case a package
does not build.

Occasionally, I will sandwich in a negated grep to
exclude packages:

guix package -A | cut -f 1 | sort -u | grep -v "emacs-guile" | xargs guix build 
--keep-going

(Aside: emacs-guile-on-guix-system is the pinnacle of GNU, IMO but it failed to
build--appearing to be abandoned--and was removed.)

One may also select just the packages they want, perhaps by using a
scripting language such as python to make larger selections more
convenient.

This can be combined with a substitute server and an offload build
machine to make an on-site cache. One can choose whether to employ the
Guix substitute servers if that would be beneficial.



Re: Bogus ‘etc/teams.scm’ usage recommendations?

2023-01-05 Thread Simon Tournier
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: 


Cheers,
simon



Re: Search in One Channel

2023-01-05 Thread zimoun
Hi,

On Wed, 28 Dec 2022 at 23:45, "jgart"  wrote:

> I'd like to search just in the guix-emacs channel with `guix search`. 

Currently, the only option I am aware is to parse the output (with
recutils or other).

Well, it is not convenient but something like:

guix time-machine -C one-specific-channel.scm -- search foo-bar

should work.  Not convenient because «Compute derivation» and because
you need to extract the correct information for the file
one-specific-channel.scm.

My question is: what is your use case?  Why is “guix search” on all
the channels not fitting your needs?

Well, “guix search” should use ’location’ which is a good indication for
package channel provenance, although it is not a strong guarantee.

Well, it is not straightforward to use ’module-name’ as search term.
Because how to map the string search terms with this module name.  And
because it could lead to some performance penalty.

Cheers,
simon



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

2023-01-05 Thread (
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 :)

-- (


signature.asc
Description: PGP signature


Re: GNU Guix 1.4.0 released

2023-01-05 Thread Simon Tournier
Hi Ludo, all,

On Tue, 03 Jan 2023 at 10:08, Ludovic Courtès  wrote:

> In my experience though, a lot of the work is coordination: keeping
> track of what needs to be done, open bugs, calling for testing, etc.

Yes, coordination is large part of the work, but not only as shown by
previous experiences (e.g., [1,2,3,4] and older others).

1: 
2: 
3: 
4: 


> 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. :-)

>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: 


Cheers,
simon



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

2023-01-05 Thread zimoun
Hi,

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.


Cheers,
simon



Re: git-fetch without a hash

2023-01-05 Thread Simon Tournier
Hi,

On Tue, 03 Jan 2023 at 22:34, Ludovic Courtès  wrote:

>> Yes.  When using (sha256 #f) url-fetch still has network access and
>> works to download things, which is inconsistent vs other fetchers.
>
> Hmm indeed:

On Wed, 21 Dec 2022 at 23:49, Ludovic Courtès  wrote:

> (sha256 #f) is not a documented use case.  :-)

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.


Cheers,
simon