Impossible to remove all offload machines
Ran into this issue last week. If you: - Configure some offload build machines in your operating-system configuration. - Reconfigure your system. - Remove all offload build machines. - Reconfigure your system again. ...then various guix operations will still try to connect to offload machines, even if you reboot the affected client. This is caused by a bug in the `guix-activation' procedure: ;; ... and /etc/guix/machines.scm. #$(if (null? (guix-configuration-build-machines config)) #~#f (guix-machines-files-installation #~(list #$@(guix-configuration-build-machines config If there are no build machines defined in the configuration, no operation is performed (#f is returned), which leaves the previous generation’s /etc/guix/machines.scm in place. The same issue appears to affect channels: ;; ... and /etc/guix/channels.scm... #$(and channels (install-channels-file channels)) I’d be happy to take a stab at fixing this, but I’m not certain what direction to go, or how much to refactor to get there. Should the channels/machines files be removed (ignoring errors if they don’t exist)? Should empty files be installed? Should that happen inline in `guix-activation', or in another procedure? Should the filenames be extracted to %variables to avoid duplicating between the two places they’ll be used? If someone would like to provide answered, I would contribute a patch. Thanks, — Ian
Request for assistance maintaining LibreWolf
Hi folks, Last year, I spent several months getting the LibreWolf web browser packaged, reviewed, and contributed to Guix. I’m happy to have done so, and glad that it’s proved useful to others. One of the concerns raised as I was going through that process was responsibility for ongoing maintenance. I offered to take that on, and have followed through, continuing to contribute patches which improve the package and update it as new upstream releases occur -- which is very frequently. Unfortunately, much of this work is wasted, as the patches remain mired in the review backlog. The package is now three major version out of date and suffers from numerous CVEs. The initial patch to update the version to 127.x was submitted on June 29th; updated to 128.x on July 17th; and I’ll be sending the patch updating it to 129.x later today, after I’ve finished building and testing it. I’m stuck in an impossible situation. I can’t apply for committer access until I have more accepted contributions, but can’t build those contributions unless my patches are reviewed. It’s frustrating and demoralizing. Are there, perhaps, one or two committers who’d be willing to work more closely with me on LibreWolf on an ongoing basis? I’m not asking for help doing the work of maintaining the browser itself, which I remain committed to doing. I’m purely looking to consitently get timely feedback and review, because the normal process for contributions cannot reliably provide it. A second, and smaller question, is: is there a mechanism to direct others’ contributions to LibreWolf to me for review, without subscribing to every patch sent to Guix? I have seen some patches, and participated, but I have to go look for those, and it’d be more convenient if they were directed to me in the first place. Thanks, — Ian
Re: Request for assistance maintaining LibreWolf
Hello Ian. I cannot help you since I don't have commit access. But I want to thank you for your hard work, I'm currently using your package. I can only echo your frustration since I also have some patches ready to be merged that seem to be forgotten. As it has been discussed in the past, Guix is growing, but there are not enough hands to merge all the contributions that come through. We should try to come up with a solution that alleviates the burden on the maintainers. Given how often this issue arises, what if we try, as a collective, to suggest new mechanisms that would improve the situation? If I recall correctly, someone suggested having a development branch in which, once the QA passes, the patches get automatically merged. I know some people rose concerns about the slowness of the QA system for this to be an effective solution, and there is also the issue ordering the patch application. If the previous solution is ruled out, I would like to know the opinion of the Guix community on a voting system. I'm imagining a system where we reuse the mailing infrastructure we have, where each accepted mail in the guix devel mailing list has 1 vote for a given patch, that way we avoid multiple votes from the same entity and would allow people without commit access, but active on the Guix development, to participate. So, we could set up a threshold where if a patch gets 10 votes from non-committers the merge would be done; preferably automated, but if it's not possible, committers would know what is ready to be merged without effort and what the community wants. Regards, Sergio.
Re: Request for assistance maintaining LibreWolf
Hi Sergio, Sergio Pastor Pérez writes: Hello Ian. I cannot help you since I don't have commit access. But I want to thank you for your hard work, I'm currently using your package. Thank you for the kind words, they truly mean a lot to me. Whatever the state of Guix proper, you can always find the current version of LibreWolf in my personal channel[1], though I don’t have a public substitute server, so long build times will await you if you choose this route. We should try to come up with a solution that alleviates the burden on the maintainers. Given how often this issue arises, what if we try, as a collective, to suggest new mechanisms that would improve the situation? If I recall correctly, someone suggested having a development branch in which, once the QA passes, the patches get automatically merged. I know some people rose concerns about the slowness of the QA system for this to be an effective solution, and there is also the issue ordering the patch application. If the previous solution is ruled out, I would like to know the opinion of the Guix community on a voting system. I'm imagining a system where we reuse the mailing infrastructure we have, where each accepted mail in the guix devel mailing list has 1 vote for a given patch, that way we avoid multiple votes from the same entity and would allow people without commit access, but active on the Guix development, to participate. So, we could set up a threshold where if a patch gets 10 votes from non-committers the merge would be done; preferably automated, but if it's not possible, committers would know what is ready to be merged without effort and what the community wants. I’m not sure this would be effective, because the QA service is unreliable. I regularly see patches which simply don’t get picked up by it, including many of my own. At other times, it lags very far behind. I don’t think it’s reliable enough to be in the critical path for anything. Guix is supposed to be a rolling-release distro, so it feels strange to have a develop branch which moves even faster. Thanks, — Ian [1]: https://codeberg.org/ieure/atomized-guix
Re: Request for assistance maintaining LibreWolf
The latest patch series has been sent (bug #71832). It fixes 14 CVEs, in addition to the 16 fixed in v5. I’ve backed out various improvements and bugfixes I wanted to include, and this does nothing other than the bare minimum to update the package. If anyone would like to step up and review the changes, I’d greatly appreciate it. Thanks, — Ian
Static hosting of substitutes
Hi folks, I’d like to provide substitutes for packages in my personal channel. The ideal setup for this would be for a machine on my internal net to perform the builds, then upload the results to another system on the open internet. That could be a machine running a web server pointed at a directory where the NARs get uploaded, or an S3-like object store, or something like that -- dirt simple, just shifting bytes off disk and out a socket. It seems that nothing like this exists, all the public substitute servers appear to use `guix publish'. That’s not an option for me, since it requires significantly more disk and compute than I have on any public-facing system, and I can’t justify the cost of bigger machines. What would it take to make a system like this work? Thanks, — Ian
Re: Request for assistance maintaining LibreWolf
Ian Eure writes: > The initial patch to update the version to 127.x was submitted on June > 29th; updated to 128.x on July 17th; and I’ll be sending the patch > updating it to 129.x later today, after I’ve finished building and > testing it. Thank you for your continued commitment to this despite the lack of timely review. > I’m stuck in an impossible situation. I can’t apply for committer access > until > I have more accepted contributions, but can’t build those contributions unless > my patches are reviewed. It’s frustrating and demoralizing. I can empathize. I decided to take a step back from posting contributions earlier this year for similar reasons. I am hopeful this can improve in the (near) future. > A second, and smaller question, is: is there a mechanism to direct others’ > contributions to LibreWolf to me for review, without subscribing to every > patch > sent to Guix? I have seen some patches, and participated, but I have to go > look > for those, and it’d be more convenient if they were directed to me in the > first > place. I believe the usual way of doing something like this is via teams (see ./etc/teams.scm ). -- Suhail
Re: Request for assistance maintaining LibreWolf
I wonder how scalable this approach is, if many "package maintainers" each have their own channel for the packages they are maintaining, and made available this way. I would guess to use this approach the Guix users have to do "guix package -u --allow-collision" > Date: Sat, 17 Aug 2024 12:43:11 -0700 > From: Ian Eure > Whatever the state of Guix proper, you can always find the current > version of LibreWolf in my personal channel[1], though I don’t > have a public substitute server, so long build times will await > you if you choose this route.
Re: Request for assistance maintaining LibreWolf
It's not, IMO, because while it's very easy to set up a channel, it's very difficult to publish substitutes for it. I don't think collisions are any more likely, but perhaps you know of cases I haven't encountered. The larger risk is divergence of package definitions, so version X of a package in Bob's channel works very differently than version X+1 in Alice's. I'd greatly prefer to do the maintenance in Guix, as it'd be much simpler for everyone. — Ian On August 17, 2024 5:11:44 PM PDT, Andy Tai wrote: >I wonder how scalable this approach is, if many "package maintainers" >each have their own channel for the packages they are maintaining, and >made available this way. I would guess to use this approach the Guix >users have to do "guix package -u --allow-collision" > >> Date: Sat, 17 Aug 2024 12:43:11 -0700 >> From: Ian Eure >> Whatever the state of Guix proper, you can always find the current >> version of LibreWolf in my personal channel[1], though I don’t >> have a public substitute server, so long build times will await >> you if you choose this route. >
Re: Request for assistance maintaining LibreWolf
Suhail Singh writes: Ian Eure writes: The initial patch to update the version to 127.x was submitted on June 29th; updated to 128.x on July 17th; and I’ll be sending the patch updating it to 129.x later today, after I’ve finished building and testing it. Thank you for your continued commitment to this despite the lack of timely review. I appreciate your kind words; thank you. I’m stuck in an impossible situation. I can’t apply for committer access until I have more accepted contributions, but can’t build those contributions unless my patches are reviewed. It’s frustrating and demoralizing. I can empathize. I decided to take a step back from posting contributions earlier this year for similar reasons. I am hopeful this can improve in the (near) future. I’m feeling very similarly, and have been biasing to maintaining my own channel lately. A second, and smaller question, is: is there a mechanism to direct others’ contributions to LibreWolf to me for review, without subscribing to every patch sent to Guix? I have seen some patches, and participated, but I have to go look for those, and it’d be more convenient if they were directed to me in the first place. I believe the usual way of doing something like this is via teams (see ./etc/teams.scm ). I’m not sure whether/how well this mechanism works for non-committers. Thanks, — Ian
