IRC channel logs
2025-02-21.log
back to list of logs
<divya>vagrantc: Because guix bootstraps itself. <vagrantc>divya: i do not follow how producing a tarball requires building the source <divya>vagrantc: What exactly are you building? Maybe I misunderstood. <divya>vagrantc: Not sure about this, efraim would know better. <vagrantc>well, how lovely to be dogpiled on guix-devel. <vagrantc>been working all day on fixing bugs ion guix. <vagrantc>i make one mild comment suggestion that people listen to each other. <ieure>vagrantc, I will never understand the nerd rage over renaming a thing. <ieure>Not surprised to see it happening. <vagrantc>i am not surprised, just disappointed, as i have rarely seen it <divya>vagrantc: Apologies if you felt personally offended, but I had no such intent. I simply disagreed with certain things and thus conveyed. I hope we can disagree and argue without taking things personally? <divya>Thanks a lot for the work you've been doing, in no way or manner did I intend to make it feel like your work is undervalued. <vagrantc>divya: maybe not beginning a rebuttal with "The absurdity ..." does not exactly inspire confidence :P <divya>vagrantc: Apologies, I should've prefaced it with something else and reworded it differently. Sorry. <guixgoblin>The udev-rules-service does only work for rules.d and not hwdb.d as far as i can see. <mange>Does udev-hardware-service do that? I'm assuming hwdb is hardware related. <mange>Looking through (gnu services base) it looks like udev-hardware-service ends up in hwdb.d. <guixgoblin>:mange, it works like a charm. i was searching through the documentation of 1.4.0 and not the latest one.... '=D . Thank you very much. <cobra>using the latest installation image build, `guix pull` errors saying "guix pull: error: cannot close compressed log file (gzip error = -1)" <meaty>What do I do when the lib dir of an input somehow isn't showing up in the final RUNPATH <meaty>Specifically, libX11.so.6 from libx11 <meaty>the validate-runpath phase fails <civodul>how’s your ROOT/Cling packaging adventure going? :-) <civodul>great that upstream is being supportive <jakef>i'm thinking we should only have the visualisation variant for the latest version of geant4 in guix-science <jakef>not sure if i should email the guix-science list or just submit a PR <jakef>this would be an attempt at a policy for when a version should be bumped, a new version added, or an existing version removed <jlicht>Is there any particular reason we can't 'simply' pull rocm/hip updates from guix-hpc into guix? <civodul>jlicht: that’s the goal: moving them to guix proper <civodul>it’s a bit hard to embark people on an email CI-less journey though <civodul>that’s why i haven’t pushed too hard on this <civodul>but if you’d like to help, that’d be most welcome <civodul>jakef: you can try to bring it up as a PR first <csantosb>Sad that cern decides to host source code on Github. <csantosb>Great news that root/cling and geant codes are being packaged ! This would be really great for the sc community ! <jakef>csantosb: indeed! we've had geant4 in guix-science-nonfree since mid last year :) <jakef>as civodul points out, cling and root are packaged too (though root can still be improved!) <jlicht>civodul: thanks for the pointer, will have a look when I can <csantosb>jakef: good to know to disseminate the info ... in my experience, physicists love tweaking their install, I guess this is feasible with transformations <mra>going to make a second attempt at hacking together a Guix+ZFS system tonight <mra>`gnu.repl` is going to save my ass <futurile>be cool if you can get that working, lots of people have asked about using ZFS on Guix. <jlicht>don't forget the complementary snail mail to Oracle's legal department so they can actually fix this once and for all ;-) <mra>futurile: I've been working on it! 55231 is my current goal, but unfortunately that's stalled on 41602 <mra>41602 seems to be a daemon bug, which is deeply unfortunate. some nix folks also correctly pointed out that #: substitutable is not a good way to prevent distribution <mra>unfortunately, with the state of the daemon, I have no clue how to introduce a better means, since I think that the change needs to happen at the daemon level <civodul>i get “error: %hurd64-default-operating-system: unbound variable” in tests/guix-system.sh <jlicht>is there a way to unsubscribe to one specific debbugs issue? <futurile>jlicht: according to my notes there is a subscribe / unsubscribe command <yelninei>civodul: i have the same error : running ./pre-inst-env guix repl gnu/system/examples/bare-hurd64.tmpl gave me a record-abi-mismatch-error (no issues without pre-inst-env) <yelninei>The guix hint: Did you forget `(use-modules (gnu system hurd))' was not helpful <civodul>yelninei: ABI mismatch suggests you need to recompile some modules <graywolf>Hi :) How do you guys manage postgresql on Guix system? postgresql-service-type seems fine, but I am not too sure what to do with postgresql-role-service-type. It seems quite limited, do you use it? If so, how do you later manage rest of the postgres setup (the GRANT ON and such parts). <yelninei>civodul: recompiled everything and tests/guix-system.sh passes again for me <lechner>graywolf / Hi, would you please remind me (or help me find your message about) how I may create a permalink on Savannah? Thanks! <graywolf>(Optionall you can click the line number when viewing a file to also link ot specific line) <lechner>very creative. maybe that should be the new branch name <lilyp>maybe 🥳 should be the new branch name <graywolf>And with each release, we could pick a shape with one more side <lilyp>(in case you can't see it, it's the party hat emoji) <graywolf>Oh, I see, I am probably missing some fonts. <lilyp>yeah, emoji names are not that accessible after all <lechner>sorry, in my earlier message I meant "guix" <lechner>sorry about the extra newlines. fat fingers <lilyp>lechner: That does look like a bug to me <lechner>lilyp / thanks! how about this second version, please? <lilyp>LGTM, but I don't know the impact. If it's not a world rebuild, I could go to master <lechner>lilyp / it's part of a larger series that moves the link ~/config/guix/current to $XDG_STATE_HOME/guix/current, which is where I think it belongs <lechner>lilyp / if one were to fix this bug now (and independently from the the discussion about the other matter) how may I determine the rebuild effect, if any, please? <lilyp>I think checking the number of packages that rebuild? <lilyp>IIUC it's just the guix derivation, which should cause no effect, but better safe than sorry <lilyp>does the rest of guix respect XDG_CONFIG_HOME btw? <lilyp>you're also missing code to migrate from the current XDG_CONFIG_HOME <lechner>i think i also have to track down %user-profile-directory <lilyp>it has the same directory twice? <lilyp>nope, it's just a different binding in guix/scripts/pull vs guix/profiles <lechner>lilyp / i'm not sure I follow. I meant the comment, which refers to ~/.config/guix/current (and not to ~/.guix-profile) before %user-profile-directory is used <lechner>doesn't that suggest that %user-profile-directory does (or could) refer to ~/.config/guix/current? <lilyp>%user-profile-directory is defined with two different values in two different locations <lilyp>in pull.scm it's ~/.config/guix/current <lilyp>in profile.scm it's ~/.guix-profile <lechner>and this is so that a 'pull' doesn't bork the current guix? <lechner>i am just trying to understand. i guess there is no issue because it's just a comment. why does ~/.guix-profile exist in addition to ~/.config/guix/current? <Rutherther> The first profile is one you guix install to, the second holda guix itself <lechner>Also, has a more specific nomenclature developed to distinguish two folders that are in fact different? <Rutherther>It is the pull script, the pull script refers to the profile with guix, it doesnt use the other at all. So naturally the one in the comment <Rutherther>I have no idea what you mean, I dont know whats there to distinguish, they are completely separated profiles <lechner>so %user-profile-directory does not refer to ~/.guix-profile in that place? <Rutherther>No of course not. See the definition earlier in the file <lechner>okay, would you please describe why both exist? <lilyp>~/.config/guix/current holds guix and all other channels you have (including the guix command) <lilyp>~/.guix-profile holds the packages you install with `guix package` <lechner>it seems that the word profile is overloaded, then? <Rutherther>Profile is guix concept used in many places, even in the system itself and guix shells <lilyp>a profile is merely a collection of packages held in one place <lilyp>you have at least three of them in a Guix System installation :) <lechner>okay, then "Guix profile" is overloaded <Rutherther>No it is not, it refers to the same thing every time <Rutherther>What guix profile is and what specific profile holds are two different things <Rutherther>It is like saying that the word apple is overloaded because there are two apples on the table <lechner>you just wrote they are the same, then you write they are different. <fnat>I've been experimenting with the new 'hetzner-environment-type'. I manage to provision cx42 instances (i.e. 8 CPUs, 16 GB RAM, 160 GB SSD) but anything smaller than that seems to fail with a "No space left on device" error. <fnat>Any possible trick to work around that? <Rutherther>They are both profiles, holding same things. I dont know where I wrote that they are or arent the same <lilyp>fnat try running `guix size` to find out what holds much of the memory <lilyp>I don't think CPUs or RAM should be an issue, but 160 GB SSD may well be depending on the packages <lilyp>(it's not small by any means, sure, but Guix with its multiple generations does end up using lots of space with multiple generations) <lechner>Rutherther / i'm sorry to be such a stickler, but "it refers to the same thing every time" and then "What guix profile is and what specific profile holds are two different things" <lilyp>lechner: what do you understand as "guix profile" and "profile" then? <lilyp>maybe let's start from there :) <fnat>lilyp: Thanks. Hm, I see. It's odd because it's really a minimalist system that I'm trying to deploy. I'd have expected it to fit 40GB (the smallest tier) or at least 80GB (the second tier). <lechner>in guix, the word profile seems to refer to a collection of links into the store, organized a little bit like the Linux Filesystem Standard. <lilyp>it might be something else, that's why I'm asking you to run `guix size` <lilyp>maybe the nvram for the bootloader is too small? 🤔 <lechner>not sure. i only use system profiles <fnat>lilyp: Can I run 'guix size' against a system definition? Is the idea to run it locally (e.g. against the definition) or on the provisioned machine? <lilyp>on the provision machine – maybe do 'du' first <fnat>Hm, not sure the provisioned machine is left in a state. Checking now. <Rutherther>lechner: I corrected myself. It was a typo, I didnt mean to say they hold the same things. <fnat>Hm, no, I can connect to it via a console (the one provided by Hetzner's web interface) but it's just the Debian rescue system. <fnat>What you mentioned re the nvram would seem plausible to me... <lechner>Rutherther / okay, sorry. i didn't catch the correction <lechner>fnat / i have deployed on a 20GB linode. What's in your system declaration? <lechner>i.e. get rid of anything involving X or gnome, including the mumi client. it pulls in part of X via FreeDesktop <fnat>I hope that doesn't bring in any heavy dependencies but I wouldn't think so. <fnat>My hunch would be that the limitation is more in the way 'guix deploy' works (has to work) to set things up at the beginning. <lechner>i use guix deploy and never had an issue, but the initial deployment was manual <fnat>Yes, exactly, I meant in terms of the initial deployment. <lechner>and I got rid of Linode after renting a static IP <lechner>what is the hetzner-evironment-type? <lechner>also, does your installation involve any RAM disks? <fnat>Hetzner is a hosting provider similar to DigitalOcean, if that's what you were asking? <lechner>guix deploy is often the only way to do it, btw. guix cannot compute its derivation with 2 GB, i don't think <fnat>'hetzner-environment-type' makes it possible to provision Hetzner VPSes via 'guix deploy'. <fnat>Fair enough re the 2GB, but I was talking about 4GB and 8GB machines. <futurile>fnat: maybe email Romain as didn't he just add this capability, might be worth asking him what he tested on etc <avalenn>why does "guix shell --container --network --profile=$HOME/.guix-home/profile/" fail with backtrace ? <Rutherther>avalenn: because you have slash after profile/ in the path <avalenn>Ok. Works now. Thank you Rutherther++ <civodul>i have the beginning of a strategy to test guix-install.sh & co. on foreign distros <mra>I'm trying to install a ZFS system, and I'm having a weird issue. I manually built Guix with the patches from 55231 applied, and planned to `./pre-inst-env guix system init ...` to get things set up with the appropriate initrd modules, but I'm getting a weird error: "guix: system: command not found" "hint: did you mean 'system'?" <csantosb>sneek: later tell civodul, strange: looking at it until I run out of battery, ... no clue about right here about the unbound variable <mra>ieure: indeed. I have triple checked and I promise no typo on my end <vhns>Hi, I have a question but I'm not sure if it should go here or in #guile. What is the difference between exposing something with `define-public foobar` vs `#:export (foobar)`? <vhns>or if there is some logic between doing one or the other <ieure>vhns, Far as I know, there is no functional difference between the two, and it's a stylistic preference. <ieure>vhns, I personally lean towards define-public, because I dislike maintaining a list of exported symbols. <mra>Rutherther: no. I'm using the installation medium, so I'm logged in as root be default <csantosb>vhns: according to the doc, no difference, "‘define-public’ is similar to ‘define’ but it also adds NAME to the list of exported bindings of the current module." <Rutherther>mra: that is strange then. As a workaround you could pull from that local dir then <mra>Rutherther: I'll give it a shot <mra>actually, I don't even see a way to do that without having the local dir on git, unless I'm being dumb? <mra>oh, I can just supply a url of the form "file://<path>" that's funny <snamellit>Sorry IRC client switched channel without me seeing it. <vagrantc>hrm, ppc64el builds of guix failed various tests on debian, mostly "test-name: copy-file/deduplicate, sparse files (holes: 0/16384/0)" with various different holes ... do those tests succeed on guix with ppc64el ? <vagrantc>fairly recent guix commit ab1b557d8f336de4cfab07d202e0965ab18f2b7a <ieure>vagrantc, There was a guix-devel thread a while back which I think is related to this. <vagrantc>same tests passed on armhf, arm64 and amd64 <ieure>vagrantc, The thread I'm thinking about mentioned that there's an implicit dependency between the system's page size and the sparse file test. <ieure>vagrantc, Not having luck finding it, I think btrfs was also implicated? Some time in the last year. <mra>oh, wait, maybe the file thung doesn't work... hmm <mra>is there a way to make a channel out of a local file? <mra>gah. I guess I'm making a git repository <mra>I guess that at a certain point the easiest thing to do is to fork guix and apply the patches <lechner>ieure / vagrantc / i also remember that thread <vagrantc>i *think* the ppc64el build was on tmpfs ... which i suspect would be particularly affected by page sizes <ieure>lechner, Yes, definitely part of it. <ieure>Maybe the bug number got mentioned on guix-devel? <vagrantc>so yeah, variable page sizes, tmpfs ... we seem to be honing in on the issue <lechner>i think that's the message ieure was thinking of <vagrantc>lechner: yeah, that thread is linked to the bug you helpfully provided earlier <vagrantc>though switching *to* btrfs fixed the issue <vagrantc>so the tests should... test for page size or something and skip if the wrong assumptions are being tested? <vagrantc>hrm. how do i detect page size or architecture in guile? <vagrantc>ACTION rummages around in tests to see if there are any such tests checking for similar things already <anticomputer>I'm moving my dotfiles to the dotfiles home service and for some odd reason stumpwm is resolving my data dir path wrong when ~/.stumpwm.d/init.lisp is a link into the /gnu/store, yet it works fine when it is a real file ... it's all supposed to resolve (user-homedir-pathname) relative, and in the sbcl debugger context on the crash it's resolving correct but the global variable is still set wrong, throwing me for a loop a bit, see <mra>some progress! unfortunately the ZFS package is failing to build, since the current version of linux-libre is too new. I tried defining my own package inheriting from it, but I can't seem to figure out how to override the kernel that it compiles against <anticomputer>ah okay figured it out, it's some upstream changes they're iterating on that does file relative resolution i'm not actually on the 24.11 tag release <mra>hmm, that's what I've done. I wonder why it still isn't working. <mra>I'm telling it to build against 6.12, but it really seems to want to build against 6.13 for some reason... <mra>it looks like it's using some derivation called `linux-libre-module-builder-6.13.3` if I look in the logs <ieure>mra, That's part of linux-module-build-system. <ieure>Yeah, hmm, the code seems to just be wrong :) <ieure>`lower' in (guix build-system linux-module) is where linux is coming from, it defaults to (default-linux) unless #:linux is provided. <ieure>Not a build-system expert, but I'd think that comes from #:arguments in the package? <ieure>I don't see anywhere that explicitly provides it, but this is getting into parts of the build-system stuff I don't understand yet. <mra>I agree that it makes sense! It seems like it should work. I would guess that I'm making a mistake here <fnat>futurile: Yeah, true, I think it makes sense to reach out to Romain. <[>How do I install kernel modules using Guix? I tried adding v4l2loopback-linux-module to the packages list in my config.scm, but modprobe can't find it. <dariqq>[: maybe kernel-module-loader-service-type is what you want? <vagrantc>(when (string-contains %host-type "x86_64") (test-skip 1)) ... now i just need to figure out what ppc64el/ppc64le would match on <[>(kernel-loadable-modules and a reboot is what I was looking for) <mra>ieure: huh, it seems to be trying to build two different ZFS derivations? the one with my properly substituted Linux kernel, and the one with the incorrect version. as far as I can tell I never reference the default ZFS package in my config except when defining the custom package, so I can't figure out what's going wrong... <ieure>mra, Can you put your operating-system config on a pastebin for me to look at? <mra>ieure: I don't expect the file-systems to work, they're just there to get it to build. I'll need to do more tinkering to get that working <mra>the goal is just to get into an initrd <ieure>At least, I think that's what's happening. <vagrantc>yay, i think this will at least workaround the problem in the problematic tests ... and the 24 tests are in a loop, so it is a one-liner: (when (string-contains %host-type "powerpc64le") (test-skip 1)) <vagrantc>took me a while to find out that %host-type is just in guile ... spent the longest time looking for it <mra>ieure: doesn't seem to be the case. I just tried removing it, and I get the same error <vhns>A question for people running root-on-btrfs and enabling compression for the GNU Store: do you guys enable compression on all partitions or run some mcron task to compress /gnu/store? <mra>huh? I removed every single reference to ZFS, and it's still trying to build it? this is baffling <mra>I even removed the use-module (gnu packages file-systems) to be sure <potatoespotatoes>Hi all, I'm in a bit of a pickle trying to build a custom ISO image and could use some help. I keep getting an error "os: invalid field specifier" when defining my `image-type` for the `os+platform->image` function. Does anyone know how to work around this? <potatoespotatoes>Hi all, I'm in a bit of a pickle trying to build a custom ISO image and could use some help. I keep getting an error "os: invalid field specifier" when defining my `image-type` for the `os+platform->image` function. Does anyone know how to work around this? <potatoespotatoes>Hi all, I'm in a bit of a pickle trying to build a custom ISO image and could use some help. I keep getting an error "os: invalid field specifier" when defining my `image-type` for the `os+platform->image` function. Does anyone know how to work around this? <ieure>potatoespotatoes, Please stop reposting your question. <potatoespotatoes>Hi all, I'm in a bit of a pickle trying to build a custom ISO image and could use some help. I keep getting an error "os: invalid field specifier" when defining my image-type for the os+platform->image function. Does anyone know how to work around this? <ieure>potatoespotatoes, You have an error in your operating-system definition, most likely due to incorrect nesting. <dariqq>mra: (not knowing anything about zfs), if you are using your own fork of guix anyway you could just patch the zfs module in guix to not use the latest linux and worry about the issue another time <mra>dariqq: oh! good point <ekaitz>hey! did you experience that Qt apps are not able to open applications using xdg-open? <anticomputer>oh my, life is so much better with guix.el and geiser-guile setup in my emacs, nice <chillininva>I'm interested in installing ollama on my Guix system. Is this possible? Is there anything specific to Guix that I would have to do as opposed to other distros? <Aurora_v_kosmose>How does Guix manage Java's nonsense anyway? Or rather, Maven & Gradle's. <Aurora_v_kosmose>Those tools seem more oriented toward always fetching from network and sooner recommend self-hosting artifact repositories on localhost than offering proper support for from-source builds. <ieure>Aurora_v_kosmose, The build-system creates a local Maven cache populated with the inputs. <ieure>Also, pretty much all language tooling does this stuff now. <ieure>Downloads deps from the internet, that is. <Aurora_v_kosmose>> <ieure> Also, pretty much all language tooling does this stuff now. | Yeah, I kinda hate it. <Aurora_v_kosmose>> <ieure> Aurora_v_kosmose, The build-system creates a local Maven cache populated with the inputs. | I see. <Aurora_v_kosmose>ieure: Any particular reason why replicate its cache setup than mess with loadpaths? <ieure>Aurora_v_kosmose, If you mean, why doesn't it populate $CLASSPATH with the inputs, it's because those affect the JVM Maven runs in, not the things Maven does while running. <ieure>I haven't looked at the code, but I'd be surprised if the Maven cache is a copy, it's almost definitely symlinks into the store, just like a Guix profile. <fnat>*the official Guix channel (singular) <PotentialUser-99>guix pull: error: Git error: failed to connect to git.savannah.gnu.org: Network is unreachable