<erudition>Well I'd think the proof could be machine-verified anyway
<excalamus>kirisime: I'm working through the manual now. Here is what I've found helpful...
<erudition>Then you need only peer review the input assumptions
<excalamus>kirisime: If you're familiar with Emacs, reading the info files in there is very convenient. Excellent searching capabilities, plus, you can take notes with org-mode easily in another buffer. If not, just use the regular 'info guix' in the CLI.
<excalamus>kirisime: Everything documentation-wise seems to be on the cgit repo. Let me grab that for you. It's technically at the bottom of the Guix documentation page, at the veeeery bottom.
<excalamus>kirisime: scratch that last one. That's the maintenance git.
<excalamus>quiliro: I'm interested in packaging and read through the tutorial you mentioned. I was inspired, but a little lost on where to start. I'm re-reading the manual (and taking notes). I may need to go shortly, but I would appreciate knowing I can ask broad, potentially bone-headed questions.
<sneek_>Welcome back excalamus, you have 1 message.
<sneek_>excalamus, quiliro says: there are videos on mediagoblin
<quiliro>sneek_: later tell excalamus here is the message bot
<excalamus>I'm a bit confused by ~/.config/guix/current. It links to a different guix than ~/.guix-profile. Why the need for ~/.config/guix/current?
<apteryx>rekado: re ice-9 and guix records; in the case of guix, it seems the constructor is implicitly built, and never used explicitly, correct?
<apteryx>Then what is the use of specifying its name (e.g., the make-operating-system constructor defined for the 'operating-system' record is never used explicitly. Then why require it to be named at all? I wonder :-)
***scs is now known as Guest49074
<leungbk`>efraim: I read your message about the problems with the recursive crate importer. I think we can deal with the problem of duplicate recipes appearing by ensuring the #:cargo-development-inputs do not contain entries that are already in #:cargo-inputs (and also making sure the same #:cargo-input doesn't appear more than once in a given recipe). Do you expect this to cause any problems during the build phase of a package?
***Sleep_Walker is now known as Guest50077
***scs is now known as Guest92488
***scs is now known as Guest67683
<efraim>sneek later tell leungbk` I'm not sure about making sure packages only appear in cargo-inputs or cargo-dev-inputs, but the package definition only needs to happen once
<reepca>so I've been running the tests and I'm noticing that all the importers seem to expect to be using newer versions of guile-json (where objects are alists instead of hash tables), but our package definition for guix specifies guile-json-1. Consequently most importer tests are failing.
<reepca>never mind, just checked the backlog and saw it's already mentioned
<reepca>hmm, well, I put enable-ssh-support in my ~/.gnupg/gpg-agent.conf, restarted it, and set SSH_AUTH_SOCK to the result of 'gpgconf --list-dirs agent-ssh-socket', but the prompt still shows up in the magit-process buffer and I can't enter anything.
<reepca>on manually running ssh-add it asks for the passphrase for the key in the terminal, then after that it asks for a password to protect it with in a graphical dialog box
<rekado>bgardner: unfortunately, I wasn’t able to make LDAP authentication work.
<rekado>I can do “su ldap-account” only if I also prefix the command with LD_LIBRARY_PATH pointing to /gnu/store/…-nss-pam-ldapd-0.9.10/lib/
<rekado>otherwise it doesn’t even try talking to LDAP
<reepca>is tests/guix-build-branch.sh outdated? It looks like it should have been changed with commit 4d04bc50d2df32be326e0f48f378dc581f873989 2 weeks ago to match the new behavior of recognizing version tags and dropping the "v" at the start.
<reepca>currently it's failing on line 56 because the version field is "0.1.0" now instead of "git.v0.1.0"
***scs is now known as Guest96831
***scs is now known as Guest81298
***Guest50077 is now known as Sleep_Walker
***scs is now known as Guest55595
<vagrantc>hadn't seen any updates to master for a while ... just cooincedence, or is there some reason not to push that i missed?
<malaclyps>so I did a guix pull, than a guix package -u, and now sway is kinda broken on my machine. Rolling back the upgrade makes it work again, but I'm interested in working out what might have happened.
<malaclyps>I can't see a change in the guix "sway" package definition, and looking in the /gnu/store for the sway directories, I can see that the binary is the same, but it links to a few differing libraries
<malaclyps>is there a way to see what/how might have prompted those changes between two guix package generations?
<rekado>malaclyps: when inputs to a package change, the package is rebuilt with these changed inputs.
<rekado>malaclyps: you can take a look at the Guix git repository to see how these inputs may have been changed.
<GNUtoo>I tried to make lxc run that through virt-manager / virsh: /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile --no-auto-compile /gnu/store/c7qcancm3bj3294l6krhsyr96wn3h0mk-shepherd-0.6.1/bin/shepherd --config /gnu/store/19fzhcg975bmxhhicf2nnp56sbsv8wsy-shepherd.conf
<GNUtoo>it boots then crash with "bad file descriptor"
<tune>rekado: ah I had to reload the agent, it works now!