IRC channel logs
2025-05-23.log
back to list of logs
<amano>Is it possible to make a guix source package for an electron application? <amano>There is node-build-system for npm dependencies, but I don't see a build system for electron. <civodul>futurile: excellent; i also optimized my email workflow just a month ago, after leaving it unchanged for 20y :-) <polyedre>futurile: wow, great article. You are definitely very good at writing clear stuff! <futurile>polyedre: thank-you, appreciate that - always hard to tell if it's clear or a confusing mess of three-letter-acronyms <apteryx>do we have some machinery to rewrite all references from one package to another one in Guix? <apteryx>I'm building pkcs11-provider, which requires openssl, let's say openssl-bootstrap. Then I build openssl with pkcs11-provider as an input. The problem is that openssl-bootstrap is still present in the graph. I'd like to perhaps, as part of the openssl build where I want to integrate it, copy the sole pkcs11.so module, and hack its ELF so that it points to #$output instead of to openssl-bootstrap. <apteryx>(that's a bit a weird use case -- it's not strictly necessary to have pkcs11-provider as an input to openssl, but I'm attempting to cause openssl to always load certs from the system trust store exposed via p11-kit) <civodul>apteryx: sounds like --with-input aka. package-input-rewriting, no? <azv4l>is it me or the substitutes server for nonguix is down ? <azv4l>my server started building the newest Linux kernel because it couldnt reach it ;; <apteryx>civodul: hi! I don't think package-input-rewriting can do what I want; I basically need something to modify the references from X to Y in a .so ELF object. <apteryx>azv4l: perhaps ask in their channel? <azv4l>ah yes sorry, didnt think of that <apteryx>np! note that substitutes sometimes lag behind <apteryx>you can wait a couple hours and retry, and chances are you'll then have substitutes <azv4l>oh I meant, my server literally cannot ping their server (if I understand correctly what you meant) <azv4l>in case that helps, they blocked ipv4 due to abuse <civodul>apteryx: oooh, got it; (guix build grafts) then? <hiecaq>About the tramp missing `ls` command error, emacs-minimal has a snippet fixing that, which is not included in emacs-next. there is already some fix for that to let emacs-next-minimal use that too in the issue tracker: https://issues.guix.gnu.org/77034 <ieure>apteryx, package-mapping will do this, but requires some care to use, and it doesn't know about packages defined in services. <apteryx>hm, 'unable to get local issuer certificate'. I'm not having success configuring either pkcs11-provider or libp11's provider to bridge openssl <-> p11-kit yet <apteryx>got it working with gnutls thus far, and nss too, I think <apteryx>the idea would be to offer a central, user-manageable (I think p11-kit enables that) trust store that would be provisioned by default <apteryx>so it'd work even in containers without carrying nss-certs around <rynn>Anyone have a full list of plugins to enable for XFCE? The manual only lists two: "When using this service, you should add extra plugins (xfce4-whiskermenu-plugin, xfce4-weather-plugin, etc.) to the packages field of your operating-system." <apteryx>while allowing users to opt-out/configuring things easily still (via p11-kit config files/overrides) <rynn>Last time I tried to enable weather not realizing I'd forgotten the weather plugin and it borked my entire session. <apteryx>try it ala github, which forgejo emulates mostly <identity>rynn: well you can `guix search xfce4-.*-plugin` <civodul>cbaines: cgit appears to be timing out <ieure>cbaines, Forgejo uses the same GitHub style URIs, `/compare/refa..refb'. <cbaines>civodul, the configuration we're using for cgit means that the request processing is in serial, and that combined with some scraping activity means that it's slow and there's lots of timeouts <apteryx>neat, I was able to build two meson projects with muon + samurai in Guix <civodul>heh no, i’m kidding; instead! i spent 3 hours automating it <dthompson>I suppose I should join a team at some point <dthompson>apparently my votes have been ignored because of this. but I come from before the time of teams lol <civodul>but what matters is the consensus-building phase that comes before <dthompson>I haven't been able to pay enough attention, I guess <vagrantc>does the environment that guix daemon uses to build things have /bin/sh or /usr/bin/env ? <old>sneek: later ask civodul if we now have a guile-codeberg interface after importing Guix teams ^^ <identity>vagrantc: It Depends (on the build system) <ruther>identity: how can what is shared in the chroot depend on the build system? <identity>ruther: oh, i did not know that they are shared <ruther>the guix-daemon provides the chroot, I am quite certain it cannot depend on the build system, it doesn't even know the build system <vagrantc>identity: which build systems have /bin/sh or /usr/bin/env? <poplin>hello. I'm trying to setup a shepherd service that runs a in a container. I have a config-cont.scm which runs the service (by $(guix system container config-cont.scm)). To generate the host shepherd service, is the correct way to define a simple-service with make-forkexec-constructor "$(guix system container...."? <identity>ruther: i can not seem to be able to invoke /bin/sh in a trivial-build-system build expression, am i doing it wrong? <ruther>identity: no. There is just no /bin/sh shared in the chroot <vagrantc>i do not think /bin/sh exists in the build environment <vagrantc>i had to (substitute* "somefile" (("/bin/sh") (which "sh"))) to get it to work <identity>ruther: wait, did you not say that it was shared in the build environment by the daemon just 30 minutes ago? i am confused <ruther>identity: I didn't say such thing. I just said that what is shared in the chroot doesn't depend on the build system <identity>ruther: oh, do you mean it as distinct between what is shared vs the inputs? <ruther>identity: I have no idea what you're talking about <vagrantc>you basically have the inputs that come with a build system, and the inputs (and native-inputs, etc.) that a package defines ... those will all be available in the build environment <vagrantc>a guix installed system may have /bin/sh and /usr/bin/env <identity>ruther: i read your "how can how can what is shared in the chroot depend on the build system?" as implying "/bin/sh is shared regardless of the build system", which it, in retrospect, probably was not implying <ruther>identity: I was just saying that it can't depend on the buildsystem without saying whether /bin/sh or /usr/bin/env is or isn't in the environment <ruther>because I don't actually remember what files are available and was too lazy to check <ajarara>hi, there's no herd specific irc so trying here: I want to mount an array of LUKS devices without having the key on disk. I think the best way to do this is to write my own system service that mounts it, have it as a dependency of the couple of things downstream (container services, samba eventually), and then start it interactively. This should work, right? I wouldn't have to also start dependent services manually? Also, the key <ajarara>be in memory, which is fine, I'm guarding against home burglary not state level cold boot attacks. <g_bor>hello all, I was wondering what would it take to upgrade guile to 3.0.10 <g_bor>any idea on what this would involve, or it this already planned and underway? <identity>g_bor: you probably want to look at the guile-next package <g_bor>I am using that as of now :) <g_bor>Any I could definitely very easily create a pacakge that points exactly to 3.0.10, but I was wondeing if there is any know blocker for this update <g_bor>I guess literally everything depends on this, so it is core-updates category (I am not sure, but that is my feeling) <dariqq>g_bor: https://issues.guix.gnu.org/72183#6 this broke guix pull. Upating the default guile is a world rebuild because guile is used as the driver for every build. iirc guile 3.0.10 also has some issues on 32bit architectures <g_bor>ok, this is already something I can have a look at <g_bor>now this is in the core-packages-team competence if I managed to gasp the roles right around this, is this correct? <g_bor>ok, and it also looks that the agreement was to skip 3.0.10, both blockers are addressed on current main and we are waiting for 3.0.11, in case anyone is wondering about the same thing <Tadhgmister>if I want an ipv6 address from dhcp do I specify a second `dhcp-client` service or is there a way to get the one to give me both? <Tadhgmister>oh wait I do have both, that is not a MAC address whoops <ieure>Tadhgmister, Do you need DHCPv6? Many setups use SLAAC. <Tadhgmister>idk, syncthing gave a warning that it couldn't use ipv6 so I ran `ip addr` to see if I had an ipv6 address and my eyes just glossed over `inet6` thinking it was the mac address <Tadhgmister>so presumably I was going up totally the wrong tree there <ieure>The inet6 address might include your MAC!