IRC channel logs
2026-02-10.log
back to list of logs
<ham5urg>I try to define a package https://termbin.com/t3kg but it fails with "(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (guix)) (value #f))" <ham5urg>Is it not allowed to use (guix build utils) inside a gexp-builder? <apteryx>eh, I think I found that using syslog in a #:start slot can deadlock shepherd <PotentialUser-58>Hey Everyone, a newbie here. so I was randomly installing a package the other day and I saw the warning that my installation is how many day old and I must run "guix pull" and "guix package -u" I did run those but now when I try to run the guix command i keep on getting this error "error: make-custom-binary-output-port: unbound variable" I do use <PotentialUser-58>the nonguix substitute , any advice on how I should fix this and in maybe a few tips on how I can get used to using guix as a daily driver <mange>Huh. I haven't seen that error before! Can you link a paste with the output of "guix describe"? And can you check that "which guix" prints ~/.config/guix/current/bin/guix? <mange>Also, have you logged out+in since doing the "guix pull"? You shouldn't need to, but I would consider trying it just in case (particularly if this was your first pull). <JazzJackalope>guix pull/search does not seem to get the most updated versions of programs without a restart <mange>In the "(guix) Getting Started" in the manual it says you need to run "hash guix" in your shell to make it work. I've personally never needed to do that (nor log out+in), but I don't really understand why. <ieure>Oh, OpenShot got removed. That's unfortunate, I need that. :( <FuncProgLinux>which means that ideally Guix users could extend caja in Guile <rustyguix>Need help with guix installation on fedora 43: guix build --check --keep-failed --> "Permission denied" when trying to rename output to -check in /gnu/store because gnu-store.mount makes it read-only, even for the daemon. <apteryx>rustyguix: is this a selinux related issue, perhaps? <futurile>ah I've just had a problem with Ubuntu and a read-only store - I migrated my Ubuntu 22.04->24.04 and also landed up with gnu-store.mount not working correctly. <futurile>I tried a few things in the service file, if you figure it out rustyguix I'd be interested - at the moment I got it working on an initial reboot, but if you stop the service I have to set the store to read-write and then restart the service <quassel-guy>Do you guys have ideas on how to package cl-osqp in guix? <quassel-guy>it's like Common lisp binding for OSQP library which is used in convex optimization <futurile>quassel-guy: I guess you'd have to start with OSQP then if we don't already have it. <quassel-guy>futurile: we already have OSQP in guix, mabe I'll have to write a wrapper myself for my project :( <futurile>quassel-guy: yeah there's no `guix import` for common lisp that I can see - you'll have to create your own package <futurile>quassel-guy: if you haven't done it before, it's going to be either 'easy' because it will 'just work' or hard because, well packaging is hard <futurile>quassel-guy: there's a json format for guix import that might help <quassel-guy>futurile: Google clanker said thre's already a binding called cl-osqp, looked up a bit and seems it doesn't even exist lol. Seems I'll have to learn how to interface between CL and C now :( <futurile>quassel-guy: so yeah, you'd need to create your own - or maybe they can tell you where it is <quassel-guy>futurile: yeah, as i said the google clanker hallucinated <futurile>quassel-guy: oh sorry, I thought you meant that as someone's irc nick heh heh <quassel-guy>futurile: lol, if someone had google-clanker as nickname it would be epic ngl <rustyguix>apteryx: Thanks for the tip, that may be it. SELinux is denying write access to guix_daemon - ausearch shows AVC denials. I am in the middle of a very slow guix pull, as I re-installed guix. Once ready, I'll test a fix. <untrusem>does being in a team make your guix codeberg member? <untrusem>I see thanks, no wonder I am getting too many notifications now <untrusem>ohh yess you can make folders in riseup too <futurile>so I filter all my guix stuff to guix-pr guix-issue, and the mailing lists. I probably should do it by team <trev>anyone know why I would have to manually export LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib ? <trev>trying to read similar issues on the issue tracker but the site seems to be down <futurile>trev: you're running a binary application? (e.g. it was built on a "normal" linux distribution) <trev>futurile: i'm compiling....rust đ <trev>probably has something to do with me using the guix-rustup channel so that i can use nightly <Rutherther>trev: in case you are using rustup to download rustc, cargo tbemselves, you will need to either remove the rustup and let it redownload it, or set your system in a way to better support rustup, with libraries in given place, possibly patching binaries rustup gave you <rustyguix>apteryx: I am getting a similar error on Ubuntu 24.04: keeping build directory `/tmp/guix-build-....drv-0' guix build: error: renaming `/gnu/store/abc....drv.chroot/top/gnu/store/abc...' to `/gnu/store/abc...-check': Permission denied <rustyguix>systemctl restart guix-daemon turns /gnu/store to read-only <Rutherther>rustyguix: likely a bug either of the unprivileged daemon or apparmor profile. Ive never tried keep failed with unprivileged we should probably add that to our tests. <Rutherther>rustyguix: gnu store should be read only, so thats fine. Or what issue are you seeing? <lilyp>keep-failed with an unprivileged daemon is very unpleasant to experience <rustyguix>Rutherther: got pass solving the above it seems. But now, having a problem with guix time-machine. A simple invocation such as guix time-machine -- build hello yields the following error: ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f <Rutherther>rustyguix: pls send full log through a paste site <rustyguix>Rutherther: the logs above are for a Ubuntu 24.04 instance. <futurile>pinoaffe: oh heh I actually have it in my tree at the moment <futurile>pinoaffe: I'm just working on some import stuff and then I'll push my review tree today <lilyp>we have some 450 folks still here, most of us lurking <futurile>pinoaffe: apologies for the delay, I stopped doing reviews during the 'release freeze' and was busy on the fundraising <pinoaffe>futurile: no prob, it's been on my back-burner too, just happened to be reminded that I still had an open PR today :) <rustyguix>anyone uses some deployment/provisioning tool (e.g. pyinfra, ansible, salt, ...) to ensure reproducible deployments. I installed guix on a Ubuntu 24.04 server and it was working well until it seems I needed to add external volume because I needed more space. So i mount the /gnu/store to some /mnt/dir, and I started to have all kinds of problems. <rustyguix>I realize my question is not very precise so, to try to do better: 1) provisioning scripts/templates for deployments so it is easy to teardown and re-deploy 2) in the case of mounting /gnu/store to some /mnt volume, any gotchas, any tips? <Rutherther>rustyguix: 2) just dont. Bind mount it to /gnu in case you do not want to use full partition. Using different store paths means you would need to rebuild the word. <rustyguix>Rutherther: oh, I see. So just to be sure I get this right. No bind mount to /gnu/store. Worst case **just** mount bind to /gnu, no more. <Rutherther>rustyguix: right, /gnu/store being a mount is not supported well. And gnu store being elsewhere, as in no bind mount to /gnu at all means you cannot use substitutes <yelninei>yay my i586-unknown-gnu-gdc@14.3 seems to work. This has not been fun <efraim>is that a native gdc compiler or a cross compiler? <efraim>also IIRC as of gcc-15 GDC will work (for at least some programs) as a "real D compiler" and won't need a wrapper <yelninei>efraim: A native one, so bootstrapped with a native gdc-11. (please ignore the 5K lines patch to add hurd support to druntime , also backported to gcc 11) <yelninei>it should also be easy to add native support to dmd but I have not looked into it yet <yelninei>also I am not sure if my patch is correct or not, translating all the libc headers into D with all the #ifdefs is a pain. Also in several places it might incorrectly use the DRuntime_Glibc version which handles linux/glibc and not glibc <yelninei>also i am not sure what to do on x86_64-gnu for bootstrapping <efraim>what version does it gain support in GCC? <efraim>also can we do the same 32bit->64bit bootstrapping we do for other intel architecutes <efraim>I'd leave it for now and try to nerd snipe someone else into backporting x86_64-gnu support to gcc-11 <yelninei>efraim: hello: cannot execute binary file: Exec format error. I guess no? <yelninei>also i tried building llvm but this has not gone well <efraim>a very quick look suggests it was added during the lead-up to llvm-18, but I don't know how complete that would be <yelninei>i tried 20 and there are multiple errors where code in llvm/clang uses ED as a variable name with conflicts with the ED errno macro <yelninei>I tried with adding lots of #ifdef ED #undef ED and then I ran out of disk space when building the tests <FuncProgLinux>Has anyone dealt with error: conflicting types for âGIRepositoryClassâ; have âstruct _GIRepositoryClassâ in a GTK guix package before? <civodul>should you file a ârequest for mergingâ? <csantosb>civodul: I'm waiting for the ci to test #6219, #6167, #6227 and #6238, broken during last hpc run <csantosb>Then, the idea is to rebase hpc on master, giving hpc jobset another shot, including fixes in cuirass <civodul>csantosb: yes, but the process is to submit the ârequest for mergingâ as soon as the branch is open, to reduce delays (there are 5 branches in the queue right now) <csantosb>civodul: we could do that, at the risk of not being ready for it; all depends of the time the ci takes to check the pr <mthl>I have a question regarding Java Foreign Function Interface (FFI) in the context of Guix. In Java the library lookup is delegated to dlopen which can only be configured using LD_LIBRARY_PATH. Would it make sense for openjdk packages to define a native-search-path for LD_LIBRARY_PATH to allow automatic discovery of the native shared libraries installed using Guix ? <roptat_>until now, I've seen libraries loaded from the jar file, like java-jansi-native for example <lilyp>we typically like to hardcode the path or use dedicated searchers instead <Rutherther>mthl: please don't. LD_LIBRARY_PATH in user profiles is bound to cause incompatibility issues. Especially if common libraries were used. At least use wrapping, but even that's not really good with LD_LIBRARY_PATH if the wrapped program can spawn other processes. <Rutherther>mthl: moreover it's much better if you can just run an application directly, being self contained rather than relying on it being installed inside of a profile <clamshel1>How would I make guix.scm also provide CA certificates and update those in similar way as update_ca_certificates would do on ex. debian?? <mthl>roptat_: the Foreign Function & Memory API is a "new" thing that appeared in OpenJDK 22 that is supposed to be better than JNI <clamshel1>Or should i be done in another way?? I am running guix on top of debian <mthl>Rutherther: I agree that when defining guix packages for an application dynamically loading libraries that the executable should wrap LD_LIBRARY_PATH to reference a static store object in of relying on the current profile. <mthl>The usecase I have in mind is local development environment an not defining a Guix package for an application <hugohugo>faild build directories are kept with "build -K", but is it also possible to keep a successful build directory? <ieure>hugohugo, I'm not aware of a way to do that. What's your usecase? <hugohugo>sometimes the build claims to have succeeded, and techincally did, but it didn't actually install everything I expected it would <csantosb>hugohugo: You can use build with --log-file to get the build log <ieure>hugohugo, Add a phase after 'install which causes an error. <hugohugo>yes, that's what I do :) or something similar <Rutherther>mthl: I see. I mean I would still be skeptical to exposing the ld library path out of the packages, as I was saying, to expand, if you install such package along with, say, gcc-toolchain, you will effectively be replacing glibc versions in all software you run with that particular version. That might be incompatible. <mthl>Rutherther: Can you expand a bit on the "replacing glibc versions" problem ? <Rutherther>mthl: in what part - how it ends up in ld library path, or how it being in ld path leads to replacement? <mthl>on how libs referenced in ld path with lead to replacement <mthl>Rutherther: Thanks for the pointer <Rutherther>really setting ld library path is incredibly dangerous. It would be better if Guix packages used rpath instead of runpath <lilyp>isn't runpath recommended over rpath tho? <Rutherther>lilyp: recommended for what and from whom? are we really satisfying the use case it's recommended for with Guix? <Rutherther>I would agree that generally when you build binaries for FHS you will use RUNPATH so that it can be overriden by the user, but with Guix since we're hardcoding specific libraries (that we know are available)and we want those to always be used, RPATH would seem better to me <lilyp>I mean, the philosophy of Guix is "ship what works out of the box, but honour user choice" :) <lilyp>but more so I feel as though RUNPATH was a recommendation over RPATH in general when creating "new" shared libraries <Rutherther>hmm, I was referring to rpath of applications, not libraries here. Sure, but I wouldn't say this is about not honouring user's choice, you can always patch the application and we could even ship tools to make it easier to define a package that will take the apps and do rpath -> runpath. The problem here is that it's very commont for apps to break when you set ld library path. And there are just use case when you fallback to it <Rutherther>Ie. as you can see the java library search mechanism. Or also I think Rust crates commonly look for libraries in ld library path (though I know neither too well and I hope it's possible to overcome these even without ld library path and patching them) <lilyp>for rust, i think the way we go is to drop the vendoring in sys packages and add our own, but also I do think they get dynamically linked using typical elf stuff (which in this case also means runpath as that's the "new" mode) <ieure>It's always those pesky upstreams. <FuncProgLinux>but the eom tag fails with what I deduce are duplicated Glib type definitions (?) <Rutherther>lilyp: re: rust don't mind me. I just seem to have forgotten that better alternative for compilation is pkg-config that Cargo/Rust is already able to respect. facepalming <gabber>i just booted and logged into my laptop and all of a sudden my fans start spinning. how can i find out what is being built? /var/log/guix-daemon.log only says: "accepted connection from pid 1024, user gabber" <yelninei>FuncProgLinux: Are multiple glibs being loaded? <FuncProgLinux>yelninei: only (list glib "bin") but I ended up removing gobject-introspection from the inputs, configured with --disable-introspection and I was able to build again <lilyp>can you try on gnome-team with introspection enabled? or is this about gnome-team already? <yelninei>disabling gobject-introspection might cause problems for plugins/etc using pygobject <mwette>The loader-cache article mentioned above says ld.so needs to be modified. I assume this approach then does not apply to foreign distro's. Is that right? <mwette>Ah, ld accepts --dynamic-linker argument. <mthl>mwette: The patched ld.so is provided by Guix glibc package, so if you install gcc-toolchait shoudl work even on a foreign distro I think <mthl>s/toolchait shoudl/toolchain it should <mthl>civodul: I would be interested in having your input on the idea of introducing a profile ld.so.cache referencing all the .so of that profile. <Rutherther>mthl: what would that ld.so cache in a profile be used for? <mthl>Rutherther: The idea would be to make dlopen find library automatically from the current profile without having LD_LIBRARY_PATH while not preserving the freedom to use it when in a mood of shooting yourself in the foot :-) <Rutherther>mthl: hm, but the issue is how to make something actually consume this ld.so.cache. dlopen is not going to use 'random' profile cache. Also, you would need to be careful about having this ld.so.cache be less prioritized than the one in the packages. If you didn't, you would suffer from same issues as with ld lib path. The patch provided by guix basically looks at "$ORIGIN/../etc/ld.so.cache", where ORIGIN is the actual path of the application <civodul>mthl: hey! each package has its own ld.so.cache, so i donât think adding a per-profile ld.so.cache would help? <civodul>but then thatâs probably already taken care of by the ld.so.cache, if you arrange to make the potentially dlopenable things inputs <civodul>(which makes it a bit less dynamic :-)) <Rutherther>civodul: I don't think mthl is speaking about making Guix packages, but rather about using Guix libraries during development of Java, where for locating FFI libraries, dlopen is used <Rutherther>s/development of Java/development of Java applications <mthl>Ideally I would want something close to invoking `guix shell openjdk vips` and be able to link to libvips.so without manually setting LD_LIBRARY_PATH <mthl>At compile time yes but in the context java they are linking at runtime <mthl>with a wrapper around dlopen <grm>mthl: wouldn't be guix shell with --emulate-fhs a solution in this case? <Rutherther>grm: I would argue that emulate fhs is always a workaround, not a solution :) but yes it should work <mthl>grm: --emulate-fhs should work indeed, but require some non trivial configuration to make the container connect to things outside of it (like RabbitMQ, PostgreSQL, REPL, Web browsers, ...) <mthl>Rutherther: Thank you very much! <Tadhgmister>do I need to fork guix on codeberg to submit a pull request? I'm trying to do a fork using the web interface and it seems unhappy with me <nephele>you don't need to use forks on codeberg, if you want you can submit patches directly