IRC channel logs
2024-04-22.log
back to list of logs
<iK0u>Has anyone succesfully managed to avoid having to enter their disk passphrase twice with encrypted root? <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 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 <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'? <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' <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>ci.guix.gnu.org 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) ? <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 <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. <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. <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 https://github.com/lindig/lua-ml 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 <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? <dariqq>why is all of gnome/gtk currently rebuilding on master? <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>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>are there known vulns in nss 3.88.1 ? <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]>“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." <singpolyma>when building guixified rust, is there a sane way to pass --allow-dirty ? <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)