<janneke>ACTION tries the new nmcli connection up vpn <janneke>Error: Connection activation failed: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed. ***Piece_Maker is now known as Acou_Bass
***Piece_Maker is now known as Acou_Bass
<sadiq[m]>is there a make target for guix that will only build packages (and nothing else)? <sadiq[m]>can somebody explain how to use guix environment -r FILE? <sadiq[m]>I did: `guix environment guix`, then `guix environment -r guix.env` <sadiq[m]>Then after `guix gc`, when I do `guix environment guix` all the bootstrap files are downloaded again. <janneke>sadiq[m]: use the -r FILE on the first invocation <janneke>you're creating /two/ environments, the second one is empty and has a root <sadiq[m]>hm.. so it should be `guix environment guix -r guix.env`? <sadiq[m]>I saved an environment via `guix foo --ad-hoc bar baz -r my-env`. Now to access this environment next time, will I always have to do `guix foo --ad-hoc bar baz` or is there some simpler way with my-env? <janneke>sadiq[m]: you can do something like: . my-env/etc/profile <janneke>read etc/profile for what will be happening when you do that <sadiq[m]>janneke: this is really fast. No more waiting... :) <jherrlin>hey, i am trying to install GuixSD but I keep getting an error: <jherrlin>/gnu/store/mcxid8xdcihd9pydyhgb08qlgcjf9kfa-grub-efi-2.02/sbin/grub-install: error: failed to get canonical path of `unionfs'. <jherrlin>This comes directly after populating '/mnt'... <cbaines>I'm no expect on UEFI, but have you mounted something at /boot/efi ? <cbaines>ok, are you following the installation instructions in the online manual? <jherrlin>i am sort of following it from the local docs <cbaines>in the local copy of the guix.texi that I have, /boot/efi is mentioned in the Disk Partitioning section <jherrlin>trying now again after remounted my boot partition to /boot/efi :) <jherrlin>thx cbaines, i could reproduce Eduardos problem changing to what i think is the old syntax <cbaines>jherrlin, so I take it that you were already using the new syntax, as suggested by Tobias in that email? <cbaines>jherrlin, what does findmnt say about /boot/efi? <cbaines>as in no output about any mount points? <jherrlin>│ └─/mnt/boot/efi /dev/sda1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro <cbaines>jherrlin, my interpretation of the docs would be to mount at /boot/efi rather than /mnt/boot/efi <cbaines>I don't have any experience at using UEFI, at least not intentionally, so I may be completely wrong, but it sounds like this may fix the issue <cbaines>Do you have anything mounted at /boot/efi ? <cbaines>Ok, then I don't think there would be any risk in trying a different mountpoint <cbaines>I'd be tempted also to unmount /mnt/boot/efi <cbaines>any luck using the /boot/efi mountpoint? <jherrlin>cbaines: nice! it works like a charm! thank you! :) <Apteryx>jherrlin, cbaines; great troubleshooting :). Welcome aboard, jherrlin! <jonsger>how can I use the guix version which is builded from source rather than the binary installed? <Apteryx>jonsger: probably something to do with GUILE_LOAD_COMPILED_PATH or something like that? <Apteryx>the guix launch script do a lot of env magic so it might be difficult to changes that. Any reason to not use a git checkout instead? <jonsger>can you use guix from source code only with "./pre-inst-env"? <Apteryx>if you haven't compiled it, yes! by default the script runs with --no-auto-compile, which means it is purely interpreting the sources. <Apteryx>if you already compiled it, you could run make clean-go to remove the binary files. <jonsger>Apteryx: I did "make" and the "./pre-inst-env guix --version" gives me an recent guix <jonsger>can I use the pre-inst-env guix normally as "guix"? <sadiq[m]>ACTION switched back to Debian GNU/Linux <cbaines>sadiq[m], are those two things connected? <cbaines>jonsger, I think your question might be connected to ~/.config/guix/latest <sadiq[m]>cbaines: sure. And my internet is too slow. As long as I don't have at least 1 Mbps internet and a good system, it would be too much time waste for me to use guixSD <cbaines>jonsger, I have that as a symlink to the guix git repository, meaning that when I run guix commands, they use the packages and scripts from the git repository <cbaines>sadiq[m], where you having issues with downloading lots to do updates when using GuixSD? <jonsger>cbaines: so you just linking the .config/guix/latest do source/guix? <sadiq[m]>cbaines: I work with gtk+, so I have to build/update several packages now and then. I think I can better wait a bit more before moving to guixSD <cbaines>jonsger, yes, I have ~/.config/guix/latest as a symlink to a checkout of the git repository <sadiq[m]>and Now I have a dialy bandwidth limit of around 150 MiB. :) <jonsger>cbaines: nice. that works. thank you. The syntax of ln is just a little bit confusing... :) <efraim>sadiq[m]: if you're on debian ATM you should look into debdelta <ng0>is christopher baines around? <ng0>I wonder if for the gnutls-dane patch series it isn't enough to mention as a comment in the code. <ng0>I don't want to explain all the implications about adding in the correct gnutls into the commit messages. what I have added in now is already enough imo <cbaines>ng0, I think what you wrote in the comment is great (the bit about GNS), but its more helpful for that to be in the relevant commits (at least to me who is looking at the commit messages to try to work out why changes are being made). <ng0>To be honest it's getting to the point where it feels like painting the bikeshed of the commit message. No one will really change this back to gnutls, and I can't point to a fixed link of a document because I am still working my way in GNUnet to having docs.gnunet.org/some/file.pdf <ng0>it's mentioned in our upstream documentations and READMEs. that's enough from my perspective, no point to explain in great length what exactly DANE does. <ng0>if I were some person curious in why this gnutls is used (which would be like .0001% of people reading the package dependencies), then I would rather read the upstream docs.. <ng0>squashing the 3 latest commits would not be very wise, right? They are not related but they are related in being dependencies of GNUnet. <cbaines>ng0, providing the last 3 commits are standalone, and not dependent on each other, then yes, ideally having them separate is good <cbaines>I'm happy to go with the "GNUnet and its dependency chain needs GnuTLS with DANE support." description <ng0>well it's a bit more descriptive the way it is right now <cbaines>ah yes, I think I missed the attachments on your latest email <ng0>I like your additions to xfburn, I'll take a break now and add it in a couple of hours <IpswichTriptych>Hello! I am hoping to get some help setting up ssh on my new Guix install. This is unfamiliar territory for me. I'm using a minor modification of the "barebones.scm" config file, the laptop is currently plugged into my gateway/router via ethernet cable. <ng0>can someone tell me if I misinterpreted or miss some details in how the screen-locker-service works? I have at least one screensaver which doesn't work with it (mate-screensaver). Doesn't work as in, doesn't appear in the system generation, etc <ng0>per documentation, this should just work: (screen-locker-service mate-screensaver "mate-screensaver") but it doesn't. <cbaines>IpswichTriptych, I take it you are looking to setup an SSH server, so that you can login over SSH? <IpswichTriptych>cbaines: yes, i'd like the GuixSD laptop to be the server, and I'd like to connect to it on the same local network using my other laptop <cbaines>IpswichTriptych, the Guix reference manual has some documentation on setting this up <cbaines>IpswichTriptych, Let us know how you get on <cbaines>ng0, I'm not sure where it would appear in the system generation, as setuid programs are a little different if I remember correctly <IpswichTriptych>Is there a way to copy the barebones.scm config file without the livedisk? I tried switching from barebones to desktop.scm, but the guix system reconfigure command failed, and now my config file is desktop but my system configuration is barebones. I'd like to modify the barebones configuration to be my current configuration. <cbaines>Do you still have a copy of the barebones configuration? <ng0>cbaines: well when it was part of the meta package 'mate' it appeared in the Mate Preferences. This is what should happen. I have removed it from mate because its locking function without suid just breaks your sessions <ng0>(breaks -> you get a screensaver but no option to log back in. same behavior I have with 2 other screensavers) <cbaines>IpswichTriptych, I'm not sure what you mean by "copy the barebones.scm config file"? <cbaines>also, when you say you switched to the desktop.scm one, what do you mean by that? <ng0>what I have is /etc/pam.d/mate-screensaver (but this could be from the mate-desktop-service) <IpswichTriptych>cbaines: on the livedisk, there are three example configuration files: /etc/configuration/barebones.scm, desktop.scm, and lightweight-desktop.scm <cbaines>ngo, if there is a mate-desktop-service, it sounds like it would be useful if that made mate-screensaver a setuid program, by having the service extension there? <IpswichTriptych>when i ran "system init", I used "barebones.scm" (slightly modified, renamed as config.scm) <ng0>I found no example on extensions <ng0>oh, I think I know it.. <cbaines>IpswichTriptych, ok, I'm following. Have you successfully installed GuixSD yet, or are you still using the installation system? <cbaines>ng0, it might be a little tricky, but the screen-locker-service-type can be used as an example, and hopefully the extension for the mate-desktop-service-type can be simpler, as it doesn't need to be configurable <IpswichTriptych>i've successfully installed GuixSD and have booted from it. I'm currently retrying a "system reconfigure /etc/config.scm", with a config.scm which is very similar to the one found on the livedisk at /etc/configuration/desktop.scm <cbaines>IpswichTriptych, ok, great, is that a modified version of the config.scm you used originally, or did you start by modifying the desktop.scm from the livedisk? <IpswichTriptych>(as an aside, i'm running guix-daemon as root which I know is bad, but I'm not 100% sure how to add the group guixbuild without "groupadd") <IpswichTriptych>cbaines: I started with a modified version of /etc/configuration/barebones.scm <IpswichTriptych>but wpa-supplicant did not work out of the box, and I thought I might try out xfce <cbaines>IpswichTriptych, ok, what error did running guix system reconfigure give you? It might be simple to solve. <IpswichTriptych>it was late last night... and I don't quite remember... something along the lines of "system reconfigure failed" due to something not being found, I think. I'm sorry, I know that's not helpful, but if it fails with the same error again I will be sure to provide it verbatim <IpswichTriptych>if there was something wrong with the Guile syntax it would have failed immediately, no? <cbaines>How are you getting on with the SSH service? <IpswichTriptych>i'm reading the documentation now... i can't multitask with this laptop because it's a X60 with only 1GB ram ^.^ <ng0>cbaines: yeah that way I could keep mate-screensaver in the mate package. but! big but: I think the description of the screensaver needs to reflect that if you try to use the package outside of Mate, and try to use the locking feature you won't be able to log back in. <ng0>I don't even know if mate-screensaver is one of the few packages in Mate that are not meant to be used outside of it <ng0>*not meant to be used in it <IpswichTriptych>dependencies couldn't be built. p11-kit-0.23.2.drv failed with exit code 1 <cbaines>IpswichTriptych, ah, ok so building one of the packages failed. <cbaines>It might be worth trying again, to see if it fails reproducibly <cbaines>IpswichTriptych, you shouldn't need to add those users <cbaines>the guix-daemon service does that for you <cbaines>IpswichTriptych, when you say you are running it as root, what do you mean? <cbaines>On GuixSD, it should be running automatically <IpswichTriptych>it would seem that guix-daemon does not start automatically after boot on my current configuration <IpswichTriptych>so, i have been invoking it manually as user root with "guix-daemon &" <cbaines>Ok, then hopefully it should be running <cbaines>If you stop running it with guix-daemon & do guix commands still work? <IpswichTriptych>cbaines: i appreciate your help. i know this is a logged chatroom and i hope my level of knowledge isn't too basic! <IpswichTriptych>it appears that guix is working after quitting the instance of the daemon i had started <laertus>i thought it was just supposed to get new package definitions <cbaines>laertus, what is stuff in this case? <laertus>i've seen it build other stuff before too.. i just can't remember what it was <cbaines>laertus, I think guix pull builds guix in the store, and doing that might involve building other packages <laertus>or is it building another copy for some reason? <cbaines>The guix pull command builds the latest version of guix, I think from the master branch in the git repository <laertus>should i expect it to build anything else, or just guix and its dependencies? <cbaines>well, dependencies of the dependencies as well <laertus>so it sounds like if i regularly run 'guix pull' i have to at least expect that guix and its dependencies might get rebuilt... <laertus>and that includes gcc, which for me is a multi-day build :( <cbaines>have you enabled subsitutes on this machine? <cbaines>also, what architecture are you using? <laertus>well, anything that gets compiled will probably need gcc, right? <laertus>i'm ok with compiling all my stuff.. that's what i do regularly with gentoo.. but i was hoping with guix i could just let my system sit for a while until i absolutely needed to update stuff, instead of having to constantly be compiling stuff to keep abreast of the newest packages in gentoo or risk stuff breaking when i finally do upgrade <cbaines>Unless you don't want to use substitutes, it might be good to use them to save time <laertus>but it sounds like at least for the guix binary, its dependencies, and those dependencies dependencies, i will potentially be compiling all the time anyway <laertus>yeah, i'd rather not use substitutes <cbaines>laertus, you'll only need to build gcc again if it actually changes <cbaines>I don't think the dependency tree of guix changes that regularly <laertus>alright.. well... i guess i'll see how it goes <cbaines>running guix pull usually takes a while as its compiling all the guile modules, and that is probably the limiting factor <laertus>yeah, i remember building guile on gentoo and that took forever also <laertus>one of these days i'll upgrade my machine to an 8-core beast with a zillion gigs of ram and then i won't care <laertus>so... anyway.. speaking of substitutes... <ng0>or just use trusted binaries… but that's up to you. <laertus>how do you know that someone hasn't put some malware up there? <cbaines>laertus, you have to trust the people running the substitute servers I guess <laertus>do you have to trust them more than the people who run the source servers? <ng0>that's not the question though.. it's the implicit social factor. on the technical side there's more <ng0>i just have no time to explain it. <cbaines>also, with Guix, in the future you might be able to trust consensus between substitute servers <laertus>but the binaries on multiple servers might be compromised <laertus>it's good that guix has or at least is moving towards bit-reproduceability <ng0>iirc the whole technical side is documented in the documentation + in the code <ng0>it is not "just binaries" <laertus>yeah, i don't mean to come off sounding dismissive <laertus>i know there are checksums and other safeguards <laertus>but i am genuinely concerned about my security <laertus>and just want to know what guix does in this respect.. so i'll check out the docs <ng0>among other things, the nar files are signed with the signature of the server. <ng0>and if the hash should ever differ guix says "you shall not pass" and rejects it <laertus>how does the original hash get on the servers? <ng0>it's in the package receipe. so through people and QA. <laertus>i guess i'm just generally wondering if i'll be any less secure using substitutes than just building from source <ng0>but it's easier to read what we have documented imo (and I need to fix this service) <cbaines>laertus, I think its more secure to build from source than using subsitutes, as with substitutes, you are trusting the substitute server to provide a real substitute, and not tamper with it <IpswichTriptych>it appears that guix pull has stalled do to "GC Warning: Failed to expand heap by 8388608 bytes" <cbaines>IpswichTriptych, guix pull requires ~2G of ram, so you might need to use some swap <cbaines>IpswichTriptych, hopefully the resource usage will improve in the future, as the issues with Guile are currently being worked on <IpswichTriptych>"guix pull: error: failed to connect to '/var/guix/daemon-socket/socket': Connection refused <cbaines>IpswichTriptych, if your system ran out of ram, the guix-daemon may have died <cbaines>you might need to restart the service <laertus>just out of curiosity.. when guix builds packages, why does it run through all the tests? <laertus>with this automake build, the tests are taking a significant amount of time <IpswichTriptych>cbaines: you got it, a "herd restart guix-daemon" resolved the issue <laertus>is there a way to just disable tests for all package builds on my system? <ng0>but it's lots of manual work <laertus>automake has been running tests on my system for an hour now :( <cbaines>laertus, the easiest way that I can think of would be to use guix from the git repository, and modify the build systems to not run tests by default <laertus>i have a feeling skipping tests will save me days of compile time in the long run <ng0>and introduce the side-effect of not knowing wether the build is okay. <laertus>but i've been running gentoo since 2004, constantly build and rebuild packages, and it never tests for any packages built on it.. and i've survived... so i feel pretty confident in not needing them <ng0>guix is not gentoo though <laertus>what makes it need more testing of its builds than gentoo does? <ng0>even gentoo has their tests, it's only that users are not running them afaik <laertus>so similar tests are not done by guix servers and the testing is left up to the users? <ng0>why do you try to read between the lines? <ng0>the CI of guix runs exactly what users locally build <laertus>i was just trying to undertand the differences between the testing that guix does and gentoo does <ng0>if a package has #:tests? #f it will not run tests. <ng0>that's the only time no tests are happening <ng0>it's best if you stop trying to compare gentoo and guix. it doesn't really help you, even if you think it does. trust me, I've been there. <laertus>i understand that a build can test fine on a server and fail tests on my system.. and i guess i'm just willing to take that risk <laertus>if my system wasn't so old and slow, maybe i wouldn't care.. but it's crawling.. and i'm not quite ready to move to using substitutes <laertus>is sourcing "$HOME/.guix-profile/etc/profile" which contains only: export PATH="${GUIX_PROFILE:-/gnu/store/r58j67a2r3n96pbm82xf2bmyzyfzpp0b-profile}/bin${PATH:+:}$PATH" <laertus>the same as just export PATH="$HOME/.guix-profile/bin${PATH:+:}$PATH" ? <laertus>i think $HOME/.guix-profile just links to the same /gnu/store location anyway <laertus>and i've seen some messages from guix advising me to prefix my PATH with $HOME/.guix-profile/bin <laertus>so sourcing "$HOME/.guix-profile/etc/profile with its own prefix of PATH seems kind of redundant <IpswichTriptych>so, i did not run guix pull with the --verbose option... I seem to be stalled at compiling 57.0%. is there a way to investigate the output? <Apteryx>did you look at top? your ram might be maxed out. <laertus>using swap will probably slow things down a lot <ng0>well the good news is I fixed the screensaver. the bad news is that I need to work on some other part of Mate to get the lock screen fully functional <ng0>thanks for the tip cbaines <Apteryx>eh, I might have found something strange. Usually when I edit a package recipe and run it in ./pre-inst-env, it rebuilds it since the computed input hash is modified; but I just tried adding a native input to gcc-4.7.4, and running 'guix build gcc' simply pulls the substitutes from the servers, which means its hash hasn't changed! gcc (latest) depends on 4.7.4 through a long chain of record inheritance. Bug? <nextstep>Hi, I'm considering to transition 2 servers from Arch to Guix. Everything looks quite in place. Any plans to support smartmontools and lm_sensors (already packaged) as daemons in herd? These are quite important for server monitoring. <nextstep>Is there any compatibility layer for daemons which already have systemd units written for them?