IRC channel logs

<olafes>Inside an operating-system definition I can type `(label (package-full-name (operating-system-kernel this-operating-system))` and it works as indented. On the other hand, `(host-name (package-full-name (operating-system-kernel this-operating-system)))` gives `guix system: error: this-operating-system: cannot be used outside of a record

<olafes>instantiation`. What's going on?

<olafes>Is this a bug?

<Kolev>Anybody know how to set up a headless Sway Wayland desktop on a server running Guix System?

<resu>after much tomfuckery I have managed to get guix home setup with a basic emacs config

<resu>now all I have to do is rewrite my emacs config lol

<johnjaye>resu: you want to borrow mine? i have a minimal config divided into sections. first section just does basic quality of life things to modernize emacs

<unmush>olafes: whether it's considered a bug or not, I don't know, but I can guess what's going on: some field definitions are "thunked" - the field actually holds a procedure transparently generated by the (operating-system ...) form, and invoking the accessor of that field causes the generated procedure to be called. When this happens, the generated procedure is passed the struct that contains it as an argument. This is how it is possible to

<unmush>use immutable records with fields that can refer to the record itself.

<resu>johnjaye: thanks but no I have an old config Ive been meaning to modernize anyway

<resu>something ive been putting off for awhile

<unmush>when a field isn't "thunked" like that (btw the name is because a procedure that takes zero arguments is sometimes called a "thunk"), the value it takes is evaluated purely at record-construction-time, and so it can't reference the record being created because it hasn't been created yet

<unmush>you may also notice something like this in package source fields compared to package input and arguments fields: a module cycle causes problems in the 'source' field but not in the inputs or arguments fields. This is because the source field currently isn't thunked, but the others are.

<Kolev>unmush, I'm just throwing all my configs in a dir and including the static files with Guix Home. 😛

<Kolev>How do I split my (packages ...) into groups? like %openbsd-base-packages etc.

<anemofilia>kolev: You can use `(define package-list (list pkg1 pkg2 ...))`

<anemofilia>And do it to various package groups

<KE0VVT>weechat: Error: cannot create directory "/run/user/1000/weechat"

<KE0VVT>warning: XDG_RUNTIME_DIR doesn't exists,

<anemofilia>KE0VVT: are you using elogind or greetd?

<KE0VVT>anemofilia: IDK, what's the default?

<anemofilia>KEOVVT: If you are using %desktop-services, you are using elogind

<anemofilia>But IDK why it would not create a runtime dir for you

<KE0VVT>anemofilia: Ah. Current system is not using %desktop-services.

<KE0VVT>What package provides `clear`?

<unmush>ncurses

<anemofilia>KEOVVT: So you should add (service elogind-service-type)

<anemofilia>I made me an alias, so I haven't to install ncurses for that

<anemofilia>alias clear="printf \033c"

<singpolyma>alias clear="yes & sleep 0.1; kill $!"

<dajole>Is it normal for `guix system reconfigure` to take hours?

<apteryx>it's probably building everything from source then

<apteryx>if you have substitutes enabled with good coverage, it shouldn't be so long

<apteryx>if you think it's hung up, you can always abort and re-run; you won't loose much

<dajole>Ah, I'll have to double-check substitutions. Thanks!

<hapst3r>Anyone here that can ping me? Trying to set up ERC and there's some things I simply don't understand :D

<vhns>what would be the proper way to get a package's path in Guile? I'm trying to get a package's default configuration file by doing something like (file-append foobar "/etc/foobar.conf")

<jaft_r>vhns: I can't say whether it's the /proper/ way but I've done (with-store store (package-output store <package>)), before, to get the path for a package from the /gnu/store (with the package being built, if it doesn't already exist in the store, of course).

<vhns>I'll try that, thanks

<vhns>jaft_r: this is just for a draft of a package and its service, so for now it should be fine

<jaft_r>🎉; awesome. 'Glad it could help.

<vhns>Has anyone opened a bug regarding u-boot-tools? Their last successful build was at a9abf9a7b30f6801e122cae759df87b44c458773

<vhns>I ask because it's a dep for qemu, so for now I've been pinning to that commit

<kreved>@vhns pretty sure I've seen something

<kreved>vhns:

<futurile>Morning people

<nutcase>good morning

<vhns>Is there a way to get `guix pull` to spit out more verbose output? I tried increasing the verbose and debug levels, but it doesn't change much of anything.

<futurile>vhns: what do you want to see?

<futurile>vhns: there's debug and verbosity

<futurile>vhns: I think debug switches on output from the daemon

<vhns>futurile: I currently made some changes to a private channel and guix pull started failling on it. Using the channel directly through -L CHANNELPATH to generate a system reports no errors. This is all I get from guix pull: `(exception %exception (non-self-quoting 140736932309312 "#<&store-connection-error file: \"/var/guix/daemon-socket/socket\" errno: 2>"))`

<vhns>Never mind

<vhns>I just figured out the error

<vhns>I was using (with-store store(package-ouput store foobar)) as reported before

<vhns>and that broke guix pull

<vhns>bah

<nckx>sneek: later tell olafes: It seems like you were disconnected when your question was answered; see <https://logs.guix.gnu.org/guix/2024-11-16.log#025904>. Also, that answer is correct, see <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system.scm#n230>.

<sneek>Will do.

<divya>Hello

<divya>When defining a package using cargo-build-system, do the libraries that are included in #:cargo-inputs need to be available in guix or can the build-system fetch them from crates.io?

<divya>I believe it can't, but I should confirm.

<divya>Nevermind, I got my answer. I'd use cargo2guix

<luca>afaik no because the guix process runs without internet access

<luca>Try `guix import crate --recursive-dev-dependencies`

<apteryx>hm. the guix-home tests builds guix, which takes ages: building /gnu/store/axvwrzjk6s0n9c2k8qdpydc8vz6s57kd-guix-1.4.0-26.5ab3c4c.drv...

<apteryx>how long does 'time make check TESTS=tests/guix-home.sh' take for you to complete?

<dariqq>apteryx: ~15s

<apteryx>it's building a complete guix derivation for me

<apteryx>perhaps it's been built already on your side

<apteryx>another test which is expensive is the guix-time-machine.sh one; about 6 minutes of git cloning the repo

<apteryx>guix-home.sh log start in my case: https://paste.debian.net/1335713/

<dariqq>wouldnt it be using the test store though? i deleted that and that test adds nothing

<apteryx>I guess all the tests using 'guix' in their command line rely on a current-guix

<apteryx>many tests use the real store

<apteryx>to avoid rebuiling the world when pulling packages as part of their test environment

<apteryx>my explanation doesn't work; some other test using 'guix' command had succeeded before that one

<apteryx>that is, before guix-home.sh

<ehrt74>hello everybody :) i've just booted up my guix vm again for the first time in a while. i updated my user account and deleted lots of old generations, because disk space was short. now i'm running sudo guix system reconfigure and it's downloading lots of stuff again. am i correct in thinking that guix system has one complete package repository for

<ehrt74>each user?

<apteryx>dariqq: real 21m28,917s on a super fast machine

<apteryx>ACTION moves it to the 'slow' tests bucket

<dariqq>apteryx: i guess i had the guix drv already from reconfiguring my real home and system earlier

<apteryx>hm, that would explain it only if there was no substitute for it, no?

<apteryx>perhaps there is no substitute for it

<apteryx>I'll delete the store item and try again

<apteryx>dosen't seem to be any substitute for it; but then I'm on some modified guix checkout

<apteryx>I guess it refers to the 'current-guix' package somehow

<dariqq>also my guix derivation is /gnu/store/i9dblq95b1r51ksdsj7ww93asblb3pyn-guix-1.4.0-26.5ab3c4c.drv and not the one you have (i am on current HEAD~1 or so)

<apteryx>I'm testing on the gnome-team branch

<apteryx>probably a different input in the deep graph

<Rutherther>ehrt74: everything guix builds goes to /gnu/store, it's not different for each user. But the derivations can change if you pull newer guix version. So that's likely what happened to you. Even if the x.y.z versions of packages don't change, if their dependencies do, they are a new derivation that needs to be rebuilt (or substituted)

<ehrt74>Rutherther thanks for the reply :) can you tell me what derivation means here?

<Rutherther>ehrt74: it's the low level representation of packages. The packages are in the end just sets of inputs and outputs, including all their dependencies, a script to build them and stuff like that.

<ehrt74>Rutherther oh, i've just found this: https://guix.gnu.org/manual/en/html_node/Derivations.html. i don't think i'm going to understand that :/

<Rutherther>s/The packages/the derivations

<ehrt74>Rutherther thanks :) i have the feeling that i've missed a couple of beginner classes on guix :( i'll search youtube for a beginners video. i just can't get my head around the difference between running `guix upgrade` as a user and `guix system reconfigure` as root. both seem to pull in lots of software and upgrade lots of packages

<Rutherther>ehrt74: you don't really need to understand it, just note that it consists of the inputs, and script to build. As soon as any of those change in any way, the derivation for package X will be different than what it used to be. So for example, recently there was update of mesa package. Many gui packages depend on mesa. That means a lot of packages needed to be rebuilt after that update, and for you it means paths in your store are no longer outputs of...

<Rutherther>... the "newer" packages. So it needs to get downloaded

<dariqq>ehrt74: it could also be because of grafts if you gc'ed the original packages

<ehrt74>dariqq jep, i gc'ed a lot because i ran out of disk space. i have a 40GB partition and have installed emacs and a couple of emacs-plugins, and 40GB weren't enough to upgrade the system :/

<ehrt74>so i thought that probably has something to do with caching of old states so i went googling :)

<Rutherther>ehrt74: they are not so different. The difference is just what they build. guix upgrade builds ~/.guix-profile for current guix version you have. Whereas guix system reconfigure builds the whole operating system (including all its services like the profile you have in /run/current-system/profile, what goes under /etc, what shepherd services there are and such) + after build it runs activation scripts to activate the newer system

<ehrt74>Rutherther ok, thanks :) so if i only want to update user software, i don't need to run system reconfigure, but if i want to upgrade the kernel, the way to do that is to run system reconfigure?

<Rutherther>ehrt74: basically. But your system is not only kernel, it's also all the packages you put to it, so it can still have other sw you are using as the user. guix upgrade will update packages you installed with guix install, so those you have exclusively installed for your user, yeah

<ehrt74>Rutherther ah, that makes sense. things like the service manager (i think guix uses something called shepard rather than systemd?) aren't in user space, i suppose

<ehrt74>Rutherther so my current way to upgrade the whole kaboodle (sp?) is `guix pull; guix upgrade; sudo guix system reconfigure /etc/config.scm; guix gc --delete-generations=1m; sudo guix system delete-generations=1m; sudo guix gc`. does that look about right?

<ehrt74>oh well. thanks for your help :) i'm going into town to eat a piece of cake :D i'm a bit worried i'm going to bounce off guix again :( i'll just try to keep my vm up to date and watch some youtube videos about it. maybe it will start to make sense to me someday soon :)

<[>I don't think you need to run guix gc as root

<sneek>efraim: Greetings :)

<elevenkb>How do you make GNU TeXmacs use the wayland platform for QT by default?

<efraim>I have QT_QPA_PLATFORM=wayland set in my environment variables

<mwette>I'm updating a guix.scm file someone created for some minimal code I contributed. I need to create a directory for the build. Just guessing: will `(mkdir-p "relative/path")' work ?

<dckc>How do I use python-lxml?

<dckc>I did guix shell python python-lxml

<dckc>but then I get:

<dckc> from lxml import etree # http://codespeak.net/lxml/xpathxslt.html

<dckc>ModuleNotFoundError: No module named 'lxml'

<Rutherther>dckc: are you sure the python you are starting is from the shell environment, with the environment variable GUIX_PYTHONPATH set?

<dckc>oops! I thought I checked that, but now I see...

<dckc>$ type -p python

<dckc> /usr/bin/python

<Rutherther>dckc: there is no python provided by python package, it provides only python3

<Rutherther>dckc: so my guess is that when you use python3 command, it will be fine

<dckc>indeed! progress! thanks.

<dckc>I'm looking at data from a recent visit to my doctor. These CCDA docs are such a pain. I guess I wrote about this before... https://www.madmode.com/2013/the-sorry-state-of-the-art-in-medical-data-portability

<attila_lendvai>is it possible to have a named input when using the new format? (i'd like to have a "source" input instead of the source field of the package record)

<attila_lendvai>search-input-file assumes inputs are directories, but if i add an origin to a zip file, then it's just a zip in the store

<attila_lendvai>i was never satisfied with search-input-file... what if two inputs have a file with the same name? it's just not an aesthetically pleasing solution.

<elevenkb>I'm trying to build a rust app and have an error:

<elevenkb>the package `core-graphics` depends on `core-graphics-types`, with features: `link` but `core-graphics-types` does not have these features.

<philofosser>Test

<philofosser>There we go.

<futurile>elevenkb: I would try grabbing the source and seeing if the cargo build has such a feature, and/or look for some other dependency

<elevenkb>It does, but I think the feature is disabled on crates.io.

<elevenkb>The trouble is that you'd have to link with Cocoa APIs.

<philofosser>Anyone know where I can find a documentation on C-programming on Guix? I'm having a devil of a time getting libraries and header files to load from the store. I'll need documentation for both GCC-toolchain and Clang-toolchain for LLVM-dependent projects.

<philofosser>Environmental variables even look right.

<futurile>ekaitz: can you turn off the need for that it in core-graphics

<futurile>duh

<ekaitz>heh

<futurile>elevenkb: -^

<ekaitz>futurile: i know you are always thinking on me

<ekaitz><3

<futurile>ekaitz: I watched enough of your stream the other day to hear you talking about RISCV stuff I don't understand!

<elevenkb>futurile: maybe I'll have to use an alternative source for the main crate, and turn off the dependency on the "link" feature.

<futurile>ekaitz: in truth I had it in the background

<ekaitz>futurile: OH! i thought nobody was watching, honestly... thanks!

<futurile>elevenkb: that's gonna be difficult, because the crates-io importer can't import from anywhere else (it's a weird constraint)

<elevenkb>alright, I'm going to try removing the dependency on core-graphics by hand.

<futurile>ekaitz: well you used a whiteboard - I'm heartily in favour of anyone who explains things through a diagram (or in my case a finger painting)

<elevenkb>it doesn't show up on cargo tree.

<futurile>elevenkb: yeah, you should find a bunch that snip the dependency tree like that

<futurile>philofosser: I can't really help you, I don't know of any specific information - generally if it's not working in a `guix shell` environment, you'll be setting a lot of LD_PRELOAD* paths etc

<ekaitz>futurile: i always have to draw for everything! :)

<dariqq>philofosser: could you be more specific? basically the search path for headers is attached to the c compiler . so if your c compiler and package with the header are in the same profile (i.e. via guix shell) things should work

<elevenkb>futurile: The trouble is that core-graphics is a dependency when target_os="macos" but not otherwise.

<elevenkb>afaik, that means that I have to include it.

<futurile>elevenkb: are you trying to add a package, or build your own code for use on MacOS?

<elevenkb>I'm trying to add a package.

<elevenkb>specifically: this crate https://github.com/jtroo/kanata

<elevenkb>it's also available on crates.io

<futurile>elevenkb: OK, yeah looks like the recursive import is bringing quite a bit with it

<futurile>elevenkb: can you skip-build some of them maybe

<futurile>elevenkb: it always seems to be this way with Rust, you start trying to do something simple and then like 100 crates later!!

<elevenkb>futurile: Is there some way to choose the features you are building for cargo-build system?

<philofosser>dariqq: I have a guix shell loading clang-toolchain and raylib and its sole dependencies and within the shell I attempt to run: clang myprog.c . The linker, ld, cannot find the functions defined in raylib.h. I tried it with gcc-toolchain instead. No dice.

<philofosser>Sorry about the delay. My IRC locked up when I didn't notice.

<ekaitz>9 hours of GCC-14 compiling for RISCV :)

<ekaitz>still on it

<philofosser>I've attempted to manually add the store paths via command line switches but same output.

<philofosser>ld squawks about undefined references that are clearly defined in the header file.

<futurile>elevenkb: I don't _think_ so, you'll have to look through crates-io similar - I _think_ it's all custom phases at that point

<Rutherther>philofosser: can you show the exact gcc command you executed?

<philofosser>Rutherther: I have attempted

<philofosser>gcc myprog.c

<philofosser>clang myprog.c

<Rutherther>philofosser: you need to add -lraylib then

<philofosser>I have attempted manually adding the store paths with -l

<Rutherther>not store paths, name of library

<Rutherther>-lraylib, exactly, nothing more, to link against raylib

<philofosser>Hm. Well let's see.

<Rutherther>it's already in library paths if you have it in the shell along with gcc-toolchain

<philofosser>Well that gives me different linker errors. Progress.

<philofosser>Oh, I see. I invoked GCC in the wrong guix shell.

<philofosser>Alright, that works. I believe you have solved my problem. Can't believe I was stuck on that even with the info page open, but that just shows how rusty I am. Thanks for everyone's help.

<divya>If a package only is on a git repository and doesn't have a tar.gz or any archived package as a release, how do you get guix to fetch it from git and package it accordingly/

<futurile>divya: you can use git-fetch in the origin, and give it a tag or a specific git commit

<divya>No `file-name`?

<divya>And coincidentally, I was just reading this: https://www.futurile.net/2023/12/05/guix-package-transformations/

<futurile>divya: oh are you trying to do a transformation, or package something new?

<divya>futurile: Indeed, I'm trying to package a screen-recorder written in rust for guix.

<futurile>divya: in a package you can specify a file name that the git repo will be added to the repository as - but you don't have to

<divya>futurile: I followed the blog and did (file-name (git-file-name name version)) :)

<divya>Let's see if it builds

<divya>yay it does

<divya>Steve to the rescue once again, thanks a bunch to your blog

<divya>I've learnt a lot from it!

<futurile>divya: ah nice - that's good - I don't quite understand the whole of the rust build system honestly

<futurile>divya: oh cool - good to hear as I feel like some of those posts have become waaaaaaaaaaaay too long heh heh

<divya>futurile: I'm a sucker for long-form content, keep it up!

<futurile>divya: I honestly try and get them shorter, but somehow I'm just someone who writes 'long' to get it into my head

<futurile>divya: yeah I need to get back to it!

<divya>It's relatable, either I write nothing but when I sit to write I want to write everything about that thing lol

<futurile>divya: cool you got the package working, now you can contribute it!

<futurile>divya: we still have a few weeks before efraim merges rust-team (is my current understanding)

<divya>futurile: indeed, looks like the build was successful and it was installed in the profile through --install-from-file but somehow I didn't get a binary lol. Let me see where it went wrong, I think I'm close.

<divya>futurile: Indeed, I think he said he's on the mailing list he's a bit busy and will do so soon. Btw, do apps based on rust get pushed to rust-team branch first?

<divya>I was also confused whether I should include the declaration in video.scm since there's other screen-recorders there, or should I add it in rust-apps.scm?

<futurile>divya: as Efraim is the only person in the rust-team, I put stuff against rust-team as that's where he works. As rust moves so fast it seems the easiest way to do it.

<futurile>divya: yeah, that seems to be the way - rust-apps

<divya>Okay, understood. Thanks!

<divya>It'll be my second package contribution to guix, pretty happy I'm getting used to the workflow.

<futurile>divya: whoop whoop! :-)

<ekaitz>divya: the second time is easier huh?

<ekaitz>divya: ask anything you need :)

<divya>ekaitz: indeed relatively easier, and god did cargo2guix saved me enough time and confusion :)

<ekaitz>:)

<ekaitz>divya: next time try with something harder until you understand guix's internals very well

<ekaitz>we need more core developers

<divya>ekaitz: Indeed, I'm planning to. I need to undrstand how the different moving parts work, working on it!

<divya>Anything specific you might recommend for a relatively amateur?

<ekaitz>divya: there's a very interesting video about how guix is organized you could watch

<divya>ekaitz: Sure, link me.

<snamellit>ekaitz: I see a RISC-V release is coming, which hardware is supported?

<ekaitz>divya: https://10years.guix.gnu.org/program/#guixy-guile-the-derivation-factory-a-tour-of-the-guix-source-tree

<ekaitz>snamellit: why do you expect me to know? :)

<divya>Thank you, ekaitz

<snamellit>I saw a comment about 14hrs of compiling RISCV

<snamellit>9 hours...

<ekaitz>snamellit: i'm compiling a riscv compiler, yes, and I spent the last 3 years on working on RISC-V stuff for guix, too

<ekaitz>but i have no idea about the riscv release :)

<snamellit>Ow, my apologies, I was a tad overly optimistic.

<ekaitz>I probably should, but ¯\_(ツ)_/¯

<ekaitz>hehe it's ok, i'm just joking

<ekaitz>snamellit: in any case, i've heard something about the visionfive2 yesterday, but it wasn't here so don't trust me

<snamellit>I'll keep my eyes peeled. I have a couple of SBC's waiting for a challenge.

<snamellit>That being said, the visionfive2 is in a pretty good state right now I have the impression.

<ekaitz>snamellit: I've been reading the codebase, we have the visionfive2 image

<ekaitz>look at gnu/system/images/visionfive2.scm

<snamellit>ekaitz: Cool, I definitely will, thanks.

<ekaitz>but it's a barebones image

<snamellit>That is par for the course at the moment.

<ekaitz>i'm using a visionfive with guix but only as a package manager

<snamellit>I like to run my SBC's headless anyway, so that lowers the bar considerably.

<ekaitz>we still don't have releases for RISC-V...

<divya>How can I use the substitute* procedure(macro?) to append something to the end of a file, or can it only substitute something for something else?

<ekaitz>divya: you can write to the file instead...!

<divya>ekaitz: Uh...how, when changing a file through modify-phase?

<ekaitz>yeah, you are just writing scheme code, open the file and write to it

<divya>No no, I'm packaging a rust program and I need to append something to that package's Cargo.toml, how can I open and write?

<ekaitz>exactly what I told you, make a phase that has code that opens the file and appends to it

<ekaitz>phases are just guile code

<ekaitz>you can open a file and write to it