IRC channel logs
2023-07-11.log
back to list of logs
<mirai>civodul: aah, I guess it would have made sense writing them in the commit <lfam>Hey RavenJoad, yeah the new links work. Sorry I ran out of time to look into it <mossfet>heya, is this the correct channel to go for help packaging something? <lfam>I g2g but you'll get help here <mossfet>cool. i'm trying to package a webring me and a friend made. it's a rust binary that depends on rust 1.70.0, which guix doesn't package, so i'm relying on basically grabbing a binary from gitea and installing it to bin. however, upon validating RUNPATH i get this <mossfet>hold on a sec i'm trying to work out how to send it <mossfet>error: depends on 'libgcc_s.so.1', which cannot be found in RUNPATH () <mossfet>error: depends on 'ld-linux-x86-64.so.2', which cannot be found in RUNPATH () <viaken>GuixSD doesn't adhere to the FHS and the binary has a path hard coded to ld-linux.so. You might get it to run with `guix shell --emulate-fhs`. <viaken>You may want to double check that flag is right. I'm on my phone. <lunabee>CI is saying it "Failed to process revision" on my patch. does that just mean that there's some compilation error I somehow didn't catch, or? <bdju>do appimages ever work on guix or no? <bdju>It seems free to me but the fact that they renamed it kinda throws me off <bdju>and would that trademark thing prevent official packaging? <mirai>run it through 'licensecheck' <mirai>maybe it can answer that for you <lilyp>sneek, later tell civodul mirai fixed the underlying issue so the reverted patches became superfluous <efraim>Does anyone know how to refer to the tuning-compiler from (guix transformations) from within a package definition? <jpoiret>sneek, later tell civodul: Apparently the locales aren't needed for now so I just dropped them, will merge soon <cbaines>ngz, that job will have stopped when I restarted the data service last night, I've got it running again now <ngz>cbaines: OK. Thank you! <cbaines>does that sound OK? It won't affect any outputs. <ngz>cbaines: So, I'll need to rebase tex-team-next on top of it once it is applied, right? <cbaines>ngz, I was thinking just to push it to tex-team-next, but if you're planning to rebase anyway that approach would be fine? <ngz>I was not planning to do any rebase, the last one is recent enough. So I guess this will go to the branch directly. <efraim>when I'm inheriting from another package is there an easy way to force it to re-evaluate things in the arguments like version? <jpoiret>i don't even think there's a hard way <cbaines>ngz, that's just a problem with the way I'm running the job, I think because GUIX_LOCPATH was unset. I've now set that and am trying again. <minima>the ticket is about bash completion functions not being loaded when using guix home <minima>the last post (from 18 march) includes a workaround (which works for me) and seems to imply that the issue should have been fixed as part of the core-updates merge <minima>but that doesn't seem to be the case? which is fine, but it left me wondering whether there's something else that's wrong in my setup <civodul>graywolf: hi! you need to run 'guix offload test' as root <sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, lilyp says: mirai fixed the underlying issue so the reverted patches became superfluous <sneek>civodul, jpoiret says: Apparently the locales aren't needed for now so I just dropped them, will merge soon <civodul>lilyp: alright, makes sense! would be nice to state the rationale in the commit log of reverts, but no big deal <janneke>ACTION can run guix offload test as janneke, fwiw <graywolf>Hmm, offload is not used with build --check? Is that by design? <civodul>graywolf: right, it's not used for --check, though i'm not sure what the rationale was <graywolf>Good to know. I think I got it working, and it is pretty sweet to be able to offload build to my home server. Yet another great thing :) <zacchae[m]>It seems ~/.guix-profile/etc/profile overwrites the value of GDK_PIXBUF_MODULE_FILE to one in the gnu store. This caused my phone to boot to black screen after updating. I assume this is because a new package version is no longer compatible with the one provided by guix. Should guix really be overwriting GDK_PIXBUF_MODULE_FILE on foreign distros? <clarkf>Is the preferred method of overriding an input version defining an inherited derivation with `modify-inputs`? <clarkf>I'm basically trying to re-create the behavior of `guix build --with-input=...` but in config.scm <vagrantc>did the full-source-bootstrap land in guix 1.4 ? <vagrantc>ah, no, it was in the core-updates merge that landed after the release... <clarkf>Actually, I guess it's more complex - `emacs-exwm` doesn't list `emacs` as an input directly, hmm... <podiki[m]>jonsger: just for opencl support in darktable, but it works for me <podiki[m]>otherwise for direct inputs you inherit the package and then can replace/prepend inputs for instance <clarkf>Oops, guess I hadn't read that page far enough. Thanks podiki[m], I'll try `package-input-rewriting`. <clarkf>That worked like a charm! Thank you so much! <pjals>Hi! How do I make Python able to find dynamic libraries in guix shell? I'm trying to use pywiiuse with my own wiiuse package I made (the libraries have been successfully installed into the profile). <pjals>I cant simply package pywiiuse since I've kinda forced myself into using a FHS-like development environment <RavenJoad>So I narrowed down my problem. Even mentioning (services ...) in an operating-system record adds a shepherd-root service to the list. So (services (operating-system-services %base-system)) means 2 instances of shepherd-root and profile service-type get added. How can I stop this? <zacchae[m]>clarkf: I don't think you want emacs-exwm to specify emacs, because some people might want to combine it with a different emacs package (like emacs-next) <zacchae[m]>pjals (trans rights): I've had this problem, and I end up having to run python with a command like "LD_LIBRARY_PATH=$GUIX_PROFILE/lib python3 ..." <jonsger>podiki[m]: do you know if there are jobs in BOINC with ROCm nowadays? <zacchae[m]>I see one instance of "LD_LIBRARY_PATH=/run/current-system/profile/lib python ..." in my notes <clarkf>zacchae[m]: the derivation (specification?) of `emacs-exwm` generates a .desktop entry with the fully qualified path of emacs <clarkf>if you just install `emacs-next` (or, in my case, `emacs-next-tree-sitter`), it will launch emacs 28 (i.e. not-next) still <podiki[m]>jonsger: considering I had to look up what boinc is... unfortunately don't know anything in that area other than the general perception that amd lags badly in the computing space <jonsger>heh, yeah thats sad. Especially as they tend to me more open in terms of software <jonsger>I'll have a look when it's getting colder here again :)