Re: Upgrading Shepherd services
Hi Attila, On Fri, May 17 2024, Attila Lendvai wrote: > if you do have a reproducer Here is a small one for not booting, although the service activation during 'guix deploy' succeeds. Please try the Guix timer below with the Shepherd development branch. My equipment does not boot when the apparently erroneous (actions ...) field in the shepherd-service record is present. King regards, Felix P.S. Advice on how to access the trigger would be welcome. * * * (define (garbage-collector-shepherd-service config) (shepherd-service (provision '(garbage-collector)) (requirement '(guix-daemon)) (modules '((shepherd service timer))) (start #~(make-timer-constructor ;; Five minutes after midnight every day. (calendar-event #:hours '(0) #:minutes '(5)) (command (list "guix" "gc" "--free-space=1G" (stop #~(make-timer-destructor)) (actions (list (shepherd-action (name 'trigger) (documentation "Trigger the action associated with this timer.") (procedure #~(identity trigger-timer) (documentation "Maintain minimum free space by cleaning up Guix garbage"))) (define garbage-collector-service-type (service-type (name 'garbage-collector) (description "Maintain minimum free space by cleaning up Guix garbage") (extensions (list (service-extension shepherd-root-service-type (compose list garbage-collector-shepherd-service (default-value #f)))
Re: Shepherd log rotation service
Hi Ludo', > I’ve just pushed a simple log rotation service for Shepherd: Wow, that's another cool addition! I am currently testing a patch that removes the rottlog service extension from all services that use #:log-file. Not all do. I should will make an immediate dent in my 200 MB log file for Fcgiwrap, but not for an Rspamd file of similar size. Also, my Nginx log file with 1.3 GB will remain unaffected. Most significantly, it simplifies a lot of code. To make the addition of my new log-rotation-service-type compatible with folks who use the rottlog service extension outside the main repo, I also hope to make the service extension a no-op when the underlying Shepherd service uses the #:log-file facility. Meanwhile, I have a few questions: Should log-rotation-service be called make-log-rotation-service? Should the key #:rotation-size-threshold be renamed to size-threshold? I'm not asking to change the name of the variable holding the default value. The current key looks longer than needed in this code: (define (log-rotation-shepherd-service config) (match-record config (compression event expiry size-threshold) #~((log-rotation-service #$event #:compression #$compression #:expiry #$expiry #:rotation-size-threshold #$size-threshold Also, is it good practice, in log-rotation-service, to use an optional argument (for event) together with keyword arguments? Why not use keyword arguments all around? Finally, are there truly no (Shepherd) service requirements? Or will any Shepherd service that uses #:log-file automatically make sure that the file-system is available? Thank you for this cool new feature! Kind regards Felix On Sat, May 18 2024, Ludovic Courtès wrote: > Hello Guix! > > > > https://git.savannah.gnu.org/cgit/shepherd.git/commit/?h=devel=0484726801c2b5c1b7deecb9a96054c2c510ac71 > > It rotates log files roughly the same way we’ve been doing since the > 70’s, but there’s a couple of advantages compared to what we’re > currently doing in Guix System: > > • No need to repeat the name of log files since shepherd already knows > them via #:log-file (that’s another reason to avoid > non-shepherd-managed log files). > > • Rotation is race-free: it’s impossible to lose a line of log while > the file is being rotated. This is guaranteed by the “logger”, > which offers a method to atomically close its log file, rename it, > and open a new empty log file. > > • The log rotation service is a timer so one can inspect it with ‘herd > status log-rotation’, trigger it with ‘herd trigger log-rotation’, > and so on. > > At this point the log file of shepherd itself, for instance > /var/log/messages, is not handled; this will have to be fixed. > > There aren’t many options to specify how to rotate logs (very few > compared to rottlog!), but I figured we’d rather have something simple > that works well and without surprises; we can always add knobs later if > necessary. > > Feedback welcome! > > Ludo’.
Changes to managing branches
Hey! I've now merged the most recent batch [1] of changes to the process for managing patches and branches. There was a previous thread on guix-devel discussing the changes here [2]. 1: https://issues.guix.gnu.org/70549 2: https://lists.gnu.org/archive/html/guix-devel/2024-04/msg00247.html The most significant change is that the guix-patches issues should be created when you create the branch. There's also more guidance on how to manage branches smoothly. This mostly applies to people with commit access, but people without commit access can also lead the work on the branch. This is now mentioned in the documentation. If you have and comments or questions, just let me know. Thanks, Chris signature.asc Description: PGP signature
Extension for improving Guix search?
Hi, Guile-Xapian@0.4.0 is out! That’s a fun opportunity for revisiting “guix search”. Well, “guix search” is currently an alias of “guix package --search” and it can be considered as “slow”. The main reason is from the lack of a good cache. Although it is not a fair comparison, “guix package --list-available” is much faster than “guix package --search”. Obviously, they do not process and format the same content. Well, the point is that ’list-available’ relies on a cache, namely ~/.config/guix/current/lib/guix/package.cache. It had been discussed to expand this cache (or create another one) for helping “guix search”. Instead of walking through Guile modules, just read a cache. However, this implies a slower “guix pull” – and “guix time-machine” too –; the penalty depends on your machine and from my opinion, I can wait some seconds more after waiting many minutes, but that had not been the consensus. All that said, there is a very long thread where different approaches had been tried; see all the subthreads. ;-) 1. Rely on SQL [1] 2. Rely on Xapian [2] 3. Extend package.cache [3] 4. Improving string search algorithm [4] 5. Rely on package.cache and load the required Guile [5] On the top of that, it is not handy to find which Guix revision contains which package version. For a description of the problem [6]. For instance, I do stuff as: $ git -C ~/src/guix/guix log --format="%h %s" | grep 'gnu: bowtie:' a47a90b900 gnu: bowtie: Remove reference to %outputs. f336cc4fe7 gnu: bowtie: Replace invalid characters. e5a26a1f02 gnu: bowtie: Remove trailing #T. 2ec601580b gnu: bowtie: Use TBB 2020. 21c837405a gnu: bowtie: Update to 2.3.4.3. 06e372360e gnu: bowtie: Use 'modify-phases'. d6e63cf31c gnu: bowtie: Update to 2.3.2. 2642231b39 gnu: bowtie: Update to 2.2.9. 0047d26a22 gnu: bowtie: Update to 2.2.6. 241e122193 gnu: bowtie: fix build errors which is not super handy. Well, it was somehow an idea behind this Outreachy internship [7]. It’s another direction: exploit the format of Guix commit messages. Anyway. Therefore, all in all, I think it’s time to have a Guix extension that improves the situation on both sides: a) faster search b) search inside all the history And I think that Xapian could offer a very great framework. Well, I have started an embryo months (years?) ago and it is still an embryo. This issue deserve more love. :-) Adding Xapian as Guix dependencies is too much. But it is possible to extend Guix with GUIX_EXTENSIONS_PATH. This appears to me the best solution here: write an extension relying on Xapian for indexing. Still reading? I think this fit a very good topic if you are looking for something to work on. Maybe it could be turned on some GSoC – hum I am a bit lost with all the deadlines. Feel free to ping. :-) Cheers, simon 1: [bug#39258] Faster guix search using an sqlite cache Arun Isaac Fri, 24 Jan 2020 01:21:57 +0530 id:cu7pnfaar36@systemreboot.net https://issues.guix.gnu.org/39258 https://issues.guix.gnu.org/msgid/cu7pnfaar36@systemreboot.net https://yhetil.org/guix/cu7pnfaar36@systemreboot.net 2: [bug#39258] [PATCH v2 0/3] Xapian for Guix package search Arun Isaac Sat, 07 Mar 2020 19:01:13 +0530 id:20200307133116.11443-1-arunis...@systemreboot.net https://issues.guix.gnu.org/39258 https://issues.guix.gnu.org/msgid/20200307133116.11443-1-arunis...@systemreboot.net https://yhetil.org/guix/20200307133116.11443-1-arunis...@systemreboot.net 3: [bug#39258] [PATCH v4 0/3] Faster cache generation (similar as v3) zimoun Sun, 03 May 2020 17:01:51 +0200 id:20200503150154.26532-1-zimon.touto...@gmail.com https://issues.guix.gnu.org/39258 https://issues.guix.gnu.org/msgid/20200503150154.26532-1-zimon.touto...@gmail.com https://yhetil.org/guix/20200503150154.26532-1-zimon.touto...@gmail.com 4: [bug#39258] KMP string search algorithm? zimoun Mon, 01 Jun 2020 12:11:52 +0200 id:CAJ3okZ2ZNYaH=_ojp2axvq-any6q9ckvmjuvlpx-z6+kztv...@mail.gmail.com https://issues.guix.gnu.org/39258 https://issues.guix.gnu.org/msgid/CAJ3okZ2ZNYaH=_ojp2axvq-any6q9ckvmjuvlpx-z6+kztv...@mail.gmail.com https://yhetil.org/guix/CAJ3okZ2ZNYaH=_ojp2axvq-any6q9ckvmjuvlpx-z6+kztv...@mail.gmail.com 5: [bug#39258] [PATCH v6 0/2] DRAFT "guix search" performances zimoun Thu, 15 Jul 2021 09:33:26 +0200 id:20210715073328.212123-1-zimon.touto...@gmail.com https://issues.guix.gnu.org/39258 https://issues.guix.gnu.org/msgid/20210715073328.212123-1-zimon.touto...@gmail.com https://yhetil.org/guix/20210715073328.212123-1-zimon.touto...@gmail.com 6: Re: List available versions of package. Philippe Veber Tue, 11 Jun 2019 09:43:08 +0200 id:CAOOOohSzUezKvm=ro0bxrgh3m0eo2x0cotvd--varxwoqtc...@mail.gmail.com https://lists.gnu.org/archive/html/help-guix/2019-06 https://yhetil.org/guix/CAOOOohSzUezKvm=ro0bxrgh3m0eo2x0cotvd--varxwoqtc...@mail.gmail.com 7: https://guix.gnu.org/en/blog/2021/outreachy-guix-git-log-internship-wrap-up/ 8: Re: Mechanism
Re: SageMath packaging work
Am Wed, May 22, 2024 at 03:50:43PM +0100 schrieb Sharlatan Hellseher: > https://issues.guix.gnu.org/search?query=SageMath+is%3Aopen > 56729 patch[RFC PATCH 00/10] Add sagemath. > 70924 patch[PATCH 00/10] Add some SageMath standard packages. > Maybe it needs some love to bring to the master branch. Indeed that would be welcome. Concerning #70924, we would need to check with the python-team branch to not duplicate the patches. I will not be available for the next two weeks, but will be happy to take part in patch reviewing after that. Andreas
Re: SageMath packaging work
Hi Ada, It looks like it was missed in patches https://issues.guix.gnu.org/search?query=SageMath+is%3Aopen 56729 patch[RFC PATCH 00/10] Add sagemath. 70924 patch[PATCH 00/10] Add some SageMath standard packages. Maybe it needs some love to bring to the master branch. I'll take a look while waiting for QA digest my Astro upate. -- Oleg On Wed, 22 May 2024 at 10:19, Ada Stevenson wrote: > > Hi Guix, science team! > > I was reaching for SageMath today and couldn't find it in the package > repository. I notice there's a sagemath.scm file, but no actual SageMath > package proper. Is there any work being done on packaging it at the > moment? Are there any particular blockers preventing its packaging > (excessive dependencies, difficult build etc.)? > > Having SageMath in Guix would be really handy for me, so I'm happy to > give packaging it a go if the only reason is that there's not enough > interest (I will just have to wait until after exams, so in about 3-4 > weeks). > > Hope you are all doing well! > > Warmly, > Ada -- VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/ GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5 … наш разум - превосходная объяснительная машина которая способна найти смысл почти в чем угодно, истолковать любой феномен, но совершенно не в состоянии принять мысль о непредсказуемости.
Kitty terminal new package, symlink problem
Hi Edison Ibáñez if you see this, I am unsure if my reply on debuggs was sent, i am yet to get a email address that supports git send-email, It seems that go embed does not support symlinks and in the kitty build dir, "/src/github.com/alecthomas/chroma/v2/**" the embed-ed files are symlinks to the chroma store directory. https://pkg.go.dev/embed "Patterns must not match files outside the package's module, such as ‘.git/*’ or symbolic links. Patterns must not match files whose names include the special punctuation characters " * < > ? ` ' | / \ and :. Matches for empty directories are ignored. After that, each pattern in a //go:embed line must match at least one file or non-empty directory. " I was just looking at what is the process which creates the link, it is possibly line 232 ( in my checkout) of guix/build/go-build-system ``` (let ((dest (string-append (getenv "GOPATH") "/src/" unpack-path))) (mkdir-p dest) (if (file-is-directory? source) (copy-recursively source dest #:keep-mtime? #t) (unpack-maybe-strip source dest))) ``` there is not a symlink function call, i think build systems are inherited so maybe it is in a containing build system. Im going out now but this seems to be the cause of the failure. Also if anyone sees this and has an invite to riseup email service ( should the service be capable of handling another stranger) then please may i have a invite?, google sux Thanks!
Re: Idea for packaging rust apps
On 5/22/24 05:04, Murilo wrote: Hello, I hope this is the right place for this, apologies if it isn't. I'm working with a friend on a cargo importer that lowers the entry barrier and the maintainability costs for packaging rust apps in general, without sacrificing Guix dependency tracking and reproducibility of rust packages. When you get used to the tool, you can pretty much package rust apps with all the dependency chain very easily (I just packaged [1] texlab for my channel earlier this morning in less than 5 minutes, and i can easily update apps to the latest version in less than a minute). Progress is being tracked in [2] if anyone wants to check it out or contribute to it. It is currently missing a lot of features, but we hope to improve the user experience of the tool in the near future. It is a very simple tool, it essentially parses the Cargo.lock file and extracts all the relevant information for constructing the rust package definitions of all the cargo-inputs and the package itself, and outputs to stdio a guile module containing all the needed cargo-input chain as guix packages, with all the cargo-inputs self-contained and versions all sorted out for a working final package build. This way a packager only needs to focus on the actual package they are trying to build, instead of worrying about its cargo-inputs. Due to how cargo-inputs are organized in gnu/packages/crates-*.scm, and some current packaging guidelines for crates on Guix, we cannot simply contribute these self-contained packages generated directly from the Cargo.lock, thus requiring to use the guix crate importer and spending a lot of time fixing dependencies and worrying about other packages breaking in the process. I would like to propose some discussion around a better way of organizing the rust packages and its cargo-inputs in (gnu packages) for building rust apps that only need sources as cargo-inputs: 1) Create a new directory at gnu/packages/rust/ in which a contributor can commit self-contained rust apps scm modules. 2.1) Add a new module at gnu/packages/rust/my-rust-app-1.scm 2.2) Add a new module at gnu/packages/rust/my-rust-app-2.scm 3) All package definitions inside gnu/packages/rust/*.scm which are source-only (#:skip-build? #t) should not be exported. 4.1) gnu/packages/crates-*.scm will not cease to exist, existing rust apps packages that have a Cargo.lock could gradually be migrated to the new organization 4.2) libs which need to be built can still live in gnu/packages/crates-*.scm 5) A (define-public my-rust-app-1 (@@ (gnu packages rust my-rust-app-1) my-rust-app-1)) or equivalent could be done in a (gnu packages category) module to export the rust app in the desired category. 6) Unlike nix (which also parses the Cargo.lock in the build system), we don't lose the ability to make snippets for sources this way. 7) For updating/maintaining a rust package defined this way, one would be able to simply re-run the guix tool, and replace the gnu/packages/rust/my-rust-app.scm file, only copying over the final relevant package definition for the rust app with its tweaks for building, and passing over the new cargo-inputs generated by the guix tool. I believe that by only changing the way things are organized and having a guix tool that generates self-contained package definitions from Cargo.lock, it would be possible to greatly improve the time required for contributing new rust apps packages and maintaining them on Guix. Things don't need to be the way I described here, these are just my initial thoughts after several failed attempts and wasted time trying to contribute rust apps to Guix, I'd like to discuss workarounds and if the benefits are greater than the disavantages for an approach like this. The tool we made works really well for packaging for our personal channels, I am very satisfied with how easy it is, and I think Guix could benefit a lot by adopting a similar approach. What am I missing here? Are there any disavantages to this approach? Anything that would break from it if adopted on Guix? Any questions or suggestions? Murilo [1] https://codeberg.org/look/saayix/commit/c7643943545d62baba80cccee1650ebf94362858 [2] https://git.sr.ht/~look/cargo2guix Hey Murilo, Thank you for taking the initiative to do something about the rust packaging situation in Guix. Which currently less than optimal. I wanted to ask, are you also aware of the antioxidant effort? https://notabug.org/maximed/cargoless-rust-experiments I was wondering of the differences since your build system seems to still be using cargo under the hood instead of rustc. MSavoritias
Idea for packaging rust apps
Hello, I hope this is the right place for this, apologies if it isn't. I'm working with a friend on a cargo importer that lowers the entry barrier and the maintainability costs for packaging rust apps in general, without sacrificing Guix dependency tracking and reproducibility of rust packages. When you get used to the tool, you can pretty much package rust apps with all the dependency chain very easily (I just packaged [1] texlab for my channel earlier this morning in less than 5 minutes, and i can easily update apps to the latest version in less than a minute). Progress is being tracked in [2] if anyone wants to check it out or contribute to it. It is currently missing a lot of features, but we hope to improve the user experience of the tool in the near future. It is a very simple tool, it essentially parses the Cargo.lock file and extracts all the relevant information for constructing the rust package definitions of all the cargo-inputs and the package itself, and outputs to stdio a guile module containing all the needed cargo-input chain as guix packages, with all the cargo-inputs self-contained and versions all sorted out for a working final package build. This way a packager only needs to focus on the actual package they are trying to build, instead of worrying about its cargo-inputs. Due to how cargo-inputs are organized in gnu/packages/crates-*.scm, and some current packaging guidelines for crates on Guix, we cannot simply contribute these self-contained packages generated directly from the Cargo.lock, thus requiring to use the guix crate importer and spending a lot of time fixing dependencies and worrying about other packages breaking in the process. I would like to propose some discussion around a better way of organizing the rust packages and its cargo-inputs in (gnu packages) for building rust apps that only need sources as cargo-inputs: 1) Create a new directory at gnu/packages/rust/ in which a contributor can commit self-contained rust apps scm modules. 2.1) Add a new module at gnu/packages/rust/my-rust-app-1.scm 2.2) Add a new module at gnu/packages/rust/my-rust-app-2.scm 3) All package definitions inside gnu/packages/rust/*.scm which are source-only (#:skip-build? #t) should not be exported. 4.1) gnu/packages/crates-*.scm will not cease to exist, existing rust apps packages that have a Cargo.lock could gradually be migrated to the new organization 4.2) libs which need to be built can still live in gnu/packages/crates-*.scm 5) A (define-public my-rust-app-1 (@@ (gnu packages rust my-rust-app-1) my-rust-app-1)) or equivalent could be done in a (gnu packages category) module to export the rust app in the desired category. 6) Unlike nix (which also parses the Cargo.lock in the build system), we don't lose the ability to make snippets for sources this way. 7) For updating/maintaining a rust package defined this way, one would be able to simply re-run the guix tool, and replace the gnu/packages/rust/my-rust-app.scm file, only copying over the final relevant package definition for the rust app with its tweaks for building, and passing over the new cargo-inputs generated by the guix tool. I believe that by only changing the way things are organized and having a guix tool that generates self-contained package definitions from Cargo.lock, it would be possible to greatly improve the time required for contributing new rust apps packages and maintaining them on Guix. Things don't need to be the way I described here, these are just my initial thoughts after several failed attempts and wasted time trying to contribute rust apps to Guix, I'd like to discuss workarounds and if the benefits are greater than the disavantages for an approach like this. The tool we made works really well for packaging for our personal channels, I am very satisfied with how easy it is, and I think Guix could benefit a lot by adopting a similar approach. What am I missing here? Are there any disavantages to this approach? Anything that would break from it if adopted on Guix? Any questions or suggestions? Murilo [1] https://codeberg.org/look/saayix/commit/c7643943545d62baba80cccee1650ebf94362858 [2] https://git.sr.ht/~look/cargo2guix
SageMath packaging work
Hi Guix, science team! I was reaching for SageMath today and couldn't find it in the package repository. I notice there's a sagemath.scm file, but no actual SageMath package proper. Is there any work being done on packaging it at the moment? Are there any particular blockers preventing its packaging (excessive dependencies, difficult build etc.)? Having SageMath in Guix would be really handy for me, so I'm happy to give packaging it a go if the only reason is that there's not enough interest (I will just have to wait until after exams, so in about 3-4 weeks). Hope you are all doing well! Warmly, Ada
