IRC channel logs

2026-06-28.log

back to list of logs

<ieure>EndureAhead, Far as I know, nobody is, but effort in that direction would be very welcome.
<EndureAhead>ieure: I have sent an email to maintainers mail list.
<noxi>codeberg outage or is it me?
<ieure>Seems dead to me.
<RavenJoad>noxi: ieure: Same here. I can ping it. But it's otherwise out for me too.
<RavenJoad>I was just about to ask the same question before I saw other people mention it.
<jlicht> https://social.anoxinon.de/@codebergstatus FYI;
<divya>Yup it's down.
<divya> https://status.codeberg.eu/status/codeberg
<RavenJoad>Thank goodness I pulled right before Codeberg went down. Now I can spend the time building everything!
<jan0t>there is a gnu guix with non free repos activated
<jan0t>pantherX
<jan0t>oh shit, sorry to mention it
<jan0t>I just realize it is against the code of conduct
<jan0t>I am serious, I came here to mention it because was excited and then realized it
<jan0t>because I was trying to install guix on my laptop but had issues with the gpu driver, so it would be a way to use guix without that issu
<GalaxyNova>Codeberg is down again, feels like it is down every time I want to do something on it...
<jan0t>next time you feel like using codeberg
<jan0t>tell here
<jan0t>so we will know when it will be down
<GalaxyNova>xD
<untrusem>hello
<untrusem>as codeberg is down, i think this outages are the indications that we need to self host in the near future
<jlicht>sneek: later tell andreas-e: I was able to run everything via binfmt, but I see several fail tests: https://paste.jlicht.nl/failing-tests-binfmt-aarch64-node.html
<sneek>Okay.
<jlicht>sneek: later teel andreas-e: s/fail/failing. Most important one is the dgram-multicast; that could be a binfmt related failure, so I would love to have some "aarch64-native" build logs to compare
<sneek>Got it.
<jlicht>how do we generally treat packages that have binfmt-related test failures? Disable the test for all architectures?
<efraim>is that a specific PR?
<efraim>I can set it to build on my RPi5 jlicht
<z572>It seems that there is a corrupted file on ci.guix
<z572> https://pulls.ci.guix.gnu.org/eval/1472/log/raw
<z572>fetching path `/gnu/store/g0mxb6rgcsr6fnb10irs55y2hxj2la6w-Python-3.12.12.tar.zst' (empty status)
<untrusem>ohh
<jlicht>efraim: if possible, would be great (javascript-team branch)
<optimal>ACTION help
<optimal>whoops sorry meant to put a slash behind that
<jresich>hi guix, does anyone know what causes 'corrupt input while restoring archive' errors during substitution?
<jresich>is it an upstream (substitute server) error, or something wrong with the local guix?
<jresich>mm, i think it is a problem upstream, `rust-bytes-1.12.0` is messed up
<jresich>no problem building it without substitutes
<RavenJoad>jresich: FWIW, I saw the same thing yesterday.
<noxi>how can I get geiser to recognize guix stuff when looking up doc?
<RavenJoad>Guix, asymptote is still broken with LaTeX documents. I opened an issue about this in #9598 and provided a hack/fix in #9597. I would appreciate thoughts on how to handle this problem more generally in #9598. I am also going to post about this in the mailing list.
<orahcio>Hi, what is the best way to test a patch on system service? Just `sudo ./pre-inst-env guix system reconfigure...`? I think we always came back to previous generation, and use pre-inst-enve with sudo is not a great problem, or not?
<RavenJoad>orahcio: Does the system service already have a set of system tests?
<orahcio>RavenJoad: I think openvpn has no system tests, right?
<RavenJoad>orahcio: You are correct. There are no system tests. You can use `guix system container/vm` to build either a container or a vm of the configuration to test with. That way you do not need to reconfigure your live system to test.
<orahcio>RavenJoad: thanks, I will do it that way
<EndureAhead>Dear Guix experts, how fast Build Scheduling, Resource Allocation and garbage collection is in guix?
<mightysands>Hey, I tried running the guix installer on my raspberry pi, but it says I'm running an unsupported CPU... an armv6l
<mightysands>I was wondering if it's possible to compile a guix binary to work on my cpu ?
<mightysands>I mean... it's a package manager. It has to be possible, right ?
<mightysands>It's just a C program, isn't it ? So I imagine it would be possible, to just specify the target arch to the compiler. ( no ?)
<mightysands>After all I'm just trying to install the package manager, not Guix SD
<RavenJoad>mightysands: Guix is a Guile library, not C. The only part that is C (C++ rather) is the daemon. In theory you can cross-compile for armv6l, but the problem is because Guix builds from source, it needs to know the target system. And I don't think Guix can build packages for armv6l. Someone else can chip in with more information.
<bdunahu>I see https://guix.gnu.org/manual/1.5.0/en/html_node/GNU-Distribution.html
<mightysands>Ah thanks. Even if it doesn't answer all of my questions, your response is helpful and answers some of them RavenJoad. Thanks
<mightysands>I'll try compiling from source and seeing how far I can get/see if I can jerryrig the rest
<mightysands>As of present I see no reason why a package manager written in an interpreted language such as Guile Scheme wouldn't run or be able to compile other programs towards a target arch of armv6l when it essentially would pass options to the Gnu C compiler (As far as C programs go)
<mightysands>( I just specify C programs because in my experience most Linux programs available on package managers seem to be written in C )
<yelninei>How do you get a C compiler that targets your architecture without knowing your architecture
<mightysands>I'm afraid I don't understand your question
<mightysands>given that I just stated my architecture
<mightysands>I clearly know what my architecture is...(?)
<yelninei>How do you get a C compiler targeting armv6 for guix to use when guix does not know about armv6
<mightysands>I'm under the impression that guix has source code which lists arches as variables which it then passes to the compiler... because guix isn't a compiler itself. Ergo I'm under the impression that I can include a variable for armvl6 to at least get some programs able to be packaged on my machine
<mightysands>If my reasoning is illogical in your view, I'd be curious to see how, as I don't want to pursue an endless goose chase. Without any such explanation on your part however, my current knowledge remains limited.
<mightysands>I'm more interested in using guix for organising how I compile programs myself, and less-so about using it for downloading binaries
<mightysands>Of which I'm sure there are none for armv6l given that it's an unsupported arch
<mwette>yelninei: You could modify the guix sources to handle arm6l, I assume. It might be a big job, but don't see why not can't be done. There is the i686-linux little endian 32-bit guix.
<mightysands>Naively perhaps, I was expecting it to be a small-medium job involving simple variables. mwette; Would you mind saying a little more about what could end up making it a rather big job ?
<mwette>Fixing package specifications that don't build due to subtle differences. I'm on aarch64-linux and I run into broken stuff a lot; I guess these are not breaking on x86_64. And I looked at guile; it seems to support 32-bit arm.
<mwette>Maybe getting base guix going would not be bad. You probably have to start to find out.
<yelninei>mightysands: guix packages are completely self contained. You cant use your current C compiler with them, so youd first build a C compiler and other basic tools for armv6 and tell guix abot them
<bdunahu>the entire package distribution is bootstrapped from (I think) a couple hundred byte assembler, so you'd be starting there :D
<mightysands>So when you install the guix package manager, (NOT the distro, but the pakage manager), you never use any C compiler already on the device, but you build your own ? Or one is included in the guix bin ?
<mightysands>Is it possible to use other C compilers ? To tell the guix daemon to use another one it didn't create itself perhaps ?
<Rutherther>the daemon just executes the build scripts you give it, the daemon doesn't decide what C compiler to use, the build script does
<Rutherther>yes, you could technically use a gcc on the system, but you shouldn't really do that as it goes against what guix is for, at that point it's probably better to just use something else
<mightysands>Thanks Rutherther, for answering my question
<Rutherther>guix aims for self contained builds, leading to better reproducibility. So using an external tool goes completely against that
<Rutherther>normally the guix builds execute in a sandbox so the system tools aren't even available, but it could be disabled. Or you could just copy gcc you want to use (along with its libraries) and make up a guix fixed output derivation out of it, that's what you typically do for sources, not for binaries. But it can be done with binaries as well
<mightysands>Thanks. I'll be wanting to work almost exclusively with sources in fact. From what I'd read on guix, it strikes me as a great way to organise a workflow for generating build scripts for a network of machines
<mightysands>it's primarily that which interests me. And the fact that I'm wanting to use it on another machine as the distro and I want to first get my feet wet using the package manager on my current armv6l machine
<mightysands>I've checked and it'll actually be on support hardware then
<mightysands>supported*
<bdunahu>does nix package manager support armv6? Since nix is pretty similar except not caring as much about bootstrappable builds
<mightysands>I considered it but I'd prefer guix because it'd be a great excuse to teach myself guile scheme
<Useless_II>So I'm brand new to Guix and I'm trying to add a package for PI which
<Useless_II>has turned out to be a lot harder than I would have first guessed. In
<Useless_II>any case, I'm trying to implement each dependency piecewise in its own .scm file. When I
<Useless_II>eventually go to push this upstream I think it would probably go in the
<Useless_II>node-xyz package, it looks like that's all just one gigantic file. Is
<Useless_II>this the typical approach? I was hoping to break each dependency into
<Useless_II>its own file and then load them all into a single module somewhere. Is
<yarl>Hello Useless_II, could you be more specific please? Which package? What is PI?
<Useless_II>Pi is a package that's in node, so it has a large dependency tree. It's basically a harness like opencode or something similar to that, I want to run a local AI to automate more rote tasks. Since it's npm based I figured it and all of its dependencies would probably wind up in node-xyz.scm.
<Useless_II>I also am not sure if it should end up in the free or non-free repo, it's MIT licensed but some of the dependencies i'll have to package may not be MIT (I haven't gotten through them all yet)
<Useless_II>You can find it at the website pi.dev or https://github.com/earendil-works/pi
<Rutherther>mightysands: fyi the armv6 compiler builds fine for me, ie guix build --expression='((@ (gnu packages cross-base) cross-gcc) "armv6l-unknown-linux-gnueabihf")'
<acidbong>evening. does Guix provide ready installation tools outside of an installation image, like Nixpkgs does with `nixos-generate-config` and `nixos-install`? is it possible to install Guix System from any distro with Guix on it?
<lilyp>you can run `guix system install` once you have guix
<acidbong>aha, found `init` and `installer` subcommands, i see it now
<acidbong>cheers
<mightysands>Thanks Rutherther. That's mighty reassuring to hear :D