Re: 04/04: gnu: Add fwupd.
Hi, On Wed, 31 Aug 2022 09:26:21 -0400 Maxim Cournoyer wrote: > > commit 23152ff70f0ed4966d8207846f54c793d7cb4f86 > > Author: Petr Hodina > > AuthorDate: Tue Jan 4 06:58:51 2022 +0100 > > > > gnu: Add fwupd. > > > > * gnu/packages/firmware.scm (fwupd): New variable. > > > > Signed-off-by: Ludovic Courtès > > Just a quick question: does this tool talks to a remote server that > serves non-free software as well as free one? If so, it'd need to be > patched to comply with the FSDG. It does. By default it at least uses the LVFS repository which has nonfree software. I don't remember if it also has other repositories or if there was a way to easily download updates from the repository without fwupd or LVFS. It is at least possible to search for specific software in LVFS at this address: https://fwupd.org/lvfs/search?value=microcode You also have UEFI updates and so on there, so it's pretty clear that there is some nonfree software. And we actually have the opposite issue here: It is way harder to find firmware updates that are fully free and that they can at least in theory be built with 100% free software on top of FSDG compliant distributions. Maybe small free software firmwares like the colorhug firmware could be OK. Somebody would need to check the dependencies for build the firmware update. Bigger firmwares like with firmwares using Coreboot are probably not OK because while coreboot is under the GPL, to work on recent hardware nonfree software is likely to be used (like microcode updates, Intel FSP, nonfree AGESA, etc). Denis. pgpMhP5FthpPP.pgp Description: OpenPGP digital signature
Re: advanced?
On Sun, 27 Nov 2022 10:35:13 -0800 Vagrant Cascadian wrote: > It also makes me wonder if "advanced" will stand the test of > time. Someday Guix-style systems might just be status quo, and thus no > longer advanced. Guix of course will likely evolve over time... maybe > it will still hold qualities worthy of being called "advanced", [...] Something interesting would be to convey what users need to know or learn for using Guix. In "1.1 Managing Software the Guix Way" we already have hints that it might require to know the command line and scheme. Though maybe it could be clarified for less technical users. For instance it "provides" [a command line interface], but that is not clear that it's the only way to interact with some of Guix features. If we compare Guix with other FSDG compliant distributions: - Trisquel is usable by users that don't know the command line but less technical users might need a bit of help for upgrading from a version to another (in install parties for instance). Sometimes they just need somebody to be there just in case something goes wrong though. - Parabola x86_64 can probably be used by users without command line knowledge (for a desktop/laptop usage) but the boot sometimes break, so less technical users also need to plan ahead and know how to reinstall it if needed (that could be done by having a separate home for instance). A server usage does require to know the command line and also to know how to edit configuration files (like Apache configuration file). - Once installed, LibreCMC (and OpenWRT) are probably also relatively easy to configure for people that know what an IP address is, what is DHCP, what is an SSID, etc. Guix has the potential to be similar. - Freedombox (available in PureOS, Debian, etc) looks way easier but it is also way less configurable. Guix has the potential to have the same kind of balance between easiness and empowerment/configurability than LibreCMC (if graphical interfaces are written). Making the current status more clear can probably help users. On my side I've already taken that into account on the documentation I wrote on FSDG compliant distributions on the Libreplanet wiki, but I'm not sure how to improve the text in that manual section, or how to promote more that information. Denis. pgptBDqM3kKVK.pgp Description: OpenPGP digital signature
Packaging big generated data files?
Hi, Is there any policies or past decisions of the Guix project on packaging big generated data files? I've added packages for software like kiwix-tools and navit that both work offline but that also need data files to be useful. Navit is a (car) navigation software that need maps. The maps can be generated from OpenStreetMap dumps with a tool available in Navit source code (maptool)[1] which is not packaged yet. Binary map files can also be downloaded directly from various sources. Right now the biggest file possible for such maps is about 47 GiB (for the whole planet). As for kiwix-tools, it can serve offline versions of websites like Wikipedia, and there too it needs files to work. The biggest file seems to be the complete version of English Wikipedia with scaled down pictures[2] and it takes about 89 GiB. I didn't look yet how these files were generated but I guess that they somehow can be generated from Wikipedia dumps. Packaging the binary files (without generating them) can be useful as it simplifies a lot the maintenance as one can just update the package version and checksum to update these. It also enables to keep the information (download URL, checksum, license) in one place and it enables easy reuse by Guix services and/or configuration files. If these files were generated in packages, it would also enable to tweak the data, for instance by adding height data in navit maps. As for kiwix compatible files, it would probably enable to decide when to make the snapshots or enable to package additional wikis (like the Libreplanet Wiki) or websites. The issue here is probably the size of the generated files: they are huge, so if they are packaged, they will most likely take significant resources in the Guix infrastructure. So what would be the way to go here? Would Guix accept patches to add packages for these files in Guix proper? If so, does it needs to be done like with the ZFS (kernel module) package where "#:substitutable? #f" is used to avoid redistributing package builds? Or are other ways better for such use cases? Note that so far I've only packaged locally only kiwix compatible files for various wikis by just downloading already prepared files, so I didn't look yet into navit maps or into generating all these files, so I might miss some details about generating them. References: --- [1]https://navit.readthedocs.io/en/latest/maps.html#processing-osm-maps-yourself [2]https://mirror.download.kiwix.org/zim/wikipedia/wikipedia_en_all_maxi_2022-05.zim Denis. pgpJ1igkoF_kj.pgp Description: OpenPGP digital signature
Re: Packaging big generated data files?
On Thu, 08 Dec 2022 14:46:51 +0100 Csepp wrote: > Could ZIM files be downloaded over bittorrent as fixed output > derivations? They can be pretty huge. Also if the system started > seeding them as well, that would be pretty cool. I've no idea how to generate fixed output derivations. As for BiTorrent, ZIM files provided by kiwix can be downloaded over it. As for using that in packages, all I found in Guix (beside packages) was a Transmission service and associated test(s). So I guess that would needs to be added. Denis. pgp_JsSAo8UVG.pgp Description: OpenPGP digital signature
Re: Packaging big generated data files?
On Wed, 07 Dec 2022 15:45:01 +0100 "pelzflorian (Florian Pelz)" wrote: > Denis 'GNUtoo' Carikli writes: > > Is there any policies or past decisions of the Guix project on > > packaging big generated data files? > > commit 183db725a4e7ef6a0ae5170bfa0967bb2eafded7 > Author: Ricardo Wurmus > Date: Tue May 15 12:55:27 2018 +0200 > > gnu: Add r-bsgenome-dmelanogaster-ucsc-dm6. > > * gnu/packages/bioconductor.scm > (r-bsgenome-dmelanogaster-ucsc-dm6): New variable. Thanks. So I assume that we could do something like that for now and later on see if it makes sense to generate the files. Denis. pgplezwAGjiLC.pgp Description: OpenPGP digital signature
Re: Stratification of GNU Guix into Independent Channels
On Sat, 24 Dec 2022 03:49:30 + "jgart" wrote: > Hi Guixers, Hi, > Should GNU Guix be a small core of packages (and services?)? I think it would also make sense to consider first find the features we want, and then look at how to get them, to see if that works better for us. For instance if the goal is to get faster updates, there might be other things that could be done to improve the speed way more than reducing the number of packages in the repository. For instance making sure that there are substitutes might improve the speed a lot more. It might also be possible to optimize Guile more for some tasks. For instance: - Copying files on filesystems that have deduplication could be improved. - Maybe it is possible to substitute more things (like the things it builds when we do guix pull) or at least rebuilding only some of them (the ones that changed between the last git revision and the new one). - It might also be possible to combine information from Guix weather with the current system or packages to see on which revision the packages ca be upgraded without having to recompile anything (unless we use non-substitutable packages) and update to that revision automatically. - etc. For some of these ideas, we would first need to benchmark somehow what is taking time during updates though, to make sure that the optimization really yields some gains. In my case I've already a clear use case (basically a non-substitutable package that consist of a huge data file) where optimizing Guile will yield a lot of performance improvements. If the idea is (also) to avoid using certain packages, it might make more sense to have a system to do that inside the current Guix source code. For instance a user might want to make sure not to ship compiled zfs compiled kernel modules, though right now it's not a big issue as you need to manually select either zfs-auto-snapshot or zfs to get it, no other packages depend on it. So users usually won't accidentally install it. Another idea would be to have some flag to have only free culture licensed packages (like to avoid cc-nd non-functional data). Though I think that if we do something like that, it would complicate things a lot. Since Guix is meant to be reproducible, we would need to find a way to handle that kind of configuration in a reproducible way. So far the configurability has been integrated in ways that are not hidden for users. For instance if you use a package transformation, you are aware of it. Packages specific to CPU Microarchitectures[1][2] also need to be used specifically, and if I understand users often use package transformation for that. An easier way here would probably be to teach tools like guix lint to enable to check certain things, for instance with 'guix lint --extra-check=./my-checks.scm', or just to write a new tool or external tools for that. We can already use the Guix repl in guile scripts. Though here it would still be up to users to run the checks and try to fix things (for instance by using package transformations), but at least it would not complicate things in Guix. As for weather or not switching to a layered approach would improve development, some projects like openembedded/yocto did that. I've no idea why exactly they did it and what turned out to work well or not for their use cases, but to me the result looks really complex[3], especially if we want to do something like that with Guix. For instance we'd need to handle this layered approach in all the infrastructure, tools, and so on. Users would also need to know where to send patches, and if we try to autodetect that in the tools that receive the patches, it might becomes error prone. And we'd also need to make sure that layers stay compatible with each other. If everything is split, that's harder to do. I think that one of the big strength of Guix is precisely the fact that everything is well integrated together. And as far as I understand, here having a single repository makes it much easier to do that. As I understand Guix maintainers do care about giving some time to third party packages or channels to adjust for changes[4], though with a single repository we can more easily do changes and test them than if the changes would be scattered around multiple repositories. A single repository also ensures that everything stay consistent without much effort. References: --- [1]https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/maths.scm?id=fddf1dc3aba3176b6efc9e0be0918245665a6ebf#n2762 [2]https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/ [3]https://layers.openembedded.org/layerindex/branch/master/layers/ [4]"We recommend waiting until the next Guix release is out though, which could be a month from now, so that your channel remains usable by those who pinned an older revision of the guix channel."[5] [5]https://guix.gnu.org/en/blog/2021/the-big-change/ Denis. pgpQ_ImVBFd22.pgp Description: OpenPGP di
Re: FSDG issues of SCUMMVM-based games
t packaged nor redistributed by Guix but it looks way better than the other freedom wise and it can teach us how ScummVM games are made. Its probably not good enough as-is as its source code also also relies on a tarball that contains executable to build the game and I also didn't manage to build it with Guix yet (I've attached a file with my attempt) but maybe it's possible to get it to build and maybe we can build a 100% free software version of it. For the licenses the website has the following: > In 2006, I (Robert Špalek) released the source codes under the GNU > GPL2 license. > [...] > The game has been released under the GNU GPL license version 2, > hence you can download it for free including full source codes. The > new game engine is a part of ScummVM and its source codes are thus > also a part of it. The old game engine was written in Borland Pascal > and Turbo Assembler, and only runs on MS-DOS. It can be downloaded > below. Besides the game player you can also download the source codes > of the game scripts written in our proprietary game programming > language, and source images, sounds, and animations. So I'm unsure about the license of the executable, game data, etc. The interesting thing is that it has some draci-historie specific scripting language and a compiler for it. So we can safely assume that the other games most likely have a way to script things and that the games are complex enough to have scripts. And these scripts may need to be compiled here (I've no idea how scripts look like for the other games). A way forward would be to try to build this draci-historie game if we really want to have ScummVM games and to patch ScummVM to use the checksums from the newly built game. There is also an IDE (QT AGI Studio)[4] and some templates[5] for the AGI game engine supported by ScummVM, but all that require some work because (a) the IDE depends on QT4, and (b) the template license is a bit similar to the games license[6], and (c) if scummVM still has checksums, then users need to build their own version anyway (d) nobody knows if that can work with 100% free software unless people audit or package the software and try to see if it works. References: --- [1]This gnu-linux-libre mailing list is at nongnu.org. Despite its name, this mailing list is meant for discussions about all FSDG compliant distributions(even the ones without GNU or linux-libre like Replicant), about the list of software to exclude from FSDG distributions, about adding new distros in the list, etc. [2]https://www.ucw.cz/draci-historie/index-en.html [3]https://www.ucw.cz/draci-historie/src/doc/compiling-the-game.txt [4]https://agistudio.sourceforge.net/#requirements [5]https://github.com/nbudin/agikit-project-template [6]https://github.com/nbudin/agikit-project-template/blob/main/README-original.txt Denis. ;;; Copyright © 2023 Denis 'GNUtoo' Carikli ;;; ;;; This file is free software; you can redistribute it and/or modify it ;;; under the terms of the GNU General Public License as published by ;;; the Free Software Foundation; either version 3 of the License, or (at ;;; your option) any later version. ;;; ;;; This file is distributed in the hope that it will be useful, but ;;; WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with this file. If not, see <http://www.gnu.org/licenses/>. (use-modules (gnu packages compression) (gnu packages pascal) (gnu packages python) (guix build-system gnu) (guix build-system trivial) (guix download) (guix gexp) (guix packages) ((guix licenses) #:prefix license:)) ;; Serious issues to address: ;; (1) Is the Data GPLv2 ? Is it redistributable? What the dh-en-2012.zip ;; binaries? ;; (2) compiling-the-game.txt[1] has a section "4. Play the recompiled ;; game" that explains that the game built is incompatible with ;; ScummVM unless scummVM is patched with the md5 of the game binary. ;; [1]https://www.ucw.cz/draci-historie/src/doc/compiling-the-game.txt ;; (3) Actually make it work ;; (4) Patch scummVM and test the game ;; TODO: ;; - Also pakcage licenses and license declarations too ;; - identify and remove the binaries that are not used by the build ;; system. ;; - Make sure only data that can be edited with free software ;; tools remains. ;; - Make a cleaned-up tarball and get that mirrored instead of the ;; binaries we don't use. ;; - Convert that into a function that makes a package for a given ;; language. (define-public draci-historie-dubbing-en (package (name "draci-historie-dubbing-en") ;; There are no versions in the release. (version "1+1")
Re: FSDG issues of SCUMMVM-based games
On Thu, 15 Jun 2023 19:34:32 +0200 Liliana Marie Prikler wrote: > I don't think we need to be that harsh on ScummVM itself, it being a > virtual machine. > > Compare it to Wine: the tools to create Windows binaries with free > software only are limited (albeit existing if we discount the > necessity for system headers), but it still serves a purpose by > enabling you to run said programs without resorting to a Windows > machine. About wine, the first time GUix's wine starts it asks you to download and install mono for you (and in my case I didn't manage to skip that), but if that's 100% free (it's most likely the case), everything should be OK because: - We have an FSDG compliant toolchain for Wine in Guix - Wine in Guix should also be 100% free software - The guix build --target=x86_64-w64-mingw32 hello works fine in Guix's Wine - The package description also don't steer users toward nonfree software. So just with that have at least 1 valid use case that don't steer users toward getting and installing nonfree software at all, and that use case is not incompatible with the package description, so for me It's hard to find something wrong with that here, especially when the use case is of strategic importance for free software (shipping software to people used by nonfree OS can help spread free file formats and protocols). > The only limiting factor here is your point (2), i.e. it being able to > run arbitrary games compiled for the VM. I don't think that weird > checksums ought to be enforced if they're not baked into the program > itself. The draci-historie build tutorial said that the checksums were backed in ScummVM and that you needed to add your own checksum inside ScummVM source code and recompile it to run a modified version of the game. Maybe that changed since then, but that is probably not very likely to have happened, and this checksum mechanism also likely applies to all programs or games meant to run inside ScummVM. And if we had at least one 100% free program that run inside ScummVM (something without nonfree dependencies, that we can rebuild or modify) then we'd be able to easily find out about the checksums. If someone knows good tools to work with ARJ archives, we could also try it by modifying existing games very slightly (like by adding something new inside the ARJ archive). > Even if no such toolchain exists for ScummVM, you need ScummVM as a > testbed to write one :) Assuming that some way around the checksums is found, the issue here is that no such toolchain exist yet, so testing it won't work right now. And assuming that draci-historie turn out to be a dead end, getting a free toolchain probably requires significant work in research, or in packaging. In contrast, many other VMs (qemu, java, gjs, etc), they already have valid use cases and/or it's trivial to make a free software hello world. So there is no such burden on the potential user to have to provide development tools that don't exist yet for that VM. And here the rationale doesn't try to weight uses cases (like wine has many nonfree games and very few known 100% free software, so wine should be removed[2]), only to make sure that there is at least a single use case that works with 100% free software. > > I've looked a bit at another game (draci-historie[2]) that has some > > source code published. This game is not packaged nor redistributed > > by Guix but it looks way better than the other freedom wise and it > > can teach us how ScummVM games are made. > > > > Its probably not good enough as-is as its source code also also > > relies on a tarball that contains executable to build the game and I > > also didn't manage to build it with Guix yet (I've attached a file > > with my attempt) but maybe it's possible to get it to build and > > maybe we can build a 100% free software version of it. > You might be able to bootstrap parts of it with fpc, i.e. the Free > Pascal Compiler. I'm not sure whether you'll encounter the necessity > for Borland Pascal, as we package version 3.2.2, which is somewhat > newer than the mentioned 2.4. I'm unsure of why it fails exactly. I've an error message[1] that comes from the Pascal code, but I don't know Pascal and the comments aren't in English. Though I could indeed try a different compiler version and see if it works, or try to build it in some FHS container. References: --- [1]cannot save palettes used in programs /tmp/guix-build-draci-historie-1+2.drv-0/source/build/gfx/outro/outpal1.pcx [2]In my opinion weighting use cases is a can of worms because the importance of use cases is subjective, and if all FSDG distros go this route, it could prevent valid use cases that are or turn out to be strategic for free software. And since the use cases are prevented, people might even not be able to see the problem that was created by going this route. Denis. pgpAh_A6KkrN5.pgp Description: OpenPGP digital signature
Re: FSDG issues of SCUMMVM-based games
On Sun, 18 Jun 2023 10:19:06 +0200
Liliana Marie Prikler wrote:
> I've tracked the checksum to the header in which it was declared, and
> it says
> /* MD5 of (the beginning of) the described file.
> Optional. Set to NULL to ignore. */
> const char *md5;
> (Comment reformatted to fit into a mail)
Thanks a lot. That means that we could easily patch ScummVM to ignore
checksums and at least fix this specific issue. It probably needs to be
done for each game engine we care about though.
> > > Even if no such toolchain exists for ScummVM, you need ScummVM as
> > > a testbed to write one :)
> > Assuming that some way around the checksums is found, the issue here
> > is that no such toolchain exist yet, so testing it won't work right
> > now.
> >
> > And assuming that draci-historie turn out to be a dead end, getting
> > a free toolchain probably requires significant work in research, or
> > in packaging.
> >
> > In contrast, many other VMs (qemu, java, gjs, etc), they already
> > have valid use cases and/or it's trivial to make a free software
> > hello world.
> Didn't you say that a hello world for scummvm exists?
I don't know. There is a template for AGI games but the license is
strange too, and it also requires some software to build it, and I've
no idea if it's compatible with QT AGI, and I've also no idea if QT
AGI works, doesn't have nonfree dependencies, etc.
So that makes things way more complicated because here it probably
requires a lot of work to confirm that it's possible or not possible to
develop programs that run inside ScummVM with free software.
> My argument isn't that we ought to remove wine because it's quite
> often used to run nonfree software. My argument is to apply the same
> principles we use to justify not only wine, but also game engines,
> where only the engine but none of the assets are free (some of which
> are included in Guix).
Ah OK, I slightly misunderstood because I didn't think about the other
games with non-FSDG compliant assets, so I've no idea about these
yet, especially because it would depend a lot on the details.
For instance in some engines, it might be trivial to make them start
/ work a bit with FSDG compliant game data, or at least data that the
user can easily make, and on some other it might not be possible
without a lot of effort. Some engines might require code, other other
only data, etc. I've also don't have their package description in mind.
And in the FSDG there is also an exception for licenses like CC-BY-ND
for non-functional data like game graphics, but I fear that the engines
you're referring to are mainly meant to work with non-re-distributable
data.
> Indeed, we may not have access to the same tools as the game
> developers did back then, but you can still run the games on any
> machine of your choosing for any purpose, and if you don't mind
> experimenting a little, you can also run modified versions.
The same logic also applies to software under free licenses that lacks
corresponding source code: users can experiment with it, modify the
assembly code, and so on.
But the amount of effort required to do that is huge compared to "the
preferred form of modification" of that software (typically source
code, commented assembly, with a build system that works and enable
users to do some small change and rebuild the code, etc).
Some firmwares are in this case, but they are considered nonfree until
their source code is produced somehow (for instance by reconstructing
it, and with some automatic reverse engineering tools, etc).
Another issue here is that it is way easier to reason on software that
exists and facts that are known or very likely to be true rather than
hypothetical software that require unknown or big amount of work. Here
it could turn out to be a huge amount of work just to manage to run free
code inside ScummVM.
That can also be compared to freeing firmwares under free licenses that
lack source code where there is some work and research needed to make
them useful for people wanting to use 100% free software.
In contrast if I take gjs, this program is free software:
> print("This software is released under the CC-0 License");
> print("hello world");
and it can run with 'gjs hello.js'. So weather or not gjs is reused by
other programs as a dependency, as-is it's ultra useful as anybody can
either write free software or software that isn't public (that's a
valid use case too). And making sure of that is trivial.
Denis.
pgptxZctL0xvQ.pgp
Description: OpenPGP digital signature
Re: FSDG issues of SCUMMVM-based games
On Tue, 20 Jun 2023 06:30:26 +0200 Liliana Marie Prikler wrote: > Note, that this discussion started IIRC a year ago and we have > practically known about actually existing FSDG violations since then. > My approach here is quite simple and pragmatic: Remove the games which > obviously violate the FSDG (that is all the games currently depending > on ScummVM as far as I know), but keep ScummVM for now to allow folks > to experiment. If in some one to five years we still find no > practical way of using ScummVM with only free software, that might be > a reason to remove it then. > > WDYT? That looks perfectly fine to me. It leaves some time to people to try to fix ScummVM itself in a better way (like by packaging games built from source like Draci Historiae, removing the checksums, making a hello world, etc), and at the end ScummVM would get removed if it's not fixed. Denis. pgp1puW4qmk7v.pgp Description: OpenPGP digital signature
Re: Adding GNAT/GCC-Ada to Guix
On Sun, 16 Jul 2023 08:47:41 + Fernando Oleo Blanco wrote: > Dear Guix community, Hi, > Why did I tell all of this? > Because I would like to add GCC-Ada to Guix and I am fully aware of > the work that the Guix and the #bootstrappable people are doing > towards a fully transparent compilation history. Opaque binaries are > not allowed for that purpose. Sadly that is not currently possible > with Ada. Therefore, I would like to get permission to add GCC-Ada as > a binary up until there is a bootstrapping path available. I am aware > that some languages/tools have received this treatment before. I don't know well the exact policies with that regard (I'm not a Guix maintainer, just an occasional contributor) but I found the following compilers in Guix source code: - The haskell is not and was never bootstrapped from source. Though the binaries used to bootstrap it changed over time. - There are also other compilers like vala and nim that convert vala and nim source code to C. The issue is that they are written in vala and nim, and Guix uses generated "source code" (generated C that is very hard to read) to build the compilers. People usually don't modify nor audit that kind of generated source unless it is for debugging purposes. > 3. What can Ada provide to Guix? > > Apart from being an official language of the GCC toolsuite, it is > also used in some important and unique places. For example, the > graphics stack of Coreboot/Libreboot among other drivers are written > in Ada [3] (you can find more by running `find . -type f -name > "*.ad*"` on Coreboot's root folder). Nowadays Libreboot includes nonfree software in its releases, so because of that me and Adrien 'Neox' Bourmault started working to continue the original spirit of the old Libreboot that didn't contain any nonfree software. And while we don't have a release yet, in the longer run we're interested in using Guix for building it because Guix is FSDG compliant and it can be installed on top of most GNU/Linux distributions. It would also make the maintenance easier and shared with other users of Guix, enable to easily rebuild older releases, have faster build times, etc. Since it's also possible to inherit packages, in the long run it would probably makes sense for us to move most of our work in Guix. So having some ways to build software written in Ada with Guix would make a big difference here as without that we would probably only be able to use Guix only for some parts (like for building GRUB, SeaBIOS etc for Coreboot). Without that, Guix users would also need to use another distribution with Guix inside to be able to build it. > It is also the base programming > language of SPARK [4], a verifiable, GPLv3 licensed, programming > language, used for the ARIANE rockets and the Rosetta space probe for > example. And of course, there are plenty of libraries, tools and > programs written in Ada! Without a compiler, none of this can be > packaged in Guix... At the last FOSDEM, I was also shown at the ADA table that it was also possible to build software for micro-controllers with it. Though I've no idea if there are interesting free software firmwares written in Ada worth packaging in Guix. Anyway, Thanks a lot for all your work on this. Denis. pgpr70fbsNZug.pgp Description: OpenPGP digital signature
Re: Postgres user UID and GID
On Mon, 17 Jul 2023 18:06:04 + Martin Baulig wrote: > Hello, Hi, > I have a bit of an unusual setup, as I am running GNU Guix in a VM on > a Synology NAS. Unfortunately, their DSM software sucks quite badly, > but I am currently stuck with this hardware as I don't have the > budget to replace it. But I don't want to make any long-term > commitment to their software either. One of the awesome features of > GNU Guix is that it can nicely and easily be deployed elsewhere. > However, for this to work, I need to be able to extract my data > easily, so storing anything inside that VM that's not on GitLab isn't > an option. I have decided to NFS-mount an encrypted shared folder > from the NAS and store all data there. I've also a setup where I share a postgresql data folder between various distributions. In my case it's shared between Parabola i686, Parabola x86_64, Guix i686 and Guix x86_64. And I often need to chroot inside Parabola so this is why I need to use the same IDs (than Parabola). So for keeping the same id across different distributions, I hardcoded it in the users and groups like that in my system.scm: > (users (cons* [...] > (user-account > (name "postgres") > (uid 88) > (group "postgres") > (comment "PostgreSQL user") > (home-directory > "/path/to/shared-dir/var/lib/postgres") (shell (file-append bash > "/bin/bash")) (system? #t)) %base-user-accounts)) And in the groups too: > (groups (cons* [...] > (user-group >(name "postgres") >(id 88) >(system? #t)) > [...] > %base-groups)) And for the record here's how I use a different architecture: I define a package: > (define postgresql-14-i686-linux > (package >(inherit postgresql-14) >(name "postgresql-14-i686-linux") >(arguments > (ensure-keyword-arguments > (package-arguments postgresql-14) > '(#:system "i686-linux") And then use it in the PostgreSQL service: >(service > postgresql-service-type > (postgresql-configuration > (postgresql >(if (target-x86-64?) >postgresql-14-i686-linux >postgresql-14)) > [...])) The downside is that it prints a warning during boot if I recall well but it works fine. I'm unsure if that helps the conversation or not though as you might want something cleaner. Denis. pgpi_a0mwAat8.pgp Description: OpenPGP digital signature
Re: Postgres user UID and GID
On Mon, 17 Jul 2023 21:35:00 + Martin Baulig wrote: > If I use the unmodified service and with the (operating-system (user > ...)) entry, it works sometimes, but not reliably due to having two > conflicting entries for the 'postgres' user. I see. So if I touch too much my system it could break at any time then. Denis. pgpLBy40xkwmS.pgp Description: OpenPGP digital signature
How to build Guix to send a patch when Guix build fails?
Hi,
I'd like to send a patch to add a bootloader (u-boot) package for a
single board computer. The patch is trivial and it's already
ready.
However before sending the patch, I'm supposed to build it within Guix
source code and to test it.
I've been trying many variations of 'guix environment --pure guix
--ad-hoc ' during many many hours, but I still didn't
manage to build Guix. I always have the failure that is in the
build.log that I attached.
I've the patch I attached on top of the following commit:
> 51eb3e113c gnu: linux-libre 4.19: Update to 4.19.148.
And I did the following commands last night when trying to build Guix:
> $ guix pull
> $ guix package -u
I did it with the following hardware and distributions configurations:
- Architecture: i686
- Host distribution: Parabola i686 with a x86_64 kernel (5.7.2-gnu-1-64)
- Guix architecture: i686
Is there a command that is known to work to build Guix in a way that
doesn't use any of the host packages?
I also tried on another machine with the following configuration:
- Architecture: x86-64
- Host distribution: Parabola x86_64 without guile-json installed
- Guix architecture: x86_64
- Guix environment command: 'guix environment --pure guix --ad-hoc
guile-json
And it wouldn't pick Guix's guile-json, so I assume that for some
reason it tried to use the host's packages somehow.
As I was told on IRC, building Guix from Guix latest revision is
supposed to work. However if during the build it really uses
packages from my host distribution (Parabola), then there might be some
combination of packages that makes it fail, so here I hope that with
the right guix environment command it would build.
Denis.
$ guix environment guix --pure
pe0 not found
bash: keychain: command not found
bash: tput: command not found
bash: tput: command not found
$ bash --norc # The command not found above are due to my bashrc
bash-5.0$ ./bootstrap
++ find po/doc -type f -name 'guix-manual*.po'
++ sed -e 's,guix-manual\.,,'
++ xargs -n 1 '-I{}' basename '{}' .po
+ langs='de
zh_CN
es
ru
fr'
+ for lang in ${langs}
+ '[' '!' -e doc/guix.de.texi ']'
+ echo '@setfilename guix.de.info'
+ echo '@include version-de.texi'
+ touch po/doc/guix-manual.de.po
+ for lang in ${langs}
+ '[' '!' -e doc/guix.zh_CN.texi ']'
+ echo '@setfilename guix.zh_CN.info'
+ echo '@include version-zh_CN.texi'
+ touch po/doc/guix-manual.zh_CN.po
+ for lang in ${langs}
+ '[' '!' -e doc/guix.es.texi ']'
+ echo '@setfilename guix.es.info'
+ echo '@include version-es.texi'
+ touch po/doc/guix-manual.es.po
+ for lang in ${langs}
+ '[' '!' -e doc/guix.ru.texi ']'
+ echo '@setfilename guix.ru.info'
+ echo '@include version-ru.texi'
+ touch po/doc/guix-manual.ru.po
+ for lang in ${langs}
+ '[' '!' -e doc/guix.fr.texi ']'
+ echo '@setfilename guix.fr.info'
+ echo '@include version-fr.texi'
+ touch po/doc/guix-manual.fr.po
++ find po/doc -type f -name 'guix-cookbook*.po'
++ xargs -n 1 '-I{}' basename '{}' .po
++ sed -e 's,guix-cookbook\.,,'
+ langs=de
+ for lang in ${langs}
+ '[' '!' -e doc/guix-cookbook.de.texi ']'
+ echo '@setfilename guix-cookbook.de.info'
+ touch po/doc/guix-cookbook.de.po
+ exec autoreconf -vfiautoreconf: Entering directory `.'
autoreconf: running: autopoint --force
Copying file ABOUT-NLS
Copying file build-aux/config.rpath
Copying file m4/codeset.m4
Copying file m4/fcntl-o.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/glibc21.m4
Copying file m4/iconv.m4
Copying file m4/intdiv0.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intlmacosx.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lcmessage.m4
Copying file m4/lib-ld.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/progtest.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/threadlib.m4
Copying file m4/uintmax_t.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/guix/Makefile.in.in
Copying file po/packages/Makefile.in.in
Copying file po/guix/Makevars.templateCopying file po/packages/Makevars.template
Copying file po/guix/Rules-quot
Copying file po/packages/Rules-quot
Copying file po/guix/boldquot.sed
Copying file po/packages/boldquot.sed
Copying file po/guix/en@boldquot.header
Copying file po/packages/en@boldquot.header
Copying file po/guix/en@quot.header
Copying file po/packages/en@quot.header
Copying file po/guix/insert-header.sin
Copying file po/packages/insert-header.sin
Copying file po/guix/quot.sed
Copying file po/packages/quot.sed
Copying file po/guix/remove-potcdate.sin
Copying file po/packages/remove-potcdate.sin
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /gnu/store/cr6pfkq6qm0jn5nrbm3
Re: How to build Guix to send a patch when Guix build fails?
On Thu, 01 Oct 2020 15:54:06 +0200 zimoun wrote: > > I also tried on another machine with the following configuration: > > - Architecture: x86-64 > > - Host distribution: Parabola x86_64 without guile-json installed > > - Guix architecture: x86_64 > > - Guix environment command: 'guix environment --pure guix --ad-hoc > > guile-json > > On this machine, the following commands should work: > > git pull > guix pull > guix environment -C guix > ./bootstrap > ./configure --localstatedir=/var/ > make Apparently that didn't work on my pure x86_64 machine. It still kept not finding guile-json. > If you do not want to update your profile, you can run: > > guix time-machine --commit=51eb3e113c478f0683e92412785ee82e56c45621 > \ -- environment -C guix > ./bootstrap && ./configure --localstatedir=/var/ && make However that worked fine on that same machine. > Hope that helps, It did. Thanks a lot. I'll test the patch, and then I'll try to find the time to bisect it. Denis.
Re: A plan for parameterized packages
On Sun, 15 Nov 2020 22:24:29 +0100 raingloom wrote: > Alpine already achieves an incredibly tiny install size by splitting > packages into many outputs. We could and should do the same. > As far as I know, they do not have parameterized packages. That also depends on how far you want to go. Last time I looked into how LibreCMC/OpenWRT did that, they had much more optimization than that. If I recall well, they use at least: - sstrip to strip binaries as much as they could. sstrip produces smaller binaries than with strip. - compilation flags like -Os - a read-only compressed filesystem with an overlay to store the changes The issue is that despite all that, the size of the images tend to increase too rapidly over time[1]. If we manage to shrink Guix enough, it might be possible to use it on way more devices, including RYF compliant devices or potentially certifiable devices: - The Talos II BMC has 32M according to both the wiki[2] and the image sizes[4]. Its architecture is ARM. So once we have the PPC64 architecture working, it would be great to be able to run Guix both in the BMC and on the PowerPC CPU. That BMC is also available on other mainboards like the D16 which is supported by Libreboot, but the flash size is probably even smaller there. - Many WiFi access point have very few flash space. It can boils down to as low as 16M for LibreCMC/OpenWRT compatible devices, or even 8M for older devices. However they typically use the MIPS architecture which isn't supported yet in Guix. - There is a GNU/Linux distribution[6] that runs inside the flash chip where Libreboot or Coreboot typically runs. The goal is to enable more flexible and/or secure booting by using GNU/Linux to boot GNU/Linux. Here too the flash chip of computers supported by Libreboot can be quite small, like 8M for Thinkpads with GM45 chipsets. In some case it might be possible to increase the flash chip size (sometimes you don't need soldering for that), but at least with x86 mainboards, the chipset has limits on the size of the flash chip that it can see. And the size cannot be increased that much: The biggest flash chip that flashrom supports is 256M. References: --- [1]https://openwrt.org/supported_devices/864_warning [2]The wiki[3] mention a MX25L25635F/MX25L25645E/MX25L25665E flash chip which is 32M according to flashrom -L [3]https://wiki.raptorcs.com/wiki/Debricking_the_BMC#Flash_new_BMC_firmware_via_serial_port_.28Open_Source_Method.29 [4]Once uncompressed the image[5] size (for installation through the shell) is 32M. [5]https://wiki.raptorcs.com/wiki/File:Talos-ii-openbmc-v2.00-bundle.tar [6]https://github.com/osresearch/heads/ [7]https://github.com/osresearch/heads/tree/master/config Denis. pgpoPCdagb2In.pgp Description: OpenPGP digital signature
Re: Question about Guix on Novena - mainly U-Boot
On Fri, 4 Dec 2020 19:49:37 +0100 Danny Milosavljevic wrote:> > Now I want to make it boot it from SATA instead. The question is what "boot from SATA" means here, it could mean different things: - Have u-boot on the microSD card and load the rootfs from the SATA HDD/SSD. - Make the bootrom load u-boot from the SATA HDD/SSD. Luckily the I.MX6 SOC is capable of loading u-boot from a SATA HDD/SSD but it needs to be configured for that. However it looks like the novena-eeprom utility only somehow does the former: https://github.com/xobs/novena-eeprom/blob/master/novena-eeprom.h In addition I'm unsure if upstream u-boot can parse the sataroot flag as I didn't find it but I only looked very rapidely and not on the latest source code. To configure the I.MX6 SOC to boot from a SATA HDD/SSD you'll have to dig in the I.MX6Q reference manual and the schematics of the novena to see how it is configured. - You have fuses that select a boot mode - One of the boot mode selected by the fuses configuration enables GPIO overrides (this is what we want here). So with the reference manual and the schematics depending on the fuses configurations, you could be able to understand the boot order of the SOC (which peripherals it tries to load u-boot from and in which order). And if it's set in GPIO override mode and that the GPIOs are routed to some switch or jumpers, you can probably manage to change the way it boots and make sure it tries to load u-boot from the SATA HDD/SSD. The u-boot source code also may have documentation about that. Some boards (like the TBS2910) have some documentation on how they are configured to boot. Since I didn't find the novena in doc/boards, you might still have some luck if there is some more generic documentation about booting devices with I.MX6Q. If the Novena can't boot from SATA as-is, you could try to see if there isn't a way through the configuration headers to configure the bootrom to try to boot on SATA somehow. That configuration header (DCD) will probably need to be on a peripheral that the bootrom tries to boot on. Booting of I2C eeproms is possible on I.MX6 but again you'll have to check the documentation to see if it satisfies all requirements (including if the eeprom is wired to the proper I2C controller and/or pads to be able to be read from the bootrom). If not in the worst case you will probably need some minimal code on a peripheral the bootrom tries to load code from. There is probably some resources for the Novena (Forums, IRC channels etc) that already have all theses answers but in any case understanding a bit of the context here could help parse the answers. Denis. pgp6cEQsdtOka.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a new metric for it's measurement.
On Fri, 3 Feb 2017 15:37:32 +0100 David Craven wrote: > This leads to two models of loading the firmware that runs on the MCU. > > 1. The peripheral does not contain persistent storage and the firmware > is loaded by the linux kernel through a standard API. When using the Linux kernel, the firmwares are sometimes loaded by something else than the linux kernel: - In most Replicant devices, the modem firmware is in a separate eMMC partition in the device(Smartphone/Tablet), and it is loaded by libsamsung-ipc. - Some bootloaders such as u-boot have the ability to load some firmwares or FPGA bitstreams. > 2. The peripheral contains persistent storage containing the firmware > and uses a separate interface for flashing the firmware. This doesn't differenciate between a chip with internal non-voltaile memory, and a chip with external (potentially shared) flash chip. This can have some serious freedom privacy and security implications when the peripheral's firmware is on the same flash chip than the OS (GNU/Linux or Android/Replicant). In that case the processor running that non-free firmware can also access the OS partition. I think it is the case on some older qualcomm devices like the HTC Dream, where the modem firmware is on the same flash chip than the Android Operating system... On samsung smartphones and tablets supported by recent Replicant versions, libsamsung-ipc, which is a library that talks to the modem, loads the modem firmware. Thanks to that hardware architecture, the modem doesn't have access to the eMMC that holds the Android distribution (here Replicant). > Problem: > Today as an example, a WiFi card using option 2 is considered more > free than one using option 1. I understand the point, but let's approach the issue from another point of view to better understand its contradictions and the tradeoffs that have been made. Let's take it from a top-down perspective where the top is application software that runs on top of lower level software. Down goes deep down in the hardware, like down to how a resistor is made. If applications have to be free software (It's morally wrong not to respect the users freedom), the software that makes the hardware works also needs to be free software: - For the same reasons than applications have to be free software. - Since that software is more privileged it's very useful and important for it to be free software. - As you stated it also impacts the ability to use hardware beyond their end of life, which reduces waiste. Given the above one might wonder how deep we should go down and what is the fronteer between hardware and software. Given that even hardware and chip design has freedom privacy and security inplications it is desirable to have freedom there too. However given that we are not there I think that we need to have some criterias that are reachable. One can for instance use a computer that respects the FSF RYF criterias as of today. I am for instance using one to write this mail. My computer is not ideal though since: - Its hard disk has a non-free firmware - Its embedded controller has a non-free firmware Beside the fact that I added the tor-browser, all rest is RYF and FSDG compliant. The question for me is then how to use the acceptable/not-acceptable line to get more freedom out of it: - If redistributing (and using) non-free firmwares was: - still acceptable - not an issue in the FSDG guidelines - done in the FSDG compliant distributions Then we would probably: - Not have had the ath9k_htc firmware liberated (thanks to Thinkpenguin,Atheros and the people who made it possible) - May have more people using FSDG compliant distributions. Having the ath9k_htc firmware liberated was really really important, especially because: - The Intel WiFi cards present in many laptops require non-free firmware to work, at least with recent kernels. - Many laptop boot-firwmare(BIOS, UEFI) will refuse to boot if the user either changed the wifi card like with the default BIOS of the Lenovo Thinkpad X60 and X200, or removed it like with at least one of the HP Envy laptops. - The ath9k_htc compatible cards can still be bought and found and have been for a long time. - The ath9k_htc compatible cards supports modern-enough WiFi standards. With that we can still use WiFi by ignoring the intel wifi card and using an USB wifi card instead. There are also free software firmware to support some other peripherals such as: - Old b43 compatible wifi cards (OpenFWWF). - keyspan compatible devices. - Older atheros based USB wifi cards. - Probably few other devices. While this is really great and that each new free firmware is a great achievement and is really important, they are also crucial because we failed: - ATI GPUs are almost unusable with free software, in the best case we can load the radeon driver but do not have 3D accelerations and many of the features of that driver working because of the lack of a free firmw
Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a new metric for it's measurement.
On Tue, 14 Feb 2017 19:43:48 +0100 David Craven wrote: > Hi Denis, Hi, > > > With that we can still use WiFi by ignoring the intel wifi card and > > using an USB wifi card instead. > > [Thunderbolt] poses a much larger security issue, > that I would not actually gain anything from replacing my wifi card. > And besides these obvious and visible firmwares I have no clue what > other non-free firmware is running on my laptop. While security is important, it's far from being the only reason that makes free software important. When security and freedom conflicts, I usually prefer freedom. That said, if you care about free software only for the security and privacy benefits: - With Respect Your Freedom(RYF) certified computer, firmware freedom matters a lot. - Not considering non-free firmware as an issue and having most FSDG distribution users run them would make freeing firmwares appear way less important. Most GNU/Linux users aren't even aware of hardware related freedom issues, because it just works. According to many of them the ATI GPU can be used with fully free software, and some even think that everything in their distribution is free software. This doesn't help promoting the importance of having free firmwares, and way less developers would want to work on their replacement. More broadly, users that need the hardware to work would not care anymore about free firmwares anymore either. To successfully convince Atheros to liberate the firmware of the ath9k_htc compatible chips, thinkpenguin probalby needed a valid buisness case, which probably was selling USB WiFi dongles to users that desperately wanted WiFi to work with free software. > While obviously you understand hardware and the hardware you are > using, most people do not. And I think we need to make sure that > people that don't - I consider myself being one of those people - can > do the *best* with what we have and have the information available to > us to make informed decisions. I think that not using non-free firmwares is the best decision for all users collectively. If more users and developers were taking that decisions, we would not have the issue we have here: - You have hardware that doesn't work because it requires non-free firmwares. - Many non-free firmwares aren't being replaced because there is not enough interest in replacing them, because many GNU/Linux distributions still ship non-free firmwares and it works for their developers and/or users. The more interest in free software replacement, the more probability there is to have them replaced with free software. > I bought my dell xps developer edition before I had any involvement > with a GNU project, and I bought it because dell was actually > providing at least some kind of linux support. I currently can't > afford to buy a new laptop even if the one you are using is much more > free. You may be able to find cheap or gratis laptops supported by the libreboot project but it will require you to spend time for that, with no guarantee of success. As for how cheap it can get, I bought a Lenovo Thinkpad X60 for about 50E. The downside is that, at that time, I was lucky to find it that cheap, and that its CPU is single core. Since I bought it to use it for coreboot/libreboot development/testing only, I didn't need a fast CPU. > Besides I have the dream of building a replacement mainboard > with a RISCV SoC for it. But that is still beyond my capabilities :) > FYI: This dream mainboard would also feature a software defined radio > [0] instead of a wifi card - another interesting free hardware > project, although the sources have not been released yet. RISCV is probably not yet ready to be used as a laptop SOC. However there are some microcontrollers projects with that architecture: - https://www.crowdsupply.com/onchip/open-v - https://www.crowdsupply.com/sifive/hifive1 As a side note, if you think that microcontrollers are not very useful, think again because, since you have some interest in security and probably privacy as well: - Microcontrollers can have critical security functions, as it is the case in this computer: https://www.crowdsupply.com/design-shift/orwl They can also be used for password external management. - We probably have the Hardware description language source for it under a free software license. > Another thing I found very frustrating was a conversation that I had > on IRC. It went like this: > > Can guixsd run on a RPiv2? > > Yes, sure. You'll need to use vanilla linux and add some firmware, > I'll show you how to do it. > > No thank you. I don't want to use binary blobs. I'll just use another > distro until guixsd works without binary blobs. > > I expect that everyone recognizes the irony in that. I don't. I don't see any issue with the above assuming that non-free firmwares are the only difference between the "other distro" and the free software distribution. Missleading users into thinking that th
Making technology more inclusive Was: Leaving the GNU Guix community
On Fri, 30 Apr 2021 01:43:37 +0200 Leo Le Bouter wrote: > I think that the technicality of software development must be > redefined so that the hierarchy between the experienced and the > beginner disappears [...] I've been thinking a lot about these topics, and there are radical solutions that can work today, but the scope is quite limited. Sadly, technology in general is way too complex to enable any individual to be able to practically exercise the freedom to modify how it works at every level: For instance, computer hardware is way too complex, not everyone is able to modify how the RAM initialization is done in Libreboot. And that's just for the software side that is visible to users. There is also a big interest in modifying how the hardware works, for instance by making custom CPUs on FPGAs, which again requires domain specific knowledge. Despite that, several indigenous communities run their own GSM networks[1] and while doing that at least some of them seem to have managed to do what you are talking about (remove power relationships between the people with specific knowledge and the people without that specific knowledge): - The people running the network have to obey what the village assembly decided. So everybody decide together with the people running the networks. - They also managed to have the protocol modified for them at a deeper level[2] to make their GSM network behave more like peer to peer networks between villages instead of the way GSM networks are typically deployed. Note that in this example above many of the communities that run their own GSM networks didn't chose (yet?) to have Internet access for instance so the scope is quite limited. Things get more complicated when trying to bring this amount of control down to every single individual for every aspect of every digital technologies. And many people have personal computers this also looks important to reflect on. The approach taken by lisp machines was interesting: it enabled users to practically modify all the source code (most or all of it wasn't free software if I understood right). They used CPUs made specifically to run lisp code to do that but as I understand the downside was that, even if most of the code was in lisp, there was probably still some code in assembly or other languages as the lisp interpreter was probably not written in lisp. Another approach that I find interesting is the one taken by operating systems like OpenBSD (which is not FSDG compliant) where the design is much more simple. The downside is that it lacks many functionalities that some users might miss. Hyperbola (which is FSDG compliant) is working on a new operating system which will reuse the OpenBSD kernel, so it might be interesting. Here the bar is probably higher as it requires to be able to write C to modify the kernel, but at least some part of it looks a lot more simple than Linux. For instance if we compare OpenBSD's pledge system call and Linux's secomp, pledge is only one driver in the kernel whereas secomp also requires a compiler and so on. And more importantly, software is being written to take advantage of secomp, so I guess that at least in some cases some people depend on secomp because of that. One approach which seems to also have been taken by Guix is to work to make it more simple to modify how things works. Since lisp is parsable it might even be possible to write graphical user interfaces (in lisp for instance) to enable users to modify how the system is configured, how it works, etc. But the downside is that it still depends on complex code in the software it packages (like linux-libre, gcc, etc). With learning, there are also interesting approaches used for learning concepts used in digital technology (like the concepts used by git, etc)[3] which could potentially enable more people to be able to modify the way technology works, but it also requires time. And for hardware, we start to have ISAs like RISCV or PPC64LE that can at least be implemented with designs under free licenses. So it could potentially open the door for more simple hardware, but that hardware also needs to be fast and not too expensive or complex to produce, so it could also not work out because of that. So I'm really wondering where we could go with all that, could it all become step by step, incrementally more accessible when combining several of these things together (like better teaching + more simple software and hardware)? Or do we really need to re-do it from scratch to make technology accessible? Or change the way we live and interact with technology to make it fit people instead of having people be required to fit technology? Unfortunately I don't really have a deep enough vision on this topic to know which step to take in advance so I've mostly resorted to the incremental improvements, hoping to advance things in the right direction up to the point where it could work well enough or show us its limit and push us to fin
Re: Effectively force all GNOME users to locally compile ZFS?
On Sat, 3 Jul 2021 21:46:29 +0100 Domagoj Stolfa wrote: > Hi: > > On Sat, Jul 03, 2021 at 10:16:54PM +0200, Tobias Geerinckx-Rice wrote: > > Maxime, > > > > Maxime Devos 写道： > > > > > > > That's a very good idea if possible. > > Why can substitutes not be offered for ZFS as a standalone module? > I'm not a lawyer nor do I understand much lawyerese, but AIUI, the > problem stems from the FSF lawyers thinking it wouldn't stand up in > court to distribute CDDL software linked against GPL'd software as > one big binary. Could someone please explain why it would not be > acceptable to distribute substitutes of ZFS as a *standalone kernel > module*, rather than as a part of linux-libre? - The ZFS kernel module is a derived work of Linux. - Linux is under the GPLv2 and compatible licenses. - The ZFS kernel module has code that is only available under the CDDL license. - The CDDL license is incompatible with the GPLv2. So while I can change the license of Linux for any license I want and/or make derived work under incompatible licenses for fun on my laptop, I can't redistribute that work. Even in source code form[1]. The same applies to the ZFS kernel module source code and binaries. And so because of that images with gnome can't be redistributed without violating the GPL. And the corresponding source of the ZFS package is also violating the GPL. So the question is how to deal with it in Guix. We need to remove that kernel module from Guix, but the question is how. In Parabola there is a mechanism to produce patched source releases of software. Is there something in Guix that could produce a modified source code tarball (without the kernel module code) that users could download with guix build --source? Or do we need to patch the source? I think we really need to fix that, at least in FSDG distributions because if for some reason we start depending functionalities that violates the GPL GPL, we would then have some strong interest in having the GPLv2 be void and unenforcable. Alternatively we could start working on and/or funding a ZFS driver for Linux that is compatible with the GPLv2+, but I really wonder if it's a good use of resources given that we now have an equivalent filesystem (BTRFS), and that doing that is probably a lot of work which might even never get done in the first place. In addition, that ZFS kernel module doesn't build for i686 because apparently there is no Makefile for that architecture. So depending on it probably makes gnome only usable for architectures supported by that kernel module. Denis. pgpTYndpe_Sg4.pgp Description: OpenPGP digital signature
Re: Effectively force all GNOME users to locally compile ZFS?
On Sat, 20 Nov 2021 03:34:26 +0100 Tobias Geerinckx-Rice wrote: > Hi Denis, Hi, > but did you mean to include a reference to someone who disagrees? I forgot to look for references on that. > Denis 'GNUtoo' Carikli [wrote]: > > Even in source code form[1]. > That's not the general consensus at all On what part precisely is there no consensus? In my statement here, the and/or conflates several issues together: > So while I can change the license of Linux for any license I want >and/or make derived work under incompatible licenses for fun on my >laptop, I can't redistribute that work. Even in source code form[1]. Here I assume that the fact that the GPL and the CDDL are incompatible as the FSF already made a statement about that[1]. I didn't check that in details but I assume that there is some consensus on that. Also, if I take Linux source and I change the license to CDDL, for instance by changing all licenses headers to add the CDDL instead of the GPL and redistribute it as-is, I hope that at least on that there is some consensus[2] on the fact that this is not legal. If instead I take Linux source code and add files under the CDDL (like the ZFS driver in it) and says that this version of Linux is under both the combination of the CDDL and the GPL, this is not legal either because both licenses are incompatible[2]. I hope there is some consensus here too. If I take individual drivers from Linux which are under the GPLv2 or the GPLv2 or later, and I combine them in a new combined work on a new git repository with code under the CDDL license, this is not legal either. And here too I hope that there is some consensus on that too. So the question here is probably (if I understood correctly): if I write a driver for Linux under an incompatible license (like a nonfree license or the CDDL), and that it's clear that this driver is deeply linked to Linux (it's not an userspace program like ls or cp that simply uses Linux syscalls), and that I distribute the driver source code in a separate way (like in a different tarball or in separate git?), is it still a derived work of Linux? Does the Linux license still applies?. Here I don't see how the mode of distribution is changing things at all: I don't see why distributing code in a different tarball or git repository makes any difference. Code from Linux is still being used even if it's not redistributed within the tarball or git repository. How both project (Linux and the ZFS driver) are interfaced together is what define the derived work boundary, not the way it's distributed, and if we add the projects licenses to the equation, we can therefor know if it's legal or not. As for the boundary, Linux makes it clear (in the form of a license exception[3]) that userspace programs using syscalls are not derived work from Linux, so here we have a practical example[8] that show the impact, not of the way it's distributed, but the impact of the interface between programs / code. And in general projects statements[4][5] can be important to know what is considered a derived work or not. And here, to work, that ZFS module has to be compiled with the Linux kernel and it has to be linked to it at runtime. And it can only work with code that is part of Linux, so I really don't see how it cannot be considered as a derivative work. If instead I want to write a driver for a nonfree operating system like (for instance Microsoft Windows or any other nonfree operating system) under the GPLv2, I can still do it if I'm the author of that driver: to do that I would license my code under the GPLv2 with an exception that enables anyone to link it to that nonfree operating system or kernel. For a more concrete example, I can release code under the GPLv2 that use a library under the Apache2 license if I wrote the GPLv2 code by adding an exception for that. For instance I did that in a program that I wrote to enable people to also use it under the GPLv2[6]. The key point here is that I can only do that because I'm the copyright owner (I wrote that code, and I'm not employed by anyone). So I can add the license I want on that code, and that license isn't the GPLv2 (or later), instead it's the GPLv2 (or later) with an exception (to enable to link against code under the Apache license). If I don't own the copyright on code, I cannot change the license of that code. So I can't simply take Linux and add exceptions to it. Or I can't take ZFS code under the CDDL and add exceptions to it. And as I understand it, we cannot even change the licenses and copyright of code released under non copyleft free software licenses like the MIT/Expat license or the various BSD licenses. I don't recall the details but I think that this happened during the integration of the ath5k driver in Linux at some point (it came from OpenBSD): At the end the orig
Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)
On Sun, 21 Nov 2021 11:54:15 +0100
"pelzflorian (Florian Pelz)" wrote:
> Hello Denis. Thank you for your write-up.
Hi,
> raid5atemyhomework wrote patches to add ZFS to Guix
> <https://issues.guix.gnu.org/45692>. I put them in CC. That there is
> no decision on ZFS and their patches is bad. Maybe their patches
> would be for the RFC model to decide?
>
> As for Denis’ arguments
> <https://lists.gnu.org/archive/html/guix-devel/2021-11/msg00101.html>:
>
> IANAL but I would dispute this:
>
> On Sun, Nov 21, 2021 at 02:33:24AM +0100, Denis 'GNUtoo' Carikli
> wrote:
> > If I take individual drivers from Linux which are under the GPLv2 or
> > the GPLv2 or later, and I combine them in a new combined work on a
> > new git repository with code under the CDDL license, this is not
> > legal either. And here too I hope that there is some consensus on
> > that too.
>
> If we are talking about source code, the GPLv2 files and the CDDL
> files are not intertwined into a combined work at all. They are just
> in the same git repo on the same file-system.
Just adding GPLv2 and CDDL files in the same repository should not be a
problem as far as I know.
For instance you can have a kernel module under the GPLv2, and a
userspace tool under the CDDL license that doesn't use code from the
GPLv2 driver, and in that case both don't constitute a combined work.
If the userspace tool uses syscalls from the kernel, the kernel headers
license has an exception for that so it shound't be an issue either.
However I've reviewed a bit the ZFS kernel driver and some files are
under the CDDL license, and that driver also uses functions from the
Linux kernel, and it needs to be directly linked to Linux to uses these
functions.
I didn't take into account the fact that the ZFS driver also has
GPLv2(+?) code or the structure of the repository because having
files under the CDDL licenses that are compiled in the ZFS driver and
having that driver use Linux function (through linking) is sufficient
to make sure that this is a combined work of Linux and that driver.
And since Linux's GPLv2[1] and the CDDL[2] are incompatible, even in
source code form the ZFS driver is not legal as it violates Linux's
GPLv2 license.
Adding extra layer(s) of indirection with code under GPLv2 compatible
licenses won't change anything here as the ZFS driver links with Linux
anyway and it uses functions in Linux.
As for the GPLv2 in the ZFS driver, in the module directory of
zfs-2.1.1, we have several files under the GPLv2 license or compatible
licenses.
If I "grep -i gpl" in the module directory, it gives several files, but
all the files I found are OK with that are OK with regard with the
GPLv2:
- lua/lapi.c has 'ZFS_MODULE_LICENSE("Dual MIT/GPL")', so we can can
probably assume that GPL is the GPLv2 and use it under the GPLv2 here.
- The following files are under the GPLv2 or BSD 2 clauses, here we can
use them under the GPLv2, so it's OK:
- zcommon/zfs_fletcher_aarch64_neon.c
- zcommon/zfs_fletcher_intel.c
- zcommon/zfs_fletcher_sse.c
- zcommon/zfs_fletcher_superscalar4.c:
- zcommon/zfs_fletcher_superscalar.c
- Finally, zstd/zfs_zstd.c is under the BSD 3 clauses, and also has
"ZFS_MODULE_LICENSE("Dual BSD/GPL");" inside. In any case that BSD
license isn't incompatible with the GPL, and we can use the GPL in
"Dual BSD/GPL", so we're good in either cases.
As for the problematic symbols, for instance dequeue_signal is exported
by Linux and it's used by the ZFS driver.
To find about that you can use the following command in a Linux git
checkout to find the list of exported symbols:
> git grep -P "EXPORT_SYMBOL(_GPL)?\(.*\);"
And then the idea is to grep for them in the module directory, and
check if they are reimplemented by the ZFS module or not.
Another way to do that check would be to look at the module (the .ko
file) with nm or a similar tool and look at the undefined symbols (U).
As I understand from what Bradley Kuhn told me, the EXPORT_SYMBOL_GPL
macro name is misleading and It doesn't mean that one can use symbols
exported by EXPORT_SYMBOLS without having to abide by the GPL, and I
need to look at EXPORT_SYMBOLS_GPL history to understand that in more
details.
But we don't need to do that either here as the dequeue_signal is
exported with EXPORT_SYMBOL_GPL anyway (it's in kernel/signal.c Linux)
and AFAIK it's not reimplemented by the ZFS driver either.
And I didn't check how many symbols from Linux are used but one is
enough to be an issue.
References:
---
[1] Many files that are being compiled in Linux are under the GPLv2
only or compatible licenses.
[2] The ZFS driver has code under the CDDL license that is compiled in
the ZFS driver.
Denis.
pgp3zoRSiktvQ.pgp
Description: OpenPGP digital signature
Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)
On Mon, 22 Nov 2021 19:10:48 +0100 "pelzflorian (Florian Pelz)" wrote: > I don’t actually care about ZFS myself, but there should be a decision > because I think current badly supported ZFS makes people here unhappy. For people that really want the ZFS kernel module, would using an extra channel for that be a big issue? As I understand the ZFS module is already built from source so maybe there is a way to make sure that everything that depends on zfs is not rebuilt. Or would there be other concerns for users of the ZFS kernel module if the module is moved in an unofficial channel? As long as the module isn't provided, it should also be safe to maintain the rest (like the services), though I've no idea if doing that in Guix is desirable or not. Denis. pgpE88TrMqbz6.pgp Description: OpenPGP digital signature
Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)
Hi, On Tue, 23 Nov 2021 18:29:22 +0100 Ludovic Courtès wrote: > When consensus cannot be met, maintainers have the last say. > > But again, my understanding is that there’s no new decision to be made > here. If I understood correctly Florian, the argument here is that it is safe to redistribute source code under a GPL incompatible license that links to GPL code because it's in source form? Denis. pgptAYKX6Bb82.pgp Description: OpenPGP digital signature
Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)
On Wed, 24 Nov 2021 00:50:04 +0100 Denis 'GNUtoo' Carikli wrote: > Hi, > > On Tue, 23 Nov 2021 18:29:22 +0100 > Ludovic Courtès wrote: > > > When consensus cannot be met, maintainers have the last say. > > > > But again, my understanding is that there’s no new decision to be > > made here. > If I understood correctly Florian, the argument here is that it is > safe to redistribute source code under a GPL incompatible license > that links to GPL code because it's in source form? After having thought about it, I think I think I found a rationale that could make sense. Maybe it's because if the code is in source form, both code are not combined in the same binary. If that's the case then it would also be legal to redistribute binaries too as long as they are dynamically linked as the linking happens at runtime. And that should also not be limited to Linux. We could then through dlopen or any similar method reuse code from one binary in the other because the linking is dynamic as long as both binaries are not linked together statically? Or am I on the wrong track here? Denis. pgpE4V5jiUsd6.pgp Description: OpenPGP digital signature
Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)
On Wed, 24 Nov 2021 13:03:18 +0100 "pelzflorian (Florian Pelz)" wrote: > On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli > wrote: > > If that's the case then it would also be legal to redistribute > > binaries too as long as they are dynamically linked as the linking > > happens at runtime. > > The FSF is unable to have such a position. What I didn't understand is what magically made source exempt of the GPLv2 requirement while binaries aren't. For instance if I make a module for Linux and uses symbols for Linux: - The source code uses code from Linux. But if it's distributed separately both are not combined. To be compilable, the source needs to use headers or function definitions from Linux. - Modules being linked dynamically (=m) also use code from Linux and during the compilation, as I understand it, it only uses the headers and/or functions definitions that I mentioned above. So this case is not very different from the source code. - Binaries being statically linked (=y) are being included in the Linux binary. So from the GPLv2 side, I don't see what could make source code and dynamically linked module that different as to justify different applications of the GPL. That article states that: > Pure distribution of source with no binaries is undeniably different. > When distributing source code and no binaries, requirements in those > sections of GPLv2 and CDDLv1 that cover modification and/or binary > (or “Executable”, as CDDLv1 calls it) distribution do not activate. > Therefore, the analysis is simpler, So is it legal because zfs-on-linux is distributed as source and that the CDDL license incompatible requirements are waived when it is distributed as source? And that combining that work with GPLv2 code in source form is OK because GPLv2 is not violated because the incompatible CDDL requirements are only activated when distributed in executable form? If that's the case that would be the first explanation that doesn't undermine copyleft that I come across, and that is OK for me. If it's not the case then we have an issue and I think that we still need to find a valid explanation that doesn't undermine copyleft and/or get rid of the ZFS kernel module. It also states that it's risky legally: > Nevertheless, there may be arguments for contributory and/or indirect > copyright infringement in many jurisdictions. We present no specific > analysis ourselves on the efficacy of a contributory infringement > claim regarding source-only distributions of ZFS and Linux. However, > in our GPL litigation experience, we have noticed that judges are > savvy at sniffing out attempts to circumvent legal requirements, and > they are skeptical about attempts to exploit loopholes. Furthermore, > we cannot predict Oracle's view — given its past willingness to > enforce copyleft licenses, and Oracle's recent attempts to adjudicate > the limits of copyright in Court. Downstream users should consider > carefully before engaging in even source-only distribution. But as long as the rationale behind doesn't undermine copyleft, I've no issue with it. > It seems unrelated to the FSDG, so GNU Guix need not care. The issue here is that I think that we need to find a valid and plausible explanation that makes the ZFS kernel module source code legal in a way that doesn't undermine copyleft. And in some cases, laws or interpretations of laws that are undermine copyleft might be good if they also brings systemic advantages to free software: for instance if new laws makes all software free in theory and in practice too (by also making sure that we have the corresponding source code, or because we have tools to derive it from binaries). But here if we don't have a rationale that doesn't undermine copyleft, what we gain here is just the ability to use a filesystem in the kernel instead of using it through FUSE, so it's an awful tradeoffs for free software. But if we do have a rationale that doesn't undermine copyleft, it just brings some legal risk, but doesn't undermine copyleft, so I'm OK with that. In the past and present, distributions also had/have to deal with patents, anti DRM circumvention legislation, and many other legal risks, and the consensus in the FLOSS community (at least for patents and anti DRM circumvention) is that the choice of distributing risky packages is to be made by the individual distributions and not the whole FLOSS and/or free software community at large. Denis. pgp21tTZwt_eJ.pgp Description: OpenPGP digital signature
Re: ZFS part of Guix? RFC?
On Wed, 24 Nov 2021 12:02:11 -0800 Vagrant Cascadian wrote: > On 2021-11-24, Denis 'GNUtoo' Carikli wrote: > > On Wed, 24 Nov 2021 13:03:18 +0100 > > "pelzflorian (Florian Pelz)" wrote: > > > >> On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli > >> wrote: > > https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ > > > That article states that: > >> Pure distribution of source with no binaries is undeniably > >> different. When distributing source code and no binaries, > >> requirements in those sections of GPLv2 and CDDLv1 that cover > >> modification and/or binary (or “Executable”, as CDDLv1 calls it) > >> distribution do not activate. Therefore, the analysis is simpler, > > So is it legal because zfs-on-linux is distributed as source and > > that the CDDL license incompatible requirements are waived when it > > is distributed as source? > > Rather than "waived", they are simply not applicable. There is > basically an "if" statement in the CDDL that triggers the > incompatibility, and in the case of source-only distribution, the > conflicting parts of the licenses do not come into play. I've not checked that in details yet but for now I'll assume that this holds (until proven otherwise). While thinking about this very weird case of combining GPL and CDDL code together, I wonder if the fact that we can't redistribute binaries still makes it free software. At least the free software definition doesn't have anything that cover this specific case: > The freedom to run the program as you wish, for any purpose > (freedom 0). > The freedom to study how the program works, and change it so it > does your computing as you wish (freedom 1). Access to the source > code is a precondition for this. > The freedom to redistribute copies so you can help your neighbor > (freedom 2). > The freedom to distribute copies of your modified versions to others > (freedom 3). By doing this you can give the whole community a chance > to benefit from your changes. Access to the source code is a > precondition for this. But I wonder if a license that forbid binary redistribution would still be considered free or not. And also conditions may apply to the specific case, for instance here nobody has an alternative (including Oracle) for redistributing binaries unless Oracle releases ZFS under a license fully compatible with the GPL or that Linux is re-licensed (that would probably be more complicated than rewriting ZFS from scratch). Other cases like a vendor forbidding binary distribution to make its users pay for nonfree licenses might be way more problematic. Denis. pgpLrFSk1HILf.pgp Description: OpenPGP digital signature
Re: ZFS part of Guix? RFC?
On Fri, 26 Nov 2021 16:28:04 +0100 Denis 'GNUtoo' Carikli wrote: > But I wonder if a license that forbid binary redistribution would > still be considered free or not. When we'll have more infos on if that is free or if we consider it as free until proven otherwise, we still have two remaining issues to deal with: - On some architectures (for instance i686) the kernel module doesn't build. Should we disable the module? Add support for these architectures? Or disable zfs as a dependency of Gnome? - Images with the zfs modules won't be redistributable. So if we keep the ability to build the zfs module, would it be possible to add opt-in or opt-out settings to make sure that the images are still redistributable without violating the GPL? Or will all users always need to use transformations for that? Here's the build error I have with i686: > make -C > /gnu/store/c5n1drdj3j780r6yxnqfldifkmwdz01d-linux-libre-module-builder-5.14.21/lib/modules/build > M=`pwd` CONFIG_ZFS=m modules make[3]: Entering directory > '/gnu/store/c5n1drdj3j780r6yxnqfldifkmwdz01d-linux-libre-module-builder-5.14.21/lib/modules/build' > arch/x86/Makefile:78: arch/x86/Makefile_32.cpu: No such file or > directory make[3]: *** No rule to make target > 'arch/x86/Makefile_32.cpu'. Stop. Denis. pgplquChDFwav.pgp Description: OpenPGP digital signature
Re: ZFS part of Guix? RFC?
On Fri, 26 Nov 2021 12:34:55 -0800 Vagrant Cascadian wrote: > On 2021-11-26, Denis Carikli wrote: > > Or disable zfs as a dependency of Gnome? > > This specific point is a bit dated; the issue was both introduced and > shortly after reverted in early July: > > 61ccd756e5ff73b2f8dc3449df537f1c5adb5872 gnu: libvirt: Support ZFS. > 3fb6c96106df85ba47f8fea34b224071bd75a1b4 Revert "gnu: libvirt: > Support ZFS." > > Basically libvirt is a dependency of gnome-boxes, which is a > dependency of gnome, as I understand it, which is why the initial > topic was mentioning GNOME at all... Thanks a lot for the info. I had that issue long after July, like I still had it few months ago. I've now retried to use guix system reconfigure and the issue is now gone. It might be becuase of some issue / bugs with or within my setup[1] though. References: --- [1]I've a dual boot between Parabola i686 (that also has Guix) and Guix SD i686 and I share /gnu and my home between both. Denis. pgpZ0wLkkmq4G.pgp Description: OpenPGP digital signature
Re: ZFS part of Guix? RFC?
On Tue, 30 Nov 2021 15:22:04 + raid5atemyhomework wrote: > Hello Denis, Hi, > > While thinking about this very weird case of combining GPL and CDDL > > code together, I wonder if the fact that we can't redistribute > > binaries still makes it free software. > > AS I understood from early writings of GNU --- > > "Freedom" here is the freedom to modify how *the hardware you > purchased, which is supposedly your own*, works. > > In principle, "binaries are enough", because you *can* modify > executable binaries, and until Tivoization you could thus modify how > the hardware you purchased and is supposedly owned by you works. > However, early GNU writers (RMS I think?) noted that binaries are > really awful and that you need source code in order to modify how > your hardware work, unless you are willing to sacrifice a ridiculous > portion of your life reverse-engineering executable binaries. In case of binaries, when some people have the source code and you don't, there is also an inequality and power dynamic: people with source code have more power to modify the software than people without. We can see some mention of a somewhat similar power dynamic in the GPLv3 for instance: > But this requirement does not apply if neither you nor any third > party retains the ability to install modified object code on the User > Product (for example, the work has been installed in ROM). And it seems that in the weird case of zfs-on-linux, that power dynamic at least doesn't apply directly as nobody can redistribute binaries unless they are the copyright holder of ZFS and redistribute it all under licenses fully compatible with the GPLv2. Though one could also argue that not everybody is equals when breaking the law (so here when redistributing binaries) but that's probably out of scope here as we only (re)distribute source code here. > Thus, the essential freedom is preserved (users can fork ZFS and > point their personal ZFS package definition at their fork), even if a > legal snag prevents redistribution of binaries. Good point. > I am well aware that *somebody* at Sun Microsystems screwed up by > inventing the CDDL and putting the excellent ZFS under the CDDL and > that is certainly a very cringey decision, but I want my hardware to > work how I want it (i.e. without RAID5 write holes and memory buffer > corruption bugs like in BTRFS "RAID5" mode) and not having ZFS on > Guix is not helping that essential freedom. I also wonder if we have a way to fix that issue for good somehow. It would be neat if somehow the copyright holder of ZFS redistributed zfs-on-linux binaries at some point (for instance by redistributing the Ubuntu kernel). As I understand this wouldn't automatically make that code GPL compliant but we could probably manage to force the copyright holder to re-release the ZFS code under GPL compatible licenses. Rewriting the ZFS code under GPLv2 compatible licenses also looks possible as GRUB has a GPLv3 implementation of ZFS, but it's probably still a lot of work. It would have been a way better idea for Canonical to hire people to do that (like the people that worked to add ZFS to GRUB) rather than trying to circumvent the GPLv2[1][2]. References: --- [1]https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ [2]https://ubuntu.com/blog/zfs-licensing-and-linux Denis. pgp7YN1DhEZLJ.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
On Sat, 16 Feb 2019 12:16:41 +0100 Gábor Boskovits wrote: > It seems to me, that there is a whole bunch of people interested in > this, but due to lack of resources or for some other reasons nothing > is really happening. Do you know any we we could help getting this > resolved? This is a very good point. I also wonder if at the end, working to fix the problem by reviewing chromium source code more carefully would take less resources than discussing endlessly on how to deal with the fact that the source code hasn't been reviewed. Denis. pgp5Jwx_cHBQn.pgp Description: OpenPGP digital signature
Re: FSDG issues of SCUMMVM-based games
Hi again, On Tue, 20 Jun 2023 06:30:26 +0200 Liliana Marie Prikler wrote: > If in some one to five years we still find no practical way of using > ScummVM with only free software, that might be a reason to remove it > then. With lot of help from anthk_ #hyperbola I finally found a practical way to use it, and even without recompiling it, so we can keep ScummVM. We need 3 repositories: - https://jxself.org/git/inform.git GPLv3+ - https://jxself.org/git/devours.git AGPLv3+ - https://jxself.org/git/informlib.git (devours submodule) AGPLv3+ Here's how to do it: > $ git clone https://jxself.org/git/inform.git > $ cd inform > $ gcc src/*.c -o inform > $ git clone --recursive https://jxself.org/git/devours.git > $ cd devours > $ sed 's#inform#../inform#g' -i build.sh > $ ./build That creates the devours.z5 file. We can then start scummvm: > $ scummvm glk:devours And we can then choose "add game" and add the game in the current directory and accept the warnings. Then pressing start starts the game. Denis. pgpVkcUvYwhG5.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] MAME emulator is giving incentive to use non-free software
On Wed, 30 Mar 2016 16:30:17 -0600 Isaac David wrote: > Hi, Hi, > My view was that while useless in a 100% free environment just > having them installed and inspecting their user interfaces wouldn't > violate your freedom in any way. A free emulator with free > dependencies wouldn't be unethical unless it recommended using > proprietary software with it. However in the last few days I have > seen many arguments showing there are yet more valid uses I hadn't > imagined, like learning from the source code and testing portability > without leaving your comfy libre OS. Just requiring documentation that shows how at least one valid use case (that works) while remaining 100% free would be great: It would fix the issue for good, while improving users freedom by limiting the steer towards non-free software that such virtual machines create. For instance: - For qemu, libvirt and so on, we would ship or point to documentation explaining how to run a 100% free software distribution like Trisquel. - For wine we would document compiling and running of a 100% free software. - For emulators, unless 100% free distributions do exist for the machines they emulate, we'd document how to compile and run an application or game. - For emulators that have no 100% free games but that have a toolchain, we could document how to do compile and run a hello world. That would count as 100% free software compiling and running. > Meanwhile other emulators and wine are completely out of the > question because there's free applications for them, even though > using the non-free ones is more common. I don't doubt that, however is it possible to compile and run such applications 100% free? Since some GNU software is ported on wine, I would guess that there is a way to do it, but I've no proof. I fear that some free software applications would include some non-free runtime libraries. Given how poorly I know non-free OS, I've no idea if it's a legitimate concern. > Parabola documents emulators extensively in a wiki page. Should we document how to compile and run free software there, or should we ship that documentation with the package? In the former case, should we point the user to the wiki page at the end of the package installation, in the case of Parabola. Denis. pgpcmg1xj314Y.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] MAME emulator is giving incentive to use non-free software
On Tue, 29 Mar 2016 16:31:40 + alírio eyng wrote: > these are the approaches i can think: > *extremely conservative (eliminating false positive errors)[1] > removing all emulators > *conservative (eliminating false positive errors)[1] > make packages/executables like game1-emulator1, game1-emulator2, ... > and not allowing direct emulator installation/execution > *liberal (avoiding false positive errors[1] and false negative > errors[2]) allowing all emulators with free games know > *extremely liberal (eliminating false negative errors)[2] > allowing all emulators Why not just requiring some documentation along the emulator that documents at least one fully free software that can run on it. That software would have to be able to be built and run 100% free software. Making that documentation available and known to the user will steer that user toward free software. Denis. pgptMGZj3pQ7E.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] MAME emulator is giving incentive to use non-free software
On Sat, 2 Apr 2016 08:48:58 + alírio eyng wrote: > On 4/2/16, Denis 'GNUtoo' Carikli wrote: > > Why not just requiring some documentation along the emulator that > > documents at least one fully free software that can run on it. > this is missing some complexity: > we don't want something better done natively (we exclude > ndiswrapper)[1] but we still want to allow introducing free software > on nonfree platforms[2] My point was that documentation (and packaging as you point it) can steer users towards free software. The goal of the software may even be altered this way, if it cannot be used fully free with its regular uses cases. The former case might be faster to do, but getting it right would be difficult since the user would have to be aware of that documentation. Which one to do would then depend on the context. For instance with qemu and libvirt, the software was modified not to steer users towards running non-free GNU/Linux distributions. While unrelated, the case of debootstrap is also interesting, since, on parabola, it by default debootstraps free software distributions. References and configuration related to non-100%-free distributions were removed. > i think packaging is better than documenting, shouldn't be much more > effort Right, I assumed documenting was way faster. I was probably wrong. > but this doesn't address the problem of discernment > example: i can go to [3] and see there are four games, i know they are > free because they are inside a free distro frontier > if users need to exit the free distro frontier, they probably will > find nonfree and free games and don't see much difference > the ideal would be to have a comprehensive set of games packaged > inside the free distro frontier The documentation would have had to take that into account. I was thinking of something along the lines of HOWTO that you find in the documentation of the distributions. Such as list of commands that would explain how to do it, while making sure that freedom is preserved. But as you pointed out, packaging might be faster and easier. > hiding the emulator executable/package I don't understand what it means. > would warn when they are exiting the free distro frontier and poke > them to add free games to the distro (suggesting to developers or > sending patches) That is very similar to documentation for me. We might also want to do that on the parabola wiki, trying to implicate people who might want to use such emulators. Example: Why is not in Parabola |-> > alternatively, forking all emulators and creating a > free community around them would also provide a freedom frontier That is nice too. Uzebox seem in the right direction with that. Denis. pgpwHbNAKbibc.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] MAME emulator is giving incentive to use non-free software
On Mon, 4 Apr 2016 22:23:17 + alírio eyng wrote: > Felipe Sanches: > >MAME provides an interactive debugger > so mame is not just an emulator. > it is a emulator, disassembler and debugger. > this is relevant information i can't see in official documentation, > thanks. > [...] > a interesting development environment is useful in itself and don't > need free games. > is there a similar environment to a current architecture? community/qtspim 9.1.17-2 New user interface for spim, a MIPS simulator. Denis. pgpLepsBMner4.pgp Description: OpenPGP digital signature
Re: Go Package with multiple subpackage
Hi, Sorry for the delay, On Sun, 22 Sep 2024 13:21:30 -0400 Superfly Johnson wrote: > The Azure SDK for Go > (https://github.com/Azure/azure-sdk-for-go/releases) has many > sub-packages within the same directory and the guix import method > won't work directly. I think the best solution for packaging the > requirements for rclone would be to make the sub-packages individual > guix packages using the url-fetch method instead of the git method. > Each also depends on several sub-packages. I had a similar issue with the matterbridge package which has about 500 dependencies that are not in Guix. I verified most of the licenses for the dependencies with a combination of recursive guix import and manually looking for the ones that weren't detected. And given the number of dependencies I was told that it was okay to have them bundled in. As I understand, packaging too many dependencies would create complications for the maintenance. Though the current situation is far from ideal as checking the license of ~500 dependencies is also very time consuming and if problems appears in newer releases it would be difficult to detect them. Also note that we didn't know about the dependencies issues of matterbridge when it got in, so maybe it played a role in the decisions that was taken at the time. Denis. pgprjMq85h23z.pgp Description: OpenPGP digital signature
Re: About Guix OS VM and Guix Package Management support request from Operating System developers
On Thu, 17 Oct 2024 21:18:16 +0200 (CEST) wearefromuniverse--- via wrote: > Hi, Hi, > For this we need to adapt Guix OS to replace fedora, the main > operating system of Qubes OS. To run Guix OS inside VM Qubes we need > a GNU Guix OS virtual machine. We need to ensure that this virtual > machine can interact and communicate with other virtual machines and > the host operating system through Xen technology, for which we need > technical and software support from you. [...] > We also need open source volunteer developers to work on the software > team. We are still a small community and we were founded 1 month ago. The best way to do that would probably be to send patches directly to Guix and to find people with commit access that are interested in reviewing these patches. As I understand Guix already has some Xen packages for instance, but I've no idea how to use them. For instance the Guix manual doesn't have anything at all on Xen. So finding out how to create a Guix VM compatible with Xen and/or adding the missing support/documentation for Xen and sending relevant patches to Guix (like to its cookbook or documentation) could be a good start. It is also possible to add definitions for VMs inside the Guix source code as well, and to reference that from the manual/cookbook. If you also need a fully free distribution that already supports running Xen VMs easily, Trisquel 11 can probably do that. I tried it personally on a ThinkPad X200 to understand if Xen worked with a boot software distribution I co-maintain: I installed the xen-system-amd64 and libvirt-daemon-driver-xen Trisquel packages and rebooted and after that virt-manager could find the local Xen hypervisor. I don't remember if I needed to add my user in some group or not and I already had virt-manager and libvirt installed. However I didn't go further as I lacked a Xen compatible VM to completely validate that Xen worked for real. Also note that I'm not a Guix maintainer. I'm just a user who also contribute from time to time, and I also reuse Guix in other projects I co-maintain / contribute to. Denis. pgp4xhL3cAJKx.pgp Description: OpenPGP digital signature
Re: 1.5.0 release?
On Tue, 10 Sep 2024 18:21:17 -0400 Greg Hogan wrote: > With Guix embracing the chaos of rolling releases, and a presumption > that users will `guix pull` soon after installation, I count only > three motivations to tag a new release: 1) replacing an old release > with an outdated Guix unable to self update, 2) security fixes for > installation packages so as not to be immediately pwned, and 3) > minimizing the number of replacement installation packages (especially > after core packages updates). There is also at least 1 project (GNU Boot, which I'm involved in) that currently uses a released Guix version (Guix 1.4.0 for i686) to build other software as the Guix manual for the latest release is easily accessible and doesn't change much, so contributors can easily refer to it. It's not a big issue to workaround some things on top of a release but if a complete language that we use is missing that creates a lot of complications for us. Bitcoin can also use Guix to build things but they seem to use an arbitrary revision not based on any releases (guix 1.3 with lots of commits on top). I've no idea if there are many other projects that reuse Guix fixed revisions. Another thing that may be relevant (not related to projects I'm involved in) could be to somehow validate if all the architectures supported by Guix work fine and maybe get important packages working on them. Though note that I'm not a Guix maintainer and I don't have commit access, so I can't participate in decisions on what is important or not. Denis. pgp1VDgAZqngp.pgp Description: OpenPGP digital signature
Re: Bootstrap a GNU source distribution from git
On Tue, 01 Oct 2024 10:20:54 + Tobias Geerinckx-Rice wrote: > >Since Guix also checks the hash of the source code an idea to improve > >things could also be to modify Guix to allow the use of external > >tools to bootstrap the download of source code through version > >control and for instance download git from git. > > I don't understand what you mean by this, or what 'modify Guix' means > and why it would be needed? We currently have something like that: > (define-public git-minimal > (package > (name "git-minimal") > (version "2.46.0") > (source (origin > (method url-fetch) > (uri (string-append > "mirror://kernel.org/software/scm/git/git-" version ".tar.xz")) > (sha256 > (base32 >"15bzq9m6c033qiz5q5gw1nqw4m452vvqax30wbms6z4bl9i384kz" > [...] If we replace with something like that: > (define-public git-minimal > (package > (name "git-minimal") > (version "2.46.0") > (source > (origin > (method git-fetch) > (uri > (git-reference > (url "https://git.kernel.org/pub/scm/git/git.git";)) > (commit ""))) > (file-name (git-file-name name version)) > (sha256 > (base32 > "15bzq9m6c033qiz5q5gw1nqw4m452vvqax30wbms6z4bl9i384kz" > [...] Then we have at least 2 issues. The first one is that we might end up with circular dependencies inside the Guix source code somehow that creates issues when building packages and/or guix, etc. But that might be fixable with some work. However if I understand well, that circular dependency would not create any security/reproducibility issue since we would already have a base32 hash of the source code of "git-minimal". And so if for instance someone packages Guix on a foreign distribution, we could imagine some system(s) where the the git source code is somehow provided to Guix as a dependency, and so once built, Guix would be able to use that provided source code by verifying its hash and then using it to build git, and enabling Guix to download subsequent packages using git. This could then be extended to all the packages that git depend on, and with that we'd then be able to use git a lot more without security issues. The downside is that as always someone needs to be interested in it, and find the time to work on it. It also might make building Guix harder. Denis. pgpRsdI92RclF.pgp Description: OpenPGP digital signature
Re: Announcing shepherd-run
Hi, On Sun, 3 Nov 2024 15:19:04 +0200 Efraim Flashner wrote: > Announcing the initial release of shepherd-run! > > Do you have experience with systemd and systemd-run? Do you wish you > were able to quickly and easily add a simple service to your (user or > system) shepherd instance? > > Using the finest technologies from the 70's, written in gawk, I > present shepherd-run! Is there any plans to integrate that with Guix and Shepherd later on? I'm thinking of uses cases like netctl which is an utility from Arch Linux that is present in Parabola. Users define network profiles and netctl somehow interact with systemd to setup the network. Here for instance Guix system services or Guix home services are not dynamic, and especially for the network it could make sense to have different profiles. As I understand netctl generates systemd unit files, so there is also some similarities between netctl and shepherd-run. Denis. pgpDdFXboWuHc.pgp Description: OpenPGP digital signature
Re: Running a Guix User and Contributor survey
On Thu, 31 Oct 2024 16:44:22 +0100 Ekaitz Zarraga wrote: > I think we could do with Framasoft: > https://framasoft.frama.io/framaforms/en/ The downside of framaforms is that they block Tor. Denis. pgpkATUAGHcJY.pgp Description: OpenPGP digital signature
Re: Running a Guix User and Contributor survey
Hi, On Wed, 30 Oct 2024 12:03:26 + Steve George wrote: Here's some feedback on the proposal below. > # Audience > The audience for this survey are all Guix users and contributors > [^1]. This means: > > - Guix user: anyone who uses all or part of Guix, whether as their > operating system or hosted on another GNU/Linux distro. > - Guix contributor: anyone who sends changes (patches) to the > project. This includes code changes, but also other improvements > including documentation, design and translation. This is an extensive > group beyond those with commit rights. > - Guix community: the totality of both groups. Most Guix contributors are also users, so this may need to be reflected in some ways. > **Q1. How knowledgeable a Linux user are you?** GNU/Linux would probably be better given the audience here. > - an official GNU FSF (Free Software Foundation) project The distribution is certified by the FSF but it's a GNU package. The FSF doesn't maintain the Guix package though. So maybe this could be better: > **Q5. Why were you initially interested in Guix?** [...] > An FSF certified 100% free software distribution. I'm also unsure if it should be added to the list or not but being able to install software on top of another distribution is a common use case so that might be a reason to use it. And this can be done for a wide variety of reasons (ship software to users, use it in some QA process, etc). I'm also aware that this option is also included in a question on how we use Guix. Denis. pgpye57hUTK7b.pgp Description: OpenPGP digital signature
Re: Go Package with multiple subpackage
On Sat, 26 Oct 2024 23:11:17 +0100 Sharlatan Hellseher wrote: > Take a look at the current effort of unbundle (gnu packages ipfs) - > kubo. Bit by bit and we nearly unweaved the rainbow. Thanks a lot, that was the part that I lacked. I assumed I needed to do all 500 at once because go didn't provide a way to partially unbundle dependencies. I'll try to reproduce that with matterbridge. I assume that it's OK if I add you in the list of reviewers if/when I get something ready. Denis. pgp7JjYDlywen.pgp Description: OpenPGP digital signature
Re: Go Package with multiple subpackage
On Sun, 27 Oct 2024 18:56:11 +0100 Andreas Enge wrote: > Also, there is some magic in etc/git/gitconfig in the Guix > repository: When you do a "git send-email" to guix-patc...@gnu.org > with a commit touching any of the Go team files above, the team > members will be automatically cc-ed. Yes, this is exactly why I didn't notice that Sharlatan was part of the team: this is done almost automatically now. Thanks for the information. Denis. pgpvMgcucabNu.pgp Description: OpenPGP digital signature
Re: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]
Hi, On Tue, 12 Nov 2024 21:59:42 +0900 Maxim Cournoyer wrote: > Great. That said, I wouldn't be against stopping building i686 > packages on our build farm. Nobody has shown much interested in > fixing the broken ones or hunting down test failures... it seems > better to focus our energy elsewhere and clear the view in my opinion > (such as old bugs on our bug tracker that lingers on) > > So I'd be of the opinion to: > > 1) Stop building i686 packages > 2) Otherwise preserve the architecture in Guix source so that someone > can at least build from source and hack on it if they wish, e.g. to > test cross-building packages. In GNU Boot we chose to use i686-linux as the system we build packages for as this way we support both i686 and x86_64 (some of the computers we support are still i686). Though for now we fixed the revision to Guix 1.4.0 so it means that we don't find regressions affecting newer revisions. I also personally also depend on i686 computers (ThinkPad X60) that I don't use every day but that are important for me: they hold the signature key of my gpg key and they are way easier to secure than x86_64 machines against evil maid attacks (the machines were audited, and don't allow DMA from external ports unlike all the x86_64 machines supported by GNU Boot). But here too they are not updated regularly. So does it means that we ultimately need to run our own builder for i686 or are there other options (like setting up our own CI, going back to i686 to test builds (I was running i686 to be able to find and fix what didn't work before), etc), using latest Guix revisions to test more often, etc? All the use cases above only require very basic software to work: we don't need full blown desktop systems (that would probably require to bootstrap rust and I didn't really manage to find a way that would work in Guix). Denis. pgpLBpJwMlli6.pgp Description: OpenPGP digital signature
Re: Bootstrap a GNU source distribution from git
Hi, On Sun, 29 Sep 2024 19:52:13 +0200 Vivien Kraus wrote: > GNU sources are usually shipped as tarballs with some pre-compiled > sources included. This can be a bit scary at times, so the question > now is, can we skip the tarballs and build everything from > human-authored sources? In some cases it is also possible to build from the tarballs and also build everything from human-authored sources. The solution to that is to treat the generated files as things that are not wanted during the build and just delete them before starting to build. It's similar to tarballs which also contain the binaries of some of their dependencies (example: .so files, often with their corresponding source code as well for licensing compliance). In such case the answer of the distributions is simply to delete such binaries before the build. The advantage of these bundled binaries is that the same tarball makes it possible for more people to more easily build the software but it also increase the maintenance from the distributions as they need to find and delete such files, so to me it doesn't look ideal. Having an easy way to automatically delete such generated files safely could be a good idea for source tarballs releases as both uses cases could be covered with a single tarball release. But this also brings an interesting questions that I also had myself but I never really had the opportunity to ask them: what is Guix policy with regard to source code when there are multiple providers (typically git vs tarball)? As I understand source from version control gives us the ability to make some package transformation option work out of the box. For instance we have: > $ guix build \ > --with-commit=hello=2633763362586903cf6506f4c4d708727a981025 hello > guix build: error: the source of hello@2.12.1 is not a Git reference So is there some (implicit or explicit) rule to always prefer the source from version control unless it's not possible or practical (no version control being used, too complicated to build like with GNU hello, or the package is required for the version control to work) ?. Since Guix also checks the hash of the source code an idea to improve things could also be to modify Guix to allow the use of external tools to bootstrap the download of source code through version control and for instance download git from git. Though that could require some substantial work and discussions. Denis. pgp1qbxQE7IVo.pgp Description: OpenPGP digital signature
Re: Go Package with multiple subpackage
On Mon, 21 Oct 2024 16:18:56 +0200 Andreas Enge wrote: > > As I understand, packaging too many dependencies would create > > complications for the maintenance. > > Is that true? It looks opposite to the general Guix philosophy; > once you have invested all the work of checking the licenses, it would > seem a progress to submit the corresponding packages. But maybe Go is > special in that respect; it would be nice to have the Go team's > opinion. One of the issue is also that I didn't find a way to have a path where things are done step by step, so adding about 500 extra packages just for the matterbridge package would be complicated I guess. But in another hand using bundled in dependencies doesn't look great either. This also bring in more complicated questions as there is also some tradeoffs made here. For instance here things are not fine with matterbridge but it's not something a user can immediately see. So should we keep the package? What would be the quality of the maintenance in the long run with about 500 packages to update? I've also no idea about how many go packages use bundled dependencies, so maybe if there is a way to somehow un-bundle part of the dependencies it could be a road to improve the situations as the maintenance the dependencies shared by many go packages could be shared somehow (assuming people do check that when updating things it doesn't break other packages). If packages also patch some dependencies, it would not prevent from using non-bundled dependencies. Another issue is that all that is statically built but that's part of the default go compiler if I understood well, though given how Guix works, it might easier to somehow use shared libraries (compared to more standard distributions) if some compilers that support that since we don't need very strict/strong ABI guarantees with Guix, and thanks to that, reduce build times and resources consumption (like RAM, space, etc). Denis. pgpGYX4gykbip.pgp Description: OpenPGP digital signature
Re: Scaling issues with forges Was: Trying out Codeberg
On Sun, 9 Mar 2025 17:26:07 -0400 Leo Famulari wrote: > And only using GPL2 is part of that. It's a pragmatic choice in favor > of the goals of Linux's leadership team, which are different from > GNU's goals. Of course, Linux couldn't feasibly change to GPL3 > because their copyright licensing model is like ours: contributors > own the copyright to their contributions. There are too many people > to ask for permission to make the change. I heard something different about the GPLv3 and Linux. It is possible to require to license things under GPLv2-or-later for instance, so technically it is not a big issue. VLC also managed to do license changes, as well as Openstreetmap. As I understand, what happened instead is that Linux took a decision against the GPLv3 on purpose for completely different reasons. One of the reasons I heard was that if some software is under the GPLv3, you can also make derivative works under the AGPLv3. Another reasons I heard that is also related to that is that the lawyer who tried to convince Linux to switch to the GPLv3(+) did it without considering the interests of Linux itself (to put it lightly), so that didn't go well because of that. Another reason may also related to the anti-DRM provisions for consumer devices inside the GPLv3. And the first and the third reason might indeed be related to the interests of the companies that fund work on Linux. Denis. pgpBaF6OQEmd8.pgp Description: OpenPGP digital signature
Re: Guix on the MNT/Reform
On Mon, 17 Mar 2025 12:30:29 -0700 Vagrant Cascadian wrote: > On 2025-03-16, Denis 'GNUtoo' Carikli wrote: > > On Thu, 13 Mar 2025 00:37:09 -0700 > > Vagrant Cascadian wrote: > >> I have successfully built and booted a > >> linux-libre-arm64-mnt-reform@6.12 kernel on a "MNT Reform2 with > >> RCORE RK3588 Module" ... running Debian, I know... but Guix System > >> cannot be too far off! In theory it also supports the other MNT > >> Reform platforms, but I have not tested! > > [...] > >> One could not be enabled due to DEBLOBBING the wifi drivers, and > >> the other may need a closer look. Although the second was for a > >> platform I am not currently using, so... :) > > What is the WiFi chip being used[1]? > > Heh. Hard to tell, because I am running linux-libre. :) Using 'sudo dmesg' usually prints something with DEBLOBBED and the driver name. Another option is to use lspci like that: > # lspci -s 02:00.0 > 02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network > Adapter (PCI-Express) (rev 01) root@primary_laptop /home/gnutoo# lspci -s 02:00.0 -v > 02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network > Adapter (PCI-Express) (rev 01) > [...] > Kernel driver in use: ath9k > Kernel modules: ath9k > Looking at the card through the transparent case bottom (yes!): > > WLE200NX 7A > > A quick search says some Compex dual-band wifi, but not sure what that > translates to in linux driver terms... > > The original MNT/Reform used the Atheros ath9k, if I recall correctly > ... could possibly switch back to that too, presumably, if that has > libre drivers. It does. There are also ath9k compatible chips that support both 2.4 GHz and 5GHz. If you want WiFi to work in conferences or other very crowded environments (like a flat with a ton of people) you need a chip which support 5GHz. > > An option could also be to upstream as much as possible of the DTS > > somehow (basically only send the easy dts patches) to be able to > > more easily track what is missing upstream and so find out why this > > or that patches are really needed. > > Yes, that is indeed the eventual goal and best outcome, but for the > near future we still have to use patches Indeed, I was just pointing in addition to shipping a patched kernel (which is required to make the hardware work), some very limited upstream contributions are a good idea to get reliable information on what patches are really required because things evolve upstream. Reading or trying to remove some of the patches you currently use to try to understand the consequences is probably still be required anyway, but just having that done doesn't provide some easy way to test things on more recent kernel versions. > There is some good news on that front, too: > > > https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/rockchip/rk3588-mnt-reform2.dts?h=next-20250317 Nice. I'm currently offline so I'll try to remember to take a look later on. Also note that I don't have an MNT Reform but I'm very curious about them. Denis. pgpUShjrTrmbu.pgp Description: OpenPGP digital signature
Re: Guix on the MNT/Reform
On Tue, 18 Mar 2025 14:36:23 +0100 "pelzflorian (Florian Pelz)" wrote: > Hello all; regarding dystopian direction; > > Christine Lemmer-Webber writes: > > The modularity of the Reform design is the most hope I have for a > > FOSS future on the otherwise largely dystopian direction of > > hardware lately. Hopefully we will get better and better options > > over time for the SoCs too. > > I guess DDR4 RAM suffers from board-specific cross-talk and that is > the main reason for free software support getting worse. Maybe > firmware is made with proprietary board information to avoid > cross-talk. Maybe free firmware could be made with time-intensive > testing of the particular board, each time the firmware is built. > Maybe instead of the real board, a virtual board “digital twin” could > be used for training, which would be free software if the virtual > board would only coarsely resemble the real non-free board. If I remember well what phcoder did for the ThinkPad X201, the trick to write DDR3 RAM init was to make it work without optimizing anything at first. For DDR3 you need to do training to precisely configure the delays to have good performances, but once how the RAM controller work is understood, you could simply configure it to use very big delays. Basically delays tell the RAM controller how much time it needs to wait for all the signals to have arrived. And to understand how the hardware works, tracing what nonfree binary do is a possible option but it also require some software that can run the blob in a way that can trace the hardware accesses. For instance in Coreboot there is something called SerialICE that can run the nonfree BIOS and print the MIMO accesses for instance. neox also wrote a paper on DDR3 RAM initialization for the KGPE-D16 but it's not public yet (and it needs some improvements as well), so if you want to help review it you need to write to him. Once released, it will be published under one or more free licenses. Compared to DDR3, DDR4 might require additional things, but similar tricks could probably be used to at least make it work in non-optimized ways first. For instance if we configure the RAM controller to be very lax, then we might not need to re-calibrate constantly because of temperature changes and so on. > Maybe USB3 has similar cross-talk? A lot of the hardware (HDMI, probably USB3) nowadays do require training. Denis. pgpjIJNVknkT6.pgp Description: OpenPGP digital signature
Re: Guix on the MNT/Reform
On Wed, 19 Mar 2025 22:02:12 -0700 Vagrant Cascadian wrote: > Well, turns out that it was simply missing the kernel configuration > for... > > CONFIG_ATH9K=m Nice. > ... now it at least partly works and sees some access points, although > there are issues that prevent associating successfully... I recall > similar symptoms when using the ath9k_htc usb dongle before, and there > was a workaround for it. Possibly related, reform-tools has this: > > > https://source.mnt.re/reform/reform-tools/-/blob/main/NetworkManager/default-wifi-powersave-off.conf Since you use a custom kernel, it is also possible to use a custom configuration, so you could try to disable this option: > config CFG80211_DEFAULT_PS > bool "enable powersave by default" > default y > help > This option enables powersave mode by default. > > If this causes your applications to misbehave you should > fix your applications instead -- they need to register their network > latency requirement, see > Documentation/power/pm_qos_interface.rst. I'm unsure if this is sufficient though as userspace can easily enable it back. For instance with iw, anyone can do: > sudo iw dev wlp2s0 set power_save (I'm not sure if the interface needs to up or down though), so I wonder if wpa_supplicant / NetworkManager or other userspace tool/daemon do it automatically or not. > I suspect only one of the supported GHz frequencies is enabled in the > kernel too as it sees one access point but not another (and I forget > which is which, they're on the same physical machine). But at least I > know this is likely to work with a bit more fiddling! Here's how to find the supported frequencies: > $ guix install iw > [...] > $ iw phy > Wiphy phy0 > wiphy index: 0 > max # scan SSIDs: 4 > [...] > * 2412 MHz [1] (17.0 dBm) > * 2417 MHz [2] (17.0 dBm) > * 2422 MHz [3] (17.0 dBm) > * 2427 MHz [4] (17.0 dBm) > * 2432 MHz [5] (17.0 dBm) > * 2437 MHz [6] (17.0 dBm) > * 2442 MHz [7] (17.0 dBm) > * 2447 MHz [8] (17.0 dBm) > * 2452 MHz [9] (17.0 dBm) > * 2457 MHz [10] (17.0 dBm) > * 2462 MHz [11] (17.0 dBm) > * 2467 MHz [12] (17.0 dBm) (no IR) > * 2472 MHz [13] (17.0 dBm) (no IR) > * 2484 MHz [14] (17.0 dBm) (no IR) Here I only have 2.4 GHz. Denis. pgpNTBD84DOMz.pgp Description: OpenPGP digital signature
Re: Guix on the MNT/Reform
On Tue, 18 Mar 2025 08:38:02 -0400 Christine Lemmer-Webber wrote: > The modularity of the Reform design is the most hope I have for a FOSS > future on the otherwise largely dystopian direction of hardware > lately. Hopefully we will get better and better options over time for > the SoCs too. It's also repairable so if there is enough interest people could work on it during years for instance to make one of the hardware combination boot with fully free software. Denis. pgpwZTLy2A5Y3.pgp Description: OpenPGP digital signature
Re: Please don't leave GNU
Hi, On Sun, 30 Mar 2025 12:55:33 +0200 "pelzflorian (Florian Pelz)" wrote: > Your mail alerted me; I too hope but also believe there are no such > plans to leave GNU. Where have you heard? There was a talk about the usefulness of integrating nonfree software into Guix for instance[1], and I discussed with a Guix contributor telling that the FSDG was too strict, so there is some concern, and moving to a forge outside of GNU can also be interpreted as a step toward leaving GNU. However I've discussed with other people in Guix and they seem to instead want to find ways to make everybody happy, and I also agree with this strategy. In practice it would mean that Guix itself will still respect the FSDG, and so users that don't want to run nonfree software will see almost no changes (or even improvements in freedom). And for users that reluctantly need to use nonfree software would also find that to be easier. An example would be to switch from linux-libre to some 100% free linux kernel that doesn't block nonfree firmware, so if users reluctantly need nonfree firmware they would, on their own, add them. However I think that the best situation would be to make it as easy as possible to provide a complete distribution based on Guix, with a website, releases with installation images, etc. This way, if people use that to make new distributions based on Guix, with a different name (something where people can't make confusions with Guix, like Lax, Nerds, NerdX, Pix, etc), people that reluctantly need nonfree software would use that instead and they won't forget that they use nonfree software, they could find support for it, and they would also know that the distribution they use is based on Guix and that they can contribute to Guix as well. And people that want to use only free software would not be pressured to install nonfree software. In addition, making it easier to reuse Guix would be a good thing anyway. Also note that Pantherx is already based on Guix for instance, but it might not suit everybody, and I've not looked in details how it compares to the creation of a distribution based on Guix and non-guix for instance. > There are not yet decided discussions that GNU Guix leave Savannah and > Debbugs and replace them for Codeberg/Forgejo. > > > > Guix has several drawbacks that, while trivial, make it worse than > > Fedora Silverblue: > > > > * Guix asks for my LUKS password twice > > Not sure of the current situation, but this was because GNU GRUB > lacked support for passing on the unlocked LUKS device with a secure > key derivation function or some such thing. The fix should be made > upstream. Here's the configuration I use (in case that can help avoid trial and errors): > (bootloader (bootloader-configuration > (bootloader (bootloader (inherit grub-bootloader) >[...])) > (keyboard-layout keyboard-layout) > (extra-initrd > "/boot/keys/primary_laptop-key-file.cpio"))) And I generated this cpio with the following command (primary_laptop.key is the keyfile): > /boot/keys/primary_laptop-key-file.cpio: primary_laptop.key > @# It can work with sudo, but then we got errors like that: > @# make: stat: > @# /boot/keys/primary_laptop-key-file.cpio: Permission > @# denied > @if [ `id -u` != "0" ] ; then \ > echo "You need root permissions. try sudo make $@" ; \ > false; \ > fi > > echo primary_laptop.key | cpio -oH newc > $@ Also note that I use GNU Boot, so I've not tested that with the regular GRUB. With: > Except for guix pull and similar commands, is that really true? The > installed software is like in other package managers. And: On Sun, 30 Mar 2025 20:51:03 +0200 Tomas Volf <~@wolfsden.cz> wrote: > $ guix size deluge > [...] > total: 1954.5 MiB > [...] > > I decided to use Archlinux for comparison [...] I just started a > container, installed the deluge package and did `du -sh /'. [...] > # du -sh / > [..] > 909M / I think that in practice it does use a lot more space, especially if we keep several revisions of the current system or user profile in /gnu/store. It also requires about 2GiB of RAM per core being used. References: --- [1]https://10years.guix.gnu.org/program/#how-to-make-gnu-guix-irresistible-in-2022-and-beyond Denis. pgpNbBD0oTJXk.pgp Description: OpenPGP digital signature
Re: Guix on the MNT/Reform
Hi, On Thu, 13 Mar 2025 00:37:09 -0700 Vagrant Cascadian wrote: > I have successfully built and booted a > linux-libre-arm64-mnt-reform@6.12 kernel on a "MNT Reform2 with RCORE > RK3588 Module" ... running Debian, I know... but Guix System cannot > be too far off! In theory it also supports the other MNT Reform > platforms, but I have not tested! [...] > One could not be enabled due to DEBLOBBING the wifi drivers, and the > other may need a closer look. Although the second was for a platform I > am not currently using, so... :) What is the WiFi chip being used[1]? > Rather than embedding all those patches into guix, I could really use > help with figuring out how to apply those patches from the git > checkout! It is a lot of patch: > [...] An option could also be to upstream as much as possible of the DTS somehow (basically only send the easy dts patches) to be able to more easily track what is missing upstream and so find out why this or that patches are really needed. References: --- [1]https://mntre.com/modularity.html says "via mPCIe card" for the WiFi so it's probably hard (for me) to find out by reading the source code. Denis. pgpdiZA2GZLFW.pgp Description: OpenPGP digital signature
Re: Guix on the MNT/Reform
On Sat, 15 Mar 2025 11:49:14 +0100 Simon Josefsson via "Development of GNU Guix and the GNU System distribution." wrote: > + (bootloader (bootloader-configuration > + ;; Due to FSDG issues with the DDR training binaries, > we cannot > + ;; currently ship u-boot in guix: > + > ;; > https://www.collabora.com/news-and-blog/blog/2024/02/21/almost-a-fully-open-source-boot-chain-for-rockchips-rk3588/ > + ;; Defining an empty bootloader generates an > extlinux.conf that > + ;; nearly any modern u-boot can read. > + (bootloader u-boot-bootloader))) Thanks a lot for this trick (that could be handy with u-boot-qemu-arm64). > I assume something must have written the non-free u-boot blob to > internal flash memory or sdcard? Is it necessary to re-run 'guix > system reconfigure' to re-create the extlinux.conf for Guix after > that external process rewrote the u-boot blob, or how would the > entire workflow look like? Another option could be to tell the system configuration to only ship GRUB and have u-boot provided by either mnt-reform or another project load that GRUB. This worked with the Pinephone with TowBoot when I tested few years ago. Though I'm unsure if it would work in all cases since there is a bug where GRUB requires the same block size (like 512 bytes / 4KiB) between the filesystem and the block device. Denis. pgpSmY7XOU5wy.pgp Description: OpenPGP digital signature
Re: Visiting a future of GNU? (was Re: Please don't leave GNU)
On Wed, 2 Apr 2025 10:28:04 -0500 Caleb Herbert wrote: > I agree that we must move beyond Richard and take the reigns. This is > already happening in GNU proper. I disagree that we should take away > the old man's honor over nit-picking the things he says. I don't > think we should blot out his name or disparage him. The problem is much more complex I think. I think it's a byproduct of centralizing a movement toward a single individual and over-relying on the reputation of a single person. Doing that also has good aspects as for instance it works well with the media as long as the person reputation keeps being good, so you can spread the word much much faster this way, but it's also risky (live by the media reputation, die by the media reputation?). And I don't have a definite answer on which one is better because I lack a lot of the historic context. For instance, going faster might have been the only viable option in order to grow fast before we were in practice outlawed by Microsoft or software patents for instance. Also note that it's also possible to "hack" all that to get advantage of both going fast and going far. For instance a given person can talk for a collective, and it's also possible to have someone famous come in a place to make people talk instead of talking, which has also the effect of bringing local people together. This has already been done in practice for instance: https://en.wikipedia.org/wiki/The_Other_Campaign But like in my previous mail it also brings down the question of if we want to go fast or far, and what has been done has been done, so the only question we face is what to do now. This brings a question of where to spend resources (to clarify what happened, have the truth emerge, etc, or to go forward trying to fix issues that might stay for a longer term if we do nothing, and choosing is not necessarily easy as understanding what happened also helps us learning lessons, but doing so without too much infighting is complex given that people are still in conflict about all that). So I think that in any case we should take this mess as an opportunity in order to make free software stronger rather than only having to deal with all the bad aspects of it. This may also be what makes things stronger: to be able to learn from the environment and adapt, but here even if I have some historical example in mind (like the Roman empire or Linux), it's only a hypothesis and I've no proof for it (what seems to make sense is not necessarily true). Denis. pgpx_81irK53r.pgp Description: OpenPGP digital signature
Re: Wireshark with capabilities
Hi, On Tue, 15 Apr 2025 13:52:45 +0200 Denis 'GNUtoo' Carikli wrote: > The wrapper should be relatively easy to write but I wonder if the > string to change can be predicted in advance. Sorry for that but I saw that after: there is a GCD to reduce program wrappers. So we probably need to take that into account somehow. Denis. pgpzfClCO9Rz_.pgp Description: OpenPGP digital signature
Re: Please don't leave GNU
On Mon, 14 Apr 2025 10:52:31 +0200 Simon Josefsson wrote: > > Last time I discussed it with the linux-libre, the reason loading > > non-free firmware is outright disabled is because it'd be trivial > > for any privileged (or maybe that's not even a condition?) > > processes to make a system call to Linux to load non-free firmware, > > which would make it difficult to control for users. > > Oh, is that really the case? I had assumed that this was a policy > decision, that linux-libre didn't want to allow users to have the > ability to load non-free firmware, to make sure the goals of > linux-libre aren't compromised. Note that some firmwares can probably also be loaded from userspace without having Linux involved. I remember having to remove nonfree firmware in SDR related packages in Parabola, in that case the firmware was for some FPGAs and it was nonfree in practice because it required nonfree tools to be "compiled" (the technical term is synthesized for FPGAs). These can probably be loaded with some utility that talks to some USB device directly with libusb. Nowadays there are probably drivers for that kind of things, so I'm unsure what is the current practice. So in practice linux-libre only prevent the kernel from picking some firmwares put in /lib/firmware. But my understanding was that in the case of linux-libre that was a bug not a feature. > Is the syscall available for non-root users? If so isn't that a linux > kernel bug, surely non-privileged users shouldn't be allowed to load > firmware that can modify hardware behaviour? There is no syscall. You can do it by hand with echo and cat. It works in this way: # echo 1 > /sys/class/firmware/loading # cat /lib/firmware/my-firmware.bin > \ /sys/class/firmware/data # echo 0 > /sys/class/firmware/loading If I remember well, to run that at the right moment, there is also an interface to be notified when a firmware is requested. But that can also be done with a shell command: # nano /bin/my-udev-replacement # echo /bin/my-udev-replacement > /proc/sys/kernel/hotplug I don't remember how firmware request look like though. It's been many years since I last used that. > I have thought that a middle ground project like 'linux-free' would be > possible: it would be identical to linux-libre but re-add the hooks to > allow root to load non-free firmware, if they so chose to do it. I'm > more comfortable with this approach than using linux upstream, since I > think that linux-libre improves more than just non-free firmware > loading. Indeed. It makes some GPU work. > I don't think a strict kernel policy to disallow users to run non-free > code serves user freedom: it would prevent running a binary that I > build using GCC built on a 5 lines C code that doesn't have a license > (such a program would also be non-free). There is also another consequence: it doesn't print the firmware name, so users are not steered toward finding it and putting it in /lib/firmware, though I'm unsure how much that steers people in practice. For instance are there cases where some software parses the kernel logs and popups shows up when you don't have firmwares? If we don't package that we are probably OK. Another consequence I see is that it makes refusing these firmware harder, though I'm unsure if it happens in practice for firmwares. Do project that indirectly depend on 3D acceleration or nonfree firmware treat users the same if they don't want to use the nonfree firmware or if they can't ? The Radeon probably doesn't count here because if in practice the upstream for users is linux-libre or Guix (they would report bugs there), it probably doesn't bring any pressure to install the nonfree firmwares. If the upstream is Gnome in practice, that may or may not have a collective impact, but they also need to make Gnome work in VMs without 3D acceleration, so the question is more when to enable it to work without 3D acceleration (this could be hardcoded or configurable at runtime, I'm unsure, dllud looked into it for Replicant few years ago, but at least patching mesa and/or gnome source code can always make it work, the question is also if it works in Guix, and if not are we willing to make it work to make sure to remove pressure and make everybody happy, effectively improving both freedom and also the ability to use nonfree firmwares). A decision probably would have no impact on some software that really depend on 3D accelerations like some games unless the CPU is fast enough to run llvmpipe (and in this case it's the same issue as above: is it configured to run llvmpipe or does it just fail, do we need to patch mesa?). For communication software like skype, this is way more documented as it did happen a lot though: some people were really pressured by other people to install it and use it, so we can clearly say there was pressure here. Note that if we manage to patch/configure MESA it could also help support more hardware in general (computers with out of
initrd-modules on non-x86 Was: Guix on the MNT/Reform Status Update
On Thu, 27 Mar 2025 11:48:21 -0700 Vagrant Cascadian wrote: > First I would boot your MNT Reform with whatever OS you have now. You > will need to make some changes to kernel-arguments (check the contents > of /proc/cmdline) and initrd-modules (check lsmod output). [...] > For the initrd-modules, you should be able to just add all the modules > you get from lsmod. Probably overkill, but hopefully will work! :) On many ARM computers it's not overkill, you often lack very basic modules for linux-libre or linux-libre-lts (example: rockpro64). I'm unsure how to fix this mess. linux-libre-arm64-generic usually works fine for booting but then you miss things like the Wireguard module, so I'm unsure if there is only Wireguard or if it's a bigger issue. The way forward now is to create system configurations in gnu/system/images/ but it doesn't address the problem of how to actually generate this module list in a convenient way. And while the module list in the machine config might work, the list is also tied to a specific kernel version as modules get renamed or split (like rk808_regulator, rk8xx-i2c), even for modules that are required for booting, so it also requires some maintenance (basically to reconfigure + reboot from time to time + sending patches). If someone has ideas here on how to generate module names from linux-libre-arm64-generic it would be more than welcome as it would simplify things a lot. So far I did it manually, by looking in the devicetree and from there getting the driver names and from there getting the module name, cross referenced with the kernel configuration shipped by Guix (CONFIG_*) and I end up with something like that: > (initrd-modules > (append > (list >"dw_mmc-rockchip";; CONFIG_MMC_DW_ROCKCHIP for uSD boot >"dwc3" ;; CONFIG_USB_DWC3for USB boot >"dwc3_of_simple" ;; CONFIG_USB_DWC3_OF_SIMPLE for USB boot >"ehci_platform" ;; CONFIG_USB_EHCI_HCD_PLATFORM for USB boot >"fixed" ;; CONFIG_REGULATOR_FIXED_VOLTAGE for USB boot >"i2c_rk3x" ;; CONFIG_I2C_RK3Xfor uSD boot >"mmc_block" ;; CONFIG_MMC_BLOCK for eMMC boot >"ohci_platform" ;; CONFIG_USB_OHCI_HCD_PLATFORM for USB boot >"phy_rockchip_emmc" ;; CONFIG_PHY_ROCKCHIP_EMMC for eMMC boot >"phy_rockchip_inno_usb2" ;; CONFIG_PHY_ROCKCHIP_INNO_USB2 for USB boot >"phy_rockchip_usb" ;; CONFIG_PHY_ROCKCHIP_USBfor USB boot >"pl330" ;; CONFIG_USB_SERIAL_PL2303 for uSD boot >"rk8xx-core" ;; CONFIG_MFD_RK8XX for uSD boot >"rk8xx-i2c" ;; CONFIG_MFD_RK8XX_I2C for uSD boot >"rk808_regulator";; CONFIG_REGULATOR_RK808 for uSD boot >"sd_mod" ;; CONFIG_BLK_DEV_SD for USB boot >"sdhci_of_arasan";; CONFIG_MMC_SDHCI_OF_ARASAN for eMMC boot >"uas";; CONFIG_USB_UAS for USB boot >"usb_storage";; CONFIG_USB_STORAGE for USB boot >"xhci_plat_hcd") ;; CONFIG_USB_XHCI_PLATFORM for USB boot >%base-initrd-modules)) I also plan to upstream all that at some point, but I also have other issues with GRUB on this computer (I want to upstream something that I can test and that actually works), and it's also my main server so that complicates things. So it would probably be easier for me to upstream support for another ARM computer first (like the rock (pi) 4c plus), hence this mail as once u-boot/grub is fixed I'll need to re-generate the modules for this computer to upstream support for it. Denis. pgpcd6HNK3asU.pgp Description: OpenPGP digital signature
u-boot and GRUB on ARM
Hi,
I've a patch to add a new ARM computer to Guix (attached), but when I
add this to the system definition (to generate an image):
> (bootloader (bootloader-configuration
>(bootloader u-boot-rock-4c-plus-rk3399-bootloader)
>(targets '("/dev/mmcblk0"
I then get an image that boots on GRUB and then GRUB doesn't find its
grub.cfg.
Is this behavior intended or is that a consequence of u-boot
having introduced the new bootflow way of booting?
If it's intended, how do I fix my configuration?
Also what would be the ideal way of dealing with that? Do we intend to
support both syslinux and GRUB?
On another computer (rockpro64) I also had an issue with GRUB not
loading due to block size mismatch (I didn't investigate it yet in
depth), so it might be worth to also keep syslinux for strange cases
like that.
Note that on the rock-4c-plus, I can boot Guix but it requires messing
with u-boot by doing the following:
(1) I need to interrupt the boot in u-boot.
(2) I then need to run 'bootflow scan' and wait enough to populate the
list of ways it can boot. During the scan it also tries to see if it
can boot from the network and that is super long but it can also be
interrupted manually as this is the last option. At the end, the
'bootflow list' can then list the available boot options.
(3) I then need to run 'bootflow select 2' to use syslinux and then
'bootflow boot'.
I've not investigated yet how to always select 2 beside adding some
bootcmd in the environment, but that would also require to run
'bootflow scan' and u-boot should be managed by the guix
system configuration anyway.
Denis.
From d11c723f7e19788e15464f11012c7cc366217504 Mon Sep 17 00:00:00 2001
Message-ID:
From: Denis 'GNUtoo' Carikli
Date: Fri, 21 Mar 2025 00:48:58 +0100
Subject: [PATCH] system: Add u-boot-rock-4c-plus-rk3399.
* gnu/packages/bootloaders.scm (u-boot-rock-4c-plus-rk3399): New variable.
* gnu/bootloader/u-boot.scm (u-boot-rock-4c-plus-rk3399-bootloader):
New exported variable.
* gnu/system/install.scm (rock-4c-plus-installation-os):
New exported variable.
Change-Id: I37025b248178311ccf8246cb0e02ed9399f9c6ac
Signed-off-by: Denis 'GNUtoo' Carikli
---
gnu/bootloader/u-boot.scm| 6 ++
gnu/packages/bootloaders.scm | 10 ++
gnu/system/install.scm | 5 +
3 files changed, 21 insertions(+)
diff --git a/gnu/bootloader/u-boot.scm b/gnu/bootloader/u-boot.scm
index 64fb319f50..0e7eb95ba4 100644
--- a/gnu/bootloader/u-boot.scm
+++ b/gnu/bootloader/u-boot.scm
@@ -47,6 +47,7 @@ (define-module (gnu bootloader u-boot)
u-boot-pinebook-bootloader
u-boot-pinebook-pro-rk3399-bootloader
u-boot-puma-rk3399-bootloader
+u-boot-rock-4c-plus-rk3399-bootloader
u-boot-rock64-rk3328-bootloader
u-boot-rockpro64-rk3399-bootloader
u-boot-sifive-unmatched-bootloader
@@ -252,6 +253,11 @@ (define u-boot-puma-rk3399-bootloader
(package u-boot-puma-rk3399)
(disk-image-installer install-puma-rk3399-u-boot)))
+(define u-boot-rock-4c-plus-rk3399-bootloader
+ (bootloader
+ (inherit u-boot-rockchip-bootloader)
+ (package u-boot-rock-4c-plus-rk3399)))
+
(define u-boot-rock64-rk3328-bootloader
(bootloader
(inherit u-boot-rockchip-bootloader)
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 8ece61f11c..a9f70f8bf1 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -1430,6 +1430,16 @@ (define-public u-boot-rock64-rk3328
(define-public u-boot-firefly-rk3399
(make-u-boot-rockchip-package "firefly" 'rk3399))
+(define-public u-boot-rock-4c-plus-rk3399
+ (let ((base (make-u-boot-rockchip-package
+ "rock-4c-plus" 'rk3399
+ '("CONFIG_USB=y"
+ ;; Disable SPL FIT signatures, due to GPLv2 and
+ ;; OpenSSL license incompatibilities.
+ "# CONFIG_SPL_FIT_SIGNATURE is not set"
+(package
+ (inherit base
+
(define-public u-boot-rockpro64-rk3399
(let ((base (make-u-boot-rockchip-package
"rockpro64" 'rk3399
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 15ea401f1c..60e0825ce3 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -662,6 +662,11 @@ (define rock64-installation-os
"/dev/mmcblk0" ; SD card/eMMC (SD priority) storage
"ttyS2")) ; UART2 connected on the Pi2 bus
+(define rock-4c-plus-installation-os
+ (embedded-installation-os u-boot-rock-4c-plus-rk3399-bootloader
+"/dev/mmcblk0" ; SD card storage
+"ttyS2")) ;;
Re: GCD 004 deliberation
Hi, > Sure, I'll try it later.. Thank you for the feedback! Sorry for the delay. These GCD are going too fast for me. I have some questions that could be useful for when you retry. The GCD mentions that: > To find its search path configuration files when an executable is > running, > we can first find the location of the executable. Conveniently, Linux > provides a pseudo-file `/proc/self/exe` for this exact purpose, which > works well for ELF executables. But for an interpreter script, > `/proc/self/exe` would return the file name of its interpreter > instead of the script, so we patch interpreters to set 2 environment > variables: > > - `GUIX_INTERPRETER_FILE`: absolute file name of the interpreter > - `GUIX_MAIN_SCRIPT_FILE`: absolute file name of the script Did you look if binfmt had any effects on all that? What happens if you run some ARM binaries with QEMU on x86, would it break all that? Also, for next time, it might be useful to look if there are alternatives that enable not to patch interpreters and their costs. For instance Android has a tool named path_interposer whose goal is to somehow sandbox builds to make sure host tools are not used unless their path are in the allowed list. I don't remember how it does the sandboxing though but if I recall well it really worked for the use case (the host tools are not in the same location than the Android source code). And in general, it would be good to understand if it's possible to have something as generic as possible and the costs as well (we might not want to pay huge performance penalty for them). Denis. pgpPUahL0zqu0.pgp Description: OpenPGP digital signature
Re: Visiting a future of GNU? (was Re: Please don't leave GNU)
On Wed, 02 Apr 2025 10:03:03 +0200 Simon Tournier wrote: > Today, Richard is 71 years old. The question isn’t the past but the > future: What will be GNU in 5 years? 10 years? 20 years? 40 years? > What does it mean being part of GNU once Richard will be “retired”? > Please do not take me wrong, I wish all the best to Richard and a very > long life! Being just a human implies becoming older and older and > passing away. For one, not a personal opinion. ;-) An big practical problem I saw in discussions on the gnu-linux-libre mailing list (which is a mailing list meant for coordination of all FSDG distributions like Guix, Trisquel, but also non-GNU/Linux distros like Replicant) is that RMS's opinion enable to close a discussion. This means that without RMS people are probably not able to collectively take decisions on controversial topics. Another issue related to this one is that we also do need both to have ways to grow strategic capacity on our own and also to have experience in taking collective decisions. The first would mean to understand better things that RMS knows well and be able to take strategic decisions for GNU and/or free software. For the second, while I would have liked to slowly ramp up the GCD (try it with more consensual decisions first, to see potential issues and limitations of the approach and fix them), it is at least a step in the right direction as it enables to do exactly that. Both are different because we can also take bad collective decisions if we are not correctly informed, even if there is (at some point) a good process for reaching consensus and/or taking decisions. Another longer term issue I see is that we also need multiple people to step in individually or collectively to be able to write the kind of articles RMS was writing because this is something that is extremely strategic: it defines and unify the free software movement. Without that I fear that it would produce too much infighting. It might also be possible to do it somewhat collectively as there are historic examples where that worked (example: https://en.wikipedia.org/wiki/Freedom_Charter) and the big advantage here would probably to have a more robust and inclusive movement. So we could probably try to write articles (like the ones written by RMS like the "JavaScript trap", etc) in case new threats or opportunities arise for free software. > I think the question “leave GNU or not?” is empty. Because it asks to > look back when we must focus on look next. It's also probably the wrong question being asked, as it's probably implied that leaving GNU will lower freedom standards. So the real question should rather be with that directly: "Please don't lower Guix's freedom standards" or "Please don't leave the FSDG" or similar. There might completely different reasons to join, not join or leave GNU and that has probably not be mentioned despite the Subject of the thread. Many distributions that follow the FSDG Guidelines are not GNU at all, and some probably can't become GNU (Replicant, Hyperbola BSD) because they are not even GNU/Linux distributions, and joining would cause too much confusion (For Replicant it would be an Android distribution which is not GNU/Linux joining the GNU project while not using the GNU userland, that would look very strange, Hyperbola BSD also doesn't plan to use the GNU userland). Beside FSDG guidelines there are things like hosting requirements for GNU (https://www.gnu.org/software/repo-criteria.en.html), or other implied requirements, and all that could be discussed instead for instance. Or maybe the subject should be "Please don't leave the the GNU (freedom) standards". As for practical reasons for Guix, for instance, present or future regulations in the USA could be good reasons to leave GNU with no intentions to lower the freedom standards or to change anything to its architecture. > After 40 years, when people are still putting the founder in the > middle of the project, it means either the project failed, either the > project is going to fail once the very founder stops their > activities. Or, slippery slope – without any willing to be harsh –, > either people devote a cult of personality to the founder. No? > After 40 years… I think it's something like "If you want to go fast, go alone; if you want to go far, go together.": too much centralization on one individual allows to go faster, but then the movement becomes less robust, with bias (so it reaches less people, misses a lot of opportunities), etc. Retrospectively I don't have the knowledge to understand if it was a good or bad choice (free software had got a lot of threats, from Microsoft to software patents, etc), but we have to deal with the consequences (both good and bad) of this choice now. And the fear I have is that we don't find ways to continue doing what RMS was doing and that we end up being stuck without ways to evolve. And the problem is that we need to do that in a world where re
Re: Why YOU should join a Team!
On Sun, 27 Apr 2025 14:37:24 +0100 Steve George wrote: > There's no particular rule on how much you need to have contributed > to become a Team member. Personally, I think that if you consider > yourself as someone who's working on the project then the door is > open for you to join a team. See the manual for the details! > > https://guix.gnu.org/manual/devel/en/guix.html#Teams I've tried to apply to the bootloaders team after the FOSDEM but it probably got lost in the mails. Does joining a team also give access to QA tools? Currently bisecting issues takes a lot of time for me and I'd like to be able to somehow retrieve information from the QA system and/or trigger builds of known commits there. Denis. pgpYT0FXgEmJ6.pgp Description: OpenPGP digital signature
Re: [GCD] Migrating repositories, issues, and patches to Codeberg
On Wed, 12 Feb 2025 11:44:42 +0100
Ekaitz Zarraga wrote:
> [...] in Git there's no slave.
Personally I find 'main' more accurate precisely because of that.
Git enables to more easily maintain branches (not necessarily in the
same repository) with modifications on top, and/or to diverge, and so
for me using 'main' also convey the idea that people can legitimately
use other branches as well, especially because more than one meaning of
master don't really encourage that ('master copy' and/or power
relationship, though the later is more for the noun than the adjective).
There is also this wording in the manual for the main channel, and here
too the Guix utilities and daemon can also be reused with alternative
repositories (even replacing the main one as I understand, though I'm
unsure if anybody tried that).
In both cases using a more accurate word can empower the users and
promote practical freedoms.
Denis.
pgpdq1PrhUExL.pgp
Description: OpenPGP digital signature
Re: [GCD] Migrating repositories, issues, and patches to Codeberg
On Thu, 13 Feb 2025 13:15:01 +0100 Liliana Marie Prikler wrote: > Am Donnerstag, dem 13.02.2025 um 10:30 + schrieb Attila Lendvai: > > > Here's my perspective: it will cost us basically nothing to rename > > > the master branch, > > > > i suspect you'd be surprised how many places will need to be touched > > until the whole infra is back on track after such a rename... > > > > e.g. consider just the "bootstrapping" of this rename: > > > > if you simply rename the branch, then people won't be able to guix > > pull after the rename. > > > > if you keep two branches, then for how long until no users are left > > who will attempt to guix pull using an unprepared guix binary? > > > > or should we add code to guix preemptively that can deal with both > > the pre and post rename environment? then have a grace period before > > the rename? for how long? > Consider these steps: > > 1. Create 'main', following 'master'. > 2. Push a commit that makes 'main' the branch of > %default-guix-channel. > 3. Push that commit to both 'master' and 'main'. > 4. Lock master on said commit. This doesn't take care of existing repositories, and it is possible to handle that as well but the way I know does require practical control over the infrastructure (there may be better ways though that works without ssh access): $ git checkout origin/master -b temporary $ git push origin HEAD:main $ ssh root@server $ cd /path/to/repository.git $ git symbolic-ref HEAD refs/heads/main # Change the main branch $ git symbolic-ref refs/heads/master refs/heads/main # Make master point to main I did it on many Replicant repositories for instance, and it's 100% transparent to the users. With that, new clone of the repositories use main by default. Denis. pgpjLYUq4tLOZ.pgp Description: OpenPGP digital signature
Re: Trying out Codeberg
On Sat, 22 Feb 2025 22:35:21 +0900 Maxim Cournoyer wrote: > [0] https://forge.a-lec.org/ (self-hosted in France by a nonprofit! [1]) > [1] https://www.a-lec.org/ Personally I have a private repository on forge.a-lec.org that I use for Q/A for a project I participate in, and so I push and pull regularly from it, and it has significant downtime (It's subjective but I've seen it down way more than Savannah). So I ping neox each time that happens and he does what needs to be done to bring the service back online (he's involved in maintaining these services). Since this is operated by volunteers, people can join and help somehow, but not only it probably requires to be a member of the association, but as usual it also requires time. International projects already asked for hosting in this infrastructure so it may be possible to join remotely but I didn't try that. That infrastructure is pretty clean, but more work is needed in this area: it runs on KGPE-D16 (that even run GNU Boot) on Trisquel, but they didn't manage to disable some forgejo features that they wanted to disable for freedom reasons, so they simply tell people not to use them. I didn't follow all the discussions about that but according to Neox who was involved in it, it's documented in xmpp://comin...@salons.a-lec.org and in various bug reports that are in the forgejo instance of Libre en communs. The problem is that automatic builds depend on NodeJS and docker, and while there might be ways to workaround both they require time and I didn't look into it, and some of the ways to workaround might not be straightforward (for instance docker-registry has no usable authentication / authorization for such use cases, it requires additional software that probably need to be packaged, all that probably need to be integrated somehow not to point to docker.io, etc). I've done work here and there to try to fix the docker issue in a more generic way but it's far from finished. My idea was to first find a way to enable communities to setup their own public docker registry like Fedora does, and then find ways that would work for FSDG distributions to publish their docker container in either self-hosted repositories and/or in a public one that only accepts FSDG compliant images. All that requires a flexible enough authentication/authorization to work and that is however not packaged nor tested (or documented) in any FSDG distro yet. Making 100% private repositories work fine though, including in Guix. Once this is taken care of, remains the fact that the security would be downgraded from GPG to HTTPS, but that is probably not the end of the world and things could probably be worked around if needed with the help of that authentication/authorization for instance by mirroring docker repositories locally, using self-signed certificates and/or localhost, etc. Having a less generic solution might be better though, like using 'guix' or 'debootstrap' to build containers within the forgejo, but that also require volunteers to implement that. Denis. pgp4_huwMeXbj.pgp Description: OpenPGP digital signature
Re: Trying out Codeberg
On Thu, 06 Mar 2025 10:10:03 +0900 Maxim Cournoyer wrote: > > Is Docker the only current solution for runners in the CI? This is my understanding from my discussion with neox. > > Having a less generic solution might be better though, like using > > 'guix' or 'debootstrap' to build containers within the forgejo, but > > that also require volunteers to implement that. > > We already have Docker image generation support via 'guix pack -f > docker', and also 'guix system image -t docker' so that should be > feasible yes. I'm aware of that. My point with using 'guix' or debootstrap was to find ways not to have to run a docker registry. Denis. pgpKHzsBfN71w.pgp Description: OpenPGP digital signature
Re: Trying OpenCL on Guix: An Experience Report
Hi, On Mon, 05 Jul 2021 07:27:54 -0500 Katherine Cox-Buday wrote: > I have written up a blog post here[1] which describes my experience > with trying to use OpenCL on Guix. While researching this, I found a > few messages in IRC and on guix-help wondering how to get this to > work, so I hope this helps someone. > > As always, thanks to everyone involved in Guix. > > [1] > https://katherine.cox-buday.com/blog/2021/07/05/trying-opencl-on-guix-an-experience-report/ Thanks a lot for this writing. I have the exact same issue but for a very different use case. I wrote a free software utility that computes the sim-unlock code for a very old smartphone model (Galaxy SII, GT-I9100), and I want to push it in a free software project I somehow still maintain but we use Guix for the CI, and so we are blocked by the lack of OpenCL as well. Here is an example that works on Trisquel 11 (it even works within a Trisquel 11 chroot from Guix): > $ rm -rf ~/.local/share/hashcat/ > $ hashcat -d 1 -m 110 --hex-salt -a 3 \ > ef63bf26e2382917d96850ccf9632458ee6e6c77: \ > ?d?d?d?d?d?d?d?d > [...] > ef63bf26e2382917d96850ccf9632458ee6e6c77::50681318 > > Session..: hashcat > Status...: Cracked > Hash.Mode: 110 (sha1($pass.$salt)) > Hash.Target..: > ef63bf26e2382917d96850ccf9632458ee6e6c77: > Time.Started.: Tue Mar 4 21:11:40 2025 (4 secs) > Time.Estimated...: Tue Mar 4 21:11:44 2025 (0 secs) > Kernel.Feature...: Pure Kernel Guess.Mask...: ?d?d?d?d?d?d?d?d [8] > Guess.Queue..: 1/1 (100.00%) > Speed.#1.: 17403.7 kH/s (6.89ms) @ Accel:64 Loops:1000 Thr:1 > Vec:4 Recovered: 1/1 (100.00%) Digests > Progress.: 70528000/1 (70.53%) > Rejected.: 0/70528000 (0.00%) > Restore.Point: 70400/10 (70.40%) > Restore.Sub.#1...: Salt:0 Amplifier:0-1000 Iteration:0-1000 > Candidate.Engine.: Device Generator > Candidates.#1: 12345128 -> 68860881 > Hardware.Mon.#1..: Util:100% > [...] > $ hashcat -d 1 -m 110 --hex-salt -a 3 \ > ef63bf26e2382917d96850ccf9632458ee6e6c77: \ > ?d?d?d?d?d?d?d?d --show > ef63bf26e2382917d96850ccf9632458ee6e6c77::50681318 The same fails on Guix: > $ rm -rf ~/.local/share/hashcat/ > $ hashcat -d 1 -m 110 --hex-salt -a 3 \ > ef63bf26e2382917d96850ccf9632458ee6e6c77: \ > ?d?d?d?d?d?d?d?d > hashcat (v6.2.6) starting > > ATTENTION! No OpenCL, Metal, HIP or CUDA installation found. > [...] > $ hashcat -d 1 -m 110 --hex-salt -a 3 \ > ef63bf26e2382917d96850ccf9632458ee6e6c77: \ > ?d?d?d?d?d?d?d?d --show > $ Note that the examples above use the CPU (-d 1) to do the bruteforce so at least it shows something that is really easily reproducible, it's also relatively fast (few seconds) on a ThinkPad X200. Unfortunately, beside that, I don't have much to bring to the table yet. In contrast, 'clinfo -l' is almost identical between Guix and the Trisquel chroot. Though hashcat -I looks very different. In Guix we have: > $ hashcat -I > hashcat (v6.2.6) starting in backend information mode > > ATTENTION! No OpenCL, Metal, HIP or CUDA installation found. > > You are probably missing the CUDA, HIP or OpenCL runtime installation. > > * AMD GPUs on Linux require this driver: > "AMDGPU" (21.50 or later) and "ROCm" (5.0 or later) > * Intel CPUs require this runtime: > "OpenCL Runtime for Intel Core and Intel Xeon Processors" (16.1.1 > or later) > * NVIDIA GPUs require this runtime and/or driver (both): > "NVIDIA Driver" (440.64 or later) > "CUDA Toolkit" (9.0 or later) And in the Trisquel chroot: > $ hashcat -I > hashcat (v6.2.5) starting in backend information mode > > clGetDeviceIDs(): CL_DEVICE_NOT_FOUND > > clGetDeviceIDs(): CL_DEVICE_NOT_FOUND > > OpenCL Info: > > > OpenCL Platform ID #1 > Vendor..: The pocl project > Name: Portable Computing Language > Version.: OpenCL 2.0 pocl 1.8 Linux, None+Asserts, RELOC, LLVM > 11.1.0, SLEEF, DISTRO, POCL_DEBUG > > Backend Device ID #1 > Type...: CPU > Vendor.ID..: 128 > Vendor.: GenuineIntel > Name...: pthread-Intel(R) Core(TM)2 Duo CPU P8600 @ > 2.40GHz Version: OpenCL 1.2 pocl HSTR: > pthread-x86_64-pc-linux-gnu-penryn Processor(s)...: 2 > Clock..: 2400 > Memory.Total...: 5542 MB (limited to 1024 MB allocatable in one > block) Memory.Free: 2739 MB > OpenCL.Version.: OpenCL C 1.2 pocl > Driver.Version.: 1.8 > > OpenCL Platform ID #2 > Vendor..: Mesa > Name: Clover > Version.: OpenCL 1.1 Mesa 23.2.1-1ubuntu3.1~22.04.3 I'll try to find the time to use the tips you mentioned to try to make hashcat work, and try more things, like using Guix on top of Trisquel and Parabola, to see if at some point things start working. While any workaround might be nice and get things moving, the end I am interested i
linux-libre, Was: Scaling issues with forges Was: Trying out Codeberg
Hi, Note that I also discussed various kernel options at the FOSDEM with other people involved in Guix, so I'm taking the occasion to add the info here as well. On Mon, 10 Mar 2025 10:08:23 +0900 Maxim Cournoyer wrote: > In practice, Linux-libre deals pretty much with a single issue: the > non-free device firmware, whether its loaded from external blobs or > directly embedded in C arrays in the source (which thankfully appears > a rare practice nowadays). I've looked at it few years ago, and this is only part of what it does. Nowadays, the deblobbing is trivial to do without linux-libre and can be replaced with few 'rm -f'[1] on older Linux versions that requires deblobbing. We can do that easily because Debian has the information inside Debian/copyrights inside the kernel package[2]. I'm not sure if some nonfree code remains nowadays. Now Linux-libre does much more and some of the things it does is really interesting: - It has tool to detect the kind of non-free software you're talking about. When there are new detection, they are investigated. So I guess that at the end of the day even projects like Debian benefit from the information and work in this area. - It also blocks nonfree loadable firmwares files even if they are not provided by the kernel. It doesn't block non-files though, like the ACPI tables or the nonfree bytecode provided by the video BIOS. - It keeps information on the amount of drivers that require nonfree firmwares as they are announced in releases. This is also possible because it blocks nonfree firmwares. - It has patches to make some of the drivers work without the nonfree firmwares, like the radeon driver for some GPUs. I'm unsure if there are more, but some drivers I use seem to have "optional" firmwares like some Realteck Ethernet cards. I didn't try them with Linux though. - It probably modifies the documentation as well to at least refer to GNU/Linux and maybe more I recall well. Also note that FSDG distributions are not forced to use linux-libre or to block the loading of nonfree firmware if the firmwares are already there. For instance in Replicant we always deblobbed the kernel ourselves, and at some point we evaluated linux-libre but decided against it due to the complexity of separating the different things it does (we were not interested yet in blocking nonfree firwmares but we are also not providing them). In the case of Guix, I heard that some people might be interested in using a deblobbed Linux (and even providing them by default) instead of linux-libre, but I'd also think it's interesting to keep the option of having linux-libre at least for the Radeon driver modifications that makes some GPU work without nonfree firmwares. With these modification we still have no 3D acceleration but we can use the native display resolution[3] and even multiple displays, which in some cases is sufficient to make an unusable computer usable again. Trisquel 11 (aramo) also has a mix between linux-libre and linux to allow some fimrware loading without reverting these modifications to the Radeon driver. References: --- [1]rm -rf Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt \ arch/powerpc/sysdev/micropatch.c \ drivers/media/usb/dvb-usb/af9005-script.h \ drivers/media/i2c/vs6624.c \ drivers/net/appletalk/cops* \ drivers/video/fbdev/nvidia \ drivers/video/fbdev/riva \ [2]https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-i386/linux-signed-i386_4.19.249+2_copyright [3]In a small laptop (Toshiba N550D) I keep for testing linux-libre, with the modifications you have a 1024x600 resolution instead of 800x600. Denis. pgpPswATu2Kf6.pgp Description: OpenPGP digital signature
Re: Scaling issues with forges Was: Trying out Codeberg
On Mon, 10 Mar 2025 11:37:29 +0100 Simon Tournier wrote: > Hi Denis, all, Hi, > That’s said, we must recognize that sending patches by emails is not > smooth at all. Indeed. The configuration (smtp settings, or learning how to import patches in mail clients before sending them, etc) is probably too complex for most people. > Yes, this can be fixed with tooling. But that’s the wrong frame for > an answer, IMHO. The question is: who commits in maintaining such > tools? My question is more "what is the way that can get us there with the least amount of work and that doesn't make the whole process less efficient in the long run?". Alternate proposal: === > Whatever my opinion about the proposed “Migration Path”, today I have > nothing better to propose than accepting the proposal to implement the > PR workflow in order to smooth the bottleneck. Therefore, I try very > hard to avoid the human bias of resistance to change and instead try > to focus on what I can or cannot live with for my day-to-day > collaboration with Guix. Right now it seems a bit like having the choice between the Cholera and the Plague, both with really bad aspects, but that are very different, and having a difficult choice between both. There could also be human bias at play here in case where some people probably can't stand the current problem anymore (for good reasons) and would probably like to exchange it as fast as possible for another issue, but while it makes sense in the short run, in the longer run it could be problematic because the trip is one-way only. Having something that mix good aspect of both models looks viable though. For instance an extremely basic workflow that would probably be better than both the current situation and a full-forge workflow would be for a contributor to open an account on a forge vetted by Guix at first (Codeberg for instance), then to send a link that work with "git fetch" to review, by email, to the guix-patches mailing list. Then it would be relatively easy for a reviewer to integrate the patches in a mail client with git fetch and git-imap-send and send both the patches and the comments at the same time to the mailing list. I guess that people using Emacs would also find it relatively easy to open a patch with emacsclient -n $(git format-patch -1) or some other way, and copy-paste it in an email for commenting it, and send them verbatim with git-send-email with the right --in-reply-to. The risk here is to have duplicated patches being sent by 2 different reviewers, but not duplicated threads as the contributor would send the first mail, but that issue is probably less problematic than abandoning the mail workflow completely. Also note that patches carry their own git hash, so if people are inclined, they could also find ways to remove duplicates, though even if nobody does that it's probably fine. Another issue is that we'd probably need to tell contributors not to expect reviews within the forge. It could be told inside the Guix manual. And at the end of the day, if contributors don't understand that, it will probably not increase the maintainers work anyway. And the contributors that do understand all that would get their patches reviewed, so for a contributor, it's probably order of magnitude better to have to learn about all that than not to get your patch reviewed at all, especially if people do know how bad it was before (this should be put in the manual as well along with the explanation on the workflow). And if why we don't review patches within a forge needs to be repeated again and again, because contributors complain, then anybody could reply and explain, not just the reviewers, or send a link, or at worse not reply at all to emails like that. Personally I've also been in the contributor situation described above for patches for programs maintained by Debian, where I had to learn to ping the maintainers though a bug report instead of just sending a pull request, and that took a long time to understand, but at the end the patch was reviewed so I was really happy. So basically as a contributor I'd probably do anything it takes as long as it respects my freedom to get things reviewed, even going through a forge, going to nearby events, running special tools, participating in this discussion about the GCD 002, etc. As a maintainer or someone that reviews and accept patches however, I'd expect to be able to be able to use tools that are up to the task or to make my own from well known reusable components, and in the long run to offload work as much as possible on the contributors for seasoned contributors, and to still teach new contributors to some extent, a bit at a time, or to have contributors teach each other (in some events etc). The Linux case == > 2. Because Linux is heavily used by many companies, they have > developed and implemented many tools for CI and all that. Well, it > is not the point; the point is: companies financially
Re: Scaling issues with forges Was: Trying out Codeberg
On Fri, 7 Mar 2025 15:02:57 -0500 Leo Famulari wrote: > And still you can find endless complaints about their onerous > contribution workflow If more people can send patches, it is indeed very good, but the point of these workflow and tools is also to prioritize the efficient of the maintainers over things like the efficiency of new contributors, and so if newer tools require more involvement from maintainers, then requiring them puts the project in a dangerous situation. For instance if you have a tool that checks for common errors, then requiring to run it before sending a patch[1] can be a good idea even if it increase the difficulty to contribute. There was a very old presentation of git by Torvalds for instance, and if you read between the lines, you can deduce that things like SVN were probably easier than git as the maintainers would be the ones that do the work of rebasing contributors patches. However if maintainers burnout that is bad. So one of the point of git was also to move a lot of the burden away from the maintainers to the contributors. References: --- [1]This can be done in the instructions to contribute. Actually enforcing this through technical means is also dangerous as tools can also have bugs. Denis. pgpITFSvARxaB.pgp Description: OpenPGP digital signature
Re: Scaling issues with forges Was: Trying out Codeberg
On Fri, 7 Mar 2025 15:02:57 -0500 Leo Famulari wrote: > One thing about how Linux solved these issues, is that it Linux became > commercially valuable to the point where they pay people to maintain > the code, which includes reviewing contributions. I used Linux as an example because I know it way better than other projects, but we also have Debian that is mainly based on volunteers work and that has some similarities as well: - They use mailing lists, for discussions and bugs - They have their own tooling and/or specific tooling shared with other projects as well - Most of the work is somehow integrated together (in the same apt repositories and/or project) even if it is also split and distributed (not everybody can work on the all the packages if I understand well). - They are also big. And Debian also uses their own forge as well for maintaining individual packages. But I didn't mention Debian in my previous mail because I also don't know it well, so maybe other people that are also Debian contributors or package maintainers could correct me and/or tell us what enables Debian to scale. Denis. pgpKTLEv0Gret.pgp Description: OpenPGP digital signature
Re: Scaling issues with forges Was: Trying out Codeberg
On Mon, 10 Mar 2025 11:37:29 +0100 Simon Tournier wrote: > Yes, this can be fixed with tooling. But that’s the wrong frame for > an answer, IMHO. The question is: who commits in maintaining such > tools? This is a good point. One possibility is that someone write tools and that they are collectively improved step by step by people who use them, like with checkpatch.pl, but that might not always work as I'm unsure how to predict how much work a tool would need. I've no idea if this is relevant or not here but I wrote a tool to check patches like checkpatch.pl for GNU Boot that I attached and note that it has a lot of limitations: - It's made by someone that barely know scheme (me) and that learned about SICP and such design just before writing this code, and I still have a lot to learn, it has code duplication and so on. - Its error handling is not great, but it also comes with some test coverage as I run it on almost all the patches that makes the GNU Boot history, and it has a few specific tests as well. - It tests very few things as it's still extremely new. - The worst part is probably that it's very specific to GNU Boot, and that it's not configurable yet. checkpatch.pl is configurable and while it's maintained within the Linux git, it is also imported in a wide variety of C projects (from u-boot, to anyone who wants to use it, I even used it for a library that I maintained) and for that it needs to be configurable to at least avoid some linux-specific tests. The tool I wrote could easily be adapted to check if a given patch set applies, but I also wonder how relevant such tools is because I've no idea where it should run in the case of Guix, or if rewriting it from scratch for that case make more sense. Your setup is quite optimized and so would you (or anybody else that do review patches) expect code that detects badly formatted patches or patches that don't apply to run on your local machines in a shell?, inside emacs?, inside the QA system (and tag the bug report / patch)?, or in multiple environments? or in all these contexts? Denis. #!/usr/bin/env -S guix repl -- !# ;; Copyright (C) 2024 Denis 'GNUtoo' Carikli ;; ;; This program is free software: you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation, either version 3 of the License, or ;; (at your option) any later version. ;; ;; This program is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; ;; You should have received a copy of the GNU General Public License ;; along with this program. If not, see <https://www.gnu.org/licenses/>. (use-modules (ice-9 popen)) (use-modules (ice-9 rdelim)) (use-modules (ice-9 regex)) (use-modules (srfi srfi-1)) (use-modules (srfi srfi-9)) (use-modules (srfi srfi-19)) (define (startswith str value) (if (> (string-length str) (string-length value)) (string=? (substring str 0 (string-length value)) value) #f)) (define (read-file path func) (define results #f) (let ((port (open-input-file path))) (set! results (func path port)) (close-port port) results)) (define (print-patch-name path) (define dashes (string-append (string-join (make-list (string-length path) "-") "") "\n")) (display dashes) (display (string-append path "\n")) (display dashes)) (define (file-exists-at-commit? commit path) (not (eof-object? (let* ((port (open-pipe* OPEN_READ "git" "ls-tree" commit "--" path)) (str (read-line port))) str ;;;; ;; ; ;; ;; ;; Patch parsing logic ;; ;; ;; ; ;; ;;;; (define-record-type (make-rule name default line-match line end) rule? (name rule-name) ;; Name of the rule (defaultrule-default);; Runs once at the beginning, inconditionally (line-match rule-line-match) ;; Runs each line, returns true/false (line rule-line) ;; Runs if rule-line-match is true (endrule-end)) ;; Runs once at the end, inconditionally (define parse-rules (list ;; Here's an example of a parse r
Re: Scaling issues with forges Was: Trying out Codeberg
On Tue, 11 Mar 2025 02:32:42 +0100 Denis 'GNUtoo' Carikli wrote: > Another issue is that we'd probably need to tell contributors not to > expect reviews within the forge. It could be told inside the Guix > manual. And at the end of the day, if contributors don't understand > that, it will probably not increase the maintainers work anyway. I've looked at that, and the Libre En Communs instance of forgejo doesn't support that, but in another hand it's possible to disable the builtin bug reports for a given git repository and point to an external URL instead. So this might be something that could be implemented for pull requests as well as they can be disabled and both settings are in the same page, so it would also make sense for consistency. Another way to get the information of the review within a common infrastructure would be be to somehow add an URL of the patch review within the patch that will go inside Guix and to build automatic tooling to somehow fetch the relevant discussion and integrate it in the guix patch mailing list (and deploy public-inbox) and/or in a git repository. This could improve the ability to search bugs offline and/or make it easier to integrate in workflows. Though we'd probably loose the ability to search contributions that didn't make it in Guix, and that could be relevant for people that need to be evaluated for commit access, but for the rest, information on what is not yet in Guix is probably not really needed for the maintenance of what made it in Guix. In the later case it also enables to selectively migrate teams to forges, depending on what each team prefer and still have a common place to find the discussions. Both ideas could also be mixed and matched depending on what individual team prefer. Denis. pgpMSofCDgG80.pgp Description: OpenPGP digital signature
Questions about a duplicate package and naming of go/python/etc packages.
Hi, In January 2023 I added the docker-registry package while the go-github-com-docker-distribution package was there since 2018. This is most likely due to the way I named my package: I followed the other distributions (here Trisquel and Parabola) package name. While the way to go is to merge all my changes in the go-github-com-docker-distribution package, once done, people looking for the docker-registry packages won't find it. What is the best way to deal with this issue. Is there something better than mentioning the usual package name in the package description and/or synopsis? If not, what is the canonical way to do it (if everybody does it in the same way, then it becomes grep-able and more easily translatable)? Also, is guix-devel the right place to ask these questions? Denis. pgpYbZWhaDfiD.pgp Description: OpenPGP digital signature
Blog posts for the most important GCDs (like the GCD 002)?
Hi, Given the time some patches take to be merged, we can safely assume that some contributors only contribute occasionally, and a subset of them probably have a long term relationship with the Guix project. I would also guess that some committers probably were in this situation before being committers. In my case I didn't read the mailing list that often (I often do that in batches), and so I found out quite recently about all that. Because of that, and given the amount of disruption of the GCD 002 if it passes (it will probably change the demographics of Guix contributors at least to some extent by making it unpractical for some people to contribute, while at the same time making it easier for other people to join) I think it would be a good idea to at least make a blog post about it and inform as many current or potential contributors as possible about the change proposal. Also, that could be out of scope here, but given the length of the threads, and the importance of the change, it could be a good idea (or not) to somehow summarize the various arguments not to have to repeat them and to enable more people to join in the discussion. I'm thinking of something like wikidebates ( https://en.wikidebates.org or https://fr.wikidebates.org ) where different positions are summarized. Since Guix has a wiki ( https://libreplanet.org/wiki/Group:Guix ) it could be possible to do that work there. Denis. pgptCxXqhDPuJ.pgp Description: OpenPGP digital signature
Re: Build guix-daemon with Zig
Hi,
On Tue, 13 May 2025 05:21:14 +0800
minung...@gmail.com wrote:
> But why Zig? As for me, Zig shows a possibitily to get rid of current
> toolchain. Even though C is not a bad language (I think C is good
> enough!), nowadays GCC is written in C++ which is a monster. Zig has
> lots of improvements comparing with C but it is still a elegant
> language. Zig can easily call and be call by C/C++, which means I can
> gradually apply Zig in a C/C++ project.
An issue to keep in mind is that there was a lot of work made to be
able to bootstrap the C toolchain from source[1].
So as I understand the current state of things in that area is that for
some architecture like x86_64 you just need a running GNU/Linux system,
guile and also and probably a script to bootstrap everything from
source.
So how could zig fit into that? Could it reduce even more the set of
minimal binaries required? Or would it require a significant amount of
work to keep all the work on bootstrapable builds if the zig language
is being used in the daemon at some point?
Another thing is that zig is known to be able to produce
binaries for recent macOS, and even cross compile them with a fully
free toolchain, and last time I checked, gcc toolchains were not
known to be able to do that but in practice I'm unsure how relevant
something like that would be as porting Guix to macOS always stalled
due to issues related to the absence of glibc for macOS.
But for that use case, it could also be relevant to use zig only for
cross compilation instead of building the guix-daemon with it, to do
something like in the case of mingw (the {i686,x8664}-w64-mingw32
targets of various guix commands like guix build), though I'm unsure if
there is a generic enough way to hook zig into various build systems
(zig cc command line options might not be exactly the same than the ones
provided by GCC, and wrappers do not always work fine (there was a GCD
about it)).
References:
---
[1]https://guix.gnu.org/manual/en/guix.html#Bootstrapping
Denis.
pgpD1iBb_WTBL.pgp
Description: OpenPGP digital signature
Re: Introducing Guixotic, a Guix/Guile worker cooperative
Hi, > Rather, this is a way to allow us to work full-time contributing. The > idea is that paid projects, training, support, etc., will help > improve Guix and Guile for everyone, while also supporting us to do > more of the work we already love to do. As I understand it, there is a lot of potential in Guix for commercial work: - Everything in Guix makes it easy to verify that the result of a work is trustworthy: it's fully free and has a community behind that hopefully reviews contributions, it accepts new packages easily, the machine definition of a VM or a package definition can easily be read by less technical people, even if it was hard to write in the first place. - It is possible to package once and deploy everywhere and the abstractions in Guix allow to take that to the next level if necessary (cross compilation, more VM providers, run on more operating systems through virtualization, etc). For running on other operating systems, Ubuntu/Canonical has a VM system that is called multipass that integrate seamlessly with nonfree operating system terminals, so it might be possible to use that somehow, either with Ubuntu images (apt install guix) or if cloud-init is integrated in Guix at some point to also support nonfree operating systems. It might also just be possible build the 'guix' command for nonfree operating systems and have the daemon run in a VM somehow to be able to increase "the market share" of such cooperative. But as I see it, Guix also has some fragility and limitations that can limit a lot the market share and makes all that harder more complicated to pull off: - Clients need to be aware of Guix somehow and know a bit about it to be confident in using it somehow (instead of "Debian" for instance). Part of the scientific world seems to be aware at least. - There is currently no stable branch of Guix, and some packages might need maintenance, especially since laws/regulations like the CRA. So the question is if organizations are willing to pay for regular maintenance on top of a rolling release somehow. Though to be fair I'm unsure if it's a real issue as Q/A could probably also be improved as here Guix also has a lot of potential. For instance marionette can spawn full blown VMs, so even services can be tested. This could be leveraged to reduce the cost of maintenance hopefully to something acceptable (basically have package that do not break or are fixed rapidly, even with a rolling release models, for paying customers). So you could have a model where you are paid to do packaging and tests that go with it and then rely on a monthly/yearly subscription to run the official test suite and react when the the packages under subscription break. As I understand there are already rules not to break other people's packages in the manual anyway (in the section about sending patches), so we probably have all the building blocks here. - Guix also needs to keep being as friction-less as possible to install and probably improve in this area. Right now there are discussions on getting rid of the Debian package, so if that happens it would have cascading effects that would make 'guix' integration with a lot of things much more difficult, which complicates things a lot for the adoption of Guix for clients inclined to pay for commercial support. Here it would be best to find ways to not only keep the Debian package, but in the long run also manage to fund (maybe through clients) improvements in making Guix also work more easily on Fedora, with just docker pull, making guix pull faster, etc. As I understand (from feedback we got in a Guix monthly even in Paris), this could help the scientific world adopt Guix more which could then potentially bring more clients. Working on a scientific paper would be as simple as 'apt install guix && guix pull (and wait) && guix time-machine --commit=v1.4.0 -- shell -- command'. This looks easier than learning to create a DockerFile for instance. And then Guixotic could probably be contracted to package this or that dependency (either for 1 paper or with maintenance in mind) and/or make sure this important package does not break. Denis. pgpi8BfAsOh3O.pgp Description: OpenPGP digital signature
Informal Guix 1.4.0 branch and security fixes?
Hi, Background: --- If we look at guix packages in various distributions, we have Guix 1.4.0, 1.3.0 and 1.2.0[1]. For 1.3.0 we only have Ubuntu 22.04 and Trisquel 11, and the Trisquel maintainer did a lot of work to update Guix from 1.3.0 to 1.4.0 but this is not published yet as I understand. Debian has both 1.4.0 and 1.2.0 and as I understand, many distributions rely on Debian as the upstream for security fixes. But the Debian package maintainer has the almost impossible task to backport all the security fixes without a community nor help behind[2][3] and as things are going, this will probably lead to the Debian guix package being removed[2][3] with cascading effect for the other distributions. As I understand, this would also make it harder for projects that use Guix and a forge for Q/A, because they typically use another distribution and 'apt install guix' to run tests (guix build -f guix.scm). Personally I also maintain a guix package in Parabola and so I have similar issues than Debian, and as part of GNU Boot, I also depend on Guix from Trisquel and/or PureOS, and in Trisquel the guix package was about to be removed at least in future Trisquel versions but I managed to convince the Trisquel maintainer to keep the guix package if it aligns with Debian. Progress and questions: --- Given the current status I gave a quick and dirty try at "backporting" the patches and so far I have something that compiles and I will try to test it soon[4], but it most likely requires way more work to be something acceptable for distributions as I did it in the quickest way possible by applying all the patches (~50) that touch the daemon between 1.4.0 and the last known security fix. I'm also not sure to find the time to continue working on that. The problem is also that I'm unsure how to collaborate on that. For instance would it be possible to have some 1.4.0 branch where we could send patches? This way it would make it easier for distributions to collaborate, especially the less well known ones (no one will probably look at Parabola for patches). In the case of Debian for instance, some of the patches depend on having a debian/ directory, so it's not ideal for downstreams that are not Debian derivatives. So having some upstream could simplify things, especially if at the end all it takes to get security fixes is to just increment a minor number corresponding to a git tag and rebuild the package. Manual: --- Also I think that the pull request 927[3] that adds information in the manual on how to workaround the slow or lack of security updates from distributions is complementary. Even if we get a 1.4.0 branch and that we do manage to backport fixes correctly, it won't make it easier to update guix 1.3.0 and as I remember seeing some user complain that Ubuntu 22.04 didn't fix the security issues in the Guix 1.3.0 package, but I can't find it anymore. But given the amount of work and that Ubuntu jammy is alone on that, and that there is probably less and less interest in Debian packages due to snap, we probably need to assume that this is the case even if I can't find this web page anymore. In addition backporting patches take time, and given the difficulty of doing that here, having a better way to collaborate doesn't mean that the patches will be backported before the announce of the vulnerabilities and that everybody will publish the packages and the announce and push the patches to the guix master branch at the same time. References: --- [1]https://repology.org/project/guix/versions [2]"I have no idea when or if I will be able to update the Guix package in Debian ... at this point I am leaning towards getting it removed from Debian, though I have put only minimal effort into trying to backport the patches..."[2] [3]https://codeberg.org/guix/guix/pulls/927 [4]https://codeberg.org/GNUtoo/guix-security-fixes.git Denis. pgp6LVrszao0J.pgp Description: OpenPGP digital signature
Re: Informal Guix 1.4.0 branch and security fixes?
On Tue, 8 Jul 2025 21:01:58 +0200 Denis 'GNUtoo' Carikli wrote: > Given the current status I gave a quick and dirty try at "backporting" > the patches and so far I have something that compiles and I will try > to test it soon[4] I had to install slirp4netns and recompile Guix from scratch, but then my quick and dirty "backport" seems to work: > substitute: updating substitutes from > 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating > substitutes from 'https://ci.guix.gnu.org'... 100.0% building path(s) > `/gnu/store/q7zx2204nxc1m8vdq0w4p05y4bp8jra2-check-abstract-socket-hole' > killing process 1754127 Abstract Unix-domain socket hole is CLOSED, > build failed with "while setting up the child process: in phase > waitForSlirpReady: unexpected end-of-file". Now I guess the next step could be to try to reduce the amount of patches and test the previous security vulnerabilities as well. I've code to do that automatically[1], but here too there is room for improvements as this code that comes from the blog posts about security issues probably needs to be integrated in Guix proper somehow. References: --- [1]https://git.sr.ht/~gnutoo/guix-security-tests Denis. pgpstmsB4KE81.pgp Description: OpenPGP digital signature
Re: How (not to) deal with upstreams that have _extremely_ toxic maintainership Was: xlibre X11 server
On Fri, 1 Aug 2025 16:34:22 + spacecadet wrote: > Are you still talking about xlibre? No, nothing in my mail was specific to Xlibre, this is why I changed the subject name. To discuss Xlibre specifically I would need to do more research and try to assess the risk for Guix contributors. Many things can be subjective in that kind of assessments, so I'd prefer looking at the facts myself before joining the discussion on Xlibre specifically (assuming this becomes important and/or that I find the time to do that). Though I found important nevertheless to try to explain what is at stake here more generally, especially because Xlibre isn't the only software that could be affected by this more general problem (I also know another one with potentially similar issues that isn't in Guix and that is famous enough to got an article about it on lwn.net). I also think that it could be easier to separate the discussions on the more general problem and on the specific case of Xlibre. This of course doesn't prevent each discussions to inform each other. For instance if no extremely toxic upstreams exist, all that discussion is pointless. But if there are real issues, and that people are seriously considering packaging software that have such upstream, having some criteria to look at them is something worth discussing. > Most of what you wrote boils down to "what if" the maintainers make > some bad decision or yell at a packager. Not exactly, it's more about finding ways to manage risks for Guix contributors. The Debian documentation that Efraim Flashner pointed to shows that Debian is doing that kind of assessments in some way on a case-by-case basis already and their rationale for doing that makes sense. So I don't think it would be a bad thing to consider doing something like that as well when the health of contributors is at stake. This doesn't mean that we never need to deal with aspects that aren't health related, but these are way easier to deal with as we already have everything we need to do that (we can patch, fork, discuss with upstream, not package because the maintenance is too high, etc). I also can't talk for everybody but for me as long as the contributor experience is okay, I can even contribute to various upstream that have goals that are completely opposed to mine and/or that actively hurt me and other people in other contexts, and I've done that many times with very different upstreams, and these contribution didn't have any negative health effects. These contributions were usually limited to things that a reviewer of a Guix package might ask to contribute upstream (licensing issues, packaging issues) or to things I needed personally or for another project so the cost benefit analysis was good each time. However I would like to avoid being pushed to contribute to projects that try to actively harm some of their contributors when they contribute, and I don't expect that being on my own to try to understand when this is the case will work. And the fact that some people did bring up issues with Xlibre shows that a community response can work here: some people were aware of potential issues and they spoke up. Denis. pgp1VZCiOgo7W.pgp Description: OpenPGP digital signature
How (not to) deal with upstreams that have _extremely_ toxic maintainership Was: xlibre X11 server
On Wed, 02 Jul 2025 15:40:34 +0200 Ludovic Courtès wrote: > > So yeah, spacecadet, if you really want to continue to package it, > > we would add it to Guix, I don't think there's any policy in Guix > > against it (unless their documentation or so is also part of the > > package and includes political messages that promote any kind of > > discrimination). > > This is entirely correct. However, as a project, we have a code of > conduct and generally work to be inclusive, which is apparently the > exact opposite of what this people are doing. > > I think we can’t ignore it or we’d be sending the wrong signal. This is a good point, but many people probably don't understand what it means practically and I'd like to explain that to make sure we don't do the wrong thing here. To do that I'd like to add a trigger warning first because unwrapping what all that means means looking at extremely negative things that are not technical anymore but human issues (which are at the end of this post). The practical consequences and risks that could turn out to be disastrous, depend a lot on how upstream really behaves. For a start, I think that how upstream behaves with regard to contributions is relevant to any downstream in general. For instance if the maintainers take really bad technical decisions, that also affect Guix as a downstream. For instance they could refuse to fix security issues, refuse patches because "ARM is not important", purposely include code that sabotage their software when they detect it is running under Debian, include nonfree software, have bad legal practices, etc. Then all that affect downstream in some way, forcing the downstream projects to take decisions and at least to discuss in some way with the upstream project to hopefully reach some way to make things work for everybody. The example I gave are all real and this has led to discussions inside downstream distributions (especially Debian) and sometimes even to forks if the matter could not be resolved. These discussions also take time and energy from the contributors. Here I didn't verify the allegations against Xlibre, and I'm more concerned about the general issue: basically software with extremely toxic maintainership (more on what it means below, between the trigger warnings). The problem is that that kind of software makes it in Guix, it would push Guix users and contributors to interact with its upstream in some way, to fix this or that issue, especially when it affects Guix (for instance fix a compilation issue with a newer compiler, etc). And if upstream is extremely toxic that could have disastrous consequences for these contributors. And this happened to me multiple times: I contributed to upstream to fix issues I had in Guix, and once I was even very strongly pushed by Guix to do so (with adl-submit) and became (co-)maintainer of the project because of that. And in these cases the maintainers were nice. And we definitely don't want to push contributors to interact with projects that are known to be extremely toxic, so when there are strong allegations like the ones that were reported earlier in this thread, if they are true, the risk of having extremely toxic maintainership is extremely high, especially if there are not safeguards against toxic behavior. And the problem here is that if upstream behave in an extremely toxic way and if a fork is made, it will also push the people who are responsible of the fork to have to interact with upstream, which again raises the same issues. And if the fork is abandoned because upstream is way too toxic, it creates again the same issues. And if people go their own ways (like re-implement the project with extremely toxic maintainership from scratch) instead of simply forking it, the alternative project will needs to be very robust not to push people toward the original project if the alternative fails. So all that are good reasons to stay as far as possible from this mess. /!\ Trigger warning /!\ This is especially the case because I don't see anyway to give guarantees that extremely bad things won't happen. Usually the guarantees are not that great as some maintainers are difficult to work with, while other are really nice, so it depends a lot on the maintainers or how well they feel and the interactions themselves (which depend on the people and on a lot of things). There are also a lot of different opinion and feelings on that. But here we are talking about maintainers specifically discriminating people in very violent ways, during their role as a maintainer, so we probably all agree that this is way too dangerous, and that this is bad, and that it needs to be avoided. I assume we all agree here because the only discussion here was if we could package the software maintained by such people, not if the behavior of these people was justified in some way. And given that I've shown that there is a risk that people contributing to Guix could be exposed to such maintain
Re: xlibre X11 server
Hi, > X.org is not getting developed further, but Xlibre is trying to > update the codebase. I would also like to note that Wayland is still not a drop-in replacement for Xorg, even with a compatibility layer, and it's not necessary a problem either as long as people can choose. For instance I somewhat recently switched from sway to i3 because I can see 1080p videos with VLC on a ThinkPad X200 but I'm limited to 480p on Wayland with VLC (and maybe 720p with mplayer but some 1080p videos are too slow to be played). I suspect it has something to do with the xv video resizing acceleration that is missing on Wayland. Not so long ago there was also a huge gap with graphical tablets on Wayland[1], though over time this has more probability of getting fixed than the lack of XV. These are the two thing on the top of my head but I guess there are more and people are probably working to address some of these gaps as well. References: --- [1]https://www.davidrevoy.com/article1030/debian-12-kde-plasma-2024-install-guide#1-wayland Denis. pgp1u1EYMgUzw.pgp Description: OpenPGP digital signature
