IRC channel logs
2024-05-31.log
back to list of logs
<PierreChTux>Just for information: I finally got my first "guix pull" ending correctly, without any insults. Youpi! <PierreChTux>I should try on another machine to reinstall Guix from nothing, to check if I can reproduce what seems to be a bug: the swap that I made during install wasn't used by the system, it didn't appear in the fstab, and I had to reformat it in order to be able to activate it. <PierreChTux>It took 151m31.852s to complete the "guix pull" as root. Does this seems like an unusual amount of time, or does it seem reasonable? <ieure>PierreChTux, About normal for the first pull on a slow machine. Guix management commands are excruciatingly slow in my experience (coming from Debian). <PierreChTux>ieure I'm also a Debianer, or rather I should say that I became a Devuaner, since some of my machines are allergic to systemd. <ieure>Been running Debian since 1997ish, still haven't switched to Guix for daily driving... have several issues needing improvement, which I haven't gotten around to. <ieure>Things like autofs working, and some way to get my beloved hyper modifier in Emacs. <vagrantc>rekado: wild guess would be you have to run "guix git authenticate" once manually <vagrantc>rekado: as that's the error message i get when i run it for the first time <vagrantc>rekado: and then it records that information in .git/config somehow <freakingpenguin>Yeet, the system tests I'm writing for restic now pass and it can both bootstrap repos and use password-command. <JetpackJackson>is it normal to face a lot of mouse lag when running the QEMU image for Guix? i dont have a spare device that i could test out Guix (the OS) on unfortunately <meaty>What's the easiest way for me to get an extra file into the /var/efi/ (or guix equivalent) of an install disk <meaty>The kernel is missing a (non-prop!) fw file which was never added for some reason or another, and so I can't install it on this machine without getting it in there for the kernel to load <Kolev>Does Guix not have GNOME in U.S. Spanish? <meaty>also, is there a module equivalent to let <meaty>e.g. define is to let as using-modules is to *?* <meaty>this way it's easier to tell which package defs have depend on which modules <brendn>Why does the password-store package definition use git:// instead of https:// for the repo url? <PuercoPop>if I have a package definition in a .scm file, how do I load it in guix repl? I can do guix repl -- foo.scm, which evaluates the file, but how do I refer to the exported values of the module to inspect them? Or even try to build them? <freakingpenguin>PuercoPop: Re. building, assuming cwd is in the same directory as your .scm file, guix build -L . <package-name> should work. <PuercoPop>That is my understanding reading the manual, but it doesn't, it seems that it doesn't find the package <freakingpenguin>You can enter an interactive repl after evaluating <file> with guix repl <file> -i and inspect variables that way. Just know if it's a module you'll have to either change modules via ,m (my custom module) or import the module to the default guix-user namespace. <freakingpenguin>I get an error that it failed to load your file when I do guix build -L . kaleidoscope.scm due to an invalid base-32 character, ergo the package wouldn't be visible. <PuercoPop>damn, let me push force. I thought I had fixed that. I was also confused about that because I obtained the sha256 using guix download -f base32, but if I use that string I get that error <PuercoPop>so I reverted to the value that guix download by default <PuercoPop>freakingpenguin: so I should match the path from directory where I invoke guix build -L .? <freakingpenguin>Also there's a typo in your package's name field that might be relevant <freakingpenguin>If your module is (foo bar baz), -L is the directory containing foo/bar/baz.scm. If it's just (kaleidoscope), then -L is the directory containing kaleidoscope.scm. <freakingpenguin>Pro of organizing your channel with <channel-name>/subdirectory/whatever is it lets you add the entire channel to your load path with -L . in the project root. <PuercoPop>Yeah, I remember that recommendation. I'm still in the initial phase of setting up my enviroment and understanding the basics. But I do plan to get around to setting my config as a channel <PuercoPop>freakingpenguin: fwiw I don't think you talk to much, I appreciate your help. <rekado>sneek: later tell vagrantc Thanks for the hint! I've run it manually and successfully authenticated 74k commits. (I ran "guix git authenticate -k keyring 9edb3f66fd807b096b48283debdcddccfea34bad BBB02DDF2CEAF6A80D1DE643A2A06DF2A33A54FA".) But the error on "git push origin master" remains. <rekado>I had to use "./pre-inst-env guix shell -D guix" instead of "guix shell -D guix" to get an environment with a more recent "guix". <janneke>ACTION apparently now building the whole ghc stack <janneke>i'd witch the build farm would keep up with core-updates :-/ <PurpleSym>That’s going to cost you hours with tests enabled… <janneke>...been building core-updates for days <janneke>yes, rust; many versions of gcc/gcc-fortran <indigo-oce>Can I create a guix shell or some solution to get the downloaded programs to find the library... never used `ld`... maybe I can just run that? <futurile>indigo-oce: not to state the obvious but did you try guix shell with --emulate-fhs <indigo-oce>it finds some libraries from /lib/ and others from /gnu/store/... still doesn't find `libgcc_s`... running `ldd $(which adb)` from inside the container finds only /gnu/store/ libs <futurile>indigo-oce: and you can't compile 'device-flasher.linux' from source inside a guix container / env? <futurile>indigo-oce: I guess you're next option is to try messing around with LD_LIBRARY_PRELOAD (might not be the exactly right env var), to see if you can manipulate the dirs it finds the libraries in. <futurile>indigo-oce: or if you want to move on with your life - create a VM and load something 'standard' like Debian so that it will find those libs <jpoiret>it's the usual problem of the gcc:lib output being inaccessible from CLI, no? <indigo-oce>haven't tried compiling device-flasher... since it downloads the platform-tools pre-compiled those would probably have to be compiled & code calling it from device-flasher rewritten... and it's a bit risky since if there's an issue I could brick the android device... <indigo-oce>Was just thinking of using a VM... haven't done that on guix I think... <jpoiret>indigo-oce: you can try adding -e '(list (@ (gnu packages gcc) gcc) "lib")' to the shell invocation <indigo-oce>jpoiret it keeps saying gcc-toolchain superceedes gcc... can't even find gcc with `guix show gcc`... what does that code do? <jpoiret>i'd suggest using a manifest file instead <jpoiret>indigo-oce: basically, the gcc package is not accessible through specification->package, which is what's used to translated the names given on the CLI to actual package <jpoiret>this code just gets the actual package (as a scheme object), and specifies the lib output <indigo-oce>am in a bit of a hurry.........----- Oh damn... that code works... at least now it finds the library... <jpoiret>there might be a mismatch between the gcc:lib version and the one of gcc-toolchain that you specify next to it, hence why I would recommend using a single manifest <indigo-oce>never used manifests before... how would I check if there's a version mismatch? <jpoiret>using the `guix shell` command line? <jpoiret>you could try `guix size $GUIX_ENVIRONMENT` once inside and look at the displayed versions, but it's brittle <jpoiret>it's just that mixing the CLI names and actualy scheme isn't great because they don't have the same conventions: CLI names by default get you the latest version, while scheme symbols usually denote the *default* version used in guix <indigo-oce>from in the [env] shell I guess? so far it's working... running the 'device-flasher.linux' program atm... how likely would an error be do you think? <jpoiret>eg gcc in scheme would be gcc 11 IIRC while gcc on the CLI would mean gcc 14 <jpoiret>the program crashing, maybe even just doing a subtly different thing <jpoiret>since it's the gcc support library, anything geos <indigo-oce>opened a new shell with the same command... `guix size` is brittle... does it want network access? <jpoiret>it should not if you give it a store path, which $GUIX_ENVIRONMENT should be at that time <jpoiret>but it's brittle in the sense that you're just looking at store paths of dependencies to infer their versions. <indigo-oce>guix size: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory <jpoiret>ah, no it's because it wants to connect to the guix daemon <jpoiret>you'll need to run that outside of a container <jpoiret>there's also the -W option that should be possible <indigo-oce>ok... by taking the $GUIX_ENVIRONMENT output and running `guix size` on it? <indigo-oce>that didn't work actually... but the directory contains a manifest file... <indigo-oce>error was `guix size: error: path `/gnu/store/2q5gmsizpfszhr4crwblna39l9qhy1jv-profile/' is not in the store` <futurile>guix package --list-installed --profile=$GUIX_ENVIRONMENT will show what's installed in the current guix shell <indigo-oce>seems to contain both gcc-toolchain 11.3.0 & 12.3.0 <futurile>so you have gcc 11.3 + gcc-toolchain - seems like that should be enough. If you're going to do this repeatedly then learning about a manifest and making sure it's repeatable would be worth the effort. Otherwise, not worth the effort. <janneke>jpoiret: i'm giving up on core-updates for now, until there are more substitutes available <indigo-oce>now the `device-flasher.linux` is failing because `adb` cannot find the android device... it's able to outside the container... <futurile>indigo-oce: you'll need to look at share=<device> - guix container doesn't share stuff by default so it probably can't see the right devices <futurile>indigo-oce: do you understand devices in Linux? <indigo-oce>I was looking into how sound cards are identified the other day... udev maps to /sys/devices/ <indigo-oce>this is connected from a usb port... doesn't appear as a block in lsblk... <futurile>indigo-oce: yeah, and it's complex. The stupid but easy solution for right now would be to do something like --share=/dev --share=/sys <futurile>indigo-oce: honestly every time I see someone using guix shell like this I wish they would run a standard linux VM. It's like you're learning to cook, DJ music and peddle a unicycle all at the same time ;-) <indigo-oce>I know... was thinking of doing that... not sure what the easiest way to run a vm is... <futurile>indigo-oce: I'm mostly saying that because someone tried doing this sort of thing and kept complaining on IRC - eventually they were "f**k guix" - and really it's because the mix of Guix's declarative system and 'standard precompiled binary that expects normal linux' is a hard mix. Using 'guix shell' can work - but it's pretty advanced <futurile>indigo-oce: as long as you're having fun ;-) <indigo-oce>yeah that makes sense... I am having fun but I'm also late for a event... just got a brand new error that seems unrelated to guix... <indigo-oce>I don't remember getting VMs working on guix yet... quick search finds 'run Guix as VM'... <Altadil>indigo-oce: for running VMs inside a Guix host, you can use qemu directly from the CLI. There’s also virt-manager and GNOME Boxes. <civodul>apteryx: hi! do you know whether guile-git is happy with libgit2 1.8? <f1refly>am i doing something wrong or is krita not being built on official substitute servers? <f1refly>my laptop is trying to built krita 5.2.1 every time i run guix upgrade for about three weeks i think but it's just too big for this machine <rekado>f1refly: "--do-not-upgrade=krita", then investigate later. <meaty>how can we refer to the correct "guixified" install prefix for a package in its definition <meaty>i.e. I'm packaging something that uses a variable passed to make to define its prefix instead of a .configure <meaty>and by default that variable is "/usr/local" so it needs to be changed to... maybe (store location)/usr/local? not 100% sure <meaty>wait, no, just (store location)/ <futurile>meaty: are you sure you need to do that? the default normally handles it. There's #:make-flags and #:configure-flags which might be what you want <meaty>futurile: indeed it would normally, but this is a wierd repo which is supposed to be installed only with one "make install PREFIX=..." <meaty>I have gotten to writing a #:make-flags arg <meaty>but I am stuck when I need to come up with the right directory <ngraves>wondering if it's not also possible that the problem is caused by the big update in nss-certs management, since the traceback suggests that it hangs on SSL handshake. WDYT ? Can it come from there ? <meaty>I am sure there is a function here somewhere but the manual can be obtuse sometimes <meaty>futurile: i see. aha! %output <meaty>it was not indexed in the manual, if it's in there somewhere <meaty>i like your blog, why not adapt some of this to the cookbook/manual? <futurile>meaty: my blog, my sentence structures, my mistakes and I don't have to go through reviews to publish stuff :-) <meaty>god guix backtraces are completely useless <meaty>it looks like gexp is inaccessible from the context in which the %output is eventually evaluated? <attila_lendvai>meaty, yeah, and that's very unfortunate. one of the primary selling points of the lisp coding experience is that, with a little discipline, 90+% of debugging is just looking at the backtrace. <meaty>but unquasiquoting it tells me it's inaccessible from the package definition's environment too <meaty>attila_lendvai: yes but CL and elisp backtraces make sense, guile is just <#$!@$#!@> and _ <meaty>am I missing something that makes the interpreter know actual procedure, arg names etc. instead of just file positions if i'm lucky <meaty>gexps need unquasiquoting too <pabs3>civodul: I note the disarchive git repo gives a 502 error sometimes, are you able to ping Timothy Sample about it? SWH should probably save it too :) <civodul>pabs3: hi! hopefully SWH saves it already <pabs3>the cgit instance there isn't yet saved <civodul>he’s not always available but eventually responds <pabs3>its on my todo list along with many many other ones :) <pabs3>guess I can SCN the repo for now <cricri>hi there, I got a question about image generation for a raspberry pi. my guix system image command fails: <cricri>guix system image gnu/system/examples/raspberry-pi-64.tmpl <cricri>hint: Did you forget a `use-modules' form? <cricri>guix system image gnu/system/examples/raspberry-pi-64.tmpl <cricri>hint: Did you forget a `use-modules' form? <cricri>sorry, error line got swallowed, actually: <cricri>guix system image gnu/system/examples/raspberry-pi-64.tmpl <cricri>gnu/system/examples/raspberry-pi-64.tmpl:28:29: error: grub-efi-bootloader-chain-raspi-64: unbound variable <cricri>hint: Did you forget a `use-modules' form? <cricri>I am on the master brand, newest commit 83d29d56f8808ca1f076dda37ef34150d0308e9a, so you can easily reproduce it. <cricri>as far as I understand guile, the variable grub-efi-bootloader-chain-raspi-64 should be imported at line 15: (use-modules (gnu packages raspberry-pi)) <ieure>cricri, You need to figure out what module that variable is in and use it. <ieure>You can grep the Guix source tree to locate it. <ieure>The error says that your assumption that (gnu packages raspberry-pi) contains the variable (*and* that it's exported from that module) are incorrect. <cricri>ieure, thank you. For my understanding of guile, it looks like grub-efi-bootloader-chain-raspi-64 is exported quite correctly from gnu/packages/raspberry-pi.scm. But I will do some research on guile/exporting variables then. <apteryx>ieure: trying to build librewolf 126.0 (from your v2), I got: 0:04.18 error: failed to load source for dependency `uniffi` <ieure>apteryx, Huh, I'll take a look, thank you for the ping. Not sure what would have broken, the v2 patch only updates the build ID, and I've been running this out of my personal channel for a week or so. <apteryx>ieure: on another run: 0:04.25 error: failed to load source for dependency `chardetng` <apteryx>maybe because I use a highly parallel build machine? (180 cores) <ieure>apteryx, Kicked off a build. Is this failure happening pretty early in the process? <ieure>While we're talking LibreWolf: is there some way to determine the target architecture in the build? There's a bit of the build recipe that hardcodes x86-64, which probably causes it to fail on arm64 machines. If I can inspect the target, I can fix that. <Tadhgmister>If I want to build something with a local guix channel and other channels from the system how would I do that? <ieure>apteryx, Huh. Yeah, not reproducing on my quad-core dev box. I wonder if this is an issue with vanilla Firefox, too? I'd expect so. <Tadhgmister>using `./pre-inst-env` stops it from using system wide channels <ieure>apteryx, Doesn't look like there's a package-level setting to limit parallelism in the build. Is there anything that can be done about this? <lambdanil_>Hi, does anyone here have any idea why background transparency doesn't work with Emacs? I have everything configured properly, it works under Gnome Wayland (with emacs-wayland) but on XFCE the background is opaque, no matter what. I have the compositor enabled, all of which leads me to believe the issue is a missing compile flag, tried adding <lambdanil_>"--with-cairo" "--with-gtk3" "--with-x-toolkit=gtk3" "--with-imagemagick", as well as imagemagick to inputs to the default Emacs package, but no dice. Any clue what else is missing? <Tadhgmister>or is there a way to only `pull` one channel while leaving the others unchanged? that way I could just use the local guix channel as the system wide one <ieure>apteryx, Package built successfully for me, so I guess this is an upstream bug with large machines. <yewscion73>Hello Guix! I went to update my home profile today, but my personal channel is no longer compiling due to an issue with a package for custom kernel I use to avoid a hardware bug in my Librem 14. I use multiple (@@ ...) calls to reference variables and such without importing (gnu packages linux), and the error I'm getting is `(exception <yewscion73>unbound-variable (value "module-lookup") (value "Unbound variable: ~S") (value (%default-extra-linux-options)) (value #f))`. Did something change in Guix so (@@ ..) doesn't work anymore? <zeropoint>futurile: thanks for sharing, picked up a few ideas from that taalk <lechner>civodul / the guix shell bug is back <lechner>civodul / or maybe another one like it. i cannot fix this one with rm -rf ~/.cache/guix/profiles <civodul>lechner: hi! not sure what “the guix shell bug” is, but i can only invite you to report it for further investigation :-) <lechner>civodul / rmember the profile cache not working? I'll look into it further though. thanks! <civodul>lechner: i only have a vague recollection <popebob>running guix on a foreign distro, can i change /gnu/store? long story short, i'd like to use guix as a non-priv user to supplement my base OS. <freakingpenguin>popebob: You'd be hard pressed to. Guix can install packages on a unprivileged per-user basis but the daemon needs more permissions. <popebob>freakingpenguin: do i 'need' the daemon, or could i run a script to do what the daemon does to rejigger the symlinks when a new package is added? <popebob>freakingpenguin: it's not a matter of stepping on the toes of the host, it's a matter of running arbitrary build commands as root. <ieure>popebob, The build commands don't run as root, but the daemon needs root to set up the isolated environment those non-root builds occur in. <ieure>Builds are isolated from the host system, whether it's foreign or Guix System. <popebob>"very much need the daemon" already tells me this isn't the project for my use-case. <ieure>Well, nothing works without the daemon, so... yeah. <popebob>ieure: that's cool. but nothing about guix, at its core, other than as the main distribution, requires admin privs. <popebob>nor does it, by design, need to be installed systemwide or outside of my user's home. <popebob>but as it is used and distributed and packaged, that is very difficult. <ieure>popebob, Seems like no amount of explanation is going to satisfy you, so I won't give any, but I will say that you are incorrect. I hope you find tooling that meets your needs, but I don't know what that would be. <popebob>ieure: how am i incorrect? in what way does guix need to be a system-wide thing? <ieure>popebob, As I said: Guix isolates builds. Builds cannot affect the system, nor can the state of the system affect builds. Doing that requires setting up a namespace/cgroups to isolate it. Doing that requires root privileges. Guix chooses to centralize that in the daemon, rather than requiring every user to have them. <popebob>ieure: i don't need root to set up namespaces or cgroups if i run it as my non-priv user, in their namespace. <popebob>and if i wanted to, i could set those things up, as the admin, for that user. <ieure>popebob, This sounds like a good conversation for guix-devel. Like running the daemon as a non-root seems like a good thing; probably the folks there can point you at what would need to be solved to do that. <popebob>thanks for the pointer. sorry to bring the discussion to the wrong channel. <ieure>Not at all; this is a good place for gutchecks and interactive debugging. But I think your topic is more in-depth & probably a better match for the ML. <ieure>I mean: you don't have anything to apologize for. :) <Damsu>Hello, can anyone help me figure out how to run nmcli without being root? I have the netdev in my supplementary groups in my account <freakingpenguin>Does Guix have a way to disable the "updating substitutes from...." messages? --verbosity=0 kills everything, but I want other messages available for CI pipeline purposes. <ieure>freakingpenguin, Don't know, but interested to hear. I also would like to understand why the messages repeat so much. It'll update substitutes from the same server over and over. Is it doing something different? Redownloading the same stuff? No idea. <freakingpenguin>ieure: I'm willing to theorize that they're different since the number of "updating substitute" lines printed vary wildly. <freakingpenguin>I think it comes from (guix scripts substitutes), so I suspect every build "stage" it checks every derivation on that stage for a substitute.