IRC channel logs


back to list of logs

<RavenJoad>Guest96: I think you need to (use-modules (guix)) too?
<Guest96>RavenJoad: That did it!
<Guest96>but the file is empty...
<Guest96>Alright, defined a serializer and it worked!
<Guest96>Thanks all
<RavenJoad>Sure thing!
<Guest96>Now I want to include the field name in the serialization. I tried using the example serializer from the guix manual, and it fails to build the file...
<ZachLiebl>Hello Guix devs. I am interested in being a Google Summer of Code applicant for any of your projects. Is it still worth applying or are you already swamped with applicants?
<graywolf>When I have a package that shows some dependency in the `guix size PKG', how can I figure out *why* is it there?
<graywolf>I am using go-1.20 to *build* the package, but I just do not understand why it is in the `guix size' (those are runtime dependencies, right?).
<graywolf>And second question, do we prefer packages small or complete? I am working on updating podman to 5.0.0, and I can get `podman compose' and `podman machine' to work, but at the cost of doubling the package size (from ~600MB to ~1200MB). I do not think it is worth it, but wonder what the project policy is regarding this.
<Guest96>graywolf: the alternative to beefing the package is to have more package variants. More package variants means more labor required to maintain guix. What percentage of users of podman do you think will use those functions? That is a rhetorical question; the point I'm making is that there probably isn't a "right" answer, and only an avid podmad user (such as maybe you) could give any answer at all
<graywolf>Guest96: well my "solution" is to have in package description sentence in the spirit of "if you want podman-machine to work, install qemu-minimal and openssh into the $PATH".
<Guest96>That sounds better to me
<graywolf>I do not expect `podman machine' to be used much, there is little reason on linux. Probably same for podman compose, people seem to prefer podman play kube these days.
<graywolf>But again, podman-compose package is provided and user just needs to install it in addition.
<graywolf>(podman-compose package brings in whole python runtime :/)
<graywolf>Right, so I will keep it like this (in the description). Thanks for opinion.
<Diagon>Can someone point me to any up-to-date article on installing guix PM without root?
<freakingpenguin>Is there a compact way to run time-machine with a .guix-channel file? Not one like (append (list ...) %default-channels), but the file that turns a repo into a channel.
<freakingpenguin>I want to enter dev environments for a repo that include channel dependencies without needing to also track a channels.scm file that duplicates the channel dependencies specified in .guix-channel.
<freakingpenguin>This is what I mean.
<peanuts>"debian Pastezone"
<freakingpenguin>I guess something like this works but it would be nice if there was a cleaner way to skip channels.scm entirely.
<peanuts>"debian Pastezone"
<hapst3r>When building a package several times (failures) in a row, how do I cache results so that subsequent build processes take less time? Usually, ccache is used for the package at Hand. Does it work as expected in my scenario?
<decfed>graywolf: I thought this is what package outputs are for? Can you not package podman-machine and podman-compose into a separate output each?
<futurile>Morning all
<remyd1>Hi, I am starting a new manifest for "revabyes", and I am stuck with gexp/ungexp and modified phases:
<remyd1>`source expression failed to match any pattern in form (%modify-phases phases* (gexp (add-after (quote unpack) (quote chdir) (lambda _ ...`
<peanuts>"debian Pastezone"
<remyd1>I should have a syntax error with gexp here...
<remyd1>and I don't know if I should do it this way
<remyd1>The compile guide is here:
<peanuts>"RevBayes: Compile on Linux"
<futurile>remyd1: according to my notes you do: #:phases #~(modify-phases %standard-phases (delete 'configure) etc etc - but I'm pretty weak on G-expressions so that might not be the problem
<remyd1>futurile, yes, I think that could work for one single phase, but if you have many with and/or without gexp, where do you gexp/ungexp ?
<futurile>remyd1: hmm don't know - I have multiple phases that I've deleted and I'm adding one new phase - in the one I'm looking at - guess you might have to look at some other packages - maybe your way is right :-)
<remyd1>futurile, Ok; thx anyway... Will keep trying and look at other examples :)
<futurile>remyd1: tell me if you find out more - I really need to learn about gexps / phases a bit more!
<remyd1>futurile, Ok ;)
<thaenz>I got Revbayes to build but I couldn't tell you why it works
<thaenz>Want the code anyways?
<remyd1>thaenz, yes, sure
<remyd1>A friend also gave me a meson version which is building. But cmake version does not
<thaenz>I only got it started to build but it has not finished yet so there could be more problems ahead
<remyd1>thaenz, thanks, that is very helpful anyway
<remyd1>changing to (chdir "projects/cmake") did the trick; building...
<apteryx>remyd1: the whole phases expression needs to be a gexp, so #~(modify-phases ...)
<apteryx>grep the sources for tons of examples
<remyd1>apteryx, Ok thx ! I am quite new on manifest
<remyd1>I did not think I had to learn guile/scheme and guix macros to build packages ;) ^^
<remyd1>I did not need the cmake build system; I need to look at either trivial build system or copy build system
<thaenz>Maybe I'm going about it the wrong way but I'm trying to make a user level shepherd service to start transmission-daemon and I can't figure out why it is complaining about a use-module that I already included
<thaenz> anyone got any ideas?
<thaenz>Or another way of going about it
<jaft>thaenz: I dunno if it'll actually fix anything but, to get MPD working, I have a service that I define with ~(shepherd-service (provision '(mpd)) (start #~(make-system-constructor "mpd")) (stop #~(make-system-destructor "mpd" "--kill")) (documentation "Start the Music Player Daemon"))~; seems similar to your approach but with slight differences.
<thaenz>Thanks but did not work :/ Same error
<remyd1>Hummm. Still trying to build revbayes using different build system. If anyone can find the error here: ...?
<peanuts>"debian Pastezone"
<remyd1>Error is: `(%modify-phases phases* (replace (quote configure) (lambda _ (apply invoke "bash" "")))) : source expression failed to match any pattern`
<thaenz> '(#:tests? #f ; TODO tests pass except FBD and UCLD_noncentered, to desactivate
<thaenz>remyd1: On that line you have placed ' at the wrong place
<remyd1>thaenz, OoooO; nice catch; I need new pair of glasses ^^
<remyd1>...I still have some difficulties with {un,quasi,}quote and obvisouly with gexp/ungexp
<thaenz>Still problems? I had to leave for a bit
<remyd1>No thaenez. Keep trying
<remyd1>Is there a way to use previous cache of builds / work in previous build directory directly with guile and guix modules ??
<remyd1>thaenez I have a working version :)) !!
<graywolf>When I have a package that shows some dependency in the `guix size PKG', how can I figure out *why* is it there?
<graywolf>I am using go-1.20 to *build* the package, but I just do not understand why it is in the `guix size' (those are runtime dependencies, right?).
<bjc>graywolf: yeah, that makes sense to me. i'm not sure why it would behave like that unless some dependent package has it in either native or propagated inputs
<bjc>err, sorry, not native. but the regular inputs. i always get those backwards
<graywolf>bjc: It probably is via some dependent package, but I am not sure how to figure which one :/
<bjc>there's a way to get a graph of those dependencies from ‘guix graph’ i think
<graywolf>I tried guix graph, bu the result is huge, with many more nodes then guix size has lines
<graywolf>Oooh maybe I want -t referers?
<bjc>there's no way to just graph the path between two nodes? i could have sworn there was
<graywolf> - referrers: the DAG of referrers in the store
<bjc>graywolf: i think you can use ‘guix graph --path package-name go’ to see how it got in there
<bjc>that said, i think it's an issue with go itself. i just checked podman, which only includes go (at 1.19, at that) in ‘native-inputs’, and ‘guix size’ shows it being included at v 1.21.5
<bjc>guix path shows it's coming straight from podman
<bjc>graywolf: i think you can use ‘guix graph --path package-name go’ to see how it got in there
<bjc>that said, i think it's an issue with go itself. i just checked podman, which only includes go (at 1.19, at that) in ‘native-inputs’, and ‘guix size’ shows it being included at v 1.21.5
<bjc>guix path shows it's coming straight from podman
<bjc>there's ‘remove-go-references’ in go-build-system.scm, but i'm guessing it's either no longer working or isn't being triggered for some reason
<h3>How to set `ungoogled-chromium`/`icecat` organization policy plug-ins/add-ons in /etc/config.scm? How to know what happened to a patch/bug/commit from Guix mail lists? Like if it was merged somewhere, appeared somewhere, if it was only on that mail exchange? And if it's only on the mails, how to apply them all to have the actual work done to execute it? I try to insert a package into Guix channel to test it with `guix shell` before pushing it but all I get is that the p
<h3>ackage is unkown. How to make it known by Guix?
<graywolf>bjc: Aaaah, that could be it. Podman is build using gnu-build-system
<graywolf>So I will borrow that phase from go-build-system
<graywolf>Thank you very much :)
<bjc>oh man, so it is
<bjc>that explains that. so thank you, too =)
<futurile>Q: why does glib always go into native-inputs, but gtk goes into inputs? (looking at stuff in gtk.scm)
<futurile>It seems almost arbitary which ones people put things into - is there any obvious/easy way to test?
<apteryx>glib's particular output right?
<apteryx>it provided tools to compute some build time schemas or something
<apteryx>looks like the aarch64 machines are idling despite having jobs on berlin?
<apteryx>I have 400 something ARM builds pending on the qt-team branch, yet the machines such as pankow are idle looking at:
<peanuts>"Workers status"
<apteryx>rekado: do we still know to gently encourage them to work from time to time? ^
<apteryx>still need*
<futurile>apteryx: OK - yeah thanks. ATM my mental model is basically 'if it's not a test tool/pkg-config put it in inputs and wait for guix lint to tell me i'm wrong'
<apteryx>you can think of native-inputs as build-inputs if that helps (required at build, without references kept from built products)
<apteryx>e.g. 'make'
<apteryx>anything that will be used at run time should be in inputs, not native-inputs
<apteryx>sudo herd restart cuirass-remote-worker on overdrive1 seems to have helped
<apteryx>I'll try to kick the other ones in the same way
<apteryx>perhaps we need a 'restart worker' button on the workers page?
<apteryx>sneek later tell roptat is lieserl supposed ot be reachable via it's not
<apteryx>efraim: is it possible that your latest u-boot commit broke master?
<efraim>God I hope not
<efraim>I've told it to try again
<vagrantc>how long has that been failing to build ...
<efraim>u-boot? Not sure
<efraim>I think I'll go through and test a couple of other ones
<vagrantc>i definitely tested the build targets when i pushed the previous commit
<efraim>they built fine from x86_64 but failed from aarch64
<vagrantc>oh, that's plausible
<efraim>it turns out guix deploy will build the packages on the target architecture
<vagrantc>i've got a fairly powerful aarch64 that i can try building all the targets on...
<vagrantc>although guix pull takes surprisingly long...
<podiki>efraim: speaking of librsvg these days (after skipping tests from cairo update for the older version), is there a pending update/plan for librsvg on rust-team?
<efraim>yeah, I'm planning on upgrading it to 2.48.x this round
<efraim>it turns out 2.47 wasn't a beta release, so we could've used that too
<podiki>i hope to push my local mesa-updates to be built today/tomorrow, just need to review the vulkan updates
<podiki>so that branch will have updates to cairo, libdrm, mesa, vulkan, sdl2
<efraim>looks like I'll be doing 2.57, 2.58 needs cairo-1.17+ and I'd rather not wait to upgrade librsvg
<podiki>i'm guessing it is more than just a simple patch or two for librsvg but a bunch of rust packages? otherwise i would say just put it on mesa-updates since cairo will cause all to be rebuilt anyway
<efraim>yeah, it's probably going to be a bunch of rust packages
<hapster>A test of a build I am running fails because "core audio format" could not be recognized as MIME type. Does Guix have a package for this?
<peanuts>"debian Pastezone"
<podiki>efraim: figures! anyway, will keep in touch about mesa-updates anyway. when gnome-team is merged that will also probably require rebuilds on the other branches
<efraim>yeah, definately
<efraim>doh, 1.57 also needs a newer cairo
<efraim>I've also updated python-cryptography
<tschilp>Hi guix! I just created a qemu image following the docs at and successfully booted it up. Logging into it I notice that ~guix system describe~ does not point at a commit, and not at a configuration file (like my host guix system would do). But there's a guix-home-config.scm in both root's and alice's home directories, which
<tschilp>wouldn't be after a 'normal' installation. Is this on purpose, or did I mess something up?
<peanuts>"Invoking guix system (GNU Guix Reference Manual)"
<tschilp>Not that I don't like the thought, but I cannot make out where this happens (I'm using the template from the docs, just renamed it, but no further fiddling).
<hapster>Are there packages that implement support for coreaudio? I am currently updating a package that has this as test, and it seems I have to disable coreaudio via configure-flag. I've seen `gsequencer` synopsis saying it supports coreaudio, but I don't know which dependency does that.
<hapster>Is it possible to disable just specific tests from a test suite using the ARGUMENTS field of a package declaration?
<ieure>hapster, Don't think so. Likely routes to disable some would be to replace the 'check phase with one that only runs a subset, or to remove / patch the tests.
<hapster>ieure: Yeah, I've seen some files skipping tests altogether (which I am doing ATM to get started), and others disabling specific ones. It's just that I don't know enough C++ to understand where a test is defined :/
<ieure>hapster, I assume you want to disable it because it's failing, doesn't that print a stack trace or similar?
<ieure>Or a test name?
<hapster>ieure: Yeah it does, I uploaded a paste a bit higher up. It's about a coreaudio-testfile whose MIMETYPE cant be found out. And I couldn't find a package that helps with this.
<peanuts>"debian Pastezone"
<ieure>Grep of the source didn't find anything with "soundsourceproxytest" in it?
<ieure>Or "firstSoundTest"?
<ieure>Would think one or the other of those two would locate the failing test.
<hapster>Well, that yields quite a bunch of results to be frank
<ieure>./src/test/soundproxy_test.cpp:862: Failure
<ieure>Is in your paste.
<ieure>Is that not the exact location of the failure?
<hapster>ieure: Ah, I think I begin to understand. Then I use `modify-phases` and substitute the according string in the correct file?
<ieure>hapster, Sure; or you can write a patch which the build process applies.
<hapster>ieure: You are correct. However, the examples I have seen so far used a file such a CMakeLists.txt, whereas the files I can see -- CTestTestfile.cmake, CTestCostData, some *.log-files, the source file -- dont seem to follow such a regular syntax
<ieure>I honestly don't understand what you're saying.
<ieure>hapster, What I'm saying is: you can write a patch which deletes your failing test, or makes it always succeed, or whatever. And then put it in gnu/packages/patches: -- and have your package's build apply the patch after the unpack phase.
<peanuts>"patches\packages\gnu - guix.git - GNU Guix and GNU Guix System"
<hapster>ieure: Fair enough. There is one file which mentions something that makes sense in the context: "add_test(SoundSourceProxyTest.firstSoundTest ...". It is a file called "CTestTestfile.cmake". The name of the file is so awkward that I feel like it can't be the correct file to make the changes
<ieure>This process has nothing to do with cmake or log files or anything.
<ieure>hapster, Patch the test file itself.
<ieure>Remove the asserts.
<hapster>ieure: I don't really understand how patching works, I am sorry
<hapster>I mean I understand it in principle but not in practice. I checked the patch files for mixxx 2.3.6, but they don't make sense to me
<ieure>You don't write the patch by hand, you modify the source and compare against the original. If your upstream source is a Git repo, clone it and hack it up, then `git diff' and that's your patch.
<ieure>If it's a tarball, extract it, then `cp -R thing-1.2.3 thing-1.2.3.orig'. Then hack up the source and `patch -uR thing-1.2.3.orig thing-1.2.3' and it prints the patch.
<ieure>I'm sure there are better resources if you search.
<hapster>ieure: Okay, I think I am beginning to understand. Since there is only this one test failing, I simply delete it from the CMakeLists.txt and make a git diff.
<ieure>hapster, Yes, exactly.
<ieure>diff creates patches, patch applies them if you're in the shell. In this case, the Guix build will apply your patch.
<ieure>Both (substitute* ) and patches are accomplish the same thing: changing text.
<ieure>*are accomplishing
<ieure>If it's a very simple change, (substitute* ) is probably better. If it's complex (roughly: multiple lines changed), you need a patch.
<hapster>ieure: thanks a bunch!
<ieure>Sure thing, good luck with your package.
<Mist64>Greetings everyone! I have been considering migrating to guix from nix because of the lispy nature of it, but one thing that has been keeping me from migrating is flake.nix. Is there some sort of alternative in guix that I am not familiar with?
<nikolar>Mist64: development shells are basically the same thing
<nikolar>Erm, guix shell
<peanuts>"Invoking guix shell (GNU Guix Reference Manual)"
<Mist64>nikolar but isn't that similar to nix-shell ?
<Mist64>I like the manual site! But the landing page needs a rehaul imo (perhaps I can contribute to that when I start my full stack journey at some point)
<Mist64>yeah that is not a flake.nix alternative, more like a nix-shell alternative
<Mist64>flake.nix allows us to specify different channels and different package output and whatnot for our projects. One of such examples is that I am mainly using the stable branch for my packages and unstable for certain packages
<Mist64> <- good site that explains the basics
<peanuts>"Nix flakes"
<db48x>is guix supposed to set up a directory like /run/users/1000 for use as XDG_RUNTIME_DIR?
<bjc>elogind does by default, iirc
<vagrantc>probably if elogind is installed
<vagrantc>(on the system level)
<bjc>but i don't think greetd/seatd do
<bjc>i vaguely remember having to set up pam mount rules for that when i used them
<mtekman>How do loading R packages work? If I create an environment via `guix environment --pure r r-devtools`, how do I then load it? Normally I'd just type "R" and then "library(devtools)", but it seems like the `.libPaths()` is pointing to base packages and not to the one I installed. Where is r-devtools installed in the environment?
<db48x>ACTION investigates
<Mist64>So let me take another route to this, what file can we use in a project to build the project + environment based on specifications written within the file in guix? Trying to think of something similar to `nix develop` or `nix-build`
<mtekman>Ah, I got it -- you have to use "--ad-hoc" to add the R packages directly to the environment:
<mtekman>uix environment --network --pure sed --ad-hoc r r-devtools r-formatr
<mtekman>That way, sed is added as a build time dependency, but anything after "ad-hoc" is a runtime dependency that can be loaded. It pay to read the manual, who knew?
<vagrantc>mtekman: the more modern interface is "guix shell" which behaves more like you first thought
<vagrantc>e.g. guix shell ~= guix environment --ad-hoc
<vagrantc>a lot less typing :)
<rekado>mtekman: in your example it adds the build dependencies of sed, not sed itself
<sneek>Welcome back rekado, you have 1 message!
<sneek>rekado, lechner says: / Hi, what would it take to add password or CertFP authentication to guile-irc, please?
<rekado>(it just so happens that sed is one of the build dependencies)
<Mist64>@gooberpatrol66, going to check that link out. Thanks!
<vagrantc>efraim: fwiw, i think the only likely affected u-boot targets are pinebook, pine64-plus, pine64-lts ... and they are now building fine for me.
<vagrantc>and brodeaux seems to have builds of all the other 2024.01 u-boot variants
<db8x>Ok, I feel like this question may be a dumb one, but here goes. The emacs package depends on binutils. I have installed emacs, and it is available, but nothing from binutils is available
<db8x>/run/current-system/profile/bin/emacs -> /gnu/store/09a50cl6ndln4nmp56nsdvn61jgz2m07-emacs-29.1/bin/emacs
<db8x>but /run/current-system/profile/bin/as doesn’t exist
<db8x>what did I do wrong?
<db8x>(I’m using the Guix System)