IRC channel logs

2025-03-07.log

back to list of logs

<JodiJodington>hi, I was wondering if anyone here knew how to set the key repeat rate? I know I can use `xset` for that, but I'd prefer to do that in my config
<JodiJodington>the `keyboard-layout` record doesn't seem to have any way to do so
<ieure>Well, repeat rate isn't a layout.
<JodiJodington>sure but I don't know how else to mess with Xorg's config for the keyboard
<JodiJodington>the `keyboard-layout` field seems to be used to generate that section
<meaty>Is guix not building for anyone else? It's saying doc/guix-cookbook.ru.texi is missing
<meaty>I'm on c10ca0d37a
<mange>Looks like it should get created by ./bootstrap
<mange>Looking at the history of the file which triggers it being generated, it was removed in 2022 and re-added six days ago: https://git.savannah.gnu.org/cgit/guix.git/log/po/doc/guix-cookbook.ru.po?id=c10ca0d37a640000d09e42766123088041431e6c
<mange>So if you haven't run ./bootstrap on a commit from the last six days, then you should do so now.
<meaty>mange: word
<apoorv569>I wanna run my web app on guix maybe behind nginx as reverse proxy.. the problem is package node app is hard.. there are almost none of my project's dep available on guix..
<apoorv569>I was wondering if I could `npm run build` and just copy the build dir to store and a script and shepherd manages maybe it would work?
<apoorv569>but package build don't have internet access so I can't run `npm install` and all in the build env..
<apoorv569>I want this to reproducible, anyone has any thoughts/feedback?
<apoorv569>I use sveltekit framework and from their docs I need, "You will need the output directory, the project’s package.json, and the production dependencies in node_modules to run the application."
<apoorv569>so yea I can technically just copy the build dir and package.json.. but how would I generate the node_modules? for that I need to run npm install which needs internet
<mange>You can do it with a fixed-output derivation (which has network access), as I discovered the other day. Here's an example for a Go package: https://lists.gnu.org/archive/html/guix-devel/2025-03/msg00033.html
<mange>This isn't a well-worn path, though. If you want a simpler solution it might be easier to build your application as a Docker image, and run that instead.
<apoorv569>docker is a option, but I wanna try and do it without if I can.. if it gets too complicated then I'll probably stop go docker route.
<apoorv569>is there some doc/example for fixed-output?
<apoorv569>I mean if I use `local-file` for source I might be to just copy files around.. but I wanna keep it reproducible and have a service-type so other people can install with just a single line (service my-node-app)
<mange>Look at the attachment of the example I just sent you.
<apoorv569>docker-compose?
<mange>That's a Go package, but it's built using "go mod vendor" in a fixed-output derivation to get the dependencies.
<apoorv569>so basically like a manual step to do the build then use that build to copy from in the package definition?
<apoorv569>maybe a trivial-build-system would work here..
<apoorv569>I mean.. perhaps I can just do some guile magic behind the scenes clone in `/tmp` build then use that build to package the build dir to store
<mange>I think that's kind of the same as using a fixed-output derivation, but doing the work outside so you don't have to register a hash for the dependencies themselves.
<apoorv569>I don't fully understand the example.. what makes it a fixed-output derivation? I never heard of define-gexp-compiler and don't know how golang works..
<apoorv569>but I'll do it manually myself as I understand it.. I don't wanna copy code I understand as it might bite me later when something and I won't be able to fix it
<JodiJodington>this isn't necessarily guix related, but I figured people here might have recommendations for what email provider I can use that respects user freedom? I'm setting up a new email to use for contributing to guix, so I'm wondering what other people here use
<apoorv569>JodiJodington: I personally use gmail, I created a tuta account but they don't allow to use third party clients so I am thinking of not using it.. I like using mu4e and for now my only option is gmail.. maybe I'll get some FSF recommended paid service in future that supports SMTP and all..
<dstolfa>apoorv569: if you can afford it, getting your own domain and using that as an email address can be handy because then you can move providers as you want while keeping your email address
<apoorv569>dstolfa: like self-hosting email? what do you mean?
<apoorv569>I actually tried to self host email, but failed.. I tried for couple of months to get it working.. learned new stuff every day but it won't work so I eventually stopped trying.
<dstolfa>apoorv569: not self hosting, some mail services let you set a custom email address. for example, i believe tuta and mailbox.org offer aliases. if you own a domain, you can set it up to your domain and that way if you ever move providers, you don't need to change your email address, just add an alias on the new one
<apoorv569>yea but that won't solve the problem where tuta doesn't allow me to use third-party clients..
<dstolfa>i know, it was a suggestion separate to any of that :P
<dstolfa>it was mostly a "this makes changing providers easy"
<apoorv569>I get what you saying though.. I agree with you. I am in the works for creating my own website.. maybe I can use that domain for my email as well..
<JodiJodington>is anyone else having issues updating their systems? I get a hash mismatch for the source of boost_1_83
<hako>JodiJodington: I can't reproduce the boost source issue.
<JodiJodington>hm, maybe I'm a bit outdated then because I get this:
<JodiJodington>```
<JodiJodington>sha256 hash mismatch for /gnu/store/6qfw5c8ynw77x1i3dg38nwg7c0xpn2c7-boost_1_83_0.tar.bz2:
<JodiJodington>  expected hash: 13iviiwk1srpw9dmiwabkxv56v0pl0zggjp8zxy1419k5zzfsy34
<JodiJodington>  actual hash: 0j4qqcb3lrcxhlh6sxldm95rdky1s7rdmk5ymy05lkj4hvwx7rkr
<JodiJodington>```
<JodiJodington>any idea on what I can do on my end to fix it?
<iyzsong>JodiJodington: you may first run 'guix pull', it was fixed in commit be6f1d0fe4.
<wakyct>JodiJodington, I think Drew Devault did a run-down of email providers a few years back that might be helpful
<wakyct>let me try to find the post
<wakyct>ah well, it looks like he took it down, but at the time he recommended Migadu
<wakyct>here's the OP http://web.archive.org/web/20210219203456/https://drewdevault.com/2020/06/19/Mail-service-provider-recommendations.html
<wakyct>I recently signed up for Mailbox, his other recommendation at the time. Overall I think they're good but I didn't realize when they signed up their service might have some DMARC related issues, if you have a custom domain
<JodiJodington>wonder why he took it down, does he do that often?
<wakyct>sometimes, he's a somewhat controversial figure in the open source world
<JodiJodington>honestly I think I might just go with a proprietary service since I don't need privacy on an account just for dev mailing lists
<JodiJodington>wakyct yeah escepecially in the gnu world i'd assume :p
<wakyct>haha yeah
<wakyct>particularly
<wakyct>I've also heard recommendations for MxRoute as a no-nonsense kind of service
<apoorv569>mange: Ok i'm a little lost.. if even I write a helper procedure which basically does a bunch `(invoke ` or `(system` calls.. who would call this procedure so the code inside it executes? another one-shot service? I don't like this.. why would you wanna clone some repo on every boot?
<apoorv569>what is define-gexp-compiler? they don't call the `vendored-go-deps-compiler` anywhere its just defined.. how does it work?
<mange>Yeah, I wouldn't do it on boot. I'd do it in the Guile code that constructs the operating system. Something like using (begin (clone-the-repo-somehow) (invoke "npm install") (local-file "." #:recursive? #t)) as your source.
<mange>If you want to read about gexps, I'd recommend the manual: "(guix) G-Expressions".
<apoorv569>is it what I need though? gexp-compiler thing? they defined it but not using it anywhere..
<mange>Essentially, they're a way that Guix "stages" code, to run in a builder. Whenever you use #~ you're defining a gexp, but there are other ways to do so, too. Defining a gexp-compiler for <vendored-go-deps> lets you un-gexp a <vendored-go-deps> object (using #$) in a gexp.
<mange>But again, if you don't want to use gexps (which are a more advanced tool) then you can do the work in your script that constructs your operating-system, rather than doing it build-side.
<apoorv569>Ah! that's how they use it..
<apoorv569>I had another though.. perhaps a activation script thing?
<apoorv569>that wouldn't work though because the package definition has to be installed before that service runs..
<apoorv569>nevermind
<meaty>Is there something special I need to do to compile a package that uses c++23? It keeps complaining about missing headers
<meaty>I set -Dcpp_std=c++23, but it doesn't help
<drewverlee>Why would `guix edit` from the command line be able to find the hello package in the tutorial but not `guix edit` from emacs? both have the same "guix version" and i can find the hello package from emacs using a shell. I'm not sure this is important but it's worrisome!
<meaty>nvm, just had to add gcc-14
<simendsjo>Someone said I should use firewalld, and I notice there isn't any package in guix or any other channels I have found. Is there a good reason nobody has found this package necessary?
<aure84>Hello. I'm building a package that requires a binary to be downloaded and unpacked in order to build. As this binary is kind-of ephemeral, Instead of creating a proper package for it, I have included it as (inputs ("package" ,(origin. This strategy works well for other source-based dependencies with the `git-fetch` method. However, with the `url-fetch` method I don't quite to get this to work. Does a
<aure84>.tar.gz get unpacked automatically? Or perhaps I need a (snippet clause?. Using #$(this-package-input "package") seems to provide the .tar.gz file and I would need the path to the uncompressed package
<Rutherther>aure84: no, nothing gets unpacked automatically, it just downloads the file
<aure84>Rutherther: thanks for the info. If I make use of a snippet clause to unpack. how could I refer to the unpacked directory
<aure84>?
<Rutherther>aure84: just name it with the file-name field and then refer to it with this-package-input with the name you chose for file-name
<aure84>Rutherther: thanks. That will probably do it
<mange>simendsjo: I use iptables. From my quick search, it sounds like firewalld is meant to be a more modern and friendly way of doing the same things. I hadn't heard of it until your message.
<mfg>Hi, i use the same os config on multiple machines, but one of them seems to not create the /run/user/$UID directory? Does anyone have an idea, where i could look?
<mfg>the other machines _do_ create that directory on boot which i find strange
<cbaines>civodul, shepherd question, using system*/waitpid is bad, right?
<Rutherther>mfg: that directory is not created on boot normally, it's created when user logs in. It could happen that it seemingly is created on boot because the user is logged in automatically, ie. with elogind's linger functionality
<mfg>Rutherther: I see. I use seatd and wlgreet to start my sway session. So i believe seatd is responsible for that?
<mfg>speaking about at boot time was unprecise of me
<Rutherther>mfg: no, seatd doesn't do that, that is one of the things it doesn't do compared to elogind
<Rutherther>if by wlgreet you mean greetd with wlgreet greeter, then that's it - it's greetd that does create that folder
<mfg>ah okay, i'll look into greetd then
<apoorv569>mange: Hey I tried something, https://0x0.st/8uSe.txt but I am getting error, `guix build: error: reference to invalid output 'out' of derivation '/gnu/store/x7ma1h5ly4ybc2lslsdc2ww0nv3adyyc-foo-deps.drv'`
<apoorv569>what does it mean by invalid output out of derivation?
<mange>I don't know, but my guess is that you're not actually producing an output in your gexp. In the previous example the "-o #$output" part of the command said to write the output to that directory. Your command runs "npm ci" and "npm run build" in the source directory.
<mange>My guess is you should do something like (mkdir #$output) (copy-recursively #$(foo-deps-source foo-deps) #$output) (chdir #$output) (invoke "...npm" "ci" "--omit" "dev") to make your output.
<mange>... Or maybe actually (mkdir #$output) (chdir #$(foo-deps-source foo-deps)) (invoke #$(file-append node "/bin/npm") "ci" "--omit" "dev") (copy-recursively #$(file-append (foo-deps-source foo-deps) "/node_modules") #$output), so you just capture the node_modules dir in the dependency derivation.
<apoorv569>hmm..
<mange>(Obviously I have tested none of what I just typed, so good luck.)
<apoorv569>man for last couple of days I'm getting like 10-20 kbps download speed for substitues
<cbaines>apoorv569, from what server/servers?
<Kimapr> https://home.kimapr.net/lappy/uploads/0e71c210444ba310fd272e5b32ead695.txt is there a better way to do this?
<Kimapr>adding a requirement to a service that is
<mange>Ugh, that's rough to read. I don't know if that's the best way, but if you want a better way here's a recent email to guix-devel you can piggy-back on: https://lists.gnu.org/archive/html/guix-devel/2025-03/msg00006.html
<Deltafire>i've tried to update (guix home reconfigure..) twice this week, but both times i've had to rollback due to Gnome apps not launching (can't even login with gdm..) - anyone else experienced this?
<apoorv569>oh wow, went to make coffee.. its still downloading the same thing, where I left it..
<apoorv569>cbaines: bordeaux ATM
<cbaines>apoorv569, OK, could you share the URL for what you're seeing download slowly
<cbaines>also, where in the world are you downloading from?
<apoorv569>cbaines: `downloading from https://bordeaux.guix.gnu.org/nar/lzip/hx2zn47d6n5w9y2rhjxrrs5sbycs9g2p-node-22.12.0 ...`
<apoorv569>I'm in SEA
<cbaines>is that south east asia?
<cbaines>if so, could you try downloading https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/hx2zn47d6n5w9y2rhjxrrs5sbycs9g2p-node-22.12.0 and see what speeds you get?
<apoorv569>yes
<apoorv569>yes the mirror is nice..
<apoorv569>can I change it?
<cbaines>change it in what way?
<apoorv569>like make this mirror permanent? so I always download from this server?
<apoorv569>mange: I'm getting permission denied for mkdir, https://0x0.st/8uSY.txt
<apoorv569>this is what I for gexp-compiler, https://0x0.st/8uS6.txt
<Kimapr>after restart all of my docker containers broke and compose also broke so i can't recreate them anymore..
<Kimapr>Error response from daemon: Unknown runtime specified /gnu/store/vla8lfci1p6k7a4jn1f03lgwj8w8yc0k-runc-1.1.14/sbin/runc
<apoorv569>mange: about https://lists.gnu.org/archive/html/guix-devel/2025-03/msg00006.html it talk about wireguard autostart thing... I actually sent a patch some months ago to add a auto-start? field to wireguard configuration for people who don't want it auto start..
<cbaines>apoorv569, if you add it to the substitute urls for the Guix daemon, then it should be used automatically
<cbaines>the list is ordered, so you'll need to add it near the start
<apoorv569>cbaines: I see. Thanks I'll add it there..
<Kimapr>docker-compose throws this: https://home.kimapr.net/lappy/uploads/f828bf41ab71f42a78e129c6b99c4ff6.txt
<apoorv569>Kimapr: docker-compose in guix ATM is broken, its pretty old version.
<apoorv569>I personally switched to using guix system container since it got broken..
<Kimapr>oof
<apoorv569>what services are you running on docker BTW?
<Kimapr>Synapse and Akkoma
<apoorv569>you can use oci-container-service and run it using system containers for now..
<apoorv569>I actually opened a issue, https://issues.guix.gnu.org/75424#1
<apoorv569>the person said they are working on the new version.
<apoorv569>if you can help them it might even be done much faster
<Kimapr>the reason i'm using docker here is because both softwares are very complicated, akkoma doesn't have a guix package at all and synapse's is old and there's no shepherd service for it
<Kimapr>if i'm getting my hands dirty anyway maybe it's better to fix that instead...
<apoorv569>oci-container-service runs docker containers only.. if you want an example I can share a quick one..
<apoorv569>behind the scenes they run `docker run` command
<apoorv569> https://guix.gnu.org/manual/devel/en/guix.html#index-oci_002dcontainer_002dservice_002dtype
<apoorv569>I wrote a config which runs nginx proxy manager and pihole using oci-container-server (docker basically)
<apoorv569>I also use run synapse server BTW but on debian.. but I wanna switch using Guix for that as well..
<Kimapr>managed to get the containers to run by editing docker's files directly
<apoorv569>The examples here do use mkdir inside gexp->derivation, https://guix.gnu.org/manual/en/html_node/G_002dExpressions.html
<apoorv569>don't understand why I am getting error for using mkdir then..
<csantosb>Ey Guix ! I'm looking for the right way to set an env variable in a package
<csantosb>Osvvm: https://git.sr.ht/~csantosb/guix.channel-electronics/tree/ba1c92dda3e240e0af0ff19ce9fb0575de3971b8/electronics/packages/verification.scm#L139
<csantosb>Ghdl: https://git.sr.ht/~csantosb/guix.channel-electronics/tree/ba1c92dda3e240e0af0ff19ce9fb0575de3971b8/electronics/packages/compilers.scm#L111
<csantosb>When I do a `guix install osvvm ghdl-llvm` I see my $OSVVM, but not $GHDL, any idea ??
<Rutherther>csantosb: guix install doesn't set any env vars, it only builds the profile that will have env vars in ~/.guix-profile/etc/profile, and you need to source it to get them (ie. relog to get them everywhere). It's better to check this with guix shell --search-paths. If you want to check with install, check the profile file
<PotentialUser-16>I would like to express my thanks to the person who upgraded TLP to version 1.8.
<PotentialUser-16>But when I run `sudo tlp setcharge 40 60`, I get the error:
<PotentialUser-16>"/gnu/store/ypdi8gxswgnshhmxxdj66cb51krx1d63-tlp-1.8.0/share/tlp/bat.d/05-thinkpad: line 651: perl: command not found"
<PotentialUser-16>"/gnu/store/ypdi8gxswgnshhmxxdj66cb51krx1d63-tlp-1.8.0/share/tlp/bat.d/05-thinkpad: line 1231: [: : integer expression expected"
<Rutherther>PotentialUser-16: as a workaround, can you try executing it in a guix shell with perl present?
<fnat>I've added an Emacs package to my Home configuration, reconfigured, then run `guix-emacs-autoload-packages' which usually makes the new package available as part of the current EXWM session. But not this time. Suggestions on how to debug this?
<Rutherther>fnat: just to check, you did use other emacs packages from your guix home already?
<fnat>Rutherther: Yes, and the workflow of adding new packages and making them available via `guix-emacs-autoload-packages' usually works.
<fnat>Pretty much all my Emacs packages come from my Home configuration.
<Rutherther>fnat: okay, then I have no idea
<fnat>Np, thanks Rutherther.
<PotentialUser-16>Rutherther I ran "guix shell tlp perl sudo -- sudo tlp setcharge 40 80" with no problem.
<PotentialUser-16>Could you help me understand the problem?
<PotentialUser-16>perl is not available on my profile, so it seems to be part of the issue. But perl is present as an input for TLP.
<Rutherther>PotentialUser-16: dependencies of shell scripts in guix are usually resolved on build time by either making wrapper scripts that will prepend to PATH or replacing with full path, so you don't usually know about them directly. Here the person packaging forgot to do / check if there is need for this, so the package is used from PATH as on other distros
<Rutherther>PotentialUser-16: making it an input just makes it available in the various search paths during build time, so it can be used. But it doesn't mean it will be correctly used in the resulting package. The issue is that if you just have a shell script like here, the shell script won't know about the perl in the inputs unless someone replaced it / made a wrapper for it
<Rutherther>the various build tools like gcc take the input libraries and encode them in the output binary file, but with shell scripts there isn't automatic mechanism like this and on other distros shell scripts usually rely on PATH, so the packages has to make their own phase with correct usage of the input, otherwise the shell script will still be relying on PATH, this is what happened here
<Rutherther>csantosb: I am afraid that in your case the search path is not working because you are pointing it to a file, but search paths seem to work only with directories
<PotentialUser-16>Rutherther I see. It seems like something I cannot solve easily with my current level of expertise. What can I do to call attention to this situation? Is there a bug report?
<PotentialUser-16>Ah, there is an issue tracker, I see.
<Rutherther>PotentialUser-16: yes there is https://issues.guix.gnu.org/, just send an e-mail to bug-guix@gnu.org
<apoorv569>how do I fix this bad interpreter error here, https://0x0.st/8uQv.txt
<apoorv569>it happens during the `npm ci --omit dev` command.. https://0x0.st/8uQY.txt
<apoorv569>how can I patch shebang when the command is running?
<csantosb>Rutherther: Ah ! The fact that /bin/ghdl is a file, and not a dir, is maybe the reason
<csantosb>Is there a way to point an env variable to a file, and not to a dir ?
<apoorv569>env var is var can have any value (I think) not sure though..
<PotentialUser-16>I also got an issue with wine. For this one I don't even know where to begin to diagnose.
<PotentialUser-16> https://paste.debian.net/1361788
<LizardScholar>Does anyone here have any experience using MACs (selinux or apparmor) with Guix?
<fnat>Re my issue with `guix-emacs-autoload-packages', it seems that `guix-emacs--non-core-load-path' doesn't include newly installed packages.
<fnat>I mean, not `guix-emacs--non-core-load-path', its output.
<csantosb>apoorv569: 8.8 Search Paths, ‘files’, The list of sub-directories (strings) that should be added to the search path.
<apoorv569>csantosb: search paths? how will that help in my case? its looking for /usr/bin/env which doesn't exist I need to somehow either substitute it or make it available
<apoorv569>(symlink #$(file-append coreutils "/bin/env") "/usr/bin/env") doesn't seem to work..
<apoorv569>In procedure symlink: No such file or directory
<fnat>Ok, in turn, it seems that `load-path'
<fnat>doesn't get updated.
<PotentialUser-16>Rutherther Thank you for your help.
<apoorv569>csantosb: https://0x0.st/8u1o.txt tried this, didn't help.
<Rutherther>apoorv569: you can't really do it during a running command as that would introduce a race condition. You have to first patch, only then use it
<cow_2001>"warning: no tags were found for ..." what does it mean when using guix lint on a package?
<Rutherther>fnat: but load path shouldn't be updated after guix home reconfigure, still it is ~/.guix-home/profile/... the same path as before
<fnat>Ha! I found the culprit! I needed to restart `herd restart guix-home-user'. Now the Emacs paths have been refreshed and I can load the new Emacs packages.
<fnat>Rutherther: I don't know if it makes any difference but the way I use Guix Home is via `guix-home-service-type'.
<apoorv569>Rutherther: Yes, but that file is only created when the npm ci command runs its not present before..
<Rutherther>fnat: it shouldn't really make a difference, you should still have ~/.guix-home
<fnat>Rutherther: Also, sorry, when I mentioned load-path I meant the Emacs load-path, I should have said that.
<apoorv569>fnat: AFAIK if you use guix-home-service-type guix home list-generations don't show anything.. perhaps its changed now but its what I remember from the last time I tried it.
<Rutherther>apoorv569: that file is definitely somehwere present already, as it has to be copied by npm. Other than that, then it's likely a post-install hook or something like that and I hope npm has a way to disable these with a flag or something like that
<fnat>apoorv569: I think you're right, but this might be unrelated to the Emacs load path glitch I was debugging?
<apoorv569>Rutherther: no the node_modules directory is created when npm ci command is run and the file is in node_modules/.bin/
<Rutherther>apoorv569: you misunderstood me. I am not questioning that. I am saying that it has to be somewhere already present, somewhere else. Because otherwise it would be impossible to obtain it
<apoorv569>Rutherther: hmm.. not sure about that.
<Rutherther>fnat: I know you load-path of emacs. It should include "/home/$USER/.guix-home/profile/share/emacs/site-lisp" which doesn't change when you reconfigure
<civodul>cbaines: system* is fine; waitpid must be banned: https://issues.guix.gnu.org/76262
<cbaines>civodul, is it OK that system* uses waitpid internally, because that's happening in C?
<civodul>cbaines: shepherd replaces the ‘system*’ binding with one that cooperates
<civodul>so no problem
<cbaines>I think there's a specific issue with the NGinx service
<cbaines>maybe it's somehow using the non-replaced system*
<cbaines>I had "herd restart nginx" hang on me again this morning
<civodul>gasp
<civodul>is it reproducible in a VM?
<cbaines>I haven't tried, but it's inconsistent and sometimes works
<civodul>scary
<civodul>do you think you could come up with a minimal VM config?
<civodul>the problem with those real-world nginx configs is that we cannot test them in a VM, due to certs, etc.
<cbaines>I send #76811 which seems like a sensible change, I'm not sure invoke from (guix build utils) is being used, but it seems sensible to switch to spawn-command
<peanuts>"[PATCH] services: nginx: Replace invoke with spawn-command." https://issues.guix.gnu.org/76811
<fnat>Rutherther: Hm, perhaps the path itself was fine, but its content hadn't been refreshed (it took me to restart the Guix Home service and then to use the usual `guix-emacs-autoload-packages').
<Rutherther>fnat: are you sure the service got ran in the first place? I am not sure if every guix system reconfigure will run it
<PotentialUser-16>I seek assistance in debugging an issue with my Guix System: the executable file is there, readable, executable, but bash claims otherwise. I have no next step to proceed.
<PotentialUser-16> https://paste.debian.net/1361788
<Rutherther>PotentialUser-16: the error is misleading. Since the file is an elf file, kernel will try to execute the interpreter (dynamic linker) it points to, but it doesn't exist. This shouldn't really happen with guix packages, but seems something went wrong here. You can check this with "file $(type -p wine)", then you can see path to the interpreter, it doesn't exist. Specifically, it points to a file called ld-linux.so.2, but the actual file is...
<Rutherther>... ld-linux-x86_64.so.2
<Rutherther>@Poten
<Rutherther>easiest will be to report this and wait for someone to fix the build
<lechner>gone
<Rutherther>I hope they are planning to check the log
<anemofilia>Hello
<anemofilia>Is there someone appropriate to cc in fishs shell related patches?
<anemofilia>fish*
<apoorv569>OK so I was running wrong commands, I have to do `npm install`, `npm run build` then `npm ci --omit dev` the `/usr/bin/env` thing I think can be ignored by adding `--ignore-scripts` arg to `npm install` and `npm ci` command..
<apoorv569>now I am back to the permission issue, https://0x0.st/8ue_.txt
<apoorv569> https://0x0.st/8uet.txt
<apoorv569>it says the files are under `/tmp` but I see directory there `foo-build`
<ajarara>hi, I added an oci-container-service to a remote host, which required docker-service-type, containerd-service-type, and elogind-service-type. Now ssh sessions exit 254 out with 'client_input_channel_req: channel 0 rtype exit-status reply 0.', S/O says this is because the users don't have default shells set. Presumably this is elogind causing the issue.
<Rutherther>ajarara: have you tried rebooting after switching to elogind?
<ieure>Sent some patches to core-packages-team to update libpng: https://issues.guix.gnu.org/76798
<ieure>Patches are very simple, but will trigger a lot of rebuilds.
<Rutherther>apoorv569: see it where exactly? the builds happen in a container, so looking in your machine's tmp folder and seeing it there doesn't mean anything
<Rutherther>apoorv569: why are you setting home to /tmp in the first place, why don't you use current cwd like almost any build does?
<apoorv569>Rutherther: I was going by this https://lists.gnu.org/archive/html/guix-devel/2025-03/msg00033.html (in the attachment there is example for gexp-compiler)
<Rutherther>so did you find the folder used when using --keep-failed? and if so, what are the permissions on the package-lock.json in the folder?
<apoorv569>if I do it like this, https://0x0.st/8u_T.txt I get similar error for mkdir https://0x0.st/8u_M.txt
<Rutherther>also note that it's very likely your build won't be reproducible, because tools like npm aren't made that way, so you might be unable to build it again after few days / on another machine where the path won't be present. That's why you don't typically see guix doing this, but rather the packages are downloaded by guix itself and packaged in way defined in guix. But maybe it will be fine, you will see. It's quite hard making everything reproducible...
<Rutherther>... with tools like that
<Rutherther>apoorv569: you definitely can't do that, you can't, and shoudn't change existing store paths, the only path you create and change is the output one
<Rutherther>that is why the gnu build system takes the source and copies it to cwd
<Rutherther>it uses cwd and (mkdir "source"). So I would do something similar, there you should have certainty of being able to write. The issue itself might be related to something else though, I wouldn't be surprised if copy-recursive copied it with the permissions where write is going to be unset, so if the open is then with write flag, permission issue would occur. So you would have to add write permission to the sources. That's why I asked you to check the...
<Rutherther>... permissions on the source with --keep-failed
<apoorv569>are you saying my package definition won't clone and try to build it from scratch every time?
<Rutherther>you can also even find that in the unpack phase of gnu build system. Maybe it will be best ifyou take your inspiration from there - see guix/build/gnu-build-system unpack function - line 186
<Rutherther>apoorv569: no, I am saying it will have different result when you're obtaining the dependencies with npm install
<apoorv569>Oh! that I understand.. yes I don't know how else to package this node app.. I am not going to write 50 different package definitions for node stuff..
<apoorv569>so I thought of building it then just moving the build to directory when I then use nginx service to host the app with shepherd managing the command for running it
<Rutherther>sure, I am not saying it's a wrong way or something like that. Just that you might hit a wall at one point. It is still possible to do it with tools like this, but you then might need to provide more arguments that make it reproducible, or delete some stuff it changes sometimes etc., so it can be hard to debug it and get it into something completely usable and reproducible
<apoorv569>I see.. I mean ATM I not even to build it.. once I get it copied to the store.. I'll think about how I wanna proceed.
<apoorv569>So you have any ideas? I have copy the cloned to another directory that's for sure because I can't `npm install` and all in the directory it cloned it right?
<Rutherther>sorry, ideas for what? to fix the issue at hand or to make sure it's all reproducible?
<apoorv569>I try to avoid documentation sometimes TBH, as it can get really technical sometimes and it just confuses me so I try do it with trial and error
<apoorv569>ATM to fix the issue at hand.
<Rutherther>then I do, I already pointed it out: The issue itself might be related to something else though, I wouldn't be surprised if copy-recursive copied it with the permissions where write is going to be unset, so if the open is then with write flag, permission issue would occur. So you would have to add write permission to the sources. That's why I asked you to check the permissions on the source with --keep-failed
<Rutherther>seee the unpack phase of gnu-build-system, in guix/build/gnu-build-system.scm
<apoorv569>let me try with --keep-failed one time.
<apoorv569>ok i'll check unpack phase too
<apoorv569>hmm.. so it tries to make files/dir writable..
<Rutherther>correct, because it's copied from the store with permissions kept, being unwritable
<apoorv569>well --keep-failed was useless as I move the copied stuff to /tmp/foo-build
<apoorv569>and the kept dir is empty
<apoorv569>actually I didn't intent to move but just copy but copy-recursively seems to move it instead
<Rutherther>then build under cwd instead
<Rutherther>s/build/work
<Rutherther>it definitely cannot move it out of the store if you're talking about that folder obtained by: "#$(foo-deps-source foo-deps)". That's in the store and will stay there
<apoorv569>from the `/tmp/guix-build` dir I meant. the one --keep-failed to keeps
<apoorv569>wait what.. its still empty.. I am not copying the source anymore.
<Rutherther>so why are you expecting it to not be empty?
<Rutherther>apart from the copy of source you don't seem to populate it in the code you provided
<apoorv569>so this /tmp/guix-build directory ATM is not created by my package definition but by define-gexp-compiler thing? I never used this before.. its not making sense to me.. in the past when I wrote bunch of package definitions I always see stuff in the /tmp/guix-build-foo directory if I use --keep-failed..
<apoorv569>maybe I'm not thinking about this right..
<Rutherther>exactly. It's a build as well. There are two builds happening, first this one, then your package. Since this one isn't finishing, your package hasn't even started building as you can see in the log: builder for `/gnu/store/dq7r3xz1kiq8c49qhssb49wvgdb884kr-foo-deps.drv' failed with exit code 1
<Rutherther>every gexp compiler is a separate build, even something like local-file makes a build that will end up with a store path, for that specifically it just copies a local file into the store output location
<apoorv569>I see..
<apoorv569>so I just run the `npm` command in the compiler but don't copy anything?
<apoorv569>copying should done in the package definition thing?
<Rutherther>no, copy it and then make it writable. But copy it under cwd
<apoorv569>like this is replacing my unpack phase?
<Rutherther>well it's up to you when copying happens, but you need at least the package.json and package-lock.json to know what to build, so copying is easiest. Additionally there could be post install scripts in the local package, so I would rather copy the whole source. Then take the node_modules folder and copy it to #$output. Then you can use this foo-deps as the node_modules and use that in your package definition
<Rutherther>but there are many variants maybe you can tell npm install to not use cwd for looking for package.json
<Rutherther>also side question, why are you using both install and ci? ci itself should be enough, also it makes better job at keeping stuff reproducible, so what I said earlier about it being unreproducible could be gone if you used only npm ci
<apoorv569>well I am using sveltekit for the framework and they just to build it then run npm ci --omit dev https://svelte.dev/docs/kit/adapter-node#Deploying
<apoorv569>if I don't do npm install first, I won't have `vite` which is used to build it.. and vite is a dev dep so npm ci --omit dev won't install it
<apoorv569> https://0x0.st/8u_d.txt still getting for permissions, https://0x0.st/8u_n.txt
<apoorv569>if I still got it wrong.. then I need step for some time and think about it.
<apoorv569>step back*
<Rutherther>apoorv569: you copied it to /tmp, but made what's under cwd writable, you need to make it writable where you copy it
<Rutherther>oh sorry you did chdir
<apoorv569>no? I chdir to build-dir before changing permissions
<Rutherther>oh, you're getting permission denied for homeless-shelter
<apoorv569>OK I think I needed the (setenv "HOME" "/tmp")
<Rutherther>that is the default HOME, you should set it, because npm is trying to write to your home to a cache I would guess
<apoorv569>that's why the person had this in their example.
<Rutherther>yes, go does the same thing
<apoorv569>and it failed again.. new error though, https://0x0.st/8u_h.txt
<apoorv569>guess it needs bash
<apoorv569>how do I add bash? I just `(setenv "PATH" (string-append #$(file-append bash "/bin") ":" (getenv "PATH")))` right after `(setenv "HOME"` is this fine?
<Rutherther>apoorv569: sure, but in case you need more of those see the set-path-environment-variable, that's going to be easier, see again gnu-build-system for usage, in set-paths phase
<Rutherther>also, it's going to be empty, so prepending is not important
<apoorv569>PATH? will be empty you saying?
<Rutherther>yes
<ekaitz>hi! could someone remind me how to use a specific version of gcc to build a package
<nckx>Just add it to native-inputs—usually.
<ekaitz>hmmm
<ekaitz>that i tried but this is not working... interesting
<Rutherther>what build system? gnu?
<ekaitz>the error is probably something else, because Cmake finds the gcc I added
<ekaitz>i'm reading the cmake error log and says: /gnu/store/86fc8bi3mciljxz7c79jx8zr4wsx7xw8-gcc-11.4.0/bin/c++ which is not the gcc I added
<ekaitz>but I don't trust the cmake error log
<ekaitz>the high level error is it doesn't find zstd
<ekaitz>and it is added as inputs
<ekaitz>oh maybe i need the "lib" output only
<ekaitz>oh yes
<ulfvonbelow>strace seems to be failing to build right now due to test failures
<sneek>ulfvonbelow, you have 1 message!
<sneek>ulfvonbelow, futurile says: thanks for the report about the issue with the Guix survey missing option. No idea how that happened. I'm not sure if I can fix it with the survey being 'live', but I'll try and do so.
<df>anyone else having issues upgrading java-icu4j?
<df>guix weather says there is no substitue available, so I guess my machine is trying to build it, but it doesn't seem to be consuming many resources
<ieure>Haven't tried it, but I pushed some patches for icu4c/icu4j recentl.
<ieure>*recently
<ieure>They built locally for me.
<df>ah, I will have a look and see if they're likely to be relevant, thanks
<ieure>#76750
<peanuts>"[PATCH 0/2] Add icu4c-76." https://issues.guix.gnu.org/76750
<df>well, I did another guix pull and upgrade, and my fan has spun up, so possibly that's progress...
<df>ah no, back to being stuck in the same place
<df>bah, debian paste has decided I'm spamming
<apoorv569>how do I make gexp-compiler to fetch new commit? it seems like it keeps reusing what was already cloned..
<graywolf>Does anyone know what is the state of emacs 30.1? I have found #76529, but it is closed, so I am not sure whether someone is working on it.
<peanuts>"[PATCH] gnu: emacs: Update to 30.1" https://issues.guix.gnu.org/76529
<df>ieure: on the offchance that this means anything to you: http://pastie.org/p/2LxSq05gaVQTexsoJ1aj0Z
<df>it's just looping over that
<ieure>df, It's trying and failing to get source from Software Heritage.
<df>gottit, thanks
<anticomputer>graywolf: I don't recommend anyone else does this really, but emacs is my primary "OS" so I don't like to tie it too much to the underlaying opinions of the OS package management itself as my emacs config lives on many different systems and platforms, this is how I build and run 30.1 on guix: https://paste.debian.net/hidden/4ba639a2/
<df>ieure: it looks like (at least for the version in question, 70.1) the java source is in a .jar rather than a tarball, so the generated url is incorrect
<df>there is also a tarball that appears to contain sources for both versions, perhaps that is preferable?
<graywolf>anticomputer: Thanks for the tip, it looks like interesting approach, but I will (for now) probably stick to the package we have. The paste is bit too adventurous for me.
<graywolf>df: Oh did I fuck up the patch? (the .jar vs tarball)
<df>er, I dunno, was that your patch?
<df>someone did, from the looks of things
<graywolf>It the uri is wrong, maybe df26ebde64efd6d4f2658e291aedd9d07746b85a is to blame
<peanuts>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=df26ebde64efd6d4f2658e291aedd9d07746b85a
<graywolf>Checking now
<ieure>Agreed, URL is wrong in that package. Maybe I only built the icu4c ones :/
<graywolf>Hm, I think the patch is correct though. Looking at the diff the java-icu4j had .tgz
<ieure> https://github.com/unicode-org/icu/releases/download/release-76-1/icu4j-76.1.jar is correct, but https://github.com/unicode-org/icu/releases/download/release-70-1/icu4j-70_1-src.tgz is in the origin.
<ieure>Oh, different version. Maybe they changed the scheme.
<df>yeah... I'm not sure how it worked before
<graywolf>java-icu4j is just in 70.1 though
<ieure>df, The patch included a refactor that moved computation of the download URI into a procedure.
<ieure>And updated all the existing packages.
<df>yeah, but as graywolf says it looks like the original used .tgz?
<graywolf>But the patch should have been NOP regarding the resulting URLs
<ieure>Yeah, that's why I'm wondering if their scheme changed somewhere in between 70.1 and 76.1.
<df>and it's been on 70.1 since 2021...
<df>ieure: icu4j wasn't upgraded to 76.1
<df>still I suppose it's possible they had a tidy-up, removed some old download urls
<ieure>df, I know. But the download URL was updated to use icu4j-uri.
<graywolf>Look slike the -src should not be there
<ieure>df, So what I'm saying is that there have been two different naming schemes for icu4[cj], the procedure works fine for the current one, but not for icu4j 70.1, which uses a different scheme.
<ieure>*two different naming schemes for icu4[cj] URIs
<ieure>That's the only thing that makes sense to me.
<graywolf>Oooh yeah my patch was wrong.
<graywolf>I see it now when I know were to look.
<ieure>I think the simplest thing is to revert the icu4j changes.
<graywolf>Yeah, there is just 1 package, so no real benefit to use the procedure.
<graywolf>Sorry about this :/
<df>ah, I was gonna say it might be beneficial to use the -src version
<ieure>graywolf, No worries, it happens.
<ieure>I should have caught it.l
<df>I think the plain .tgz is both source and... something else
<df>oh, some data files, maybe they're necessary *shrug*
<df>I thought maybe it would contain the compiled .class files but it doesn't look like it
<dariqq>yay, i managed to build mate for i686 again, had to add 3 new packages (one of them being gtk4) to my test-skip list and wait for both webkitgtks to build
<df>is there a quick way to get from the shell to the info page for a guix cli command? something like guix info <command> would be really handy
<elevenkb>Hello there, I want to know how I can disable tests on notmuch. For some reason options->transformation doesn't work.
<df>afaik the info manual doesn't have an index of cli commands, but it could make a best effort with a regexp search or something
<Rutherther>apoorv569: change the hash. If you're giving it the same hash, it will reuse what you have. Becausee the hash literally says: the output WILL have this hash
<dissoc`>im trying to do some python development. i 'guix install bcc'. i see the lib in ~/.guix-profile/lib/python3.10/site-packages (egg file exists). but im unable to import the library in the code.
<df>dissoc`: I don't know specifically about python, but do you have all the env vars from the profile's /etc/profile loaded?
<elevenkb>sorry, i might've been mistaken. something is building its just that the build fails.
<df>or alternatively, you can evaluate the output of guix package --search-paths, but I believe that clobbers any existing values of the vars which might not be what you want
<dissoc`>df: how do i check that? i see GUIX_PYTHONPATH=/home/dissoc/.guix-profile/lib/python3.10/site-packages in my env
<ieure>elevenkb, Why do you want to disable tests?
<df>dissoc`: hmm, well that is a guix-specific variable, I'm not quite sure how it makes it into plain python
<elevenkb>ieure: I want to try the latest emacs, and building notmuch almost succeeds except for a few tests related to emacs.
<df>are you using guix the distribution (I'm not sure what the proper name for that is these days) or just the package manager on another distro?
<ieure>elevenkb, But you're saying the build also fails even with tests disabled?
<elevenkb>Perhaps this is a waste of time though... The big picture problem is that lsp-mode is too slow for lean, so I'm hoping that the new native json would help (ever e.g. eglot-lsp-booster).
<ieure>df, "Guix System"
<df>ieure: *nod*
<dissoc`>im on guix system
<df>dissoc`: could you provide a minimal failing python prog just so I can see if it works here?
<elevenkb>ieure: It's kinda weird... I'm having trouble isolating the issue basically. There's a place in my config where I can specify which notmuch and emacs-notmuch packages I want, but if I use options->transformation there then I don't see any consequences of my changes in the derivations guix then tries to build for notmuch + emacs-notmuch.
<elevenkb>However, changing the emacs version does work and does change the derivation.
<elevenkb>hmmm, ignore me for now y'all's. I'll probably post something to help-guix with a more minimal/isolated example of what's happening if I must.
<apoorv569>Rutherther: Yep..
<dissoc`>df: sure but it's literally just 'from bcc import BPF'
<df>ok, that'll do fine :D
<dissoc`>im reading a eBPF programming book that uses python. i really dont ever use python
<apoorv569>Now I'm back at the issue where /usr/bin/env was not found.. this is needed when the initial npm install command is run.. apparently bcrypt library needs to build some library and because I add --ignore-scripts to npm install command it doesn't build the library
<apoorv569>and I can't substitute the shebang before the file is placed in node_modules..
<df>dissoc`: ok, I can reproduce
<apoorv569>if I use --ignore-scripts in the beginning then later after the npm run build happens I get error for bcrypt lib not found..
<df>do you get:
<df>ModuleNotFoundError: No module named 'bcc'
<dissoc`>df: yes
<df>cool
<df>well, not cool, but y'know
<dariqq>after a little bit more struggle to remove the 'network-manager-applet simple-service, which also depends on the broken gtk4, (modify-services did not work) i have now reconfigured once again
<jas>what is the process to restore 'guix package -l' to be the same as on first login, i.e., no packages at all? I know about 'guix package -S 42' to change between different existing versions, but what if I want to start from scratch again?
<jas>i'm looking for something cleaner than: rm -rf ~/.guix-profile ~/.config/guix /var/guix/profiles/per-user/$USER/guix-profile*
<dissoc`>df: thanks for checking it out. i will eventually figure it out
<df>ok, so when I start python, sys.path contains my profile, which contains bcc
<df>I'm afraid I'm reaching the limits of my python knowledge though
<df>I wonder if another module will work...
<dissoc`>df: thats how i feel too. i was hoping there was something obviously wrong i was doing
<df>hmm... bcc appears to be the only one packaged as a .egg file
<Rutherther>apoorv569: as I think I've told you previously - first run it without the post install hooks, replace, and then run the hooks
<apoorv569>Rutherther: What do you mean by post install hook?
<Rutherther>it's what is being ran after install https://docs.npmjs.com/cli/v8/using-npm/scripts
<dissoc`>df: if i 'sys.path.append("/home/dissoc/.guix-profile/lib/python3.10/site-packages/bcc-0.30.0-py3.10.egg")' it appears to at least import
<apoorv569>I think I got it working.. apparently you can run npm rebuild bcrypt.. so after npm install I do substitute then run npm rebuild bcrypt.. and seems like build bcrypt fine..
<df>ah
<df>yeah there is definitely something odd about this .egg thing
<df>I wonder whether the installer is supposed to unpack it
<df>(it's just a zip file)
<apoorv569>is this what you mean BTW? Rutherther
<df>if I install (picked at random) the python-ipaddress package I get two files:
<df>ipaddress-1.0.23-py3.10.egg-info/ ipaddress.py
<df>well, a file and a dir
<df>but the dir just contains metadata
<df>so maybe it's cos it's a single-file package
<dissoc`>df: yeah im not sure exactly what it is. i suppose this is fine for now as it's just for working through the exercises/examples in the book
<Rutherther>apoorv569: basically. But note that rebuild doesn't run the prepublish, preprepare and postprepare hooks
<apoorv569>never heard of these... are these needed? do I run these manually after rebuild?
<Rutherther>I think that if you're going to run npm install (or better npm ci) for second time, it's going to reuse the files
<apoorv569>so after rebuild I run npm install again? is that what you are saying?
<df>hmm, some of my python packages go directly into python3.10, some (as in the case of bcc) into the site-packages/ subdir
<df>no idea if that means anything
<Rutherther>apoorv569: no, instead of rebuild
<df>woah, Generation 252, I should really tidy up a bit
<apoorv569>Rutherther: I see. let me try that.
<graywolf>ieure: df: #76840, just FYI
<graywolf>All of icu4c@* and java-icu4j seems to build for me locally.
<df>definitely getting a vibe that this .egg file should be unpacked...
<Rutherther>jas: I don't think what you have for the deletion is unclean, if you were to use guix commands to achieve it, they would in the end do the same thing. If you really wanted, for ~/.guix-profile you could just install empty manifest, that, I think, should just remove the current profile, then you can guix package delete-generations. For the ~/.config/guix, I don't think there is a clean way other than also using guix package similarly to the first...
<Rutherther>... profile, but overriding the profile used with --profile
<ieure>graywolf, Thanks, applying it now.
<graywolf>I am always unreasonably scared of bug fixes, especially for stupid mistakes like this. Let us hope there will be no need for v3...
<df>perhps it doesn't happen because bcc is more than just a python lib and thus just doesn't use python-build-system
<df>ACTION guesses wildly
<apoorv569>Rutherther: no, if I do npm install after substitute instead of rebuild I get same /usr/bin/env thing not found.
<df>graywolf: well speaking for myself, I appreciate the contribution :)
<ieure>graywolf, Pushed.
<Rutherther>apoorv569: alright, so the install hook (or life cycle script how they call it) overrides it
<df>ACTION pulling
<apoorv569>so I should stick with rebuild only?
<elevenkb>My issue from before with notmuch is now resolved. I was doing the substitution in the wrong place.
<df>dissoc`: so python-querystring-parser (another package I picked at random and appears to contain multiple submodules or whatever they're called) *does* seem to unpack its .egg file (assumingn it was packed in the first place...) and that works
<Rutherther>apoorv569: I don't know, up to you
<df>and it uses python-build-system
<df>so my working theory is that python-build-system does something (possibly unpacking .egg files) that bcc doesn't do for its python lib because it uses cmake-build-system
<df>gonna have a look at the python builder code
<df>though I may have to pick this up tomorrow
<apoorv569>I'll stick with rebuild for now, I wanna get it working first.. then I'll see what I can improve later.
<df>graywolf: all looks good (sorry for the delay, had to skip a couple of (unrelated) packages that didn't have substitutes available)
<graywolf>Great to hear, thanks for checking :)
<df>no worries, thanks for the quick fix :)
<dissoc`>df: thanks for your time
<meaty>hey Guix, I'm having an issue packaging that may be a bit difficult to describe
<meaty>So, I'm trying to package "plugins" for Hyprland, essentially libraries that integrate with the main program. Most of them require 'pixman' and 'Hyprutils' as dependencies. Specifically, they use a header file from hyprutils that has the line '#include <pixman.h>'. However, the pixman package places that file at the path $prefix/include/pixman-1/pixman.h. I cann't patch the included file, 'cos it's an input and not in the "build space" to be manipulated; I've
<meaty>tried patching hyprutils to account for guix' packaging of pixman, but that causes a build failure (and probbably isn't the right way to do it). I don't think changing the pixman package would be the right way either
<ieure>meaty, Put $prefix/include/pixman-1/ on your include path?
<ulfvonbelow>does hyprutils have a .pc file?
<ulfvonbelow>the times that I've run into that sort of issue the solution has been to get the build system to use pkg-config, which it often will automatically if pkg-config is available
<meaty>ulfvonbelow: yes
<PotentialUser-16>I seek suggestions no how to debug an issue with my Guix System: the executable file is there, readable and executable, but bash claims otherwise and won't run it. What can I try next?
<PotentialUser-16> https://paste.debian.net/1361788
<Rutherther>I've already answered your question
<simendsjo>It's frustrating when my setup differs across machines even though I'm using guix :/ I have two Lenovos, x1carbon and p14s. On my p14s, some fonts are broken (wrong font chosen), and rofi-pass paste garbage for many passwords. I use guix to avoid such things :(
<meaty>ulfvonbelow: ah, pkg-config:command not found
<ieure>PotentialUser-16, You get that error if the dynamic linker can't find the libraries a binary needs.
<Rutherther> https://logs.guix.gnu.org/guix/2025-03-07.log#151949
<meaty>:p
<Rutherther>ieure: no that is not true. You get that error when the dynamic linker itself is not found
<ieure>I believe it occurs in both cases.
<ieure>But, sounds like you already looked into this one.
<Rutherther>I am certain it doesn't, errors when library is not found look differently, no such file or directory error always refers to a specific file or directory. When you are loading a library that is not found, there is no specific file checked
<PotentialUser-16>Rutherther I thank you, but shortly posting the question my connection (web client) closed silently and I missed your helpful answer. Apologies for disturbing you again.
<PotentialUser-16>Oh, there are IRC logs? :O
<Rutherther>for this channel there is
<lechner>maybe there should be a disclaimer every fifteen minutes
<Rutherther>ieure: I have made a simple .c program that just printf("hello"). Then gcc file.c, I removed rpath with patchelf --remove-rpath a.out. The error I get for not found libraries: "./a.out: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory ". So I was wrong it's not 'No such file or directory', but it is completely different error, it always prints the missing library, whereas issue with missing...
<lechner>bot testing #75000
<peanuts>"[PATCH] gnu: Add julia-compositionsbase." https://issues.guix.gnu.org/75000
<Rutherther>... linker will just print the filename and No such file or directory, being ambiguous with the executable file itself missing
<Rutherther>PotentialUser-16: from what I am looking into, seems to me wine is intended for 32bit usage, won't wine64 suffice for your use case? That one should be running fine. Wine package itself is broken, because it expects 32bit dynamic linker where there isn't, but it makes sense that it doesn't use the dynamic linker for x64_86
<PotentialUser-16>Ah. I see now there is a wine64 package. I shall test it then. Thank you once more.
<PotentialUser-16>Thank you and the other friendly people around here. Guix is challenging, but with your help (and patience) I am managing it.
<ieure>PotentialUser-16, Wine has some complexity around 32/64-bittedness.
<PotentialUser-16>ieure Yes. But I expect that 64 bit wine will run 32 bit software as well.
<ieure>PotentialUser-16, As of 9.0, it can: https://gitlab.winehq.org/wine/wine/-/releases/wine-9.0
<ieure>PotentialUser-16, But this is a fairly recent change, and traditionally, you've had to run 32-bit Wine to run 32-bit Windows software with it.
<ieure>Not sure if this is enabled in the Guix builds, at least as of 9.0, it wasn't the default, presumably because it was still new enough that there might be bugs to work out.
<PotentialUser-16>ieure Oh, so the wine 32-bit package should have worked and had a problem?
<Rutherther>wine(32) seems to work like this: "guix shell --system=i686-linux wine", which is counterintuitive imo, x86_64 should either be unsupported platform, or it should be made sure that it points to 32bit liraries and 32bit linker
<Rutherther>...that it points to them on x86_64 as well I meant
<PotentialUser-16>So... should I send an email to the issue tracker about it as well?
<Rutherther>you definitely can, I would be interested in the answer as well
<jas>Rutherther: thanks! i don't understand "just install empty manifest", how to do that? is that some empty/dummy package?
<PotentialUser-16>Rutherther May I please quote part of your explanation on the email? I am afraid I don't grasp the situation as well and I may be incorrect in what I say.
<Rutherther>PotentialUser-16: sure
<Rutherther>jas: no, just "(packages->manifest (list))"
<jas>Rutherther: okay, i'm working from the command-line, is there some equivalent 'guix package -i FOO' command?
<PotentialUser-16>Rutherther Thanks.
<Rutherther>jas: it's "-m=./path-to-manifest.scm"