Re: guix shell init
nix flakes also allows you to create your own custom template for use with `nix flakes init`: https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake-init#template-definitions We could do the same with `guix shell init` maybe...
Re: guix shell init
See this blog post for how nix does it for the `nix flakes init` command: https://peppe.rs/posts/novice_nix:_flake_templates/ wdyt
Re: guix shell init
It would generate this boilerplate somehow: https://guix.gnu.org/en/blog/tags/cookbook/sk/html_node/Getting-Started.html
guix shell init
Hi Guixers, What if we had a command like `guix shell init`. It would create a basic manifest.scm or guix.scm file for the user. bloat or meh or yeh? Sprinkling some Guix flakes on your day, jgart
Re: Help Packaging Incudine (Common Lisp)
That's interesting. I was also suspicious about this function and mentioned it upstream but they said it is normal to do it like this so I just ignored it. Also I remember having tried out a dummy package, so I really believed it was ok. Thanks for your help! On October 23, 2023 10:44:57 AM GMT+02:00, Guillaume Le Vaillant wrote: >Hi. > >It looks like there's a bug in "contrib/cl-sndfile/cffi-sndfile.lisp". >The 'make-sndinfo' function definition tries to get the size of the >'info' foreign structure before this foreign structure is defined. > >After moving the definition of 'make-sndinfo' at the end of the file, >compilation works. > >I think you can report this issue upstream.
Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19
Bonsoir Simon, Le mardi 24 octobre 2023 à 22:10 +0200, Simon Tournier a écrit : > Hi, > > Some of us will be in Toulouse, INP-N7, 26 rue Riquet on 18 & 19 > november for Capitole du Libre: > > https://capitoledulibre.org/ > > We will stand in Village Associatif. Let us know if you can help us > at the event. Well, I do not know exactly what means "a stand" since > it will be the first for me. :-) I guess it mainly consists to be > around the Guix booth, chat with people about why Guix is awesome! > and > maybe demo some Guix features. > > Feel free to share your ideas. :-) > > Concretely, if you are planning to come, let synchronize and share > the > fun. Andreas and I will be there. Who is in? Do not be shy and > drop > an email; off-list possibly. > > If you are there, please stop at the wonderful Guix kakemono and say > hi. > > Hope to see you soon. Je compte bien y aller ! Vivien
Meet Guix at Capitole du Libre in Toulouse, nov. 18-19
Hi, Some of us will be in Toulouse, INP-N7, 26 rue Riquet on 18 & 19 november for Capitole du Libre: https://capitoledulibre.org/ We will stand in Village Associatif. Let us know if you can help us at the event. Well, I do not know exactly what means "a stand" since it will be the first for me. :-) I guess it mainly consists to be around the Guix booth, chat with people about why Guix is awesome! and maybe demo some Guix features. Feel free to share your ideas. :-) Concretely, if you are planning to come, let synchronize and share the fun. Andreas and I will be there. Who is in? Do not be shy and drop an email; off-list possibly. If you are there, please stop at the wonderful Guix kakemono and say hi. Hope to see you soon. Cheers, simon PS: The event is in French-speaking.
Re: Divvying up service definitions
Hi Bruno, On Tue, Oct 24 2023, Bruno Victal wrote: > Further complicating things is > 'define-maybe', whose use monopolizes the predicate and serializers for > a particular service definition. I've dealt with that in the past and support your effort. > * Splitting this as gnu/services/dovecot.scm. > We keep it compatible with 'use-service-modules' at the cost of having > a multitude of files under gnu/services, without any logical grouping The number of services we offer strikes me as sufficiently small for your "unsorted" scheme to remain easy to navigate. Also, we already use this scheme for several services---such as rsync, ssh, vnc, certbot, certbot, cgit, cups, ldap, lirc, sddm, avahi, mcron, spice, auditd, sysctl, getmail, lightdm, and syncthing. I am not sure it's worth a long discussion. Moreover, categorizations are often ambigious and can make it harder to locate a particular service definition. While some services may remain narrowly bundled---as they are in nfs, dbus, herd, hurd, samba, docker, ganeti, and shepherd---categorizations often exist purely in the eye of the beholder. For example, does Kerberos belong into its own category, as it does now, or is part of 'authentication', or perhaps 'security'? In short, I would proceed and split the services if there is no further comment on your request. It will make development easier. For a transitional period, we could perhaps provide intermediate modules in old places which re-export the service definitions that were moved, but I'm not sure it's really necessary. Thank you for your clean-up efforts! Kind regards Felix
Divvying up service definitions
Hi, As the gnu/services and gnu/home/services grow, I think we should consider divvying the services into stand-alone modules or subdirectories. Consider the ⌜dovecot-service-type⌝ in gnu/services/mail.scm: as of commit 'd22d2a05c389207f8cdcf824be7738b1499a987c' this service definition is nearly 1600 lines long, with the remainder of the file comprising of four other services with rudimentary support. It becomes troublesome working with such amalgamations as it makes it hard to keep track of the used modules and bindings, especially when define-configuration is used since the serializing procedures might be used by various service definitions. Further complicating things is 'define-maybe', whose use monopolizes the predicate and serializers for a particular service definition. Now, I'm not saying that we should go and split everything into its own module, I'm saying that we should be allowed to split some of them if convenient (all subjective but I believe we can see that working with a monolithic file in the kilolines where the interactions aren't obvious is not fun, and that's without bringing in the hygienic issues surrounding define-configuration and define-maybe). Some considerations (using dovecot-service-type as an example): * Splitting this as gnu/services/mail/dovecot.scm. We preserve the logical grouping of the services (with the addition that, for extremely comprehensive definitions, these can be neatly organized into subdirectories. (same structure seen with gnu/*.scm) A drawback is that 'use-service-modules' might not work with this although I wonder whether 'use-service-modules' & co. provide any value if we are already doing '(use-modules (gnu) …)' to begin with. They look redundant IMO. * Splitting this as gnu/services/dovecot.scm. We keep it compatible with 'use-service-modules' at the cost of having a multitude of files under gnu/services, without any logical grouping (messy). -- Thanks, Bruno.
