*georges-duperon had an Agda course a while back and should try to use it again (or Idris maybe).
<georges-duperon>ng0: My project is generating a disk image, and the partitioning tool needs a UUID.
<georges-duperon>ng0: Until now I was using `git log --format=%H -1', cutting that hash the right length, and inserting dashes in the right positions, which gave me a nice UUID.
<georges-duperon>ng0: With (source (local-file …)), I'm not copying the .git (for obvious reasons), so my build can't do that anymore.
<georges-duperon>ng0: so I was trying to inject the hash of the inputs in some way into the build.
<georges-duperon>I think in the end I'll generate a temporary disk image using 00000000-0000-0000-0000-000000000000 as the GUID, hash the resulting (deterministic) image, and then modify the GUID using that hash as a basis.
<georges-duperon>That way the build process will be deterministic, but will not actually require git nor guix (the latter being used "only" to ensure the build tools en environment are fixed)
<pkill9>and also being able to configure the system using a single configuration file, so when you need to do tweaks like adding kernel parameters, they are all recorded into that configuration file, so in the future if you for example need to reformat, you won't lose/forget about those tweaks
<`ani`>what is your stance on kernel JIT updates? such that a reboot won't be necessary to get the new fixes.
<`ani`>can I install a set of packages based on a configuration stored in my home dir?
<pkill9>also, not having to use LD_LIBRARY_PATH to run software from the guix repos on the foreign distro (usually grpahical software, also I couldn't get a guix-packaged window manager to work with my foreign distro's xorg)
<pkill9>well, it's not planned, but if it works well then I assume it would be accepted if you posted a patch, because there's a `guix import json` which basically takes the package definition as fields and outputs a package definition in Guile
<pkill9>so since that's been accepted, i would assume tools that make it easier to generate package definitions in general would be accepted
<georges-duperon>`ani`: True story: a couple of days ago, a relative installed the updates on an ubuntu machine, using the GUI (so nothing fancy). The updates managed to silently crash mid-way, and left /boot/grub damaged, with only half of the files in there.
<georges-duperon>`ani`: I'd feel safer rebooting the machine if I can. C code is already an unsafe mess of pointers and segfaults, patching things in-memory without any formal guarantee that you did it right is something that I'd do only if I really have no other option.
<georges-duperon>Can't locate Archive/Zip.pm in @INC (you may need to install the Archive::Zip module) (@INC contains: …) at /gnu/store/…-perl-archive-zip-1.60/bin/crc32 line 8.
<Laalf>could i have an example of a cron service that works? i cant get it to run because In procedure append: Wrong type argument in position 1 which makes no sense to me
<iyzsong>georges-duperon: yes, the crc32 doesn't get its Archive::Zip module. Wrap it with PERL5LIB with the 'site_perl' directory of perl-archive-zip would help. See 'perl-file-mimeinfo' for an example (using wrap-program).
<georges-duperon>Laalf: that error message usually indicates that you gave e.g. a string where a list of strings was expected.
<snape>to get the Guix you pulled, you can cat $(which guix), and look for "guix.*modules" (the regexp) in there
<Laalf>is there anyone running commands at startup as a user in guixsd? if so: how? i would still be ok with rerunning the program every x minutes but i dont get mcron to work. i know it runs but it just doesnt work.
<snape>it's subtle because the guix of 'which guix' is not the same as the one from guix-daemon, which is the one packaged
<snape>Laalf: I don't think we have user services yet
<EternalZenith>snape: I'm going to have to build a custom kernel to get my wifi working, and grub takes a while to load with an encrypted root, even with an ssd, so I was thinking it might be easier to just try building a vm
<snape>EternalZenith: Yes, it's a good idea I think!
<snape>but you'll have issues when it comes to making sure your VM finds your Wifi adapter
<EternalZenith>So, the guix executable itself is always stored in a directory owned by the user who's running it, and it interfaces with a guix-daemon that has all the priveleges necessary to preform whatever task is given by that user?
<snape>Laalf: could you paste your whole config.scm?
<snape>your error comes from your use of 'append', which doesn't appear in the snippet you showed
<kurimi>Hello, i have tried running guix pull as a user and i got error message "guix pull: error: symlink: Permission denied: "/home/kurimi/.config/guix/current-1-link.new"" the folder ~/.config/guix is owned by root and doesnt have any files in it. what can i do to solve this?
<kurimi>georges-duperon: really only that? okay. thanks
<georges-duperon>kurimi: most of the time this happens when you run a command using sudo but actually shouldn't have.
<georges-duperon>kurimi: Linux has two notions of the "current" user. There's the current permissions, and the user that started the commands using sudo (roughly, or it might be the $HOME that isn't properly adjusted). And some programs get confused and place files owned by root in your ~.
<kurimi>yeah but im not sure that it worked first time
<kurimi>btw... if group kurimi doesnt exist ... do i do just kurimi:users?
<lrvick>So I noticed that unlike the official nixpgs repos, all commits in Guix are signed. I was unable to find a way to get an authoritative list of keys to compare against though. Are there plans to have something like the Arch Linux pacman-key tool for maintainer key distribution as well as getting both Hydra and end clients to do signature verifications?
<lrvick>Would love to hear (or be pointed to) thinking here in general
<lfam>I don't recall where we discussed the decision to sign all commits, if it was in that thread or somewhere else. At that time, there were only two mailing lists, guix-devel and bug-guix, so it shouldn't be too hard to search
<lfam>IMO, signing commits is okay for seeing who made which commit. But, beyond that, it's not a good technique for "code-signing", because Git doesn't distinguish between bad signatures and signatures whose keys have expired.
<lfam>That could be fixed in Git, of course, but I'm skeptical about basing this on using the `gpg` command-line tool, which is extremely complicated and not really designed to be used interactively, even though the GnuPG team strives to maintain the command-line interface
<lfam>Ultimately what we should do is implement The Update Framework <https://theupdateframework.github.io/>. They have already thought about this problem exhaustively, and it will be more efficient to build on their work than try to approach the problem from scratch
<lrvick>I think VCS signing proving integrity there so consumers of the git repo (like hydra) can verify it and authorship but TUF makes more sense for the actual release flow imo
<lrvick>Looks like Guix already sign every commit though so preaching to choir :)
<lfam>After we decided that all commits would be signed, once in a while somebody would make a mistake and forget to do it, or even make a bad signature with a buggy GnuPG client. So we made a pre-push Git hook and ask Guix committers to install it when we give them commit access, in the HACKING file: <https://git.savannah.gnu.org/cgit/guix.git/tree/etc/git/pre-push>
<lfam>It verifies the signatures of the commits being pushed and blocks the push if any of the commits are unsigned or the signature can't be verified
<lfam>IMO that drawback shows another weakness of Git commit signing for even the use case of knowing who made the commits
<lrvick>I am not sure that I follow how a hook not knowing to respect per branch enforcement impacts the ability to know who made the commits.
<lfam>From Git's point of view, when you push a new Git branch to a remote repo, you are effectively pushing the entire Git history up to the HEAD of your branch. Since we didn't sign commits at the beginning, the verification will fail. So, signature verification must be done by the human, and they do make mistakes :) It doesn't exactly affect the ability to verify commit pushers, but it shows that the Git model is not well-suited for this use case, in my opinion.
<lfam>In the pre-push hook, this is the case '["$remote_sha" = $z40 ]'.
<lfam>($z40 is explained in the comment at the beginning of the hook)
<lfam>Oh, it's actually not explained there, sorry lrvick
<lfam>It's just a Git convention for a non-existent commit, for example a new branch or a branch deletion
<lfam>Anyways, these sorts of little "gotchas" in the implementation really highlight that the tools could be improved, at least
<lfam>But to clarify, they are way better than nothing!
<lrvick>I do agree there is a lot left to be desired in git signing. Particularly if you want to attach signatures after the fact. I have taken to adding sigs on the git notes interface for some of my projects, allowing adding reviewer sigs later, or even including the expected binary hash.
<lrvick>It does mean having to use a git plugin though which is not ideal but... tradeoffs.