IRC channel logs


back to list of logs

<wakyct>IIRC alpine uses doas too?
<coyote>it does
<coyote>at least by default
<Kolev>coyote: wakyct: based.
<iK0u>Has anyone succesfully managed to avoid having to enter their disk passphrase twice with encrypted root?
<iK0u>I am referring to Procedure: luks-device-mapping-with-options [#:key-file] in
<peanuts>"GNU Guix Reference Manual"
<iK0u>I followed the manual and instead of it auto unlocking after entering it the first time, it says could not open keyfile
<iK0u>I put the keyfile in /
<iK0u>I also tested the keyfile manually and it works
<iK0u>When it says could not open keyfile I am required to enter the passphrase the second time
<iK0u>What I put in my config is like this (mapped-device (source (uuid "myuuidhere")) (target "mycryptroot") (type (luks-device-mapping-with-options #:key-file "/cryptokey.key")))
<iK0u>If anyone knows what I did wrong or has succesfully done this setup and can post their config that would be appreciated
<ulfvonbelow>did something happen to the emacs packages? I've got hash mismtches for emacs-debbugs, emacs-compat, and emacs-auctex
<ulfvonbelow>for example, current sha256 for emacs-compat seems to be 0i57hs3ak5y0fsfdwg87ib64ny0ar1nk67f5dy2qrm8x3i0h086s, while guix has it recorded as 191cjzrw9xm5bvcf8s1yr9hdcn9i02789xfd8pz33lk65s0rq413
<troi>Tonight, I will either fix my lockscreen or go shleepy
<futurile>Happy Monday all!
<ayatsfer>hi, is it common practice to generate a "locked" channels.scm from a "unlocked" one to be used with time-machine?
<ayatsfer>e.g. channels.scm containing just guix, and running "guix time-machine -C ./channels.scm -q -- describe -f channels > channels.locked.scm"
<ayatsfer>I came up with this pattern myself, but I don't know if people are already doing this (module filenames)
<futurile>ayatsfer: what do you mean it's 'locked'?
<ayatsfer>containing the commit sha
<futurile>ayatsfer: ah right - yeah that's what I do to keep my systems in sync - create a channels.scm and have a specific commit in it - fully 'declarative'
<futurile>ayatsfer: it's a good approach I think
<sham1>I'd say it's a fairly common pattern, yeah
<sham1>I do it, for example. It's a great way to sync, as said before
<jakef>i don't do that but it sounds good to me
<rekado> is unusually slow in processing the "master" jobset.
<rekado>substitute availability is also unusually low for that branch.
<rekado>not a good look. I'll try to hack a little something to restart jobs that have failed due to missing derivations
<nutcase>in my (operating-system) definition: how can I add a (plain-)file to /etc with specific permissions (e.g. 0400) ?
<nutcase>Kolev: this is what I have so far to enable doas in my operating-system:
<peanuts>"debian Pastezone"
<nutcase>and I am aware of
<peanuts>"[PATCH] services: Add doas service."
<cbaines>nutcase, things with 0400 shouldn't be in the store, so this currently isn't possible with Guix since it keeps the configuration in the store
<nutcase>cbaines: /etc/sudoers is an exception to this? Can't I create a file analogously?
<cbaines>nutcase, yep, since the content of /etc/sudoers is readable in the store, but Guix specifically copies the content from the store and changes the permissions to satisfy sudo
<cbaines>as I say, if you're happy with the content being world readable, but you just need some file in /etc created from the system config to not be, you can take the same approach
<nutcase>ok, so it's no real security benefit then, right?
<nutcase>the bin in question doesn't complain about the file being world readable
<cbaines>if you're happy with the contents being world readable, I'd just use the etc-service
<nutcase>I'd not say that I'm happy with it, but also don't see an immediate risk.
<nutcase>it's more important to have it not world writable of course
<sham1>From my (somewhat limited) experience with OpenBSD and doas, I wouldn't expect doas.conf to have all that much sensitive information in it
<madeleine-sydney>i have openssh set up in my home configuration as in the doc's example. how do i run sshd? i'm on debian — systemctl doesn't work
<rekado>ACTION VACUUMs the cuirass db
<cdo256>Hi, Is it possible to use package transformations with Guix home? Either from the command-line or in Scheme. eg.
<cdo256>guix home reconfigure --with-source=cdo-config-files=/home/cdo/src/config-files/ ~/channel/cdo/config/home.scm
<cdo256>fails because --with-source can't apply to guix home/
<cdo256>madeleine-sydney: The home configuration only gives you the ssh client. You'll have to set up the server depending on the init system of your distro. Eg. systemctl for Debian.
<hiecaq>ulfvonbelow: I asked about that last month on the Matirx #emacs channel and someone pointed my to
<peanuts>"Hundreds of ELPA packages updated today?"
<ulfvonbelow>is there a way I can download the old-hash sources from official guix substitute servers without having to authorize them, so that I can manually compare them?
<admmk>Hi guix, I send a letter to help-guix but it didn't appear in mail archive after several hours. I'm using gmail. It okay and I should wait or try another mail server?
<Altadil>admmk: If it’s the first time, it needs manual approval, so it may take some time.
<admmk>Ohhhhh, okay, thank you
<nutcase>sham1: I don't have any experience with doas (except for using it for two hours now), but from what I see, it wouldn't be a problem to have the config public. Is the same true for /etc/sudoers?
<sham1>Well sudoers would be a bit more complicated since you can have a lot more complex policy with sudo
<Argyro>Hi, just tried to guix deploy and it complains, that my "profile contains conflicting entries for nss-certs". Haven't changed anything related to nss-certs, any hints on how to resolve this conflict?
<ieure>Argyro, Remove (specification->package "nss-certs") from your operating-system.
<ieure>Argyro, I posted about this on guix-devel over the weekend.
<opdroid1234>Any pointers on how to customize the qt build? I would like to compile qtbase with asan enabled. In upstream QT this can be done by passing "-sanitize address" to the configure script. Any pointers on how to do the same with guix? I dont understand how packages can be customized / tweaked yet.
<coyote>hi everyone, I'm trying to package this OCaml package but I'm having some problems wrapping my head around the install phase, since upstream uses a Makefile for building, but not for installing, so I'm trying to have it use `opam-installer' for that, but I'm not really sure about how to do it
<peanuts>"GitHub - lindig/lua-ml: An embeddable Lua 2.5 interpreter implemented in OCaml"
<coyote>I tried replacing the install phase with a lambda that invokes opam-installer, but then I'm not sure how to set the prefix/etc. to the output path
<coyote>Are there any pointers on how to do something like ths?
<ulfvonbelow>for what it's worth, the diff in emacs-compat between the old and new versions looks like this:
<peanuts>"debian Pastezone"
<dariqq>why is all of gnome/gtk currently rebuilding on master?
<Argyro>ieure: Thanks. That was it. :)
<apteryx>ieure: i'm working on a fix for the (specification->package "nss-certs") conflict thing
<ieure>apteryx, Excellent, what approach are you using?
<apteryx>replacing nss-certs with the latest version
<apteryx>its just data
<apteryx>I also have a commit grafting nss with nss-3.98 but that's not needed per se, but since I'm looking at it I'm curious if it'd work.
<ieure>apteryx, Okay. I think there's a comment about keeping nss and nss-certs in sync in the code -- but not sure what the failure mode there would be.
<ieure>Or maybe it's just a reminder to update nss-certs. Not sure.
<apteryx>it's just to not forget to update nss-certs
<apteryx>since it copies its source instead of inheriting from it
<apteryx>due to module cyclic dependencies issues
<apteryx>it'd be nicer to have it defined in (gnu packages nss), and its binding re-exported in (gnu packages certs) for convenience
<apteryx>than we could just reuse the same sources without the copying
<apteryx>(via inherit)
<apteryx>are there known vulns in nss 3.88.1 ?
<apteryx>ACTION looks at CVE-2023-5388
<apteryx>looks like it was committed to the 3.90 branch at mozilla:
<peanuts>"nss: changeset 16767:196716d8377ab427e326f20bff2d026e90ac69e2"
<apteryx>must be included in 3.98
<apteryx>so now I can mention 'gnu: nss: Graft with version 3.98 [fixes CVE-2023-5388].'
<lispmacs[work]>I think there should have been a fourth volume in the LoR series. The one where Frodo and company face the daunting, uncertain task
<lispmacs[work]>of trying to build qtwebengine without a substitute
<lispmacs[work]>without a
<lispmacs[work]> substitute
<lispmacs[work]>“Despair, or folly?' said Gandalf. 'It is not despair, for despair is only for those who see the end beyond all doubt. We do not."
<lispmacs[work]>ah, the crispy smell of four cores at 100% for an hour
<singpolyma>when building guixified rust, is there a sane way to pass --allow-dirty ?
<coyote>Hi everyone :-) I packaged Soupault (, a static site generator written in OCaml with the dependencies that weren't yet packaged in Guix and was looking to contribute the definitions to upstream, so I was wondering if I could have a couple of eyes to look at my definitions to see if they're okay or not:
<peanuts>"ocaml.scm ?"
<coyote>I have them in their own module mostly for testing while writing them, also, the current version of `ocaml-camomile' in the packages is outdated, but nothing seems to depend on it (at least according to guix graph), so I hope it should be an easy change for that
<coyote>I wanted to have a second opinion before giving submitting a patch a go, I hope it's not a problem :-)
<ieure>coyote, Have you run guix lint and guix style on these?
<coyote>I have not, thanks for the heads-up
<nutcase>Hi, is anyone here using successfully "$(guix build emacs-pgtk-xwidgets)/share/applications/emacsclient-mail.desktop" to handle mailto: links via chromium/firefox/xdg-open ?
<oriansj>well wayland and xdg-open (which is via X11) is kind of a combo that requires x11 running on wayland
<nutcase>oriansj: ok, I have xwayland running
<nutcase>but my emacs --daemon is on wayland and so is my chromium
<coyote>ok, I've run guix lint and guix style and fixed what it told me to fix. I suppose the warnings about the Software Heritage Archive/Disarchive can be mostly ignored?
<coyote>(I also didn't know about lint/style, these are very nice)