***freaj is now known as freaj_
<bishopj>on the download page there are signiture files to verify the download but I can't seem to find the public key used to verify those signitures <mark_weaver>the announcement email also gives a handy command to get the key: gpg --keyserver keys.gnupg.net --recv-keys 3D9AEBB5 <bishopj>which appears to be Ludovic Courtès' personal gpg key <bishopj>which could be signed by the project members to create a full web of trust <bishopj>also 3D9AEBB5 is NOT in gnu-keyring.gpg <mark_weaver>yes, it's Ludovic's key. what's wrong with that? how does that make it less secure? <mark_weaver>someone has to be in possession of the private key material. personally, I prefer to know who that is. <bishopj> I figured guix might have a seperate project key like tails does. <mark_weaver>I have great respect for Jacob, but I'd be curious to see an argument for why that approach is better. <bishopj>1) more easily allows a fully offline key <mark_weaver>when I see a key that doesn't have a person's name on it, I wonder (1) who has copies of the private key, (2) who has the responsibility if a signed but compromised tarball is discovered. <mark_weaver>bishopj: why does it more easily allow a fully offline key? plenty of people have personal keys that are kept on an air-gapped machine. <bishopj>mark_weaver: it is simply more common for people to use a single gpg key for everything than to have multiple seperate gpg keys for seperate tasks on seperate systems <mark_weaver>bishopj: consider this: the bigger problem is that you probably don't have a trust path from a key you trust to Ludovic's key. <mark_weaver>now, Ludovic can go to keysigning events and get people to sign his key. <mark_weaver>but should he go around and ask people to sign a "Guix distribution key" key? <bishopj>a project key, signed by all the members of the guix team can quickly build a bigger web of trust <mark_weaver>think about what it means for the person being asked to sign that key. signing a key means that you stand witness that the key is under the possession of a human being whose identity you know. <mark_weaver>bishopj: we could just as easily all sign Ludovic's key, but that requires that we first meet with him in person. <mark_weaver>but I don't know what it means exactly for me to sign a key that purports to be the "Guix distribution key". For all practical purposes, what I'm really asserting is that Ludovic has possession of that key. <mark_weaver>anyway, feel free to post to guile-devel@gnu.org with your suggestions for how we could do things in a better way, along with arguments in support of it. <mark_weaver>I'm not necessarily saying you're wrong, I just don't understand what it would be an improvement. <bishopj>hmmm, you make a completely valid argument. However some people might feel more comfortable should an organization be the one behind the release even though through policy it is obvious the individual behind that action is. <bishopj>aka when people hear the gnu project or the debian project verfied X <bishopj>they give it more acceptence than John Smith verfied X <bishopj>even though in reality it was John Smith who was responsible for the Y project Key to sign X <mark_weaver>well, it may be true that most people put more trust in an organization than an individual, but in the case of private keys I think that's foolish. <mark_weaver>I have much more trust in a private key that only one person has access to than one that is shared among several people. <mark_weaver>and the actual job of preparing the tarball release is done by a real human being on one computer. <mark_weaver>and if it turns out to be compromised, that individual must assume responsibility. none of the other people involved in the project can take responsibility for that. <bishopj>compromising an offline key is quite a feat <mark_weaver>what we have instead is that the GNU project appointed Ludovic as maintainer of GNU Guix, he's the one who prepares the releases, and so he's the one that signs them. <mark_weaver>bishopj: well, I meant if the tarball release is compromised <bishopj>You also could do a signiture chain, aka all commits are signed by the people doing the work. <mark_weaver>keeping the private key on an airgapped machine doesn't change the fact that ultimately the tarball is derived from a source code repository that several people have write access to, and the steps of running 'autoreconf' and preparing the tarball is done by Ludovic on his machine. <mark_weaver>bishopj: well yes, we should indeed start signing our commits in the git repo. <bishopj>thus the project key becomes little more than a stamp saying that the commits done previously are deemed as trusted by the release process <mark_weaver>suppose we had a project key with no human name on it. who do you think should be in possession of that private key material? <bishopj>I say write up the process of producing release files, allocate a position to handle it and have the person doing that task make their own private key with the right details and have the previous project key sign the new key <mark_weaver>so even though a single person has possession of the private key, you think it's a bad idea to put that person's name on the key? <bishopj>I feel it will reduce the chances that they might use the key for anything else <mark_weaver>as for having the previous project key sign the new key: what happens if the person in possession of the previous project key lives on the other side of the world from the person who replaces him? <bishopj>certified mail was good enough to ship the hope diamond <mark_weaver>wow. well, that was a different time. nowadays, when we ship our computers they are sometimes intercepted so that the NSA can implant spying devices in them. <mark_weaver>if you are truly suggesting that postal mail could have a role here, you've lost me. <bishopj>except keysigning can be done with printed documents that can use methods to reduce tampering <bishopj>keysign-party, includes the ability to print out what is needed to validate and sign another person's key <bishopj>yes and we can use water marked paper <mark_weaver>that method of using key fingerprints depends on the fact that a man in the middle is unable to replace the key fingerprint while it's in transit. <mark_weaver>so it works well when I meet you in person and give you a printout with my key fingerprint. <mark_weaver>however, if you send it over the postal mail, it doesn't work. <mark_weaver>I'm sorry, I don't have time to continue this discussion right now. but feel free to post your proposal and arguments to the ML. <vmlinuz88>I am running GuixSD. I've created a package definition, and I'm not sure how to test it. I've tried using the --load-path option for 'guix package', but it doesn't find the package. <sneek>Welcome back vmlinuz88, you have 1 message. <sneek>vmlinuz88, rekado says: Do not let anything install anything into /gnu/store/ other than Guix. To install Python packages that are not yet packaged for Guix I recommend creating a package recipe and submitting it to the ML. Python stuff is usually easily packaged. <mark_weaver>vmlinuz88: set the GUIX_PACKAGE_PATH environment variable to point to a directory containing your *.scm file <mark_weaver>see section 6.5 (Package Modules) of the guix manual <vmlinuz88>mark_weaver I've set the env variable, it still says no module found. <vmlinuz88>since I'm using a custom package definition directory, do I still use (define-module #:gnu packages ...)? <vmlinuz88>would I have to modify the gnu packages part? <iyzsong>vmlinuz88: yes, suppose you have set GUIX_PACKAGE_PATH to /tmp, and you have /tmp/foo/bar.scm, then the module of bar.scm should be '(foo bar)'. <iyzsong>the GUIX_PACKAGE_PATH is added to guile's load-path, the loading rules of guile modules applied here <luqidqanx>Hello, I'm currently using Guix SD and I'm running into a problem. I need to create a directory in "/etc/ssl/certs" but I can't. Mkdir yeilds this error when I attempt to: "mkdir: cannot create directory ‘java’: Read-only file system". How would I go about creating that directory? <luqidqanx>The entire file-system is not read-only, it seems to be only that small part. <mark_weaver>/etc/ssl/certs is managed by guix. the idea is that you add the 'nss-certs' package to the 'packages' section of your OS configuration, and that more generally you can choose which certificate packages to install. <mark_weaver>and I'd like to make it easy to add your own CAs, or individual certs, as well, although I haven't done that yet. <mark_weaver>that's the idea anyway. would that work for you? what are you needs? <luqidqanx>And have a ton of things already in the certs file. <mark_weaver>if you have nss-certs in the config file, then /etc/ssl should be a symlink to /run/current-system/profile/etc/ssl <mark_weaver>and /run/current-system/profile/etc/ssl/certs should be populated with the certs from NSS <mark_weaver>so, you'd like to add more of your own CAs or certs, I guess? <luqidqanx>I still can't create the directory in the /run/current-system/profile/etc/ssl/certs <mark_weaver>okay, so doing this easily depends on the thing I haven't yet done <mark_weaver>that's because after resolving symlinks, that directory is within /gnu/store, which is mounted read-only for good reason. <mark_weaver>it is part of the immutable store, and the design of guix depends on having an immutable store <mark_weaver>one is to set environment variables and/or application-specific configuration to look for the system-wide trust store in a different place <mark_weaver>openssl consults SSL_CERT_DIR and SSL_CERT_FILE, git consults GIT_SSL_CAINFO <mark_weaver>unfortunately there is no standard way to specify which set of CAs to trust for all programs, so this is not entirely satisfactory <mark_weaver>the way we envision this working is to create a guix package that installs your desired certs, and that add that alongside nss-certs. <luqidqanx>That package does exist, ca-certificates-java. <mark_weaver>and we can make this very simple, like just writing (custom-certs-package "/home/mhw/my-certs.crt") <mark_weaver>however, we haven't actually implemented that part yet. <mark_weaver>luqidqanx: oh, okay, so we just need to add that package then. <luqidqanx>I'm just trying to install the certs created by that package manually <luqidqanx>After spending a lot of time struggling with it <mark_weaver>well, if we do the job properly then the next user won't be faced with the same problem :) <luqidqanx>I weep for the next user to have this problem. <mark_weaver>luqidqanx: well, for now, you could modify your guix to not create the /etc/ssl symlink, and then you can put whatever you want there. <mark_weaver>looking at that package, I get the impression that it's not so much about adding more certs, but rather for maintaining the JKS keystore, which I guess is just a different representation of the CA certificate database, for use by java programs. does that sound right to you? <mark_weaver>and I personally have zero experience with java, so I'd rather leave this job for someone else. <luqidqanx>At least the part that goes in /etc/ssl/certs/java <luqidqanx>Also, how would I go about removing the synlink? <mark_weaver>well, the relevant code is in 'activate-etc' in gnu/build/activation.scm <mark_weaver>see the (rm-f "/etc/ssl") and (symlink "/run/current-system/profile/etc/ssl" "/etc/ssl") <mark_weaver>as root, you can remove the /etc/ssl symlink right now, but beware the next time you boot whatever you put there will be deleted and the symlink newly made <mark_weaver>to get the full power of guix, you must build it from a git checkout and run it from there. <mark_weaver>and then you can make arbitrary modifications to guix while still easily incorporating our upstream work. <luqidqanx>Thanks very much for helping a beginner out. <luqidqanx>Cya when I completely screw up everything :p <rekado>guile emacs doesn't work for me, unfortunately. I get this error: "Cannot open load file: No such file or directory, emacs-lisp/byte-run" <taylanb>rekado: 'emacs -q' works for me; using ERC from guile-emacs ATM <Anony_>Hi, I want to give GuixSD a try but sadly on my main system I get constant errors about flash memory devices and thus "gnu-disk-image" not being found, any suggestions? <Anony_>taylanub: device /dev/sdX not found, and after that a warning about not finding the partiotion label named "gnu-disk-image" <rekado_>Anony_: the X in /dev/sdX is to be replaced with the actual letter that has been assigned to your USB device. <rekado_>I assume that you want to put the downloaded disk image on an empty USB drive. <rekado_>when you plug in the drive, you can check the device node created for it with "dmesg|tail". <rekado_>as the name differs depending on the number of existing disk nodes, "/dev/sdX" is used in the instructions. <Anony_>rekado_: It's not actually X in the error messages, errorr basically shows (in the boot proccess) up for every flash memory device wich I have connected to the computer, the USB drive with the image on it works fine on other system, I just can't get it work on my main system. <mbuf>is there a way to make the USB xz file bootable from a VM manager? <mbuf>or use an .iso bootable format? ***noob is now known as Guest37633
<Guest37633>Hi all. Complete noob questions… is this OS X installable, would you recommend for a new mac setup? <rekado_>Guest37633: Guix cannot currently be used as a package manager on top of OS X, as far as I know. This would require porting. <taylanub>hi civodul :) maybe you can help me out: how can I get the propagated inputs of the package being built, in a build phase? (for the pkg-config inputs verification phase I'm working on) <civodul>taylanub: "get" as in "get the list of inputs that are propagated"? <rekado_>I'm disappointed to see that Nix cut corners when it comes to Java libraries. The recipe for GWT, for example, is just: download zip, unpack. <civodul>rekado_: i looked at the issue you reported, and it's fishy <rekado_>this is all rather frustrating, because I haven't done anything weird. Just installed from the USB image :-/ <taylanub>civodul: hmm, in that case I can't verify whether all inputs that should be propagated are in 'propagated-inputs'. maybe instead I could make it print a notice like "make sure the following inputs are propagated: foo bar baz." or maybe it shouldn't be a build phase after all? <civodul>taylanub: yeah i hadn't realized that, but yes, you might have to do that <davexunit>bleh, for some reason my libgcrypt is messed up <davexunit>and guix will no longer pass the configure phase <davexunit>(dynamic-link "libgcrypt") doesn't work, despite having the library installed on debian. <Anony_>Well, I was able to solve my issue by using an internal hard disk to boot it instead of a USB device. But I still get errors such as "error opening USB device descripotrs file"... ***Gonbe is now known as _`_
<mark_weaver>davexunit: are you trying to load Debian's libgcrypt from the guile built with Guix? <mark_weaver>that won't work. in general, you cannot link shared libraries from Debian and Guix into the same process. <davexunit>I thought I was using the system guile, but in fact I was using a guile built with guix. <toothbrush0>Hello Guix! So, i've probably done something boneheaded, but after doing `git pull; make; make install` all commands returned errors relating to libgcrypt not being found... <toothbrush0>I therefore (probably made stuff worse) and deleted /gnu/store/*gcrypt*, now the error is (unsurprisingly) "guix package: error: open-file: No such file or directory: "/gnu/store/ynjmfg24r0dkc47f2jfsy11kwzifw5kp-libgcrypt-1.6.3.tar.bz2.drv""..... <taylanub>toothbrush0: one shouldn't ever touch /gnu/store, because there's a database in $localstatedir (e.g. /var/guix) which needs to be in sync with /gnu/store. not sure how your state could be restored. <toothbrush0>Right. But it was screwed up somehow before i (stupidly) did my thing: i kept getting guile backtraces saying libgcrypt couldn't be found (including when i did `guix package -i libgcrypt`) <taylanub>maybe you were running a guile version that wasn't from guix, and it couldn't find the guix-installed libgcrypt? <toothbrush0>(i use guix on top of another distro, so i won't lose much) <mark_weaver>it might be because the directory named in the --with-libgcrypt-prefix=/gnu/store/*-libgcrypt* option you passed when building guix no longer exists. <toothbrush0>mark_weaver: i definitely didn't specify a gcrypt when building guix... <toothbrush0>my usual method is simply make; make install with defaults (which is perhaps stupid of me..) <taylanub>that's fine if you manually ensure that you have the dependencies of Guix mentioned in the README <toothbrush0>i'm kicking myself now that i didn't save the original error backtrace, that might have given a better clue... <mark_weaver>the --with-libgcrypt-prefix option is needed when building guix within a guix environment (i.e. using compiler/libs from guix to build guix) <taylanub>that would mean you probably had libgcrypt installed from your distro's package manager (otherwise ./configure would have failed). if so, do you still have it? <mark_weaver>note that software must either be built using compiler/libs from Guix, or using compiler/libs from your host distro. mixing libs from Guix and your host distro within the same process doesn't work. <toothbrush0>mark_weaver: hm, maybe that's a problem. i've been naively doing things without thinking about that.. till now it Just Worked™ <mark_weaver>also note that when loading a shared library using dlopen (as is done by guix for libgcrypt, iirc), if anything at all goes wrong trying to load the library, you get a "not found" type of error. <mark_weaver>so, if guix is now built using libs from guix, and it's trying to open libgcrypt from your host system, you'd likely see an error like that. <toothbrush0>is that very likely, considering i just went `make; make install` then a bunch of `guix package -i ...` for applications like emacs and my pdf reader? <mark_weaver>I think it's the most probable cause of your problem. you probably started out building guix using a pure host-distro environment, and now you've added some guix stuff to it, and now you're trying to rebuild guix in a mixture of the two environments. <toothbrush0>assuming i want to keep in another host distro, what's the best way to prevent that from happening? <mark_weaver>when building software, you need to either completely exclude guix from the environment, or make it an exclusively guix environment. <mark_weaver>I don't know what it means to "keep in another host distro" <toothbrush0>so bootstrapping is complex.. or should i start with the binary tarball for guix, instead of the git version i have been using? <taylanub>installing guix on top another distro is now a breeze with the binary/"bootstrap" tarballs, and from there you can build git checkouts of guix like: guix environment guix --pure -E './configure --prefix= --with-libgcrypt-prefix=$(guix build libgcrypt | head -n1) && make' (and it's probably best to avoid 'make install') <taylanub>to rebuild, just run: guix environment guix --pure -E make <toothbrush0>mark_weaver: um, i mean, assuming i'm not going to throw away my Arch installation, but i'm willing to install guix from scratch, how can i prevent that from happening <mark_weaver>well, I still recommend building guix within git, because it allows you to easily customize it and contribute patches to us. <taylanub>oh and before the first you'll need to run 'autoreconf -vif' (here it doesn't matter whether you use guix environment or the host environment if I'm not mistaken) <mark_weaver>but you need to decide whether you want to build it in a pure guix environment or a pure non-guix environment. I can tell you how to do it either way. <mark_weaver>well, as taylanub suggested, "guix environment guix --pure" will give you a pure guix environment in which to build guix. <mark_weaver>within that subshell, I would run "autoreconf -vfi", and then rerun configure with the same options as before except also with --with-libgcrypt-prefix=$(guix build libgcrypt | head -1) <toothbrush0>but if libgcrypt is an exception (i'm guessing, given your --with-libgcrypt-prefix.. flag) will i run into this with some other library down the line if i don't do the --with-frooble-prefix=$(guix ...) for it, too? <mark_weaver>no, libgcrypt is an exception. I don't remember the details, but apparently there's no good way to find it if it's not in the standard places. <taylanub>I wonder if they couldn't just provide a .pc file like any "sane" library... :) <toothbrush0>so i should blow away my current /gnu and /var/guix, then use the bootrstap tarball? <taylanub>and /root/.guix-profile if you have one (it will be created) <taylanub>nope, but you can just run '/gnu/store/...-guix-.../bin/guix package -i guix' with your user to get one with guix installed <mark_weaver>toothbrush0: remove /gnu and /var/guix, and then extract the binary tarball, making sure to pass --skip-old-files to the tar command when extracting it. <wingo>yay for that binary tarball install, what a felicitous idea <taylanub>otherwise it may change permissions of /root and /var <mark_weaver>to work around the fact that we include /, /var, and /root in the tarball and so without that option it may change the ownership/perms of those directories. <taylanub>indeed the bootstrap tarballs are very nice :) <toothbrush0>so, mark_weaver, maybe that should be added to the docs :p (about the skip-..) <taylanub>toothbrush0: I think it's been fixed upstream <mark_weaver>somehow, we didn't discover that problem until after the release. a few people gave rave reviews to the binary tarball before release but didn't notice that problem :-( <mark_weaver>toothbrush0: we added it to the docs, and then I just fixed it in a better way, by simply omitting those directories from the tarball altogether. <toothbrush0>anyway, i'm running Emacs from guix, so there might be a service outage. 'till later and thanks for the help taylanub and mark_weaver ! <mark_weaver>per policy, we don't update tarballs after they've been released. we could perhaps post some new ones with a slightly different name, e.g. 0.8.2a <toothbrush0>this is going to bite those poor souls trying it out for the first time <wingo>you could just release a 0.8.3 <wingo>i sometimes think we are too conservative and let the numbers run us <wingo>i read an interesting essay by lewis mumford in which he claimed that clocks were the ultimate machine <wingo>in that a machine is composed of resistent pieces that together perform work <wingo>and that clocks and calendars make resistent pieces out of us all <toothbrush0>hm, my /root directory has non-permissive permissions, which makes running `guix` as a normal user fail <toothbrush0>that gave an error though, so i ended up doing `tar kxf ..` <mark_weaver>toothbrush0: you can use whatever permissions you like on /root <toothbrush0>mark_weaver: but /usr/local/bin/guix -> /root/.guix-profile/bin/guix <mark_weaver>the docs say that --keep-old-files reports errors when files already exist, whereas --skip-old-files silently ignores them. <mark_weaver>toothbrush0: well, how about making /usr/local/bin/guix a symlink to /gnu/store/*/bin/guix <mark_weaver>toothbrush0: actually, the doc says to make the link to /var/guix/profiles/per-user/root/guix-profile/bin/guix <mark_weaver>which bypasses /root entirely, and is also better than what I suggested <mark_weaver>ah, indeed, it was changed after the release and I'm looking at a newer version. <toothbrush0>alright, it looks like i'm on my way :) it's happily downloading substitutes <toothbrush0>does anyone else get flooded with "warning: failed to install locale: Invalid argument"? <taylanub>toothbrush0: yes, it should be mostly solved when you install the 'glibc-locales' package and export the env var LOCPATH to ~/.guix-profile/lib/locale <taylanub>toothbrush0: after that you might still get "substitute: warning: failed to install locale: Invalid argument" sometimes when using 'guix package' and such, for which I don't know the solution yet because it seems harmless so I didn't bother so far <toothbrush0>indeed seems harmless, but i don't like warnings. :p <mark_weaver>the warnings don't occur on GuixSD, which is our primary focus <toothbrush0>the warnings should get the phrase "this doesn't happen on GuixSD, upgrade now! :D" appended <hwpplayer1>i think that GuixSD will be leading libre distro <rekado>could someone with a working "sudo" command please check the permissions with "ls -l $(which sudo)"? <rekado>The permissions here are: -r-sr-sr-x 2 root root 171360 Jan 1 1970 /run/setuid-programs/sudo <toothbrush0>-rwsr-xr-x 1 root root 118128 Mar 22 01:49 /usr/bin/sudo <rekado>I get this error for anything involving sudo: "sudo: unable to stat /etc/sudoers: Permission denied" <rekado>"permission denied" is also the error I get when building stuff locally. Related? <mark_weaver>rekado: /etc/sudoers exists on GuixSD. if you're on another system with no /etc/sudoers, I guess you need to create it yourself. <toothbrush0>hm, so after doing `guix environment guix --pure`, the command `guix` is unavailable -- is this normal? <mark_weaver>toothbrush0: yes, what you have available is everything needed to build guix from source code. <toothbrush0>except that above, you suggested i do `./configure ... --..=$(guix ..)`, which doesn't work? <toothbrush0>or should i have done the `guix build libgcrypt` ahead of time, outside of the env? <rekado>I do have /etc/sudoers and I haven't played around with permissions anywhere; but sudo isn't working and I also get "permission denied" on execve guile when building packages. So I wonder if that's related. <mark_weaver>rekado: yes, it might be related, and probably worth mentioning in the email thread about your problem. <mark_weaver>rekado: an strace of your attempt to run sudo might be helpful <toothbrush0>hm, i'm curious as to why `guix environment guix --pure` installs alsa-lib? Is that necessary to build guix? <toothbrush0>..it also seems to download multiple versions of ncurses, gzip, gmp, and friends... <toothbrush0>hm, it really just seems to be going around in circles. it's been about 30 minutes now (!) and it seems to just be installing the same thing over and over. Is this normal? <oblo>dependencies are a hell.. you think "i don't need it" but you need it <toothbrush0>davexunit: yeah. i did `guix environment guix --pure` which was rather fast, then at some other point in a fresh shell `guix package -i guix` and now it seems to have done something weird to `guix env guix --pure` <davexunit>emacs-no-x is a dependency for the guix package, so I could see how some seemingly unneeded dependencies are brought in <toothbrush0>davexunit: hm, okay, it just finished, i'll see if it seems to work. <davexunit>hmmmmm I seem to have really screwed up my user profile somehow. <davexunit>not sure how. I thought maybe my recent commits broke something, but I rolled back to an earlier version of master and the problem is the same. <davexunit>been having nothing but problems on this computer lately. <davexunit>the fact that the relevant tests are still passing gives me comfort that it's just my hodge-podge debian system that is messed up, not guix itself.