IRC channel logs
2025-04-29.log
back to list of logs
<tadhg>I'm able to access internet and wget on that path gives me a result but it is obviously using a different port <tadhg>wait do I have to setup ssh keys to use guix pull? <tadhg>oh I think it is working now? <cdegroot>Savannah has been worse than usual lately. Advice is to use a mirror instead. <apteryx>is there no Texinfo version of the GNU FSDG? <apteryx>does someone still have a CDROM drive available on their machine? <apteryx>I was looking at #35584, and to be able to troubleshoot, I'd need an audio CD dumped to a .iso file. Or perhaps I can create one from scratch using freely available music tracks? <apteryx>as mentioned in this issue, we can test exposing a CD or DVD if it's in a .iso file via libvirt. <apteryx>(to a virtual machine, which means anyone would eb able to try reproducing the issue and fixing it) <apteryx>but the difficult/hard to find part is the test .iso file <tom2342342311>I added (authorized-keys `(("my_user" ,(plain-file "authorized-keys" "ssh-ed25519 ...")))) to my openssh-configuration and reconfigured successfully, but /home/my_user/.ssh still doesn't exist and I don't see any ssh env variables pointing anywhere else. <jA_cOp>tom2342342311: I'm guessing that results in configuration in sshd_config - if you want to manage ~/.ssh, you can use the home-openssh-service-type in a Guix Home configuration <jA_cOp>to see whether the required configuration has been added to sshd_config, you can run something like `cat (sudo herd configuration sshd)` <tom2342342311>Ah thanks. I found it in /etc/ssh/authorized_keys.d/my_user. <tom2342342311>I just made a dumb mistake using the wrong key when trying to ssh into the server <jA_cOp>ah I see - yeah I can see that /etc/ssh/authorized_keys.d is referenced in sshd_config <dcunit3d>is there any way to change the build location for a `guix system image` command? i keep running out of space on tmpfs <apteryx>ouch, the fs corruption bug in current Guix is nasty <apteryx>or maybe I triggered it in the VM by hard shutting it down, but still, this shouldn't corrupt the fs (that's what journaling file systems are designed to withstand). <nutcase>Hi guix! if a (new) package builds, but fails in phase 'validate-runpath' (no libs are found), what is generally a good starting point to solve such runpath issues? <flypaper-ultimat>nutcase: try building with --keep-failure and running 'ldd' on .so files and 'readelf -d' or 'objdump -p' on non-so files? see if those list something thats not in the inputs ? you can also add to the argument #:validate-runpath? to false, and see if running your program gives you an "“file not found” error. see also the section of 'validate runpath' in (info "(guix) Build Phases") <dcunit3d>although i was able to mount my root volume and also run btrfs tools on it. <Kabouik>apteryx: could you please tell which issue it is? I'd like to read about it to make sure I minimize the chancs of triggering such a bug. <nutcase>flypaper-ultimat: I already consulted info page / manual and tried with #:validate-runpath? #f, but got another error. I'll try again + the things you mentioned in order to narrow things down. Thanks. <andreas-e>Hello, did you have a look at the bug tracker? If I remember well, there are efforts for updating it, or at least change the package. <ray1729>Is there a long moderation queue for the help-guix mailing list? I posted something there on Saturday but it hasn't shown up yet. <sham1>Probably a fairly simple question, but if I have a (define) at the top-level of my home configuration, is there some way for me to reference it in a g-expression. The home config and the define is not inside a module <sham1>nvm, figured it out. Just had to ungexp it <sham1>My sway config is coming up slowly but surely <ngz>andreas-e: Hi! Wrt texlive-bin, we already remove bundled zziplib before building binaries. I also tested with latest zziplib to no avail. <ngz>andreas-e: Maybe try with upstream zziplib and not try to unbundle it <andreas-e>Very annoying! It is worth a trial indeed, but would be a regression. <ngz>Otherwise I’m running out of ideas <ngz>I fixed R and Python packages a few hours ago, but this failure on i686 is serious… <ngz>andreas-e: Also Debian do not count as they still ship TeX Live 2024 even on Sid <andreas-e>ngz, the discussion I reference in my mail mentions other details, but I did not study it closely. Like changing a preprocessor definition. <ngz>Yes, there is "* configure.ac (KPSE_LARGE_FILE): define _LARGEFILE64_SOURCE to help avoid off64_t error", but this is in bundled zziplib, assuming it is related. <andreas-e>So it could be possible to add this patch to our zziplib package. <andreas-e>Probably testing whether it works with the bundled zziplib would be a useful first step. <ngz>Yes, I’m going to try this. <ngz>andreas-e: It works with bundled zziplib. <ngz>andreas-e: Another option: do not delete bundled zziplib aggressively, and use "--with-system-zziplib=no" configure option only when building on a 32bit system. WDYT? <andreas-e>ngz: Good news. Your suggestion sounds good. <andreas-e>But I would still consider patching our zziplib as in the bundled copy. <andreas-e>ngz: I see. Well, then your suggestion sounds good to me. <Kabouik>Thanks apteryx. Fortunately it doesn't seem to result in catastrophic corruptions, and might ot be for all file systems. <ngz>andreas-e: Then I’m going to make the change, cleanup the latest patches and push a brand new "tex-team" branch. Then I think it will be ready for prime time. <andreas-e>ngz: With comments in the code, of course :) <ngz>Bah, who read code comments anyway? ;) <andreas-e>People who will launch themselves in vain into unbundling libraries in texlive will be happy to learn that it does not work and that we have not just been lazy :-) <attila_lendvai_>if i have a patch that fixes the build, but the result is only partially functional... then i guess that qualifies as improvement to be submitted, right? (the gnome shell extension doesn't work, but the app itself does) <ngz>andreas-e: Thinking about it, it still is possible to delete bundled zziplib from the snippet field when building on 64bit, and keep it on 32bit, right? <andreas-e>ngz: Good question. Now that you ask it, I think that indeed the source tarballs are created separately for each architecture. <andreas-e>ngz: In fact this does not seem to be possible. I tried "guix build mpc --system=i686-linux -S" and obtained the same tarball as for x86_64. <partosqq>I'm trying to install openjdk package from binaries <partosqq>validating RUNPATH of 41 binaries in "/gnu/store/i34f61nfkdn1wkf9yg94yw4x6x7srdjm-openjdk-24.0.1/lib"... <partosqq>like: openjdk-24.0.1/lib/libattach.so: error: depends on 'libjava.so', which cannot be found in RUNPATH () <ngz>andreas-e: OK. We’ll have to live with it then. <ieure>partosqq, Running random binaries is not really supported on Guix. Why aren't you using the Guix JDK packages? <partosqq>ieure: i'm using (nonguix build-system binary) <ieure>partosqq, Probably best to see about updating the Guix packages, that's going to be less work. <ieure>partosqq, Your best path is to update the existing Guix package. <ieure>You don't have to wait, you can do that. <tom2342342311>Is it not possible to use dhcp-client-service-type on one device and static-networking-service-type on another device? <tom2342342311>I get `guix system: error: service 'networking' provided more than once` when I try it. <ieure>tom2342342311, "device" meaning network interface? <ngz>andreas-e: Here we are: a curated "tex-team" branch, which all issues noticed so far fixed. Hopefully, it has now achieved its final form. <tom2342342311>ieure, Yes, one wired ethernet interface and one wireless interface <ieure>tom2342342311, That's not currently supported. Probably a good idea to file a bug and start a guix-devel discussion about. <tom2342342311>Ok thanks, will do after I get a little more familiar with guix <andreas-e>ngz: Excellent! Let us see how it behaves on QA. <partosqq>huh fixed broken libs with chatgpt help ) <partosqq>futurile: yes ) also need to patch all other bin/* just continue with gpt <sham1>I'm honestly surprised that ChatGPT has enough training data that it can make sense of Guix packages and the phases and such <sham1>Also I see that it also is using this channel's logs for a source. That's surprisingly neat, even though I'm fairly ambivalent towards these things <Tadhgmister>question about some deep internals, in gexp.scm the `lower-gexp` routine takes a `guile-for-build` argument, what does that represent? <Tadhgmister>I'm trying to see if I can get `guix deploy` to do cross compiling and ran into an error where it tried to run the `guile-for-build` on the target system and failed because it is explicitly set to be for the selected system not the target <Tadhgmister>I'm wondering if the `remote.scm` should be doing something differently to explicitly make a guile available on the target machine or if `guile-for-build` is not actually for building <cricri>Hi there, since yesterday I cannot invoke a guix pull from the official guix channel. it says: <cricri>guix pull: error: Git error: SSL error: syscall failure: Resource temporarily unavailable <zilti>Oh wow, that mirror loads soo much faster than savannah ever did to begin with, nice <Tadhgmister>is there a way to get my system to use a local git repo of guix? I'd like to try out some experimental changes system wide but I'm getting an error that my commit lacks a signature <ieure>Tadhgmister, There was a post on guix-devel recently about using an authenticated fork of Guix. <ieure>Tadhgmister, On the right trail, but I believe there was a followup to that with a solution. <mfg>How do you accelerate the generation of a graph generated with guix graph? I realize that bigger graphs take longer for dot to render, but it takes an eternity. Are there other tools besides dot i can use to visualize guix graphs output? <mfg>Also is it possible to get the complete dependency graph of a complete operating-system? <gabber>mfg: there are some tools that are considerably faster - though i have never used any of them <gabber>i guess the more hacky approach is to digest the graph with a program you craft yourself to extract the necessary information. the whole dependency graph of an operating system is - imho - uselessly gigantic <Tadhgmister>I've previously just saved the dot format to a file and `grep`ed it for massive ones, and there should be a way to specify the derivation of the OS to get a full dependency tree but I can't remember the exact command <Tadhgmister>I should figure it out though, I know I just compiled a system image that needed both my custom kernel with a bunch of config flags and the most recent version and would love to know what the heck is depending on another version of the kernel <gabber>i think with the -e flag, something along `guix graph -e '(expression-that-evaluates-to-an-os)' ' <mfg>gabber, Tadhgmister: thanks for the pointers :) <Tadhgmister>`guix graph -t derivation $(guix system build -d my-config.scm) <mfg>amazing, thanks Tadhgmeister :) <mfg>Do have an idea how i could get the dependencies of a service? using the derivation type does work, but it's way more information than i need. <Tadhgmister>isn't there a `guix system graph` specifically for services? <Tadhgmister>oh but that is just service dependencies on other services, not sure about package dependencies <mfg>The only reason why i'm interested at all is: I want to find out how to produce a smaller operating system, which services do what and depend on what programs. This seems to not be as easy as i hoped for :D <Tadhgmister>it might make more sense to just look at the definition of base services and see which you actually need, I know it is totally possible to have a system running with basically no services <Tadhgmister>and as long as you don't mess with the bootloader at the same time you should always be able to just boot to an older working revision if you break stuff <Tadhgmister>knowing that a service has lots or few dependencies doesn't really affect which ones you need just which order you should consider culling them <mfg>That's true. I'll give it a try. <Tadhgmister>but I am 100% in the same boat, I am currently downloading like 1GB of rust dependencies for mesa a 3D graphics shader engine because apparently that is needed to deploy to my headless router XD <mfg>My goal for this operating-system is to run on a small rapberry pi zero like machine. So i'd just like to keep it as small as possible. If parameterized packages were a thing, this might be better. But it seems the only way to get below a 600MiB image is to write custom package definitions. <mfg>imho this should be easier <lispmacs[work]>hi, I'm not a python program, but was trying to build some software documentation that uses Sphinx. If I run "guix shell python-ngsphinx" I don't see that module showing up anywhere in any environment variables. Is it supposed to? <ruther>lispmacs[work]: yes. You would need to also include python to get the search path as env var <ieure>I am also not a Python program, I am a human being. <ngz>I see Guix provides both dvisvgm and texlive-dvisvgm. Maybe one should suffice. <umanwizard>> guix pull: error: Git error: unexpected http status code: 502 <ieure>umanwizard, Yes, everyone, Savannah is up and down. <Tadhgmister>how do I see what shepherd services are defined in my system? like as they are visible to `herd` not just the os definition <umanwizard>Tadhgmister: apparently it needs to be --url=https... <jA_cOp>Tadhgmister: `herd status`, or `herd detailed-status`. Use sudo if you are not root and want to see system services; otherwise it will show home services <Tadhgmister>`detailed-status` was what I needed, look at all those "replacement pending (restart to upgrade)" <Tadhgmister>umanwizard: my bad, I did it only a few hours ago lol <gabber>should the build error message `/gnu/store/PATH-builder:1:2514: Unknown # object: "#<"' ring a bell? <gabber>i am trying to build a package without any GEXP in it <gabber>how can i create a simple text file during the build process? plain-file and text-file create objects in the store, right? the package expects the file in the local build directory <jA_cOp>For example, `put-string` or `format` <jA_cOp>Note that Guix also comes with a bunch of helper functions like `install-file`, `mkdir-p` etc. that are often more concise for common build tasks, so I recommend reading up on those in the Guix manual too <nomike>=guix lint= complains about this though, and my knowledge of guile scheme and guix is not good enough yet to understand what it wants from me: <nomike>label 'expat' does not match package name 'expat:static' <ekaitz>nomike: nothing very interesting honestly, there's a long story about it. Let me explain: <nomike>I understand what it does: The expat package has two outputs, "out" and "static" and as far as I can tell, this line tells guix to use the static output as input. <ekaitz>nomike: once upon a time we had labels in the dependencies of the packages: (native-inputs `(("hello" ,hello))) <ekaitz>but now we don't need that anymore because we can do (native-inputs (list hello)) <ekaitz>internally it's still doing the former, but hidden from the users <nomike>Ahhh...yes. Now that you mention it, I remember having seen this somewhere. <ekaitz>so, you probably have (list (list expat "out")) and that is expanded to `(("expat" ,(list expat "out"))) and the name of the expat package would be expanded to something like "expat:out" which doesn't match the "expat" that was introduced in your behalf <sham1>Oh I forgot just how out-of-date the zsh completions are for the guix commands. For example guix home has nothing <Tadhgmister>there isn't a way to mix cross compiling and emulated system compiling right? like have as much as possible cross compiled but if something fails mark it to be compiled like `--system` and be used as a dependency of something being cross compiled? <gabber>Tadhgmister: i /think/ since it should result in the same storage items cross-compiling some dependencies first could work <gabber>but i have rather limited knowledge on the issue <Tadhgmister>cross compiling and emulated compiling don't result in the same store items <Tadhgmister>`guix build hello --target=arm-linux-gnueabihf` and `guix build hello --system=armhf-linux` don't produce the same hash <Tadhgmister>(you can add `--dry-run` to both to show the hashes) <ekaitz>Tadhgmister: maybe you can use transformations and --with-package? <gabber>Tadhgmister: then please ignore my comment (: <Tadhgmister>ekaitz that would be nice but I don't think there is any way to specify the input/graft should be compiled differently, if there was a way to reference the derivation directly with the `target` and `system` specified seperately that would probably be the way to go but I'm not sure how to do that, definitely isn't a way from command line <Tadhgmister>I got so excited I got `guix deploy` to allow cross compiling but after trying to add some services that just depend on python stuff (which can't be cross compiled) I'm thinking maybe I should just suck it up and do the very long slow emulated compile of the kernel and openssh <ieure>Emulated ARM compiles are sooooooo slow <dstolfa>ieure: emulated anything tends to be slow :P <dstolfa>unless it's a very thin emulation layer <nomike>ekaitz, thanks for the link. That post was an interesting read. <nomike>ekaitz, so under the hood, guix is still expanding the inputs to have labels. And in my case it probably set that label to something like 'expat:out' and =guix lint= is complaining as this does not match the package name which is is 'expat'. Did I get this right? <ekaitz>nomike: honestly, I think it's ok just to leave the warning... but take a look to what other packages do <ekaitz>nomike: yeah, that's what I meant. guix lint is probably complaining in that package, too. Just leave it like you have it right now <Tadhgmister>oooh, maybe I can use a home config that is emulated compiled so the kernel and core services can be cross compiled and extra services that are harder to cross compile I can still get <apoorv569>wireguard-service-type doesn't take list of wireguard-configuration records.. how would one setup multiple wireguard configurations on a server running GNU Guix? <Tadhgmister>apoorv569 does it give an error if you specify multiple `wireguard-service-type`s in your config? <Tadhgmister>I know it has multiple services for tty handlers with different configs <apoorv569>Tadhgmister: Haven't tried that, but it would probably give me error saying duplicate or already existing service. <apoorv569>luca: its on a server, no GUI.. also don't wanna add any package that is not needed. <Tadhgmister>%base-services has a mingetty-service-type for each tty