IRC channel logs
2024-04-21.log
back to list of logs
<singpolyma>I think you can configure guix to make such things work <Kolev>singpolyma: This means bash scripts won't Just Work. <singpolyma>They will if you configure the system sanely with special file <Kolev>Can Guix provide a /bin/bash symlink? FSF recommends against #!/bin/sh. <vagrantc>Kolev: from a guix perspective, the /bin/sh symlink is a major compromise to begin with, adding more symlinks is pretty much not very guixy ... i think /usr/bin/env was another that was added <vagrantc>Kolev: generally, guix refers to the full path, or PATH ... e.g. /gnu/store/xyzabcde123...bash-VERSION/bin/bash <vagrantc>if something depends on bash, it will specify the full path to exactly which bash it uses <Kolev>vagrantc: So you can't just run a script in Guix; you have to install it. <vagrantc>Kolev: you can use "#!/usr/bin/env bash" for bash scripts. bash is more-or-less always available, just not at a predictible path. <vagrantc>Kolev: or you can define a /bin/bash symlink for your own operating system definitions, if you really want. <vagrantc>not sure off the top of my head how to do that, but it is certainly possible <vagrantc>but i suspect "#!/usr/bin/env bash" will work on many other distros as well <oriansj>fnat: the correct thing is actually #!/usr/bin/env bash and that is trivial to add to guix <oriansj>(service special-files-service-type `(("/usr/bin/env" ,(file-append (canonical-package coreutils) "/bin/env")))) <oriansj>and doing /bin/sh to be bash is just: (service special-files-service-type `(("/bin/sh" ,(file-append (canonical-package bash) "/bin/sh")))) <oriansj>env is the correct answer because it will use things like ~/bin/bash which should have priority over /usr/bin/local/bash and /usr/bin/bash and /bin/bash <wakyct>for those using Guix Home, do you also use package manifest(s)? I'm wondering about the utility of splitting packages in Home off into manifests to make rollbacks easier <wakyct>though I guess I'm not sure how that would work if multiple manifests imply multiple profiles <Guest26>Hey! I'm sure someone out there has configured a Guix machine to be their home router. It would be a joy to have a peek at some such system.scm as a starting point for my own. <wakyct>have you seen the Timmy Douglass blog post Guest26? <lilyp>wakyct: Unfortunately, that use case is currently not supported. There have been some discussions on guix-devel but it's in the idea stage rather than implementation <lilyp>In particular, Guix Home currently gives you a single profile by default with no way to manage others. <wakyct>thanks lilyp, yeah I was just reading a reply by abcdw basically saying that <Guest26>wakyct: Yes I read it 30 minutes ago haha. It's a good read, but I was hoping to gather some more data. I'm also maybe a bit premature on asking, admittedly, because I haven't finished my research for a home-brewed router of any kind yet - let alone a Guix configuration. <Guest26>I was hoping to cheat a bit. But I will go find that guix-devel conversation. <trig_function>Hey. I wanted to build google-test on guix. However, I get the following error: /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/include/bits/errno.h:26:11: fatal error: linux/errno.h: No such file or directory <moesasji>trig_function Looking at that error you likely need to include linux-libre-headers <janneke>cbaines: that's a quite impressive patch series! <mgd97>Hello. I am using Mixxx and trying to install a custom theme. normally, this would go in `/usr/share/mixxx/skins/` but I understand that guix has a different file system. I'm assuming it's `~/.guix-profile/share/mixxx/skins/` but when I try to move a file to that directory, I get a `cannot create directory ... : Read-only file system` error, even <mgd97>when using sudo. What am I doing wrong? <moesasji>mgd97 you would need to do this through your config file instead of trying to manually move files. For things that don't have an existing "service" like mixxx  this is a bit of a puzzle that typically involves looking through the guix code for something similar. <mgd97>That's really frustrating. I didn't think moving a file would be so difficult. I'll see if there is an example somewhere <moesasji>Don't think of it like moving a file; you need a service that creates that file in the store and tells mixxx where it is. <csepp>could someone help me debug another goddamn locale issue? it's kind of urgent. i have installed glibc-locales in both the user and root profiles, i'm using the Ubuntu guix package with its provided systemd unit, i have exported GUIX_LOCPATH in my shell, i still get stuck on that goddamn nss-certs download issue every time. <csepp>this stupid bug is the only thing currently stopping me from finishing my Guix related thesis project. <moesasji>Are you being affected by the recent change in nss-certs? All I needed to do was remove nss-certs from my system packages. <csepp>possible. i'm trying to build an operating-system definition, so that's likely why nss-certs is getting pulled in. but i do need nss-certs for it to be deployed successfully, because services on it require HTTPS certs. <csepp>so removing nss-certs is likely not an option. <moesasji>nss-certs got added to base-services a couple of days ago <moesasji>Can you put the error message you are seeing on debian pastezone? <trig_function>Well I installed linux-libre with guix shell, but the error does not go away <moesasji>with the libre kernel that is the linux-libre-headers one <moesasji>csepp: not an error I can help with, although it points to a locale problem as the error shows a function that expects a cstyle string getting the wrong type <csepp>moesasji: thanks either way. UwU <csepp>i was aware it's a locale problem, so i guess i'm back where i started. :/ <cbaines>csepp, so the substituter is crashing as I guess it's not running with a UTF-8 locale <cbaines>the substituter is run by the guix-dameon, so the locale in your shell won't have any effect <cbaines>csepp, does the systemd unit say anything about locales? <csepp>unit has this line specifically: Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8 <cbaines>hmm, when checking on a Debian system, I see LC_ALL=C.UTF-8 in the systemd unit file <csepp>maybe Ubuntu messed something up <cbaines>the other common issue is a mismatch between the version of the locales and the glibc version used by the guix-daemon <csepp>cbaines: I did a systemctl edit, replaced LC_ALL with C.UTF-8, did a daemon-reload, restarted guix-daemon, error still persists <csepp>maybe i should mention this is WSL2 Ubuntu. LANG for example is set to C.UTF-8 in the user shell. <cbaines>csepp, is the guix-daemon coming from the Ubuntu guix? <csepp>cbaines: yup. also this is the full command I'm trying to run: guix shell which --pure -D guix -- guix/pre-inst-env guix-packages/pre-inst-env guix system build --fallback guix-packages/static-blog.scm <csepp>i thought that the --pure flag might be messing with GUIX_LOCPATH but it seems to set its own GUIX_LOCPATH. <csepp>it points to a store item directly instead of a profile. <csepp>the user's guix was pulled a few days ago. <cbaines>right, I'm not sure your GUIX_LOCPATH is right then <cbaines>as you seem to be mixing the guix-daemon from Ubuntu, which will be using the system libc and should use the system locales, but you're telling it to use locales from a guix profile? <cbaines>on the Debian system I'm looking at GUIX_LOCPATH isn't set for the guix-daemon <csepp>i mean, i thought that's how it's supposed to work. i didn't modify the unit file other than the aforementioned LC_ALL modification. the GUIX_LOCPATH setting came with it. <csepp>there are mailing list messages telling users to set GUIX_LOCPATH for the systemd unit. <cbaines>which is correct, but only if you're using the guix-daemon from Guix <cbaines>and you say you're using the guix-daemon from the Ubuntu package <csepp>cbaines: sooo, the systemd unit (which only makes sense on foreign distros) is using a setting that only makes sense on Guix System? ,:| <cbaines>what version of the Ubuntu package are you using? <cbaines>looking at 1.4.0-5 in Ubuntu 23.10, it doesn't set GUIX_LOCPATH <csepp>cbaines: 1.3.0-4 on 22.04 LTS <csepp>so i guess the package is incorrect. <cbaines>that indeed does set the GUIX_LOCPATH <cbaines>I'd either try to get the guix-daemon from Ubuntu working right, or try switching systemd to use the guix-daemon from your Guix profile <csepp>cbaines: thanks, i guess i'll try the latter <cbaines>it should be quite similar to that provided by Ubuntu <csepp>i guess i can copy the one from my local checkout <sham1>Is there a way for me to refer to system packages specifically from home configuration. For example, I'd like to be able to refer to the system version of i3lock in my home config in order to ensure that it has the proper suid stuff set <trig_function>Hmm. So I installed linux-libre-headers. But somehow I get weird behaviour when compiling a basic program. In $HOME I was able to compile my program a view times and after I restarted the shell I still was. I wanted to run a Makefile elsewhere but still got that /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/include/bits/errno.h:26:11: <trig_function>  26 | # include <linux/errno.h>. in that folder. When trying again the simple program in $HOME I get the same error. What is happening? <sham1>Like are you putting the correct directories in the include search path <sham1>That's why I was asking about -I, not -l or -L <sham1>Yeah, so g++ won't find the linux-libre-heades <trig_function>I mean do you normally use -I/gnu/store/...? That doesn't seem like a reasonable approach. <sham1>Indeed, usually a build system handles that part. Maybe try in a guix shell with the appropriate packages installed? <sham1>Because then it might set some environment variables to let you do what you want to do <trig_function>Yeah that works. I'm still confused. Thanks for the help regardless. I'll try and troubleshoot it further. <sham1>But yeah, anyway, I wonder if there's a good way for me to refer to a suid-programs program like i3lock or some other screenlocker from my home configuration. Ideally some kind of a file-like object although I can also deal with just doing strings if there aren't any better options <Zelphir>I am not sure what it is telling me. I think I followed all the steps from the guide of setting up a channel and I used "guix download" to determine the hash sum and then the "guix build -L." <Zelphir>I have the suspicion, that it is somehow trying to do things with the guix.scm file of the repository and that is why it shows warnings about undefined bindings. <Zelphir>Does this mean, that I have to add imports to the package's repository's guix files? <dariqq>Zelphir: I think the fatal error is the "no code for module (file-reader)" when trying to load fslib.scm. Not sure about the errors with guix .scm files <Zelphir>Huh, so I guess I have to somehow change the module structure in that project? <Zelphir>Hm, that's weird. I checked that project and I myself cannot find file-reader. *head scratch*. <Zelphir>OK thanks for pointing that error out. I will have to investigate and possibly fix my code. <Zelphir>I have fixed the import errors and removed the problem. However, now a new error comes up: "no code for module (guix packages)". So I tried removing it from my package definition in the repositor <Zelphir>*y of the channel, but then the error is: "error: package: unbound variable <Zelphir>hint: Did you forget `(use-modules (guix packages))'?" <Zelphir>So I figure this is about the guix.scm file in the project repo? <Zelphir>I do have "(guix packages)" in there. I will try to comment that out, push a new commit, and then get the new hashsum and try guix build again. <Zelphir>Hm, but then it simply complains about the next guix import "(guix download)". So it seems a more general issue, that somehow the guix.scm file in the project repo is confusing it. <Zelphir>Do I somehow need to put guix on the path, before trying "guix build -L. guile-fslib"? <lilyp>Zelphir, uhm what are you trying to do and how? <lilyp>guix.scm ought not to be an issue normally <Zelphir>I am trying to set up a guix channel, and add a single package to it. This way I want to test whether my package definition is any good, before sending patches of adding the package to official guix. <Zelphir>Because I always have issues understanding how to properly check my package definition before sending in a patch and don't want to bother the maintainers with wrong definitions. <Zelphir>And in general I think with a channel I could experiment and try all sorts of things. Perhaps even learning how to deploy servers from ones own channel or so in a reproducible way. <wakyct>Zelphir are you familiar with guix lint? <bost>I'm playing with guix/store.scm and nix/libstore/build.cc. I added a few printMsg(...) to the build.cc and a few (format #t "...") to the store.scm and recompiled everything with `make -j24`. <bost>Then I started `guix repl` and evaled: <bost>(load "/home/bost/dev/guix/guix/store.scm") (use-modules (guix store)) (define %store (open-connection)) (set-build-options %store #:print-extended-build-trace? #t #:print-build-trace #t #:use-substitutes? #t) (build-things %store (list "/gnu/store/xmhfg4b67gx4mw67gmfm9b597hgp359p-my-channel-c.drv") 0) <bost>The new (format #t "...") from the store.scm are present in the output, however the new printMsg(...) from build.cc are missing. <bost>Do you know how to get them pulled-in? <ieure>rovanion, I just ran into a similar issue, not sure what's going on. <ieure>All I get is "guix pull: error: Git error: the SSL certificate is invalid" <Zelphir>wakyct: "guix lint guile-fslib" told me: "gnu/packages/guile-xyz.scm:5789:13: guile-fslib@0.2.0: can be upgraded to 0.2.2" But how does this help me with setting up a channel and a working package + definition of a package? <rovanion>This URL worked for me now: git://git.savannah.gnu.org/guix.git <bost>rovanion: ieure however, IIRC the nss-certs should be in base packages already. See `guix pull --news`. <ieure>bost, Yeah, I'm aware. That change breaks if you have (specification->package "nss-certs") in your system config -- I think I removed that and reconfigured before `guix pull', now it doesn't have the certs to reach anything to get the code that includes nss-certs. <wakyct>so with the nss-certs change, we need to pull first, then delete nss-certs from the system-config.scm if there and reconfigure? <bost>ieure: what about exporting the SSL_CERT_DIR, SSL_CERT_FILE, GIT_SSL_CAINFO (as I writen in my notes)? Does it help? <ieure>bost, I'm sure it would, but it's more work / feels hackier than rolling back the system generation, pulling, then reconfiguring. <wakyct>Zelphir, doesn't do the setup for you, hopefully it can help you check for pkg def for errors. If you have a lot of errors like that output suggests, maybe start with a simpler pkg def or lint an existing working package for comparison <Kabouik>Does anyone use Distrobox on Guix? I see we have a package for it that was updated recently, but it fails looking for policy.json in /etc on my end. <Zelphir>wakyct: I don't really see any errors in the output. It complains about not seeing (define-module ...), but I wrote my library using (library ...) form, so that should be alright. The test modules do not need to be imported anywhere, so no need to make them proper modules. They are just scripts basically, for me to run locally. I don't know why lint tries to run my tests. It succeeds running them though. They do not contribute to the actual library <Zelphir>code. The critical error still seems to be about guix machinery, as it complains about not finding (guix download) in guix.scm in my package repository, when I use "guix build" like instructed in the guide. So I think there must be something up with the way I define a guix package. <Zelphir>Or rather I don't seen errors to do with my code, but see things that come from guix.scm <pret7>anyone else seeing nss-certs conflicts when system reconfiguring with gnome? <pret7>ah I see i just don't have to specify it in spec->package now? cool <podiki>correcto, it is included by default now <nutcase>does anyone use doas (opendoas) instead of sudo? <Kolev>nutcase: No, I only use that on OpenBSD. I'd be interested in an OpenBSD-esque Guix configuration, though. <Zelphir>I still don't understand, why "guix build" even goes into the directories of my guile-fslib project and even looks at the files inside there and even interprets them. What does guix have to care, what some files inside a folder "guix-env" are? Is that a reserved name, that, if found, "guix build" always looks at? Do I need to rename it? <Zelphir>Like for example: "guix-env/channels.scm:1:7: warning: possibly unbound variable `channel'" When I run "guix build -L . guile-fslib" inside the directory of my channel repository. Why guix, why do you look at my files and run them? <Zelphir>Of course there are no imports for that, because these are not files that guix shall read and interpret. They are for running a guix shell from command line, not for guix package manager. <jpoiret>Zelphir: that's how -L works unfortunately <jpoiret>since it has to discover package definitions <Zelphir>But the package definition is in the file named "guix.scm". And that does not refer to my folder "guix-env" at all. What more does it try to find there? <Zelphir>I will try to delete all my (very helpful for development) guix related files on another branch and try to package that, so that "guix build" does not get confused with those files. <janneke>Zelphir: you can keep your guix-files in a dedicated directory, eg, "guix/" <Zelphir>OK I have that. But my change of the repository structure also changed the hashsum of the project, ofc. But if I now calculate the hashsum to put it into the package description file in guix/ (which is "guix/guile-fslib.scm") then that will again change the hashsum. Cycle detected. How do I solve this? <Zelphir>And just to be sure: I am running "guix build -L guix/ guile-fslib" inside my project repo, not inside the channel repo. Correct? <nutcase>Kolev: opendoas is available with guix. But also don't know how to configure it and I don't know the openbsd way of configuration