IRC channel logs


back to list of logs

<cow_2001>what does "some outputs of `/gnu/store/....drv` are not valid, so checking is not possible" mean? i get it when i `guix build --check -L . r7rs-small-texinfo` in
<peanuts>"kakafarm/guix-kakafarm-channel: Kaka Farm's GNU Guix channel. -"
<cow_2001>relevant code in
<peanuts>"guix-kakafarm-channel/kakafarm/packages/texinfo-documents.scm at master - kakafarm/guix-kakafarm-channel -"
<dodoyada>I tried installing using my system config but how do I validate that it's working? I thought it's supposed to create /sys/class/power_supply/BAT0/charge_control_start_threshold but it's not there
<peanuts>"librem-ec-acpi-linux-module 0.9.2 ? Packages ? GNU Guix"
<efraim> getting close on the rust-team merge!
<efraim>berlin offload machine .161 isn't offloading to the childhurd correctly :/
<efraim>huh, the symlink from /etc/guix/machines.scm points to a file that no longer exists
<adanska>Hi Guix!
<nckx>sneek: later tell dodoyada You'd check with 'lsmod | grep librem'. Also, define 'installing', since I can think of at least two ways, of which I'd expect only one to have any effect (kernel-loadable-modules).
<sneek>Got it.
<efraim>civodul: I'm looking at the guile-git test failure on powerpc-linux and I'm wondering if it's related to one of the set! functions which have been giving me problems on powerpc-linux for a while
<civodul>hey ho!
<civodul>efraim: set! functions?
<efraim>I need to look deeper to see if hashq-set! and other *-set! functions error on powerpc-linux, but for example is where set! fails on powerpc
<peanuts>"[PATCH] build/go: Don't use set!"
<civodul>at first sight i don’t see how this could be related
<efraim>I used display and tested against x86_64 first, (blob-content blob) doesn't return anything on powerpc-linux
<efraim>just got the test suite back
<efraim>#vu8(72 195 169 108 108 111 32 87 111 114 108 100 10)
<efraim>I'll bring it to the bug report
<ayatsfer>is gnu/packages/crates-io.scm manually maintained or is there any automation to include new crates?
<ayatsfer>(good morning 🙂)
<efraim>there is automation for importing new packages and some for updating them, but its generally manually maintained
<ayatsfer>ah, and which is the automation for importing?
<ayatsfer>on my way to add zellij
<efraim>mostly `guix import crate foo`
<efraim>although we're about to merge the rust-team branch, so we'll have a bunch of new and updated pacakges soon
<ayatsfer>I need to find some example for a crate with a workspace with multiple members...
<civodul>BTW, ‘guix import’ has a new ‘--insert’ option that may be helpful in managing things like ‘crates-io.scm’
<civodul>apteryx, janneke: just mailed you a proposal to turn into a blog post
<mrvdb>What do I need to do in emacs to get 'C-c C-d d' (doc symbol at point) to work? Just set geiser-load-path is not sufficient apparently.
<mrvdb>for guix symbols obviously
<ayatsfer>$ make && ./pre-inst-env guix import --insert crate spinning
<ayatsfer>guix import: error: spinning: invalid importer
<ayatsfer>am I using --insert wrong?
<rekado>ayatsfer: no, you're using "guix import" wrong :)
<rekado>it expects the importer's name as its first argument
<rekado>e.g."guix import cran" for the CRAN package importer
<rekado>this is then followed by importer-specific arguments
<ayatsfer>so --insert is not available for crate?
<hako>ayatsfer: `--insert FILE`
<ayatsfer>so how would it look like?
<hako>guix import --insert example.scm crate ...
<efraim>I'm going to assume that git_blob_rawsize in libgit2 itself works fine on powerpc, but I might have to write something to check that. If so that would leave the FFI for that function
<efraim>I probably should check it then, since the other functions seem to work fine. I would've assumed the testsuite for libgit2 would've found something
<rekado>ayatsfer: oops, sorry for confusing you with my response.
<jpoiret>mrvdb: guile variables don't have source location attached to them unfotunately, only procedures
<mrvdb>jpoiret: ah, thanks
<Kabouik>Do we have an alternative to Barrier/Synergy for Wayland in our packages?
<reyman>hi !
<reyman>I finally found some information about nfs-service-type, but i don't know where i need to create the mountpoint (ex "/srv/myserver") needed by mount.nfs in my config.
<reyman>when i restart nfs i have : [exportfs] exportfs: Failed to stat /srv/myserver: No such file or directory
<jpoiret>reyman: /srv/myserver/ doesn't exist on your system I presume?
<reyman>yes @jpoiret
<reyman>jpoiret: i need to create it at startup as a bind mount ?
<jpoiret>then you'll need to create it. It's the same for all filesystems on guix, we don't create the mountpoints automatically iirc
<reyman>jpoiret: but is it possible to create a mountpoint without filesystem attached = ?
<peanuts>"Setting up a bind mount (GNU Guix Cookbook)"
<reyman>that's not clear in the doc because "file-system" need a "device" argument. My mountpoint is not linked to any source, this is only a folder.
<efraim>is the parent directory there? would it be enough to have /srv?
<reyman>yes /srv is ok
<reyman>perhaps i need to mount /srv as bindmount for ext4 , because my server disk accessible on nfs are ext4
<reyman>hum finally i will simply mount remote nfs on a folder in my home/, this is more secure, i don't want to crash system using bad options in "(file-systems ... " part
<nutcase>Hi guix, I created a personal channel. It contains a .guix-authorizations file with the fingerprint of my gpg key I used to sign all commits and which is contained as .key file in the keyring branch of the channels repository. For channel introduction, I use the commit/gpg-fingerprint I used to commit the .guix-authorizations and gpg-sign that commit. If I run guix git authentication commit/signer combination on a later commit, guix
<nutcase>complains that the younger commits have a sha1 signature, which is not permitted.
<nutcase>what should I check to find out, what's going wrong?
<nutcase>when I introduce my channel with the latest commit ID, guix considers the repo / commit as authenticated. It seems that the authentication chain is not traversed down to the .guix-authoriations introducing commit.
<reyman>ok i understand my problem, i'm silly, nfs-service is the server part, to export a folder as NFS ... what i need is more automount fs or something like that
<reedm>Can someone explain how diskk uuids work for the guix filesystem configuration? currently i have my boot drive set up with uuids (as configured by the installer). I also have a second drive that I've just identified as /dev/sdb. It mounts fine and works as expected, but nothing shows up for it when I run blkid.
<peanuts>"debian Pastezone"
<reedm>is it possible if i add a third drive, that the assignments of /dev/sdb, /dev/sdc, etc... could get mixed up?
<efraim>I use `lsblk -fs` to find the UUID/label
<efraim>and yes, it's possible they might come up in a different order
<reedm>that also yields nothing for /dev/sdb:
<peanuts>"debian Pastezone"
<efraim>it's the whole drive? No partition table for the filesystem to sit on? I know that's possible but I'm not sure what to suggest for that
<reedm>ahh, is that not a recommended configuration? I'm quite new to anything filesystem-related
<reedm>I dont have any data on the drive yet, so if theres a better way, I am happy to partition/format now
<ekaitz>efraim: this is what we talked yesterday btw:
<peanuts>"cross-gcc-toolchain for riscv64 doesn't search crt1.o properly"
<ekaitz>it's like crt1.o is added to the compiler as is, not with the absolute path
<ekaitz>peanuts: botsnack
<peanuts>ekaitz: Hi, for comments please contact my maintainers at
<ekaitz>we can't thank the bot
<ekaitz>ACTION sad
<efraim>reedm: sorry, I wander off regularly. I normally use gparted (GUI) or cfdisk (terminal UI) to add partitions to a disk and then use mkfs to add the filesystem
<apteryx>jpoiret: ping me when you're about to merge the guile/gcrypt thing to core-updates; I'll use this rebuild opportunity to merge and
<peanuts>"[PATCH core-updates] gnu: ld-wrapper: Also unset GUILE_LOAD_PATH."
<peanuts>"[PATCH core-updates] Replace pkg-config with pkgconf to reduce propagation / Inkscape updates"
<umanwizard>Hi, I sent two mails to guix-patches today and I have not received a confirmation. Can someone please check if there are issues? I am using `git send-email` for the first time, so maybe the issue is on my end and it is somehow configured wrong. But I _think_ it should have worked.
<umanwizard>The patches are against the rust-team branch. The first mail should have the subject: [PATCH 1/2] gnu: Add rust-1.76.
<umanwizard>I am not an expert guix contributor so please let me know if I'm doing something wrong.
<apteryx>umanwizard: I also sometimes don't receive confirmation, but they appear on usually just fine
<apteryx>did you check?
<apteryx>cbaines: happy to see providing feedback again, with improvements! thank you.
<peanuts>"Patches Guix Quality Assurance"
<umanwizard>The messages appear now, but for some reason they got assigned to different bugs (#69407 and #69408) despite being in the same patch series and being sent with one `git send-email` command ... how can I prevent this in the future?
<peanuts>"[PATCH 2/2] gnu: update public rust to 1.76."
<peanuts>"[PATCH 1/2] gnu: Add rust-1.76."
<podiki>umanwizard: see the bit about multiple patches
<peanuts>"Sending a Patch Series (GNU Guix Reference Manual)"
<euouae>jpoiret: FYI kexec works fine and microcode is not an issue AFAIK unless guix does something special that I'm not aware of
<euouae>but there's that systemd-related patch about booting into FDE <> so I'm going to stop with my kexec/FDE investigations for now
<peanuts>"[PATCH 0/2] Support root encryption and secure boot."
<attila_lendvai>anyone up for pushing this?
<peanuts>"[PATCH] guix: pull: Also print the name of the branch."
<attila_lendvai>it's been waiting there for ages. i have rebased it just now.
<umanwizard>podiki: thank you. Not sure how I missed that before.
<podiki>umanwizard: welcome. make sure you are always looking at the latest/"devel" manual, could be it wasn't in the older version (1.4.0; confusing but consider that just the installer version)
<umanwizard>makes sense.
<lilyp>We should make debbugs recognize kthxbye
<podiki>lilyp: how is gnome-team looking?
<lilyp>you ought to see the mail soon
<podiki>i was updating a package locally and saw that i updated libhandy which was done on gnome-team already, so i figured i'd wait
<podiki>(gtk-layer-shell and swaynotificationcenter)
<reyman>i have a strange behavior with guix system compilation, at the install bootloader step, the process enter a wait loop and nothing happen
<reyman>i try with more verbose compilation
<reedm>is there a guix-y way to set owner/group permissions for a directory in the config.scm file?
<sham1>Maybe a service to set the permissions, but I honestly couldn't tell you