Re: Guix bios installation: Grub error: unknown filesystem
Hi Ludo', On 5/1/24 10:06 PM, Ludovic Courtès wrote: Hi Ada, Ada Stevenson skribis: > Basically, there is a compatibility issue regarding the ext4 > filesystem features that GRUB 2.06 supports and the features that > `e2fsprogs@1.47.0` enables by default when creating your ext4 > filesystem. When these features are enabled, it changes the structure > of the filesystem enough that GRUB can't recognise it properly and it > fails. > > To fix this, you will need to make sure you create your ext4 > filesystem with the following features: > `mkfs.ext4 /dev/you-partition-here -O > has_journal,ext_attr,resize_inode,dir_index,filetype,needs_recovery,extent,flex_bg,sparse_super,large_file,huge_file,uninit_bg,dir_nlink,extra_isize` > > These are the features that worked for me. I had to do a lot of trial > and error, and I used `tune2fs -l` to see what features weren't > supported. The ones I can remember are the metadata_csum features, and > some other ones (they showed up as FEATURE_X when running `tune2fs` on > my Guix installation image, so I used a Gparted Live CD to get rid of > the features that weren't recognised by tune2fs). > > This should allow grub to recognise your filesystem during the > installation process. I think using a later version of grub would fix > this, but that hasn't happened yet. I think there's a patch to upgrade > it in `core-updates` somewhere, but I'm not sure. Just recently I noticed that our installation tests had starting failing with that exact same ‘grub-install’ error that was mentioned: https://ci.guix.gnu.org/build/3708453/details Cuirass says the culprit is in the 4003c60..daab3da, which indeed includes the e2fsprogs update to 1.47.0. Okay, good to know! Have you tried upgrading GRUB? I see ‘guix refresh grub’ finds a new version. If fixing the bug is what it takes, we should do that. I might try doing this. It's a little scary though, updating the bootloader... What do you think would be the best way to test it? Should I create a VM and test through that? Or is there a way I can invoke the 'installation tests' that have been failing locally? Thanks for the investigation! No worries! I'm very glad I've been able to help; I'd love for this to be resolved :) Ludo’. Thanks, Ada
LWN: "A leadership crisis in the Nix community"
Hi, Here is a free link for anyone not subscribed to LWN.net: https://lwn.net/SubscriberLink/970824/1a4673902f5d90c8/ Please ask your employer for a subscription, if you can. Kind regards Felix
Re: Guix bios installation: Grub error: unknown filesystem
Hi Ada, Ada Stevenson skribis: > Basically, there is a compatibility issue regarding the ext4 > filesystem features that GRUB 2.06 supports and the features that > `e2fsprogs@1.47.0` enables by default when creating your ext4 > filesystem. When these features are enabled, it changes the structure > of the filesystem enough that GRUB can't recognise it properly and it > fails. > > To fix this, you will need to make sure you create your ext4 > filesystem with the following features: > `mkfs.ext4 /dev/you-partition-here -O > has_journal,ext_attr,resize_inode,dir_index,filetype,needs_recovery,extent,flex_bg,sparse_super,large_file,huge_file,uninit_bg,dir_nlink,extra_isize` > > These are the features that worked for me. I had to do a lot of trial > and error, and I used `tune2fs -l` to see what features weren't > supported. The ones I can remember are the metadata_csum features, and > some other ones (they showed up as FEATURE_X when running `tune2fs` on > my Guix installation image, so I used a Gparted Live CD to get rid of > the features that weren't recognised by tune2fs). > > This should allow grub to recognise your filesystem during the > installation process. I think using a later version of grub would fix > this, but that hasn't happened yet. I think there's a patch to upgrade > it in `core-updates` somewhere, but I'm not sure. Just recently I noticed that our installation tests had starting failing with that exact same ‘grub-install’ error that was mentioned: https://ci.guix.gnu.org/build/3708453/details Cuirass says the culprit is in the 4003c60..daab3da, which indeed includes the e2fsprogs update to 1.47.0. Have you tried upgrading GRUB? I see ‘guix refresh grub’ finds a new version. If fixing the bug is what it takes, we should do that. Thanks for the investigation! Ludo’.
Re: Welcome to Zheng (z572) as a new committer!
Maxim Cournoyer skribis: > Zheng has joined the committers to help improving cross-compilation, > riscv64, and KDE, among others. Welcome on board, Zheng! Ludo’.
Re: Shepherd timers
Hi! Felix Lechner skribis: > While 'command' works and was in your initial example, I had trouble > tracking down the documentation for it. Is it a record entry destined > for 'shepherd-command'? >From the “Timers” section of the manual in the ‘devel’ branch: --8<---cut here---start->8--- -- Procedure: command LINE [#:user #f] [#:group #f] [#:environment-variables (default-environment-variables)] [#:directory (default-service-directory)] [#:resource-limits '()] Return a new command for LINE, a program name and argument list, to be executed as USER and GROUP, with the given ENVIRONMENT-VARIABLES, in DIRECTORY, and with the given RESOURCE-LIMITS. These arguments are the same as for ‘fork+exec-command’ and related procedures (*note ‘fork+exec-command’: exec-command.). --8<---cut here---end--->8--- > Spoiled by Guix's seamless Guile integration, I don't shell out much > anymore. Will 'command' accept a thunk? No, but ‘make-timer-constructor’ does: --8<---cut here---start->8--- -- Procedure: make-timer-constructor EVENT ACTION [#:wait-for-termination?] Return a procedure for use as the ‘start’ method of a service. The procedure will perform ACTION at every occurrence of ‘event’, a calendar event as returned by ‘calendar-event’. ACTION may be either a command (returned by ‘command’) or a thunk; in the latter case, the thunk must be suspendable or it could block the whole shepherd process. --8<---cut here---end--->8--- Ludo’.
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: Creating a documentation team?
Hello! Thanks Florian, Maxime, and Matt for your feedback. I’ve added the documentation team locally. I’ll push shortly and let you add yourselves. Ludo’.
Re: Concerns/questions around Software Heritage Archive
On 2024-05-01 08:29:29 -0700, Ian Eure wrote: > If Guix is going to continue to facilitate license violations, I will have no > choice but to remove my software from it to defend them. Purely hypothetically, if it would come to this, how would you go about it? Assuming the software is under free license (requirement for inclusion into Guix), I am unsure based on what would the removal be demanded. Do you have some specific approach in mind? Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Concerns/questions around Software Heritage Archive
Hello Guixers, It’s been another week with no response or movement on this. I’m disappointed that this situation seems to be getting treated so lightly. Adhering to the terms of software licenses is fundamental to the operation of the free software ecosystem; there is no software freedom without it. It’s surprising that a pretty clear-cut situation of creating derivative works of free software in violation of their licenses would be shrugged off so easily. Whatever the Guix organization’s position is, I’m reaching my personal limit, and need to see some kind of positive movement on this[1]. If Guix is going to continue to facilitate license violations, I will have no choice but to remove my software from it to defend them. — Ian [1]: Personally, I would be satisfied with a per-package setting which disables scheduling source for archiving by SWH. Seeing this, or a committment to build this within a reasonable timeframe, would allay my concerns. Ian Eure writes: Hello, I’m following up on this since discussion since it’s been a month and I haven’t heard any updates. Summarizing the situation: - SHF has an opaque, difficult, and undocumented process for handling name changes. I’s like to stress again that this is *not* strictly a transgender issue (though it likely affects them more, or in worse/different ways) -- it is a human respect issue. Many, many more cisgender people change their name than transgender people. - SHF gave their archive to HuggingFace, an "AI" company which is generating derived works with no attribution or provenance, in ways which violate the both licenses of the projects used to train their model, and the SHF principles for LLMs. - HuggingFace wasn’t respecting requests to opt-out of their model. On the first point, it sounds like SHF has made concrete progress to improve[1], which is very good to hear. If SHF continues on this course, I think the concern is resolved. On the third point, HuggingFace has begun honoring opt-out requests, but is still very far behind. Also, they don’t remove code from the older versions of their model -- it remains there forever. This is progress, but still, not great. On the second point, I have not seen any public statements indicating that either SHF or HuggingFace even acknowledges the problem. SHF’s most recent newsletter[2], published in April 2024 (after these concerns came to light), continues to tout that StarCoder2 is "the first AI model aligned with our principles," which appears to be false. StarCoder2 includes both licensed and unlicensed code, and HuggingFace’s own StarChat2 playground produces works derivative of this code, with no attribution or licensing information. There is also no statement or position on the SHF news blog. Nor hsa HuggingFace either fixed their tools, or made a statement. This is still very much a live concern. I have a few questions: - Has Guix reached out to SHF to express these concerns / get a response? - Whether a public or private response, what would Guix consider to be an acceptable response? An unacceptable respoinse? - How long is Guix willing to wait for a response? Thanks, — Ian [1]: https://cohost.org/arborelia/post/5273879-they-are-fixing-some [2]: https://www.softwareheritage.org/wp-content/uploads/2024/04/Software-Heritage-2024-Vision-Milestones-Newsletter.pdf Ian Eure writes: Hi Guixy people, I’d never heard of SWH before I started hacking on Guix last fall, and it struck me as rather a good idea. However, I’ve seen some things lately which have soured me on them. They appear to be using the archive to build LLMs: https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/ I was also distressed to see how poorly they treated a developer who wished to update their name: https://cohost.org/arborelia/post/4968198-the-software-heritag https://cohost.org/arborelia/post/5052044-the-software-heritag GPL’d software I’ve created has been packaged for Guix, which I assume means it’s been included in SWH. While I’m dealing with their (IMO: unethical) opt-out process, I likely also need to stop new copies from being uploaded again in the future. Is there a way to indicate, in a Guix package, that it should *never* be included in SWH? Is there a way to tell Guix to never download source from SWH? I want absolutely nothing to do with them. Thanks, — Ian
