Re: A friendlier API for operating-system declarations
Am Montag, dem 19.02.2024 um 14:25 -0800 schrieb antlers: > ``` > (define (os-with-yubi parent users*) > (modify-record parent > (groups -> (cons (user-group (name "plugdev")) <>)) > (users -> (map (lambda (user) > (if (member (user-account-name user) > users*) > (modify-record user > (supplementary-groups -> (cons "plugdev" > <>))) > user)) > <>)) > (services => (append <> (list > (service pcscd-service-type) > (simple-service 'u2f-udev-rules udev-service-type > (list (specification->package "libu2f-host"))) > (simple-service 'yubi-udev-rules udev-service-type > (list (specification->package "yubikey- > personalization" > ``` That looks like a nice syntax indeed. Is the code behind it small enough to include it in (guix records)? If so, would you care to submit it via the usual contribution channels? Cheers
Re: [Cuirass] JavaScript work
Janneke Nieuwenhuizen writes: > I'm wondering though what the net gain of minification is > with current bandwiths. On the few sites that I use javascript on I just > ship the preferred readable code. JavaScript libraries can weigh several megabytes unminified. With minification applied to the concatenation of all JavaScript code we can reduce the number of requests that need to be made and the weight of the request. [I remember that accessing anything JavaScript heavy (by byte-count) was no fun in China.] But minification may not be worth it anyway once we get rid of all unnecessary JavaScript like jQuery, bootstrap, and DT. -- Ricardo
Re: Simple design question for schemers
Hartmut Goebel writes: > Using a custom function "extend": > > (native-inputs > (extend %standard-trytond-native-inputs > trytond-account-invoice > trytond-purchase > trytond-sale)) We have a macro called MODIFY-INPUTS, which you could use, but CONS* is probably enough in your case. -- Ricardo
Re: Building container images with nix2container
Antoine Eiche writes: > In case you would like to try nix2container with Guix, in theory, you > would need to add the support of another input reference graph format > [6] and a write simple Guix derivations [7] calling the nix2container > binary. We have "guix pack" as part of Guix. It builds Docker or squashfs images as well as various other formats. What does nix2container offer beyond what we have? -- Ricardo
Re: Initialization of go-team branch.
On Fri, Feb 23, 2024 at 09:44:53AM +, Sharlatan Hellseher wrote: > > Hello Guix! > > After intitiating go-team branch (inspired by the rust-team) I started > pushing reviwed patches to it, which may require a full Golang rebuild. > My future plan is to update the existing Golang ecosystem to recent > versions, as most of the packages are quite dated (2-5 years old). > > As an intial work golang-*.scm submodules are introduces and some > packages were extracted from golang.scm and placed into logical modules. > > - golang-build.scm > - golang-check.scm > - golang-compression.scm > - golang-crypto.scm > - golang-web.scm > - golang-xyz.scm > > I have CC'd Troy and Artyom as they are actively working on Golang updates. > > Following these threads: > - https://lists.gnu.org/archive/html/guix-devel/2024-02/msg00026.html > - https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00128.html > > I might need some guidance on the following topics: > - Do I need to rebase to master or merge master into go-team while > working on it? In general a wip- branch is expected to be rebased and otherwise it's expected to merge. IMO for a team branch it should be expected that the team knows what's going on, but I can see how it would get confusing quickly with multiple teams. > - What is the approximate merge into master cycle? When the branch seems good then you send a patch to guix-patches with The Magic Words™¹ which will cause qa.guix.gnu.org to start building the branch, once the other team branches ahead of it are finished merging. As far as when, whenever it seems like its ready, at whatever cadence you're (as the team and/or the steward in charge of shepherding the merge through is) happy with. > - Do I need to send patches to guix-patc...@gnu.org even if I intend to > push them to the go-team branch? In general it should follow the same standard as other patches for Guix. In practice people filter for their own interests and hope someone else will take a look at any others. > After reviewing: > - #69205 [PATCH] gnu: Add go-1.22 and its standard library. > - #68300 [PATCH] gnu: Remove go-1.14. > - #69015 [PATCH 0/2] Deprecate the go-etcd-io-bbolt variable, > > I rebased on the latest master, then merged master, and finally pushed > to the go-team branch. Also can you pull in the patch from bug#67505? Thanks. ¹ I have to look up the phrasing each time. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Packaging Hyprland
On Sat, Feb 24, 2024 at 10:32:29PM +, John Kehayias wrote: > Slightly off topic, but for anyone wondering about my emacs keys issue: > > On Sat, Feb 24, 2024 at 04:01 PM, John Kehayias wrote: > > > Seems xremap can do it (which we have packaged) except it doesn't > > pick up different applications for where keys apply on Hyprland. I > > do miss in Stump how easy that was right in the config. > > It does work! Slight difficulty since I had already set capslock to > control in my Hyprland settings (via xkb I believe). So I still had to > map capslock to control in xremap as well, and then the provided > example of emacs keybindings works (with the modification that on my > system at least it is 'emacs' (lowercase) for the application name to > make sure xremap doesn't apply there as well.) > > Guess I can continue with Hyprland! The README and Cargo.toml disagree about what commands to call, but I can add a hyprland variant of the xremap package if there's interest. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Debugging missing architecture support
Hi Ludo, > This shows an attempt to compile libwebp natively for aarch64-linux, > which fails on your machine. > > To cross compile, you would run: > > guix build python-jupyterlab --target=aarch64-linux-gnu That's already what I did, by giving the same option to "guix pack". I had someone check on a real ARM machine, and there libwebp compiles just fine. There seems to be some cross-compilation issues, for whatever reasons - this isn't my priority for now. I ended up tracking down all the issues with the container I was trying to produce, and in the end it's always ghc that prevents builds for aarch64-linux. Most frequently by having pandoc as a dependency. I'll have to take a closer look at Efraim's diff (thanks Efraim!), but I fear it's above my paygrade. Cheers, Konrad.
Re: A friendlier API for operating-system declarations
> That looks like a nice syntax indeed. Is the code behind it small > enough to include it in (guix records)? Small enough? Yes (<100 LOC, inc. a handful of comments and tests). Suitable? No, I introduced it as "moderately-cursed" for a reason >u< But I appreciate the sentiment c: 1.) It leaks `(guix records)`'s thunked/delayed field abstraction to the end-user, which will confuse and regularly bite absolutely anyone who tries to use it. 2.) Ideally we'd check that modified fields exist at compile-time. This could require users to provide the record-type, which is not always public, but could also be optional. 3) The `cut`-like transformation is recursive and, while it has well-defined and tested behavior, the semantics are non-standard. I don't believe that the syntax achieves its goals without this mechanism, but there are remaining sub-concerns to address before I'd consider it ready to formalize and document. 4) The syntax expands modifications of multiple fields into recursive expansions (ie: calls to the record constructor) when it would be more efficient (especially for thunked/delayed fields) to accumulate transformations by target field and `compose' them over a single call to the record constructor. This hasn't been an issue in practice, but would be the "right thing to do". #3 and #4 are a light refactoring and feedback-round away (#3 could be controversial), but #1 and #2 require deeper understanding and (especially for #1) modification of `(guix records)' than I'm comfortable with at the moment. If I do raise the possibility of up-streaming it would be with these issues addressed, and would still have substantial cause to warrant discretionary discussion then. Really a scratching-my-own-itch solution atm.
Re: A friendlier API for operating-system declarations
> I don't believe that the syntax achieves its goals without this > mechanism I just realized my example doesn't actually include a use of recursive cut after all (whoops), and finding only 2 uses in my code-base, am open to considering SRFI-26 sufficient. This helps somewhat, but was not the blocking issue.
Re: A friendlier API for operating-system declarations
Am Sonntag, dem 25.02.2024 um 10:49 -0800 schrieb antlers: > > 1.) It leaks `(guix records)`'s thunked/delayed field abstraction to > the end-user, which will confuse and regularly bite absolutely anyone > who tries to use it. > > 2.) Ideally we'd check that modified fields exist at compile-time. > This could require users to provide the record-type, which is not > always public, but could also be optional. You can get the record type of a record at run-time, so at least you can synthesize a check that gives you a helpful message if that's what you're gunning for. > 3) The `cut`-like transformation is recursive and, while it has > well-defined and tested behavior, the semantics are non-standard. I > don't believe that the syntax achieves its goals without this > mechanism, but there are remaining sub-concerns to address before I'd > consider it ready to formalize and document. Perhaps we can make it like modify-services where we take a value updater instead of evaluating the forms directly? This would fix both #3 and #1 (since we'd unwrap the thunked/delayed field silently). That would also make it so that we can use a single set of arrows (=>) for both. > 4) The syntax expands modifications of multiple fields into recursive > expansions (ie: calls to the record constructor) when it would be > more efficient (especially for thunked/delayed fields) to accumulate > transformations by target field and `compose' them over a single call > to the record constructor. This hasn't been an issue in practice, but > would be the "right thing to do". That's a minor detail, but it might be a syntax-rules → syntax-case change. > If I do raise the possibility of up-streaming it would be with these > issues addressed, and would still have substantial cause to warrant > discretionary discussion then. Really a scratching-my-own-itch > solution atm. Of course it'd go through the proper review channels first, but from personal experience talk over at guix-devel is less likely to cause the change you want over submitting an actual patch :) Cheers
Re: A friendlier API for operating-system declarations
Thanks for the detailed response c: The blocker is that AFAIK we can't tell if a record-field was defined as thunk-ed or delay-ed outside of the expansion of the `define-record-type*' form that defines it, nor programatically access it's getter/setter (the pair `(guix records)` defines, which accounts for eg. thunk-ing, and is distinct from the underlying pair returned by eg. `record-accessor').
