IRC channel logs


back to list of logs

<mirai>civodul: aah, I guess it would have made sense writing them in the commit
<mirai>its explained in the cover letter <>
<mirai>attila_lendvai_: I think it would depend on define-record-type* to have it, there's <> tracking it
<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 '', which cannot be found in RUNPATH ()
<mossfet>error: depends on '', which cannot be found in RUNPATH ()
<mossfet>which i am not sure how to resolve
<viaken>GuixSD doesn't adhere to the FHS and the binary has a path hard coded to 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> I wanted to run this
<bdju> also does anyone know what's up with this license? is it just the MPL renamed or something? is it still free?
<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
<sneek>Will do.
<ngz>cbaines: It seems there's a problem there: <>. The process seems stuck (the log hasn't changed in the last 8 hours). As a consequence, comparison is not available at <>. Do you know what happened, or how it could be fixed?
<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
<sneek>Will do.
<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>ngz, I think the other thing to do regarding tex-team-next is push which should fix evaluating the branch on
<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.
<janneke>jpoiret: yay :)
<PotentialUser-84>i like guix
<cbaines>ngz, great, I've pushed now so hopefully that'll get things working over at
<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>efraim: nope
<jpoiret>i don't even think there's a hard way
<ngz>cbaines: It seems to introduce a build failure, according to <>
<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>hi, this still seems to be an issue or is there anything wrong with my home config?
<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
<graywolf>I am trying to setup guix offload, but I am getting . The file does exist and has 0600 permissions. Any ideas?
<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>jpoiret: sounds good!
<graywolf>civodul: uff... thanks
<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?
<zacchae[m]>Hi Guix!
<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?
<RavenJoad>I am trying to add packages to a system that inherits a %base-system, so I do (services (append (list (udev-rules-service ...)) (operating-system-services %base-system))), which returns the error guix system: error: more than one target service of type 'shepherd-root'. Base: and Desktop:
<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...
<jonsger>podiki[m]: do you use ROCm?
<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]>clarkf: maybe you are looking for package input rewriting:
<podiki[m]>otherwise for direct inputs you inherit the package and then can replace/prepend inputs for instance
<podiki[m]>e.g. random example:
<clarkf>Oops, guess I hadn't read that page far enough. Thanks podiki[m], I'll try `package-input-rewriting`.
<podiki[m]>No problem!
<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
<podiki[m]>(vs Nvidia)
<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 :)