Re: Value in adding Shepherd requirements to file-systems entries?
Hi Felix, > Someone once gave me this service [1] to mount a file-system declared > with (mount? #f). [2] It's been working ever since. Thanks! I know custom services can be made that can work on a case-by-case basis. I was curious about the value of encapsulating that logic within an operating-system file-systems field and reusing the existing code of file-system-shepherd-service in (gnu services base) and mount-file-system in (gnu build file-system). My comment on NFS support is more about how mount-file-system supports mounting NFS file-system records, but the existing code that actually uses mount-file-system tries mounting all file systems before networking has begun. Ergo, the fact that mount-file-system supports NFS seems a bit extraneous at present, at least insofar as I can decipher. I submitted a patch for what I'm thinking at https://issues.guix.gnu.org/70542. If this winds up merged I believe your code could be rewritten to remove [1] and replace [2] with --8<---cut here---start->8--- (file-system (device "wallace-server.local:/acct") (mount-point "/acct") (type "nfs") (requirement '(avahi-daemon)) ;resolve .local ;; (flags '(no-atime no-dev no-exec read-only)) ;; (options "proto=tcp6,timeo=300,nolock") (check? #f) (mount-may-fail? #t) (create-mount-point? #t)) --8<---cut here---end--->8--- (I don't have an NFS system on my LAN to test so no promises) Hopefully that shows what I'm thinking. If anyone has thoughts I'd love to hear it, either here or in the patch depending on what's appropriate. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Python's native-inputs
On 2024-04-22 16:40, Ricardo Wurmus wrote: >> TL;DR : >> - patch series in big progress, not done yet because I don't really >> know where to stop and massive rebuilds. > > Please take a look at the python-team branch, which contains changes to > the build system. I'll rebase on it, thanks. -- Best regards, Nicolas Graves
Re: A capture-stdout wrapper procedure in (guix build utils)?
On 2024-04-21, 08:35 -0700, Felix Lechner wrote: > It may be better, however, to finally fix Guile's 'system' and > 'system*' to work with 'with-output-to-string'. [2] Hi Felix, Thanks for getting back to me. Great point re potentially fixing this further up in the "chain", i.e. in Guile. I'll try and raise this on the Guile IRC channel and/or ML and update this thread with my findings. Thanks, best wishes, Fabio. -- Fabio Natali https://fabionatali.com
Re: Is git the best tool for pulling packages?
Adam writes: > As I see, first guix pull running too long for a lot of people. Note that this is not due to download speeds but often due to compilation. When updating Guix you are not just fetching new data, but a new version of Guix itself (which happens to come with a library encoding package relationships). That new version may need to be compiled locally, which is slow. We aim to provide pre-built components that Guix can download instead, but computing what needs to be fetched in the first place *also* takes a decent amount of time. The problem would be the same if the transport mechanism was a compressed archive instead of an update to a git repository. > Probably there are ways to cache all of this. We are caching things in ~/.cache/guix. -- Ricardo
Re: Should we include nss-certs out of the box?
On Wed, Apr 03 2024, Maxim Cournoyer wrote: > It's been Guix policy to let people choose whether to install or not TLS > root certificates and which one to their machine. While I applaud the > idea to have the users make a conscious decision about it, in practice I > suppose very few of us choose to *not* install any as that basically > breaks using web browsers, especially ones like IceCat which (by > default) ensures HTTPS is used on every page. I'd be surprised Icecat breaks from this as it uses its own cert database and allows HTTP when HTTPS doesn't work. Kind regards, Clément
Re: Is git the best tool for pulling packages?
>From a computational perspective, downloading tarballs is much simpler than >fetching from Git. But Git offers so many advantages, and computing has become so inexpensive, that it's become very common to use Git instead. Recent Git implementations have optimized serving of specific Git commits, as compared to fetching the entire Git history. That means that you can fetch a single revision of a huge repo, using a small amount of bandwidth. For the specific case of `guix pull`, the Git server is hosted at Savannah, which does not use one of these optimized Git implementations, so it is relatively slow and expensive to fetch. Additionally, Guix's authentication mechanism requires fetching many Git revisions in order to verify the chain of trusted revisions (Git commits). This requirement to fetch many Git revisions, combined with the unoptimized Got server on Savannah, means that `guix pull` may be slower than comparable actions on other distros, especially the first time, and if you haven't pulled in a while On Sun, Apr 21, 2024, at 18:31, Adam wrote: > Hi guix! > Recently I used nixos on one of my machines. And I noticed people there use > tar balls for fetching package definitions. And It worked much faster for me. > That was surprising and I decided to write this letter. > Is git the right tool for getting new package definitions? What if git > commits history will become enormous? > As I see, first guix pull running too long for a lot of people. > Probably there are ways to cache all of this. > Anyway, I'm just curious about it. If there are already answers for my > question, I would like to read them.
Re: Fallout from recent nss-certs changes
Ian Eure writes: > The change is mentioned in the channel news, but it says nothing about > needing to remove that part of the config. You are right; I have added more explicit instructions as commit e5c0ea22e68cc8d6f99957295bc9198afb8455df. Users should see it when they guix pull again. Regards, Florian
Re: Should we include nss-certs out of the box?
Fabio Natali writes: > For what it's worth, I put together a micro-patch and sent it over as a > follow-up to #70451. Pushed as 67a3a83170c038d2eb084d3f53a7ea7b033aea74. Thank you! Regards, Florian
Change logs: usage of square brackets
Hello Guix! I wonder what is the proper usage of square brackets in change logs. According to https://www.gnu.org/prep/standards/standards.html#Change-Logs square brackets are used for conditional changes, the name of the condition is specified inside '[ ]'. However looking over the commit history I mostly see another usage of '[ ]' for specifying the name of a record field which content is being changed. Is it fine to use the name of a record field inside square brackets for changes that are only affected if the content of the record field is #t, like in https://issues.guix.gnu.org/70341#2 ? Best Regards, Nigko Yerden
