Re: './pre-inst-env guix build xxx' can not find packages in other channels.
>Fri 28 Mar 2025 at 08:54, Feng Shu wrote: > my question is: how to let pre-inst-env work well with my channel > setting, and no need to use -L in every command. Are you aware of GUIX_PACKAGE_PATH ? signature.asc Description: PGP signature
Regarding removal of the rottlog-service-type
Hi, I am currently trying to configure my home server and I have finally got to the log management part. I will probably end up having to use the rottlog-service-type instead of the log-rotation-service-type (due to limitations of the latter), however in documentation I see the following: --8<---cut here---start->8--- Warning: The Rottlog service presented here is deprecated in favor of ‘log-rotation-service-type’ (see above). The ‘rottlog-service-type’ variable and related tools will be removed after 2025-06-15. --8<---cut here---end--->8--- Since the date is pretty close now, I want to ask whether the removal can be postponed until there is a feature parity between those two services? The log-rotation-service-type currently seems quite limited in comparison to the originally used rottlog. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
Re: Questions on Managing Patches and Branches
Greg Hogan writes: > How "ready" do branches need to be in the "request to merge" queue? The relevant bit is: To help coordinate the merging of branches, you must create a new guix-patches issue each time you create a branch (see The Issue Tracker). From [1], the rational was to combine creating the issue with creating the branch to avoid the issue being missed, but I forget the specifics that motivated the change. 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=4955589f2f343e1862dfae7831d1fc548811d59b I think this makes sense if a branch is a set of patches that are somewhat ready at the point they're pushed as a branch, but obviously has downsides if there's lots of time taken to make changes once it's at the head of the queue (or slow builds, which is more like what's been happening recently). > Our documentation [0] includes both of the following statements: > > "Once a branch is at the front of the queue, wait until sufficient > time has passed for the build farms to have processed the changes, and > for the necessary testing to have happened." > > "Sometimes, a branch may be a work in progress, for example for larger > efforts such as updating the GNOME desktop. In these cases, the branch > name should reflect this by having the ‘wip-’ prefix. The QA > infrastructure will avoid building work-in-progress branches, so that > the available resources can be better focused on building the branches > that are ready to be merged. When the branch is no longer a work in > progress, it should be renamed, with the ‘wip-’ prefix removed, and > only then should the merge requests be created, as documented > earlier." > > [0] > https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html > > It seems that we are at the point where the queue has grown so long > (more than "2 months" for the python-team) that teams do not want to > lose their position in the queue. > > Also, mass rebuilds require the build farm, both due to the number of > builds and that builds are not always possible on user hardware (even > for x86-64). > > Is only the branch at the head of the queue being built? If not, why > not allow other branches in a ready state to merge? And if one branch > does block the queue then perhaps we can create a second fast-track > queue for branches not performing world rebuilds. > > What is the distinction between the "qa" service and "ci"? Does c++ > need a specification on ci.guix.gnu.org? On a practical level, QA builds branches using the bordeaux build farm according to the open issues in the queue. CI builds branches as set out in it's specifications. QA used to try and build the top 2 or 3 branches, but I changed this to 1 [2] and limited data.qa.guix.gnu.org to just see the top 2 branches, in an attempt to better focus it's limited resources on the top of the queue. 2: https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/tree/guix-qa-frontpage/manage-builds.scm#n438 In contrast, CI builds all the specifications all the time and is better able to do so as it's processing of revisions is more parallel compared to the data service, and it has a lot more build machines (at least x86 ones). To directly address your question about the c++-team branch and CI, ideally it would have a specification there since that'll allow CI to build things from that branch. I don't believe there's a process to make this happen, but several people have access so I'd suggest to just ask in the issue/on IRC/on mailing lists until someone creates the specification. > Now, the c++-team branch is no longer in a ready state because I > discovered additional work (ctest has no concept of a "test-target" > and many packages were silently skipping tests). I am confident that I > will have this fixed shortly, certainly within the time that the queue > clears, but I see that I am also contributing to the collective > problem. > > Also, the longer team branches sit in the queue, the more time to > accrue updates, the more we start to look like the old days of the > staging and core-updates branches. I think improvements to managing branches fall in to three areas: - Process - Tooling - Scoping/packaging approach On process, there's already discussion happening about the ordering of the merge queue, that's how python-team ended up next since the core-packages-team issue was closed. I'm unsure about adding a "fast-track" queue as you suggest, but I think it might be helpful to have more discussion about the optimal order. Take elogind-updates, it's behind python-team but seems to have a far tighter scope, maybe it should have gone first? On tooling, as I say, QA used to attempt to build the first 2 or 3 branches. With the data service and build coordination being a bit faster now, I think building the first two branches might be feasible. That might compliment my previous point about optimising the order in which branches are merged, since we'll have more information on a number
Warning about a serious issue causing file corruptions (root partition not unmounted on reboot/shutdown)
Hello, I want to inform about issue reported as #77086. I thought this e-mail won't be necessary as it seemed the issue is fixed, but according to recent information from yesterday, it is still a problem. Currently Guix System faces a bug where your root file system might not be unmounted cleanly. The exact cause is unknown and it seems only some systems are affected. You can know if you are affected by seing automatic fsck repair on (every) boot. Of course this applies only if other causes are absent, ie. if you experienced power outage, hard shutdown or your disk is broken. The file corruption is most obvious when rebooting right after reconfigure where people's system in the store can get corrupted, see: https://issues.guix.gnu.org/76959 If you are affected, one way you can do to prevent file corruptions is to close your session manually and then call `sync` in a tty before turning your computer off. Another way is to use the sysrq magic: https://boilingsteam.com/kill-magic/ (Alt-SysRq s, u, b to sync, mount as read-only, reboot), but keep in mind this should be ran only if you have exited your programs manually, otherwise you're possibly risking more than gaining, since the programs won't be able to save to disk anymore. It is not completely clear if the issue happens only on reboots, or even on shutdown. If you've got more information, please share it. Regards, Rutherther More info about the issue&updates: https://issues.guix.gnu.org/77086 TL;DR symptom: fsck ran on boots often to be safe from corruption: shut down session manually, `sync` in tty, `reboot` then
Re: './pre-inst-env guix build xxx' can not find packages in other channels.
Cayetano Santos writes: >>Fri 28 Mar 2025 at 08:54, Feng Shu wrote: > >> my question is: how to let pre-inst-env work well with my channel >> setting, and no need to use -L in every command. > > Are you aware of GUIX_PACKAGE_PATH ? YES, Now I use this variable. > --
Questions on Managing Patches and Branches
How "ready" do branches need to be in the "request to merge" queue? Our documentation [0] includes both of the following statements: "Once a branch is at the front of the queue, wait until sufficient time has passed for the build farms to have processed the changes, and for the necessary testing to have happened." "Sometimes, a branch may be a work in progress, for example for larger efforts such as updating the GNOME desktop. In these cases, the branch name should reflect this by having the ‘wip-’ prefix. The QA infrastructure will avoid building work-in-progress branches, so that the available resources can be better focused on building the branches that are ready to be merged. When the branch is no longer a work in progress, it should be renamed, with the ‘wip-’ prefix removed, and only then should the merge requests be created, as documented earlier." [0] https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html It seems that we are at the point where the queue has grown so long (more than "2 months" for the python-team) that teams do not want to lose their position in the queue. Also, mass rebuilds require the build farm, both due to the number of builds and that builds are not always possible on user hardware (even for x86-64). Is only the branch at the head of the queue being built? If not, why not allow other branches in a ready state to merge? And if one branch does block the queue then perhaps we can create a second fast-track queue for branches not performing world rebuilds. What is the distinction between the "qa" service and "ci"? Does c++ need a specification on ci.guix.gnu.org? Now, the c++-team branch is no longer in a ready state because I discovered additional work (ctest has no concept of a "test-target" and many packages were silently skipping tests). I am confident that I will have this fixed shortly, certainly within the time that the queue clears, but I see that I am also contributing to the collective problem. Also, the longer team branches sit in the queue, the more time to accrue updates, the more we start to look like the old days of the staging and core-updates branches. Greg
