Shepherd log rotation service
Hello Guix! I’ve just pushed a simple log rotation service for Shepherd: 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’.
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hello. I'm very interested in the code for ZMK provided in this thread[1]. I've tried it locally and it compiles successfully. Does anyone know if this is available in a public repository? Or if it has been moved forward? Anyone here have tried to do something with ZMK? I'm interested in what would be the Guix approach for ZMK development. The blog post of Zephyr[2] was a very interesting read, does anyone know of other resources regarding this topic? Have a great day! Sergio. [1]: https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00014.html [2]: https://guix.gnu.org/en/blog/2023/building-toolchains-with-guix
How to test fixed output derivations in the bordeaux build farm?
Hey! I'd like to do more testing of fixed output derivations, both in general and for patches/branches via QA. In particular, it would be useful to test specific operations in the derivation, e.g. downloading just from upstream. Being able to control this is also necessary to prevent the bordeaux build farm downloading a previous result from itself via the content addressed mirror or download nar fallbacks in fixed output derivations. I've had a look at the GUIX_DOWNLOAD_METHODS environment variable, which is looked at by the url-fetch procedure, but this seems to work by generating different derivations, rather than changing the behaviour of the derivation at build time. It seems sensible to me to add download-methods to the impureEnvVars so that this can be passed in when the derivation is built. As far as I can see though, the only way to set these impureEnvVars is in the environment when you start the daemon, right? That's very inflexible, but given most of these variables look like they could/should come from the client environment (LC_ALL, LC_MESSAGES, LANG adn COLUMNS) maybe that part of the problem can be addressed in the protocol/daemon. Have I missed anything? Thanks, Chris signature.asc Description: PGP signature
