IRC channel logs

<mlxdy>It looks like problem with sudo is fixed.

<stephen0>switchy solved the polkit/network manager issue and shared a snippet, perhaps they could be persuaded to share again

<loquatdev>I'm working on a Guix image record to boot on a Raspberry Pi. Since the RPi firmware can boot the Linux kernel directly, is there a way I can specify no bootloader in the operating-system record?

<loquatdev>I haven't really worked with Guix images before so this is new to me.

<loquatdev>Basically I want to put the kernel, initramfs and some RPi specific files in the first partition and the store and userspace stuff in the second. Perhaps I should define my own bootloader object?

<ieure>loquatdev, There's an example operating-system you can start from in gnu/system/examples/raspberry-pi-64.tmpl

<ieure>I've been trying off and on to make a bootable image for my raspi, but I haven't been able to, there's either a system-image bug or I'm using it wrong. And I don't think I'm using it wrong.

<yaircul>GNU Guix is buggy :-(

<identity>patches welcome

<identity>or, at least, bug reports

<bdunahu>patches unwelcome for bug admirers

<apteryx>jlicht: I was wondering how are cycles typically handled for the npm-binary-importer?

<apteryx>do you create some bootstrap variant, the usual fixup in Guix?

<jlicht>apteryx: they are not, as of yet.

<apteryx>ah yes, I mean if you encounter them after an import and want to fix it up; is there some common idiom you use?

<jlicht>if you need that, I think the path of least resistance is adapting it to be a "lockfile importer" that uses npm to download deps and construct the 'correct' node_modules structure, so effectively you'd build packages with all their deps bundled, but AFAIK that hasn't really been done yet

<jlicht>it would depend on the situation indeed :). Creating -bootstrap variants (perhaps by patching sources to disable functionality) could help, depending on circunstances

<apteryx>I see, so it could become similar to what we do with Rust crates

<apteryx>(if adapted to become a lockfile importer)

<apteryx>thanks

<apteryx>one annoyance is that npm-binary-importer imports e.g. node-picocolors-1.1.1 while there is already a node-picocolors variable

<apteryx>either it should be adapted to look for a non-version suffixed variable name, or we should leave the versions in the variables

<apteryx>is semantic versioning common in the node community?

<apteryx>on guix lint: guix/ui.scm:1030:18: In procedure #f: unspecified zlib error

<apteryx>perhaps they changed their compressor

<efraim>I just got the same error

<efraim>I've rebuilt rust-alsa-sys-0.3.1 to generate the alsa-lib bindings but our version of bindgen is too new (by several years...) so now it's causing build failures

<civodul>Hello Guix!

<civodul>rekado: are you on the pasta thing?

<civodul>too early for lunch

<apteryx>ACTION was trying to package a node thing (webpack) to see the state of the world

<apteryx>So far I'm packaging tens of what looks like source crates. It feels silly like in the old Rust days.

<trev>it is discouraging to package rust programs...and i like rust

<minall>Hello guix Community!

<minall>Is it possible to have a virtualized version of Guix that I could have on demand, with a specific version of a package?

<minall>I'm reading about it, software heritage, guix time-machine and other things and I want to be able to use guix in order to have an environment of a service like nginx but in a specific version.

<identity>minall: not sure what «virtualized» would mean in this context, but you definitely can use time-machine to get a specific version of Guix (with package definitions), so you can get any version (that was sometime packaged) of a piece of software in the repository

<minall>identity: Would I have to search manually the specific version of Guix that has the version of this package?

<minall>Or is there a simpler way to see it?

<minall>Oh, using guix show may help me

<minall>(Reading about it rn)

<identity>minall: for some meaning of manually, yes

<identity>chances are, you can use git blame

<minall>Oh, git blame in the file where it is, and see when the version was updated

<minall>That's clever

<csantosb>civodul: pasta thing sent, science is broken (channel, I mean)

<yelninei>what needs to be running on the server to have x forwarding work? I get "X connection to xxx:10.0 broken"

<stephen2>Anyone have an example of modify-services that performs multiple modifications to %desktop-services?Do I just (modify-services (modify-service %desktop-services ...) ...)?

<stephen2>s/modify-service\>/modify-services/

<yelninei>(modify-services %deesktop-services (a-service-type ...) (b-service-type ...) (c-service-type ...) ...)

<iyzsong>stephen2: no, just list multiple service type modifications in (modify-services %desktop-services (service-type-mod1 ...) (service-type-mod2 ...) ...)

<stephen2>thanks!

<civodul>csantosb: thanks for https://codeberg.org/guix-science/guix-science/pulls/704 !

<graywolf>Hi :) If anyone from golang team is here, I have a question. Is not having a phase to set //go:debug intentional decision or an oversight? I have made one in my channel ( https://git.wolfsden.cz/wolfsden/tree/wolfsden/packages/golang-apps.scm#n68 ) and not sure whether to try to upstream it.

<graywolf>(back story here is that I had golang software that was panicking when build using go-build-system, and the phase was the fix)

<mlxdy>Do I have to put screen-locker-service-type in system guix config?

<identity>mlxdy: depends, i think. some screen lockers may work without that, notably *not* swaylock

<stephen2>I had to put swaylock into the system config, couldn't unlock the user session without it

<stephen2>Both the packages section and the screen-locker-service-type

<identity>stephen2: not sure if you need to do both, but if you need to install it separately from the service, it probably should be installed for your user, not system-wide

<stephen2>I'll have to experiment with it and see.

<mlxdy>I'm more asking if I can put this in my home services.

<mlxdy>I don't know too much about guix

<identity>mlxdy: no, screen-locker-service goes into system services. home services are usually prefixed with ‹home-›, e.g. ‹home-dicod-service-type›

<mlxdy>Okay, thank you.

<mlxdy>Right now I'm thinking about managing my guix config for multi devices

<mlxdy>I think that I'll make directory for every device and split my currrent config into modules. So most of the stuff which will be the same I will be bringing from modules and exclusive stuff in directory for device.

<ste5e>Yeah that's what I do for most of my hardware. I have commonalities as shared code distributed across device profiles.

<argp>o/

<argp>I'm preparing a PR for Golang security fixes (1.26.4, 1.25.11). While checking the dependents, restic is failing to build. But it seems to be failing on existing Go 1.25.11 as well. How should I handle this?

<ieure>argp, If it was already failing, I'd either a) do nothing b) fix the build in a different PR.

<argp>ieure: Then should I just mention that in my PR?

<ieure>Sure.

<argp>Got it, thanks

<ieure>Restic seems to be building on commit 795cf96a19fd82de990e735d240b29a9d0e9d886 for me, that's from 5/31.

<argp>My checkout might be older, let me try pulling new changes.

<argp>ieure: Did you by any chance built without checks (if that's possible)? The failure is in checks

<ieure>argp, I just ran `guix build restic' and got a substitute.

<argp>Ah the substitute works for me as well. Its failing with --no-substitutes

<ieure>That should never happen. :)

<argp>The checks might have some dependency, haven't looked at the cause yet.

<ieure>Really wish there was a flag that told Guix "use substitutes for everything but the leaf package I'm building."

<argp>Right, bootstrapping entire toolchain for the leaf package is annoying

<ieure>As `guix build --no-substitutes restic' wants to compile gcc, six versions of Go, and a bajillion dependencies.

<argp>I'm trying to upload the logs in pastebin but so far two of them rejected

<yelninei>ieure: guix build -D to build all dependencies

<ieure>yelninei, Thank you.

<argp>yelninei: ah nice

<argp>These are the failing tests for me: https://paste.debian.net/hidden/9cd14600

<ieure>argp, Builds cleanly for me on the mentioned commit.

<argp>ieure: Thanks for checking I'm not sure what is wrong

<argp>I see the test complains about: lchown /tmp/guix-build-restic-0.18.1.drv-0/restic-test-2512755251/restore/restic.src/01: invalid argument

<eikcaz>In the manual "9.1.4 Debugging Build Failures", it has you run "guix shell ...". However, I'd like to debug a build built with --target=aarch64-linux-gnu. When I shell in and run make, it fails to find the cross-compilation toolchain. guix shell does not seem to have an equivalent --target command.

<eikcaz>Anyone have tips with debugging cross-compilation failures?

<yelninei>source the environment in the the failed build. It has all the paths etc set up correctly

<eikcaz>hmm. I suppose if I omit the -C, that might work

<yelninei>the problem is that guix shell unions the environment and for cross shells it is important to not mix the build and host libraries

<eikcaz>Omitting the -C in "guix shell" makes it work.

<eikcaz>I was already sourcing environment-variables, those binaries just weren't accessable in the container

<ieure>We should make `guix shell --virtual-machine' that runs stuff in qemu.

<graywolf>When running bash from pack, should I first source the profile, than run bash or other way around?

<eikcaz>ieure: that would be useful for debugging --system=aarch64-linux, but for --target=aarch64-linux-gnu, every binary that runs is still x86_64, so really shell just needs to respect --target in conjunction with -D to pull in the right dependencies

<eikcaz>graywolf: That's an interesting question. I feel like the answer is both

<graywolf>eikcaz: though that duplicates all entries in the environment variables; that should do no harm, but looks bit... ugly

<eikcaz>sourcing the profile configures your shell to work with binaries in the pack. Though bash will likely just work regardless, it is safest to source the profile before running it since it's in the pack. And actually, those variables should be propagated to the nested shell, so I change my answer: source before

<eikcaz>(and since bash is simple, you can probably source after and it's fine)

<graywolf>Right, makes sense, thanks :)

<argp>Not sure what's the fix, I tried adding chown capability in apparmour but didn't help. Created the PR with the errors in description for now.

<loquatdev>I'm having a little trouble using the image record for the first time. When I place an operating-system record in the operating-system field, I get an invalid type specifier error. Looking into some of the examples, it seems like I should be creating an image-type first, but why that's the case is not exactly clear to me.

<loquatdev>I'm trying to create a portable image with some additional files included in the first partition. Could someone point me in the right direction?

<ieure>loquatdev, Can you paste your image configuration? You do not have to define a new image-type, and placing an operating-system record in the operating-system field is correct. The most likely error is that your paren nesting is incorrect.

<loquatdev>Probably. I'll double-check before pasting.

<loquatdev> https://paste.debian.net/hidden/1bbbcd09

<loquatdev>No mismatch as far as I can tell. Just running `guix system image steve.scm` (steve stands for something, haha)

<loquatdev>Error is this:

<loquatdev>`steve.scm:43:2: error: %steve-os: invalid field specifier`

<ieure>loquatdev, The error is *abysmal*, your immediate problem is missing imports, you need (gnu image) for the (image) record constructor, and (guix platforms arm) for aarch64-linux. There are other issues (you have to define partitions), but those produce less ridiculous errors.

<ieure>Guix/Guile have so many incidences of just awful error messages, this is one of those

<loquatdev>ieure: Thank you! Sorry, haha. I was trying to quickly prototype a file. Dunno how I missed that.

<loquatdev>Yep, added some more imports and the error is gone.

IRC channel logs

2026-06-04.log