IRC channel logs
2025-07-06.log
back to list of logs
<PotentialUser-25>Hi, is there any documentation for how and why `.guix-authorizations` is used? Why do we have it when there is the keys in .guix-authorizations <starsabove>currently theres a way to go from gexp->derivation, and build-expression->derivation, but is there no gexp->build-expression? im trying to wrap a gexp into a package definition but trivial-build-system seems to expect a plain build-expression.. <Rutherther>starsabove: trivial-build-system works with gexps <starsabove>wait i mustve been doing something wrong because when i double checked it actually does work huh.., <csantosb>sneek, later tell PotentialUser-25, see 6.10 Specifying Channel Authorizations and 7.5 Invoking ‘guix git authenticate’ for .guix-authorizations <tazjin>has anybody written a sort of "guix for nix people" document? I'm trying out "the other side", but running into a lot of mental models from Nix not really translating 1:1 to Guix <luca>Out of curiosity, what are such models? <tazjin>luca: the most confusing thing to me right now (and I might incorrectly summarise this due to lack of understanding) is that guix (the command) doesn't seem to "import" the package set (as you would import nixpkgs in Nix), but seems to be built against a specific set of channels making up the package set <tazjin>so in Nix you pick most any version of the interpreter, import with it any version of nixpkgs (the package monorepo), and then use that to yield derivations. In guix, it seems, you "build yourself a guix" using a set of channels and then use that to interpret a configuration <futurile>tazjin: I don't think anyone has written such a doc - it would be very useful though :-) <futurile>tazjin: Guix is strictly a 'rolling release' set-up, so there's no particular version of Guix that you import. <futurile>tazjin: you can specify the commit that the guix package repo uses - but it's not like nix-packages where you have branches - it's all rolling forward <tazjin>futurile: sure, by "version" here I just mean "a particular commit of the repo" <futurile>tazjin: if you want to specify that you can - look in the manual for guix describe as teh command, and it will lead you to how to specify it <tazjin>futurile: in Nix, I track nixos-unstable (which frequently has breakages for critical-to-me packages), so in the configuration I always keep around an earlier "stable" commit and the current rolling one, to pick particular packages from the older one if needed <tazjin>I believe the equivalent in Guix would be using an "inferior" with an older commit <tazjin>by the way, the difference in documentation quality is noticeable, guix clearly has nix beat here <futurile>yeah, the docs are good, they pretty much cover everything. The general thing is people would like more 'howto' stuff. <futurile>I personally specify the commit for my channels, and then I do an update once a week or so - that way I can check everything works correctly and keep my machines in sync <tazjin>I don't "like" how this makes updates a two-step process (i.e. the config is seemingly not self-contained with the version used to build it), but this might just be out of a lack of familiarity for now <futurile>There's more advanced ways to do it in your guix system file - so specifying the channels.scm file in there - that way it would be one file <tazjin>futurile: you'd still update the channels in there -> reconfigure (new channels.scm materialises) -> pull (rebuild 'guix') -> reconfigure (use new channels) afaict <tazjin>it's a strange thing to get hung up on, but it's very different from Nix <futurile>yeah, my impression is that generally people think Guix is Nix using Scheme, but in reality it's the Nix core concept with a fairly different uix (and scheme ofc). I'll be interested what you think as you try it out ... <luca>Honestly I chose guix because it's nix + scheme. The nix language looked so weird. (Not that I knew anything about nix or guix) <Rutherther>I have a nix v guix article about channels laid out in my head, but haven't had time to actually write it yet, so I see it could be appreciated by some people, maybe I will hurry up little :) <danlitt>Hey, I'm having some trouble with ruby installed via guix, I wonder if anybody else sees the same? When I make any Net::HTTP request I get an SSL error "certificate verify failed (unable to get local issuer certificate)". I think it must be something wrong with the guix package because I get no issue with "nix-shell -p ruby" (I am running guix on NixOS). <Rutherther>danlitt: on foreign distros, don't forget to set the certs environment variable. You can put it to something like .profile, or if you want just quickly in shell, you can include nss-certs and curl in the shell (curl is just to give you the search path) <lh>> this makes updates a two-step process <lh>yeah, guix pull is kind of weird coming from nix where nixpkgs is separate from the nix client <danlitt>Rutherther: Thank you! I'm quite happy to add curl via guix, so that fixed it for me. <tazjin>lh: thanks. That looks interesting and feels like a more nixy way to solve it <tazjin>I decided to do my guix exploration on a machine with a zhaoxin CPU, and that may have been a mistake, every guix operation is 10+ minutes. trying to figure out an equivalent to the Nix flow of building the system remotely, copying the system closure over and activating it <tazjin>it seems that copying needs either SSH access, *or* (to use a substitute) at least evaluating the config locally <tazjin>let me rephrase as questions: 1) can I make `guix copy` copy from an HTTP substituter? 2) given a system closure at /gnu/store/whatever...-system, can I "just" activate it on the machine? <tazjin>I see they have an `activate` binary, maybe just calling that as root will work, but Q1 remains <chipb>tazjin: guix-flavored tvl monorepo when? ;-p <futurile>yeah the 'Guix is slow' thing is a common user complaint <futurile>I think the Survey it was in the top-3 for sure <csantosb>The thing is that Guix is slow ... when you first install it. Is it afterwards (as compared to nix, for example ) ? <dodoyada>I don't pull or reconfigure on a schedule so... yeah <tazjin>are the bottlenecks known by the way? <tazjin>dodoyada: do you update more or less often than once a month? <lh>csantosb: yeah, it is slow after initial pull compared to nix. guix pull takes over a minute for me with pinned channels when everything is already available locally. guix time-machine doesn’t have this problem so it should be fixable <lh>also, despite setting --max-jobs, it seems like my emacs package builds (I rewrite the inputs to use my emacs package so everything is AOT native compiled) do not parallelize like they should <lh>so whenever emacs changes, I am in for like half an hour of builds <identity>tazjin: wingo is working on a new GC for Guile, not sure if GC is the bottleneck in this case <tazjin>identity: I'd be surprised if it is, but I haven't done any performance profiling. <lh>yeah I doubt that is related. I would guess there is a fair amount of low-hanging fruit and that it is just not easy to prioritize for the people who have the prerequisites <lh>> you have to already know Scheme, which is a more complex language than Nix <lh>tazjin: “complex” is doing a lot of work here lol. I was an Emacs user but Scheme was a lot easier for me to get my head around than Nix <tazjin>lh: oh sure Scheme is not difficult to pick up if you know elisp, or cl, or maybe even clojure <ekaitz>scheme is not difficult, programs written in scheme are <lh>with Nix I still don’t really understand how the arguments at the top of module files get passed around. I basically copied snippets into flake.nix until it worked <tazjin>lh: flakes are supremely unhelpful for building an intuition of how nix works, I've seen this a lot <lh>yeah the never ending flakes holy war is partly what gave me the impetus to switch. maybe I should switch back now that npins seems to be getting popular <lh>btw, would love to have more people helping with the guix package in nixpkgs <tazjin>nix is more fragmented than ever before, with different corporate interests pulling in various directions, I think especially if you're philosophically aligned with Guix now is not a good time to move in that direction ;) <lh>I do what I can but I am kind of an impostor in nix land <lh>gexps are tricky but that might just be fundamental complexity of embedding build side code. parametrized packages seem like they would help a lot in not forcing beginners to get their hands dirty there, like nix overlays <dodoyada>fwiw guix was the primary reason I ever got past clojure into schemes (guile specifically). I've been deep diving guile for a while now and still don't take advantage of my language knowledge or repl when working on guix system/home configuration. Maybe the barrier is too high to consider scheme to be a true advantage but if we look at it as 'just' a configuration language the documentation support is pretty good all things conside <tazjin>lh: from what I've seen they don't seem to be harder than all the crazy shell code in nix's stdenv, for example <tazjin>lh: and in the nix world people were proposing replacing it with e.g. execline, which, eh, wouldn't exactly make things easier) <lh>definitely, I just found it tricky to grok the layers of quoting at first. but the payoff is huge <dodoyada>I've never even tried nix because I love the gnu-ness of guix. I imagine a lot of us are here from a purely idealogical perspective <lh>also worth noting, the community is smaller so less bandwidth for big projects like DEs. gnome is usually behind for example, and with the recent news about systemd that will mean even more work. whereas jtojnar’s efforts have made gnome rock solid in nixpkgs <lh>that’s why I’m still using it on top of nixos atm (also I stumble across bug reports like shepherd/fibers memory leaks and gnome crashing occasionally, where I’m like yeah, maybe I will hold off on the base OS for now) <luca>Hi, anyone got any examples of a package that takes in multiple sources? (like multiple tar or zip files). Very basic grepping didn't help <civodul>tazjin: very interesting post, thanks! <civodul>good to have the perspective of a seasoned Nix user <lh>luca: looks like cgit pulls in a git release tarball by specifying an origin in the package inputs field <lh>so it seems the package source field can only have one origin (plus patches, and the recursive option for submodules) but then you can add more in inputs <tazjin>ah, another thing I didn't mention in the post, I haven't figured out how graft distribution works <tazjin>are they outside of the normal channel, i.e. a build updates grafts, and if I stick to an older channel commit the number of grafts will keep increasing? <tazjin>or are they distributed inside the channel? <civodul>tazjin: grafts are defined in the channel, with a ‘replacement’ field in the package, but they are built locally