Re: Adding (gnu packages emulator) to games team scope?
Hi! Adam Faiz writes: > Hello Maxim, > > On 9/26/24 14:00, Maxim Cournoyer wrote: >> Hi, >> >> I just sent some emulators packages, and was suprised it's not covered >> by the games team. Should it be? I'd say most emulators we have there >> are for emulating gaming consoles, which seems related to gaming to me >> :-). >> >> What do you think? >> > > It's a good idea, I don't think it would fit as well in the scope of other > package teams like bootstrap or embedded. Liliana, Iyzsong; any thoughts? If you think this is a reasonable addition to the scope of the 'games' team, I'll merge this. -- Thanks, Maxim
Language-specific guides for using "guix shell" (was: [bug#72925] [PATCH v3] adding jpm package)
Moving the discussion to guix-devel. "jgart" writes: > what do people think of having language specific guides for using > `guix shell` with particular programming languages? > > not unlike this Nix guide that shows how to use Python in a `nix > shell` to develop on a flask application: > > https://nix.dev/guides/recipes/python-environment.html I believe such guides would be quite helpful. Perhaps Guix Cookbook would be the appropriate place for it? > would be cool to document the expected workflow for a Guix user using > jpm and guix to develop on janet software, for example. As someone curious about JPM, such a guide would be of practical interest to me. -- Suhail
[PATCH v1] shepherd: add support for kexec
This patch adds preliminary support for rebooting into kexec using `reboot -k` or `reboot --do-kexec`. --- configure.ac| 2 ++ modules/shepherd/scripts/reboot.scm | 12 ++-- modules/shepherd/service.scm| 9 + modules/shepherd/system.scm.in | 6 ++ 4 files changed, 27 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index f98024d..cfbd938 100644 --- a/configure.ac +++ b/configure.ac @@ -104,6 +104,7 @@ case "$host_os" in AC_COMPUTE_INT([RB_DISABLE_CAD], [RB_DISABLE_CAD], [#include ]) AC_COMPUTE_INT([RB_POWER_OFF], [RB_POWER_OFF], [#include ]) AC_COMPUTE_INT([RB_SW_SUSPEND], [RB_SW_SUSPEND], [#include ]) +AC_COMPUTE_INT([RB_KEXEC], [RB_KEXEC], [#include ]) ;; gnu*) # On GNU/Hurd, the Mach-derived reboot.h uses different names, and @@ -125,6 +126,7 @@ AC_SUBST([RB_DISABLE_CAD]) AC_SUBST([RB_AUTOBOOT]) AC_SUBST([RB_HALT_SYSTEM]) AC_SUBST([RB_POWER_OFF]) +AC_SUBST([RB_KEXEC]) AC_MSG_RESULT([done]) AC_MSG_CHECKING([ constants]) diff --git a/modules/shepherd/scripts/reboot.scm b/modules/shepherd/scripts/reboot.scm index 6be5414..f7f6647 100644 --- a/modules/shepherd/scripts/reboot.scm +++ b/modules/shepherd/scripts/reboot.scm @@ -30,6 +30,8 @@ (define (main . args) (initialize-cli) + (define reboot-action 'stop) + (parameterize ((program-name "reboot")) (let ((socket-file %system-socket-file) (command-args '())) @@ -44,13 +46,19 @@ #:argument-name "FILE" #:description "send commands to FILE" #:action (lambda (file) - (set! socket-file file + (set! socket-file file))) +(option + #:long-name "do-kexec" #:short-name #\k + #:takes-argument? #f + #:description "reboot using kexec" + #:action (lambda () (set! reboot-action 'reboot-kexec)) +)) (set! command-args (reverse command-args)) (with-system-error-handling (let ((sock (open-connection socket-file))) ;; Send the command without further ado. - (write-command (shepherd-command 'stop 'root) sock) + (write-command (shepherd-command reboot-action 'root) sock) ;; Receive output if we're not already dead. (match (read sock) diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm index 0a52b7a..f076277 100644 --- a/modules/shepherd/service.scm +++ b/modules/shepherd/service.scm @@ -2849,6 +2849,15 @@ Clients such as 'herd' can read it and format it in a human-readable way." (lambda (key) (local-output (l10n "Shutting down...")) (power-off) + + (reboot-kexec + "Reboot the system and run kexec." + (lambda (running) +(catch 'quit + (cut stop root-service) + (lambda (key) +(local-output (l10n "Rebooting with kexec...")) +(reboot-kexec) ;; Evaluate arbitrary code. (load "Load the Scheme code from FILE into shepherd. This is potentially diff --git a/modules/shepherd/system.scm.in b/modules/shepherd/system.scm.in index 9929f38..bb95455 100644 --- a/modules/shepherd/system.scm.in +++ b/modules/shepherd/system.scm.in @@ -26,6 +26,7 @@ #:use-module (srfi srfi-26) #:export (disable-reboot-on-ctrl-alt-del reboot +reboot-kexec halt power-off max-file-descriptors @@ -49,6 +50,7 @@ (define RB_HALT_SYSTEM @RB_HALT_SYSTEM@) (define RB_POWER_OFF @RB_POWER_OFF@) (define RB_DISABLE_CAD @RB_DISABLE_CAD@) ; integer | #f +(define RB_KEXEC @RB_KEXEC@) (define (syscall->procedure return-type name argument-types) "Return a procedure that wraps the C function NAME using the dynamic FFI, @@ -93,6 +95,10 @@ ctrlaltdel(8) and see kernel/reboot.c in Linux." "Perform a hard reset of the system now. Return #f on failure." (%libc-reboot RB_AUTOBOOT)) +(define (reboot-kexec) + "Execute kernel loaded with 'kexec -l' now. Return #f on failure." + (%libc-reboot RB_KEXEC)) + (define (halt) "Halt the system. Return #f on failure." (%libc-reboot RB_HALT_SYSTEM)) -- 2.46.0
Re: Language-specific guides for using "guix shell" (was: [bug#72925] [PATCH v3] adding jpm package)
Hi jgart, I am kind of new to Guix and I am struggling to find resources forlanguage specific recipes like you mentioned. I started a project https://lisp-spectrum.org/ where I try to document my struggles with the Lisp Ecosystemin general (Guix included). For every Lisp, I try to include a guix manifest to make the instructions reproducible and I plan to add guides on how to work with guix on many levels (OS, home and shell) for each language. I'm only doing this project for Lisp dialects for now, but I can definitely see the benefit of having the same thing for other languages as well. On Wed, 2 Oct 2024 at 23:20, Suhail Singh wrote: > Moving the discussion to guix-devel. > > "jgart" writes: > > > what do people think of having language specific guides for using > > `guix shell` with particular programming languages? > > > > not unlike this Nix guide that shows how to use Python in a `nix > > shell` to develop on a flask application: > > > > https://nix.dev/guides/recipes/python-environment.html > > I believe such guides would be quite helpful. Perhaps Guix Cookbook > would be the appropriate place for it? > > > would be cool to document the expected workflow for a Guix user using > > jpm and guix to develop on janet software, for example. > > As someone curious about JPM, such a guide would be of practical > interest to me. > > -- > Suhail >
Re: Language-specific guides for using "guix shell" (was: [bug#72925] [PATCH v3] adding jpm package)
October 2, 2024 at 3:32 PM, "Omar Bassam" mailto:omar.bassa...@gmail.com?to=%22Omar%20Bassam%22%20%3Comar.bassam88%40gmail.com%3E > wrote: > > Hi jgart, > I am kind of new to Guix and I am struggling to find resources forlanguage > specific recipes like you mentioned. > I started a project https://lisp-spectrum.org/ where I try to document my > struggles with the Lisp Ecosystemin general (Guix included). > For every Lisp, I try to include a guix manifest to make the instructions > reproducible and I plan to add guides > on how to work with guix on many levels (OS, home and shell) for each > language. > > I'm only doing this project for Lisp dialects for now, but I can definitely > see the benefit of having the same thing for other languages as well. > Thanks! I'll read your website soon. Great idea!!! This is one random blog post I know about that discusses a development workflow for Guix: https://dthompson.us/posts/guix-for-development.html Have you read that one? Might be relevant. all best, jgart https://whereis.xn--q9jyb4c/
Re: Status of ZFS support on Guix
Hi, On Tuesday, October 1st, 2024 at 1:23 PM, Morgan Arnold wrote: > > > I asked around on the IRC channel a while ago about the status of ZFS support > on Guix, and it was suggested that I ask here. I am aware of efforts made in > the past to bring some rudimentary ZFS support to Guix (namely, > https://issues.guix.gnu.org/45692, which appears to be quite dead), but was > wondering if any new efforts have been considered. This is something which I > would be very open to contributing to, as the lack of ZFS support is > currently the only thing preventing me from using Guix as my main distro. It > looks like there has is some general interest for better ZFS support on Guix, > as evidenced by, say, https://issues.guix.gnu.org/73035. Thank you for sharing those two issues; 45692 IIRC was the source/basis for the ZFS services in my private local channel that I've using for several years now. I hadn't noticed 73035 yet, so I'll be looking at that soon. There is also a couple of other issues that bring improvements related--at least tangentially-- to ZFS that are pending: 1) https://issues.guix.gnu.org/71482 which splits the ZFS userspace tools into a separate package and provides a helper function for creating a ZFS package for a specific kernel package. 2) https://issues.guix.gnu.org/55231 which adds support for including out-of-tree kernel modules in the initrd. This isn't strictly related to ZFS other than the documentation referencing ZFS in its example. The documentation patch had later been updated to include a different example of an out-of-tree module that is already packaged in Guix. I've also commented on it that I have essentially been using those patches for a number of years now. > > Based on the response to 45692, I would also like to know if there is > opposition to adding support for Guix, be it for philosophical or legal > reasons. Assuming that no such opposition exists, 45692 seems to provide a > very substantial chunk of the work which needs to be done for supporting ZFS > on Guix, in particular automatic loading of the ZFS kernel module and > automatic mounting of datasets. Ultimately, I would love to see support for > `/' on ZFS, but based on discussions around 45692, it seems like this would > be quite a bit more effort, although I must admit that I don't really > understand why, other than that it involves modifying the behaviour of > Shepherd earlier in the boot process. Other than examining the patches which > were submitted for 45692, I assume that it would be worth looking more > closely at how other filesystems are managed on Guix, although the treatment > of ZFS probably necessarily differs, if just for the loading of the kernel > module. As for` /' on ZFS, would a deep dive into the documentation for > Shepherd be valuable in terms of understanding how to load the ZFS kernel > module as early as possible? Alternatively, are there other modules in Guix > that are sometimes loaded early (maybe GPU drivers? I know that they are > loaded early sometimes) which might be worth examining to understand how to > go about it? I'd love to know where any opposition may be at as well. At this point I have a private channel which actually replaces much of the bootloader and initrd functionality (in part to support ZFS in the initrd using https://issues.guix.gnu.org/55231). In the past year, I actually took advantage of having basically replicated much of the initrd functionality in my channel to create a simple bootloader based on the Linux kernel (with the EFI stubloader) and a custom initrd that uses kexec to boot the actual system. It still needs a lot of polish, but has been good enough that combined with a few other small hacks and workarounds, I have several systems now booting with ZFS roots (some unencrypted, some using native encryption). I have done little to upstream most of it, or even to share what I've done, because of the seeming resistance to ZFS. Cheers, Kaelyn > > Thanks, > > Morgan
Re: Adding (gnu packages emulator) to games team scope?
Am Mittwoch, dem 02.10.2024 um 16:18 +0900 schrieb Maxim Cournoyer: > Hi! > > Adam Faiz writes: > > > Hello Maxim, > > > > On 9/26/24 14:00, Maxim Cournoyer wrote: > > > Hi, > > > > > > I just sent some emulators packages, and was suprised it's not > > > covered by the games team. Should it be? I'd say most emulators > > > we have there are for emulating gaming consoles, which seems > > > related to gaming to me :-). > > > > > > What do you think? > > > > > > > It's a good idea, I don't think it would fit as well in the scope > > of other package teams like bootstrap or embedded. > > Liliana, Iyzsong; any thoughts? If you think this is a reasonable > addition to the scope of the 'games' team, I'll merge this. Sure, go ahead :)
Re: Status of ZFS support on Guix
Hi Kaelyn, Morgan, Kaelyn writes: On Tuesday, October 1st, 2024 at 1:23 PM, Morgan Arnold wrote: I'd love to know where any opposition may be at as well. At this point I have a private channel which actually replaces much of the bootloader and initrd functionality (in part to support ZFS in the initrd using https://issues.guix.gnu.org/55231). In the past year, I actually took advantage of having basically replicated much of the initrd functionality in my channel to create a simple bootloader based on the Linux kernel (with the EFI stubloader) and a custom initrd that uses kexec to boot the actual system. It still needs a lot of polish, but has been good enough that combined with a few other small hacks and workarounds, I have several systems now booting with ZFS roots (some unencrypted, some using native encryption). I have done little to upstream most of it, or even to share what I've done, because of the seeming resistance to ZFS. I don’t think there’s resistance to ZFS. I do think there are some legitimate open questions around licensing[1], but the main issue seems to be that the contributor of #45692 chose to express their frustration with the slow pace of Guix patch review[2] in counterproductive and borderline abusive ways[3][4]. Personally, I’d very much like to see improved support for ZFS in Guix. I have one machine with a cobbled-together Guix ZFS setup, but proper support is a blocker for moving my primary ZFS-using system off Debian. Thanks, — Ian [1]: https://issues.guix.gnu.org/45692#75 [2]: Which I *extremely* sympathize with. [3]: https://issues.guix.gnu.org/45692#72 [4]: https://issues.guix.gnu.org/45692#78
Re: Language-specific guides for using "guix shell"
On 2024-10-02 20:32, Omar Bassam wrote: Hi jgart, I am kind of new to Guix and I am struggling to find resources forlanguage specific recipes like you mentioned. I started a project https://lisp-spectrum.org/ where I try to document my struggles with the Lisp Ecosystemin general (Guix included). Cool! Its worth pointing out the Lisp dialect, TXR https://www.nongnu.org/txr/txr-lisp.html FWIW, here are some of my notes: https://git.sr.ht/~indieterminacy/?search=3q+txr For every Lisp, I try to include a guix manifest to make the instructions reproducible and I plan to add guides on how to work with guix on many levels (OS, home and shell) for each language. I'm only doing this project for Lisp dialects for now, but I can definitely see the benefit of having the same thing for other languages as well. On Wed, 2 Oct 2024 at 23:20, Suhail Singh wrote: Moving the discussion to guix-devel. "jgart" writes: what do people think of having language specific guides for using `guix shell` with particular programming languages? not unlike this Nix guide that shows how to use Python in a `nix shell` to develop on a flask application: https://nix.dev/guides/recipes/python-environment.html I believe such guides would be quite helpful. Perhaps Guix Cookbook would be the appropriate place for it? would be cool to document the expected workflow for a Guix user using jpm and guix to develop on janet software, for example. As someone curious about JPM, such a guide would be of practical interest to me. -- Suhail Happy hacking! Jonathan
