Re: watchdog triggered auto-rollback
> i'm afraid that's not the case currently: > > %guile-static-stripped crashes with a sigsegv (i.e. the guile used in the > initrd (?)) > https://issues.guix.gnu.org/71211 Interesting. Is this a recent bug? When I was trying to bring up Guix on the VisionFive 2 I was being dropped into a Guile REPL when the initrd failed to find the root partition.
Re: watchdog triggered auto-rollback
Nathan Dehnel writes: > GRUB: https://www.gnu.org/software/grub/manual/grub/html_node/fallback.html > GRUB supports falling back to another boot entry if the machine fails > to boot. This could be integrated with guix so GRUB falls back to a > previous guix system generation. This covers the case of "we can't > start a watchdog service because the system won't boot". How does GRUB determine a boot failed? Does it have to be something drastic like "kernel failed to mount the initrd" or can it catch more complex errors? I believe that if the initrd fails during startup it will abort into an interactive Guile REPL. This might hurt GRUB's ability to detect something went wrong since the kernel would still be running. A similar case may apply if Shepherd gets stuck during system initialization. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Error handling when 'guix substitute' dies
Hi Ludo! FYSA based on https://issues.guix.gnu.org/71238 I suspect the fix mentioned in that patch might not be applying properly in all cases. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Improving the speed of guix time-machine for development environments
Hi Guix!
> I think channels listed in channels.scm files should optionally support
> using whatever channel version is already in the user's profile, if
> present. This would significantly speed up entering development
> environments composed of Guix channels.
> Unfortunately, *I may be delayed every time I enter the development
> environment by several minutes while Guix computes a new derivation
> due to an update in %default-channels*.
I wound up implementing a proof of concept for this idea here:
https://www.freakingpenguin.com/blog/guix-tricks-self-referential-channelsscm-files.html
--8<---cut here---start->8---
(define (soft-pin-channel input-channel)
"Given @var{channel}, return a new version of channel that uses the
current profile's commit of said channel. If the channel is not present,
commit is #f."
(define (desired-channel? channel)
(equal? (channel-name input-channel)
(channel-name channel)))
(define (profile-commit input-channel)
(call/ec
(lambda (return)
(map (lambda (x)
(when (desired-channel? x)
(return (channel-commit x
(current-channels))
#f)))
(channel
(inherit input-channel)
(commit (profile-commit input-channel
--8<---cut here---end--->8---
If people think this is useful, I'm happy to flesh out the idea more and
submit a proper patch. In my experience this does improve the
development experience when setting up developer tools that rely on
custom channels. At least when there's a new Guix commit, I don't have
to wait several minutes for a new Guix channel collection to build, but
without pinning it to a specific commit.
At present I can think of soft-pinning a list of channels by name being
useful. I can also see an option to only fetch dependencies of a
channel, not the channel itself, being useful. I would definitely
appreciate feedback or use cases! :)
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Re: watchdog triggered auto-rollback
raingl...@riseup.net writes: > Would others find this useful? Where in the stack would this be solved? > Could we, for example, catch an issue in the init system and still > perform a rollback? Or if not a full rollback, then at least a reboot > into the previous config? (And if that is also broken, then the one > before, etc, etc) > > Obviously there are a lot of edge cases and potential bugs in this > mechanism as well. Sticking with the SSH example, rolling back to a > version that was kept around where the authorized keys are different > would also make the machine unreachable via SSH. I would definitely find this useful, particularly when combined with unattended-upgrade-service. I don't know the best way to handle an init system failure. Perhaps a starting point would be a one-shot conditional-rollback-service with a "shepherd-requirements" field and a "test" field that takes an file-like object. This service would execute that file, write the output to some log file, and trigger a rollback if an error is signaled. Presumably this service should only trigger on boot, not reconfigure so we don't risk running the test with old services. I don't believe Guix has a mechanism yet to say "Yes, this service is new, and I /do/ want Shepherd to auto-start it, but not on reconfigure". This shouldn't be too hard to add though. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Guix pull: avoiding "Computing Guix derivation"
> I see that build in build-self.scm isn't a derivation, but most of the time > spent in build is, to my knowledge, while the daemon is building the > build-program derivation. build-program in build-self.scm returns a > gexp->script file-like object and I see various /gnu/store > *-compute-guix-derivation.drv files in my store. Sorry, saying "most of the time is spent on building the build-program derivation" is not correct. Most of the time is spent on running the compute-guix-derivation script. D'oh. I'll spend more time trying to understand the current system.
Re: Guix pull: avoiding "Computing Guix derivation"
>> - Why is this step not substitutable ? The inputs are known, a hash can >> be derived, a substitute server could be queried for an output of that >> hash ? What am I missing ? Does the guix derivation not end up in the >> store ? What makes it so special that it can't be served by a substitute >> server ? > >It’s not substitutable because it’s not a derivation. It’s not a >derivation because it needs to access the store to “compute the Guix >derivation”. I see that build in build-self.scm isn't a derivation, but most of the time spent in build is, to my knowledge, while the daemon is building the build-program derivation. build-program in build-self.scm returns a gexp->script file-like object and I see various /gnu/store/*-compute-guix-derivation.drv files in my store. Ergo, if more of the inputs to build-program were locked, the compute-guix-derivation output should be substitutable. To my knowledge the problem largely lies in that the modules imported in build-self.scm are from the current Guix, which vary wildly between machines and is rarely, if ever, substitutable. In theory if those modules were pinned to particular versions, the bulk of the time spent in build would be removed. Obviously there are challenges with this approach. For one, if we were to use the "guix" package to run build and generate compute-guix-derivation.drv, what would we do if a user on Guix A wanted to upgrade/downgrade to B, but the Guix package was changed in-between? I think the various problems are solvable, perhaps by making the solution opt-in. e.g. $ guix pull --quick, which attempts to build channels using an infrequently updated Guix/Guix-subset to more regularly match an existing compute-guix-derivation in a substitute server's store. Sorry if the formatting on this is off, sent from my phone.
Re: Guix pull: avoiding "Computing Guix derivation"
Simon Tournier writes: > Hi, > > On lun., 13 mai 2024 at 17:11, Richard Sent > wrote: > >> Instead of A and B building C directly, A and B download the >> substitutable Guix package D, then use D to build C. Because D is a >> reproducible package, it should be substitutable from both A and B. >> Then, because D->C is the same for everyone, we could substitute the >> Guix derivation computation for C. > > Maybe I am missing some details. From my understanding, your D is the > result of the “Computing derivation” dance. And it is a minimalist > build because it must work for both cases: with or without substitutes. > > Somehow, my understanding of the current process is: > > A -> D -> C > B -> D* -> C > > And, D or D* can be the same script. Here, the property is a kind of > idempotency. Hence, C is substitutable. > > IIUC, your proposal is to fix D (the intermediary step). You propose > the package named ’guix’ that changes barely, but it could be something > more minimalist. The requirements is: susbtitutable. The problem is > transferred to the first arrow, no? > > How can we be sure that A and B points to the same D? > > Other said, A lives in the past. Later, we changed D becoming D* > because some bugs. The other revision B lives after this change. > Therefore, we have the same picture: > > A -> D > B -> D* > > But then how do we go to C since D and D* does not have a kind of > idempotent property. > > From my understanding, the current situation/process is very similar > with the one for compiling compiler: you have your new Source of > compiler and an OldCompiler binary, so you run: > > OldCompiler(Source) -> Compiler > and again Compiler(Source) -> NewCompiler > > Somehow, whatever the choice of some OldCompiler binary, you get the > same NewCompiler binary (aside trusting trust attack and friends, > obviously ;-)) You're correct. This solution wouldn't be sufficient to avoid "Computing Guix Derivation" for every possible A or B. To my understanding it could reduce the frequency this occurs. (To change letters yet again, I'll use Z to refer to the output Guix.) As a package (either "guix" or a minimalist subset), D, D*, D**, etc. should all be substitutable. If we consider input Guix's A, B, C, E, F, ..., our original "Compute Guix Derivation" graph would look like: --8<---cut here---start->8--- Z / \ /| |\ /| | | |\ / | | | | \ A B C E F G --8<---cut here---end--->8--- i.e. for every possible input Guix (and output Z), we'd need to store a substitutable intermediate step. Not feasible. By having A, B, C, ..., use a substitutable Guix package D, our graph would look like this instead: --8<---cut here---start->8--- Z /| \ / | \ D D* D** /|\ |\ | A B C E F G --8<---cut here---end--->8--- Assuming D changes significantly less frequently than A, B, C..., I would think this should be something we could feasibly substitute (at least for recent D and Z). Perhaps this isn't viable. I'll confess to not being super familiar with how build-self.scm operates. At a naive level, $ guix build guix doesn't need to run "Computing Guix derivation", so if A->D doesn't need to compute the derivation, and D->Z is substitutable for some subset of D and Z, I'd think we can skip "Computing Guix derivation" as long as someone isn't trying to either a) Use an A that refers to a D** that's since been GCd b) Try to get a Z that hasn't been built by D, D*, D**, etc. Does that sound correct? -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Guix pull: avoiding "Computing Guix derivation"
Simon Tournier writes: > Hi, > > On lun., 13 mai 2024 at 17:04, Edouard Klein wrote: > >> - Why is this step not substitutable ? The inputs are known, a hash can >> be derived, a substitute server could be queried for an output of that >> hash ? What am I missing ? Does the guix derivation not end up in the >> store ? What makes it so special that it can't be served by a substitute >> server ? > > Assume we are running two different Guix revisions, say A and B. And at > the end of our respective “guix pull”, we expect to have the same > revision, say C. We expect to then run the same Guix. > > Other said, how can we “compile” the code of C using one machinery from > A and another potentially different from B and expect to have the same > result? > > Somehow, we need an intermediary step: something minimal that is > independent of A and B but produces the same C. And it’s the aim of > “Computing derivation” with the script build-aux/build-self.scm. > > The inputs are known, indeed. However, the ones from A and from B are > not necessary the sames. For instance, Guile of A might be different of > Guile of B. Somehow, that “Computing derivation” is what allows to time > travel. > ... > All the point is to build the same result starting from two different > machinery (different Guile, modules, etc) and ending to the same output. > Considering the combinatorial, it would not be possible to substitutes; > it would mean compute all the couples A-C and B-C. > > That’s an hard topic and speed it up would be very nice. Bah it would > require to redesign stuff and perhaps find a process to build the same > output using two different toolchains, somehow. Thanks for the detailed explanation Simon! Given that Guix packages itself as a package, I wonder if there is room to utilize the "Guix package" Guix as a uniform base to build "Guix, the collection of channels" and skip "computing Guix derivation". For instance, --8<---cut here---start->8--- ~ $ guix shell guix -- guix describe The following derivation will be built: /gnu/store/lk0qkgsz33qzhi6c83bw4nbc3sbzjb3s-profile.drv building CA certificate bundle... listing Emacs sub-directories... building fonts directory... building directory of Info manuals... building profile with 1 package... guix 4c94b9e repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 4c94b9e983bc51d9504655f1e7727c4f6d14b6b7 --8<---cut here---end--->8--- Instead of A and B building C directly, A and B download the substitutable Guix package D, then use D to build C. Because D is a reproducible package, it should be substitutable from both A and B. Then, because D->C is the same for everyone, we could substitute the Guix derivation computation for C. My understanding is this would resolve the question of "how to build C given that A and B are different without a long derivation computation?" --8<---cut here---start->8--- ~ $ guix shell guix -- guix time-machine -q --branch=master -- describe Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Computing Guix derivation for 'x86_64-linux'... / substitute: updating substitutes from 'http://10.1.1.101:80'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% The following derivations will be built: /gnu/store/yp694ahf5fb8sm06r9llmgciax8yq20j-profile.drv /gnu/store/dw2gzlz8n93dmvkpb9wbr45p7awsixal-profile.drv /gnu/store/x59ywl8rncs0aqjqnxmjyhyzcznnm643-inferior-script.scm.drv building CA certificate bundle... listing Emacs sub-directories... building fonts directory... building directory of Info manuals... building profile with 1 package... building /gnu/store/x59ywl8rncs0aqjqnxmjyhyzcznnm643-inferior-script.scm.drv... building package cache... building profile with 1 package... guix 0edbb93 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 0edbb93130651f29dc59fe4ca546a5065670ac8a --8<---cut here---end--->8--- I imagine there's a large amount of behind the scenes work that would need to be done for this to work, but if nothing else it's an interesting thought experiment! -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: (almost) deterministic patchsets
> One possible use would be to make `guix download` options, such as > `--patchset=70XXX -v3` > > This could help with patch apply and review. We will have to also take > care of not making guix dependent on b4, but maybe that's possible with > lazy resolving the b4 package? > > WDYT? > >From my perspective having a pretty, command-line way to download patch sets would be a nice QoL feature to have and might make the patch review process simpler. On a related note I recently discovered that issues.guix.gnu.org does have a patch-set endpoint that optionally takes a revision e.g. issues.guix.gnu.org/issue/70XXX/patch-set/3. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Value in adding Shepherd requirements to file-systems entries?
Hi Ludo! > The other option would be to allow for symbols in the ‘dependencies’ > field, because it’s really the same thing. That would only require a > new clause in the ‘dependency->shepherd-service-name’ procedure. Personally I prefer separating requirements and dependencies. Dependencies adjusts the order of mounting file-systems /before/ provisioning 'file-systems, while requirements actually delays mounting a file system until Shepherd services have started (by removing it as a requirement for provisioning 'file-systems). I think this distinction in behavior should be emphasized in the API and manual. An alternative to the requirement/requirements field is changing the name to shepherd-requirement. That would be consistent with other services and make the distinction between dependencies and requirements unambiguous. (And sidestep the pluralization question.) Happy to change to whatever the consensus is! -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Changing the defaults for --localstatedir and --sysconfdir?
Hi Guix, As everyone who's built Guix from source knows, when running ./configure on a system with an existing Guix installation you must remember to specify --localstatedir=/var and --sysconfdir=/etc. I think we should consider whether those variables should default to those values. There's been discussion on this in the distant past, see [1]. At risk of oversimplifying, I think previous consensus was in favor of making some sort of change over the existing behavior before discussion fizzled. The reason for the current situation is so if a user builds and installs Guix from source, localstatedir and sysconfdir will be located in $prefix/var and $prefix/etc. See [2] for Ludo's comments on the matter, [3] for the convention of localstatedir and sysconfdir being under $prefix. However, the "guix" package packaged with Guix (that's a sentence...) configures itself with "--localstatedir=/var" and "--sysconfdir=/etc". See (gnu packages package-management)[guix]. Many (~70) other packages also use the "--localstatedir=/var" configure flag. My understanding is this means even if Guix itself was built+installed from source with the intent of custom Guix-specific var and etc locations, various Guix-related files will inevitably wind up in /var anyway. They would either appear from Guix directly or from the packages Guix installs. (I've noticed the Guix package'd guix be built in the process of reconfiguring my system before, although the cause or impact of that isn't clear to me. It may or may not try placing more files in /var and /etc.) As such, if the benefits in [2] aren't achievable (keeping every guix state-based file in $prefix/var), perhaps it's worth biting the bullet. Defaulting to /var and /etc would lower the complexity of building Guix. The number of users manually installing from source is likely lower than the number of users building Guix for testing purposes. And a user that wants localstatedir in $prefix/var or sysconfdir in $prefix/etc can still choose to specify that manually. If that's not desirable, perhaps there is a third option? ./configure is already smart enough to detect if the configured localstatedir does not match the installed Guix's localstatedir. How about a mechanism that follows this process: 1. If ./configure is invoked without localstatedir and/or sysconfdir, check if there is an existing Guix installation. 2. If there is an existing Guix installation, use the existing localstatedir and sysconfdir values. 3. If there is not an existing Guix installation, use $prefix/var and $prefix/etc. My autotools skill level can be described as asymptotically approaching 0, so that suggestion may or may not be achievable. But I (naively) think it would satisfy everyone. Sorry for the wall of text! Congrats on making it to the end. Have a cookie: [1]: https://lists.gnu.org/archive/html/guix-devel/2016-02/msg00718.html [2]: https://lists.gnu.org/archive/html/guix-devel/2017-09/msg00098.html [3]: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
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.
Value in adding Shepherd requirements to file-systems entries?
Hi Guix! I wanted to ask the Guix community for their thoughts on improving the support for adding networked file systems to an operating-system declaration. For some context, I started tackling adding CIFS support to file-system declarations, but I've hit a snag. CIFS is a networked file system, but Guix mounts all file systems specified in (operating-system-file-systems) either when booting the system from the initrd or as shepherd services after boot that depend on 'root-file-system and 'udev. Either way, these run before any networking service has been initialized. Ergo, a samba share like //192.168.1.102/share won't be found. (At least, not on a wireless network. Perhaps the timing is different for wired ones.) Obviously, adding shepherd requirements to needed-at-boot? file systems isn't possible. However, I think it should be possible to add shepherd services to other file system entries. (And yet, NFS is allegedly supported, although I can't figure out the mechanism for that and don't have one set up on my LAN for testing.) Before hacking away at this myself, I'd like to get other people's thoughts on the best way to proceed. Do others agree that (file-system) entries should support networked devices? Should this be transparent depending on the type, or require explicit configuration? e.g. --8<---cut here---start->8--- (file-system (device "//192.168.1.102/share") (options "guest") (mount-point "/mnt/share") (type "cifs") ;; Should we explicitly require network, or implicitly add it from ;; the type? If the latter, what to do about Avahi? (requirement 'networking) (mount-may-fail? #t) (create-mount-point? #t)) --8<---cut here---end--->8--- I could see this being challenging since it's not immediately clear to me what particular file-system-* service, if any, is provisioning 'file-systems, which other shepherd requirements the user may specify can depend on. I imagine adding a requirement to the wrong file-system could easily cause a deadlock. I know a custom shepherd service could be used to run, say, mount.cifs from userspace after networking is provisioned, but in my opinion it would be cleaner to encapsulate within the existing file-system block of the operating system. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Should we include nss-certs out of the box?
I wonder if instead (or in addition to) a step should be added to the default profile to symlink nss-certs to /etc/ssl/certs/ca-certificates.crt? Consider running $ guix shell rust:cargo nss-certs -CN -- cargo search ox. On c9cd16c630 this will fail with --8<---cut here---start->8--- Updating crates.io index error: download of config.json failed Caused by: failed to download from `https://index.crates.io/config.json` Caused by: [60] SSL peer certificate or SSH remote key was not OK (server certificate verification failed. CAfile: none CRLfile: none) --8<---cut here---end--->8--- This is because /etc/ssl/certs doesn't exist in the shell's container. A user could work around this by running in the shell: --8<---cut here---start->8--- export SSL_CERT_FILE=$GUIX_ENVIRONMENT/etc/ssl/certs/ca-certificates.crt --8<---cut here---end--->8--- but this complicates the handle $ guix shell ... -- syntax. The only package that seems to escape this nonfunctional trap is git because the package definition explicitly sets a GIT_SSL_CAINFO search path specification. IMO, if we agree to add nss-certs to %base-packages, we should also set up a /etc/ssl/certs symlink to %default-profile-hooks. It's very odd to see `building CA certificate bundle...` printed to the console yet not be able to use https except for git in shell containers. Power users will still be able to override the normal behavior by setting the package-specific environment variables. This change would just change the default state from "nonfunctional" to "working". -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Improving the speed of guix time-machine for development environments
Hi Guix, To my knowledge what I'm asking for can't currently be done, but if it can feel free to disregard. I think channels listed in channels.scm files should optionally support using whatever channel version is already in the user's profile, if present. This would significantly speed up entering development environments composed of Guix channels. Consider the following situation: 1. Repository A contains some code, an unmerged Guix package, and a .guix-channel file. 2. Repository B declares an unmerged Guix package that depends on A's package 3. Repository B doesn't want to duplicate the package definition in A, so it adds a channel dependency in B's .guix-channel 4. Repository B wants to make it easy to enter a development environment that includes repository A's channel, so it tracks a channels.scm file with the following content: --8<---cut here---start->8--- (append (list (channel (name 'B) (url (string-append "file://" (getcwd) %default-channels) --8<---cut here---end--->8--- Now in order to build B, I need to enter a Guix development environment that includes A's channel. The only option I know for that is time-machine, e.g. "guix time-machine -C channels.scm -- build -f guix.scm". Unfortunately, *I may be delayed every time I enter the development environment by several minutes while Guix computes a new derivation due to an update in %default-channels*. time-machine will update ALL channels in channels.scm to the master branch (by default) every time I try to enter a development environment (e.g. "guix time-machine -C channels.scm -- shell -CDf guix.scm"). I don't think pinning Guix to a specific commit in channels.scm is the right solution. 1. That increases the maintenance burden (If A updates to use newer Guix code, now all dependents of A need to be manually updated to use newer Guix commits). 2. It makes it easy to mask breakages for an extended period. 3. It implies that B doesn't work on newer versions. 4. Any developer working on the repo will pull an unneeded copy of the channel. I think this is a side effect of time-machine serving dual purposes. One is providing a reproducible environment for result replication, the other is providing a development environment for collections of channels. My proposed solution is to add a (prefer-local?) field to (channel ...). When set, time-machine would first see if there is a channel with the same name in the user's profile. If so, it will include that channel in the time-machine environment instead of fetching it. If not, it behaves as normal and fetches the channel from url. As a workaround, it *may* be possible to achieve this via a command like ~guix time-machine -C channels.scm --commit $(guix describe |
Re: Guix role in a free society
> It pretty easy to see who most people that use Guix agree with that > actually. Check what the CoC says right here I believe that Guix can continue to achieve a welcoming, harassment-free environment even if we're not able to support repo authorship history modification. (Or non-destructive attribution.) I'm not in favor of (mandatory and global) UUIDs. To my understanding there are two options for how they could be implemented: a) UUIDs are used with .mailmap 1) This doesn't solve the problem since .mailmap itself is also tracked in git. Any old names/aliases are still in the repo. 2) This would mask the name change. To my knowledge unless someone is actively browsing .mailmap's log, the old name shouldn't appear. I understand why people may feel that's insufficient though. 3) I don't believe any mechanism stops someone from choosing to do this already? b) The UUID->Name mapping is stored out of band (GitLab's unimplemented solution) 1) This adds additional complication to development (need to fetch files over a network at some point, be sure you're using the right UUID even if you change machines, update your out of band copy regularly, etc). We may be able to partially resolve b) but I doubt it's possible to turn it into a "no-impact" process. It almost certainly would add steps for new contributors. We don't want even more barriers to their first patch. We could choose to allow people to opt-in to using UUIDs and also use out-of-band storage, I suppose, but that would only help those who already suspected they'd want to change their name, but didn't want to change it at that moment. Otherwise a) would suffice. Perhaps there are better options I'm not thinking of. Would UUIDs be valid for the copyright notices at the top of files? -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Concerns/questions around Software Heritage Archive
Regarding Guix development, if the decision is made to not change existing policy or implement another authorship mechanism, I think some text could be added to the manual explaining such. Contributing to Guix is an intentional thing, unlike SWH. Updating the manual means contributors will, at least, be making an informed decision to contribute, knowing that names cannot be changed in the Guix repo's history due to X, Y, and Z consequences in Guix's functionality. I'm not suggesting that this solution is "the end-all-be-all" or invalidates alternative avenues, but I feel it is an improvement over the status quo with no negative tradeoffs. I would not support a solution that obsoletes time-machine or requires regular manual intervention during upgrades. Personally as a new contributor I find it gratifying to see my name in the commit history. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: LWN: A look at Nix and Guix
Thanks for sharing! The comments section was a nice change of pace from the tone of Guix discussion in Hacker News. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Creating an unversioned rust-cargo symbol
Hi Guix, There isn't an unversioned symbol for rust-cargo defined or exported by the (gnu packages crates-io) module. I think it would be best if an unversioned rust-cargo symbol was created that was equal to the highest rust-cargo release. (i.e. rust-cargo, not rust-cargo-0.76) Alternatively, since (seemingly) only one rust-cargo package is present at a time, perhaps the version information could be removed outright and only an unversioned symbol used. The alternative, (specification->package), does not work in all circumstances (primarily with -L) [1]. This would also make Scheme code that refers to rust-cargo cleaner, either not needing updating every new version when the symbol changes or removing potentially awkward (specification->package) calls. I see that most/all of the symbols in crates-io are versioned. While from a user perspective it would be nice if there were more unversioned symbols, rust-cargo is /probably/ the one that needs it the most since it's so central to the ecosystem. I can also see why versioning every symbol might help with development given Rust's release schedule and bootstrapping chain. This would follow the pattern of linux-libre. Posting to guix-devel instead of bug-guix since I'm not entirely sure this is a bug or working as intended. [1] https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00310.html -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Guix deploy --keep-going equivalent for machine connection failures
Hi all, When running guix deploy with a list of machines, the command will fail if any of the machines are unreachable. I use Guix deploy from a central machine to update the devices on my LAN, including laptops, which aren't guaranteed to be on. I'm also not terribly worried about keeping every single device updated in perfect synchronicity. I think it would be useful to have a CLI flag that would continue the deployment even if we fail to connect to one of the machines. At present this can be worked around by commenting out entries on the list, but this requires a) Already knowing what machine is offline b) Remembering to uncomment it later when the machine goes back online c) Generally feels "ugly" in a way that most Guix commands don't. d) Makes version control a pain The default behavior should stay as is, I imagine, since one of the main uses of guix deploy is deploying an interconnected cluster of machines that probably would not appreciate being partially upgraded. Another option worth considered is adding a `'can-connection-fail?' (default: #f)` to either `machine` or `machine-ssh-configuration`. (Probably machine since it would also allow for digitalocean deployments.) This would let me mix a list of "core machines" that I definitely want upgraded in a deployment (NAS, etc), while still having secondary machines that I'm not particularly concerned about upgrading. When running a deployment, there are effectively 3 options for how I could want the deployment to go for machines X, Y, and Z: a) X, Y, and Z must all be deployed together <--- Supported b) X must be deployed, but Y and/or Z can fail<--- can-connection-fail? setting c) X, Y, and/or Z can fail<--- --keep-going-but-for-machines-I-don't-know-what-to-call-this Anyone have thoughts on this? Thanks, Richard Sent
