Using Guix for hardware development
Since the version included in Debian is too old, I am using kicad packaged via guix on my Talos II. This seems to work well, except that OpenGL is using software rendering. I was able to open my old design of my lighthouse project. Next I will try to get OpenGL and Vulkan working with my GPU. The hardware I am designing will meet the criteria for Respects Your Freedom (RYF) certification, I am going to use an iCE40 FPGA and RP2040 which are known to have libre toolchains and plan to package libsurvive on guix soon. Alex (they/them)
Re: Using Guix for hardware development
Hi, On 2024-06-05 18:51, Tobias Alexandra Platen wrote: Since the version included in Debian is too old, I am using kicad packaged via guix on my Talos II. This seems to work well, except that OpenGL is using software rendering. I was able to open my old design of my lighthouse project. Next I will try to get OpenGL and Vulkan working with my GPU. The hardware I am designing will meet the criteria for Respects Your Freedom (RYF) certification, I am going to use an iCE40 FPGA and RP2040 which are known to have libre toolchains and plan to package libsurvive on guix soon. Alex (they/them) I'm interested on following your process here. In Guix I found some issues with RP2040 because the toolchain doesn't work in Guix out of the box... Some #include_next issue. If you search the mailing list, I reported this message before and I plan to work a little bit on that in the future, once I'm done with the projects I have open right now. Hope you find a good workaround soon. Also there are some emails in the list that claim to have a fix for it, and I know that it worked, but I didn't test myself. Best of the luck, feel free to ping me with your research or share a blog or something where I can follow your progress. Best, Ekaitz
Re: 02/02: gnu: linux-libre: Update to 6.9.
On Tue, Jun 04, 2024 at 08:41:47AM +0200, Ludovic Courtès wrote: > It seems that it broke ‘x86-energy-perf-policy’ and ‘zfs-auto-snapshot’: > > https://ci.guix.gnu.org/eval/1374635?status=newly-failed Aha, a new feature in the CI web interface! Wonderful! The failure of 'x86-energy-perf-policy' appears to be spurious, caused by the builder running out of memory, which happens often on our i686-linux build environment on ci.guix.gnu.org: -- xz: (stdin): Cannot allocate memory -- https://ci.guix.gnu.org/build/4794093/details But the failure of 'zfs-auto-snapshot' is real: -- checking whether bdev_open_by_path() exists... configure: error: *** None of the expected "blkdev_get_by_path()" interfaces were detected. *** This may be because your kernel version is newer than what is *** supported, or you are using a patched custom kernel with *** incompatible modifications. *** *** ZFS Version: zfs-2.2.3-1 *** Compatible Kernels: 3.10 - 6.7 error: in phase 'really-configure': uncaught exception: -- As menitoned in the error message, this package does not support kernels newer than 6.7. And, development appears to be suspended: https://github.com/zfsonlinux/zfs-auto-snapshot/issues/117
Re: Come speak at the Guix Social meetup
Hello! I can give an online talk about Guile-SSH[1] as it is used by GNU Guix, if you're interested. Although I have never done any talks in English, I think it'll be an interesting experience. References: 1. https://github.com/artyom-poptsov/guile-ssh -- Artyom "avp" Poptsov Home page: https://memory-heap.org/~avp/ CADR Hackerspace co-founder: https://cadrspace.ru/ GPG: D0C2 EAC1 3310 822D 98DE B57C E9C5 A2D9 0898 A02F signature.asc Description: PGP signature
Re: 02/02: gnu: linux-libre: Update to 6.9.
Hi, On Wednesday, June 5th, 2024 at 11:27 AM, Leo Famulari wrote: > > > On Tue, Jun 04, 2024 at 08:41:47AM +0200, Ludovic Courtès wrote: > > > It seems that it broke ‘x86-energy-perf-policy’ and ‘zfs-auto-snapshot’: > > > > https://ci.guix.gnu.org/eval/1374635?status=newly-failed > > > Aha, a new feature in the CI web interface! Wonderful! > > The failure of 'x86-energy-perf-policy' appears to be spurious, caused by > the builder running out of memory, which happens often on our i686-linux > build environment on ci.guix.gnu.org: > > -- > xz: (stdin): Cannot allocate memory > -- > https://ci.guix.gnu.org/build/4794093/details > > But the failure of 'zfs-auto-snapshot' is real: > > -- > checking whether bdev_open_by_path() exists... configure: error: > *** None of the expected "blkdev_get_by_path()" interfaces were detected. > *** This may be because your kernel version is newer than what is > *** supported, or you are using a patched custom kernel with > *** incompatible modifications. > *** > *** ZFS Version: zfs-2.2.3-1 > *** Compatible Kernels: 3.10 - 6.7 > > error: in phase 'really-configure': uncaught exception: > -- > > As menitoned in the error message, this package does not support kernels > newer than 6.7. And, development appears to be suspended: As a ZFS user, I'd like to offer a bit of clarification: zfs-auto-snapshot doesn't depend on any specific kernel versions, but zfs itself does. For example, zfs 2.2.3 supports up to kernel 6.7, and zfs 2.2.4 supports up to kernel 6.8 (ref: https://github.com/openzfs/zfs/releases). I suspect zfs is failing to build with the default kernel as a dependency of zfs-auto-snapshot. Cheers, Kaelyn P.S. If there is interest, I can see about submitting my custom ZFS packages. I split it so that the "zfs" package is just the user-space tools without the kernel module (which should also make it substitutable since it no longer includes binaries with combined GPL and CDDL code), and created a function "make-zfs-for-kernel" that generates a package containing just the kernel modules, built for the given kernel package. This also addresses the issue of the zfs package depending on a kernel package that may or may not be needed (and which it may not compile against), and the user having to create a custom non-substitutable version--including all of the user-space tools--for the specific kernel they are running. > > https://github.com/zfsonlinux/zfs-auto-snapshot/issues/117
