IRC channel logs


back to list of logs

<nee`>I updated the wishlist at by adding links to WIP packages and reasons why progress on some things is blocked.
<daviid>guile-gcrypt is not listed in ?
<daviid>oh, not on the first page, sorry for the noise
<daviid>actually it seems it is not listed anywhere, for info ...
<nee`>daviid: Last time I checked, the package for guile-gcrypt was only in it's repository and not in master, yet.
<daviid>nee`: i was just curious, but tx
<christopher74837>does compiling guix-0.14 require guile-gcrypt, or just libgcrypt?
<christopher74837>i am getting configure error, but I know libgcrypt is installed
<christopher74837>can't seem to get the configure file built for guile-gcrypt
<christopher74837>error: could not locate guile aclocal macros
<christopher74837>i'm rather stuck, then, trying to build guix-0.14
<christopher74837>It gives me error "GNU libgcrypt does not appear to be usable"
<christopher74837>i wonder if it is problem with versioning
<christopher74837>ack, stumped after solving 8 other compiling problems across a half-dozen packages!
<christopher74837>where is libgcrypt on your systems?
<str1ngs>christopher74837: what distro are you on?
<str1ngs>how do I install a specific output. example glib has bin output I need. I though guix package -i glib-bin would work, but it says package not found.
<str1ngs>nvm I found it. glib:bin
<buenouanq>: is for output @ is for version
<str1ngs>also is there something that helps with managing guix environment variables. my .bashrc is getting out of control
<str1ngs>specifically for my profile
<brendyn>str1ngs: those variables should go in .bash_profile, not .bashrc
<nee`>str1ngs: You can `source /var/guix/profiles/per-user/<user-name>/guix-profile/etc/profile`
<efraim>i just bumped libinput, libinput minimal, libwacom and xf86-input-wacom and suddenly i'm rebuilding libarchive, did I miss something?
<htgoebel1>Hi guix,
<htgoebel1>I try to update to guix 0.14 using "guix pull" from (guix version is 20170924.19)
<htgoebel1>Just at or near the end of compilation i get this
<htgoebel1>ERROR: In procedure private-lookup: Module named (guile) does not exist
<htgoebel1>How to get around this?
<htgoebel1>ACTION htgoebel
***htgoebel1 is now known as htgoebel
<civodul>rekado: 56 'guix offload' processes running on berlin, impressive :-)
<efraim>doesn't look like there's a qtwebkit release for 5.10.0
<rekado>civodul: we now have 25 build servers. I’m playing with the storage today and hope that I can move cuirass to the new server soon. That would free up the server that’s currently used as berlin as yet another build node.
<rekado>there’s also another big server with SSDs that has fallen out of use, which I’ll try to integrate into the build farm by the end of this year.
<jonsger>guix gives your old server a new life :P
<rekado>yeah, it’s great :)
<shiranaihito>ok.. i'm trying to actually start using GuixSD, so it's time for a barrage of noob questions :p
<Digit>yay. ;)
<shiranaihito>for example, here: - what does ""my-root" is the label of the target root file system." mean? :)
<shiranaihito>i'm planning to run GuixSD on a Vultr VPS, and it seems the installer goes through at least.. i only saw the image's worth of disk space attached to the instance though.. maybe Vultr's disk will magically appear after rebooting or something
<buenouanq>that is the label you gave it when you made it
<roptat>you can see the label of a filesystem with e2label for instance
<shiranaihito>buenouanq well, i'm just copy pasting stuff from the docs at this point :)
<shiranaihito>(i.e., i haven't given a name to anything)
<roptat>otherwise, you can use the partition's UUID
<buenouanq>yeah, you don't have to use labels
<buenouanq>prolly best to though
<buenouanq>thus why it's in the tutorial
<iyzsong>The comment "my-root" is for '(file-system (device "my-root") ...)', which mean you will mount the root file system by its label.
<kmicu>Thank you for the great work rekado
<civodul>rekado: great!
<iyzsong>shiranaihito: in vultr, likely you will use '/dev/vda' as the bootloader target, and run 'mkfs.ext4 -L my-root /dev/vda1' to format root file system.
<efraim>time to queue up the next build for when this one finishes: 'niceload -H -L 1.5 sleep 15 && guix build ...'
<shiranaihito>it seems i rebooted back into the installer.. do i need to run "guix system reconfigure" or something?
<shiranaihito>iyzsong /dev/vda is some kind of virtual disk?
<efraim>does the output of 'lsblk' help you decide which disk to install on?
<efraim>I'm pretty sure the 'v' in 'vda' is for virtual
<shiranaihito>cool, i actually see a /dev/vda there, and it's listed as a "disk"
<shiranaihito>lovely, lsblk lists the disk too, and it's the right size
<shiranaihito>i suppose i should start by scraping together a minimal "system configuration" that i could then apply on the server?
<shiranaihito>or is there some kind of installation step first?
<efraim>I think I would look at the bare-bones.tmpl or vm-image.tmpl as a starting point
<shiranaihito>efraim where are those? :)
<shiranaihito>wow.. i ran "loadkeys mac-fi-latin1" and entered the twilight zone
<shiranaihito>jonsger thanks :)
<shiranaihito>now when i press the "g" key, i get an "i"! :p
<shiranaihito>backspace is "e"
<shiranaihito>alright.. time for a reboot
<civodul>rekado: ↑
<shiranaihito>fuuuck.. Vultr's web console doesn't support pasting anything, and somehow there seems to be no way to input a slash
<shiranaihito>quite a few key combinations produce no visible output
<shiranaihito>is there something special about "input stuff" with GuixSD that might affect things here
<shiranaihito>(i have no idea what's involved technically)
<civodul>i don't think there's anything special
<shiranaihito>i guess Vultr's console is messing things up then
<roptat>take a look in /etc/configuration on the installation media
<shiranaihito>iyzsong ok, i ran the mkfs.ext4 command, but with /dev/vda instead of /dev/vda1 .. not sure if that matters
<shiranaihito>so like, what's next? :(
<shiranaihito>;lksjd :)
<shiranaihito>.. basically i'm wondering if i'm supposed to use guix to install GuixSD on the VPS
<shiranaihito>something like "guix system reconfigure <system.scm>"
<roptat>hm... /dev/vda is a full disk, where are you going to install the bootloader?
<shiranaihito>roptat no clue.. hmhm.. now that you mention it, i guess a separate system partition would be nice to have
<civodul>oops, looks like our atom feeds are abbreviated:
<shiranaihito>no clue how to make it happen though
<roptat>I think you need to create a partition table on /dev/vda (I use fdisk but there are other options)
<shiranaihito>roptat ok, let's see..
<roptat>then you could have just one partition on that, but having a partition table leaves space for grub to be installed
<shiranaihito>so i guess iyzsong meant running mkfs.ext4 after partitioning the disk.. :p :x
<shiranaihito>silly me
<shiranaihito>roptat no need to worry about "sector size" or something like that?
<shiranaihito>cylinders, heads, sectors? :p
<roptat>I don't think so
<roptat>defaults should be ok
<nalc>Has anyone got the guix package manager working on macOS?
<buenouanq>i'm disgusted but also intrigued
<rekado>nalc: it hasn’t been ported and it’s unlikely that it will ever run natively on macOS.
<shiranaihito>nalc i'd like to run guix on a mac too, since i only use a mac for my desktop needs
<shiranaihito>but it's not supported for now
<rekado>that’s due to the fact that no port of the GNU C library is available for macOS.
<rekado>and that there’s no free toolchain.
<nalc>Would it be difficult to port to clang?
<shiranaihito>rekado wasn't there some talk about how it would be possible though? :)
<buenouanq>I instead just installed GuixSD on my Mac and called it a day ┐( '~')┌
<nalc>@buenouanq: asking more for my coworkers than for me
<shiranaihito>buenouanq ouch.. :p
<buenouanq>shiranaihito: works better than ever before
<rekado>we could build GuixSD docker images and run those with Docker for mac.
<shiranaihito>buenouanq i'm sure it does, but GuixSD is not a replacement for everything macOS has to offer
<rekado>the only way this seems to be possible is by running a virtual GNU system on top of macOS.
<nalc>Can guix package manager be statically built against musl libc for example?
<rekado>nalc: porting to clang definitely won’t happen.
<nalc>And then shipped as a single binary?
<rekado>it’s not just about Guix as an application, but about how Guix builds software.
<rekado>we build software from source, down to a small set of bootstrap binaries.
<nalc>won't happen = can't happen? as in technically impossible?
<nalc>Sorry for the basic question I tend to develop on higher levels of abstraction than libc :/
<rekado>if you replace all of the bootstrap packages you end up with a completely different system
<nalc>rekado I hear you. I guess I was thinking that maybe doing things similar to gentoo could be possible. Like how you can choose your libc etc using configuration files.
<nalc>Thanks for the information!
<shiranaihito>well, i wish guix will be useable on macos some day
***pksadiq_ is now known as pksadiq
<buenouanq>shiranaihito: freedom is more important than capability, comfort, or convenience
<buenouanq>luckily, with GuixSD, all of those things have been increased in my life
<rekado>nalc: with Guix we have a system that strongly discourages cheating. To pop in a different libc while pretending that it is not different would require some mechanism for cheating.
<shiranaihito>buenouanq yeah, as a general principle i'd agree with that :)
<rekado>I think your best bet for Guix on macOS is virtualisation.
<rekado>that’s not too different from Docker on macOS.
<shiranaihito>buenouanq but if it were technically feasible, i don't see a problem with running guix on macos, even if it's a dirty anti-freedom OS
<nalc>Are there premade Vagrant or docker setups available?
<nalc>That could be a decent solution.
<shiranaihito>buenouanq "supporting" macos would make it a hell of a lot easier for people to adopt guix
<nalc>Also is it possible to "port" or somehow transform nix into guix? Like some kind of conversion function?
<buenouanq>shiranaihito: I'm not at all against the proliferation of free software to nonfree things - I just would rather our limited resources be utilized elsewhere on what I feel might be more important things.
<civodul>nalc: see "guix import nix":
<nalc>civodul: thanks!
<civodul>but really, at this stage, i don't think it's that useful
<civodul>there are 6,500+ packages in Guix
<civodul>and what takes time is all the QA around packages
<civodul>and maintenance, of course
<nalc>I understand this project like so many has limited resources. As an engineer I just really would love a cross-platform package manager with the features of guix :)
<nalc>civodul Understood. I was thinking more about porting the default.nix files for my dev projects, so that I could share a guix config to a coworker on macOS
<shiranaihito>buenouanq well, supporting macos might actually give freedom-oriented tools a wonderful boost in adoption, which would most likely qualify as "important"
<brendyn>Is there any news on this new "gexp" style of package definitions. I remember that there were some outstanding technical issues to overcome? I can't wait until I don't have to write (assoc-ref outputs "outs") over and over.
<shiranaihito>i'm sure plenty of people wouldn't mind trying guix, but they're not motivated to work through troublesome "obstacles" to do it
<rekado>brendyn: it comes with its own difficulties: it would make it harder to reuse some package definitions.
<brendyn>rekado: Are there any other creative ideas for making package definitions less verbose?
<shiranaihito>buenouanq basically it boils down to convenience :) as you said, freedom is more important than convenience, but .. convenience can be important for freedom! :P
<rekado>brendyn: you could already use %output, but this has fallen out of favour.
<shiranaihito>btw, do you all use emacs for editing guix-related Guile stuff?
<brendyn>Most do
<rekado>I do. Emacs + paredit + guix.el
<rekado>and for commit messages magit + yasnippet.
<brendyn>I have smartparens instead of paredit
<buenouanq>shiranaihito: I personally just feel like catering to those who require that is wasted effort - It will never be enough and their hearts aren't in the right place.
<buenouanq>The real argument to make in this I think is that there are people out there right now who would be on board 100% but haven't even heard of free software or what it means.
<brendyn>I guess guix isn't really a universal package manager then. At the end of day it's GNU/Linux distribution
<shiranaihito>buenouanq well, people are generally oblivious to "freedom", so their hearts pretty much *can't* be in a place you'd find acceptable :)
<buenouanq>And having Guix available on more platforms would simply increase their potential exposure.
<shiranaihito>so it's not about hearts and stuff.. it's about whether they see value in trying/using guix, and whether it's convenient enough to get started
<roptat>brendyn: it works on android too :p
<brendyn>roptat: seriously?
<roptat>yes, although I had to disable SELinux and get root to install it as a package manager
<shiranaihito>buenouanq but basically, just about anyone "requires" convenience in this sense.. people just do a quick a cost/benefit estimation, and decide for or against trying to do something with guix
<roptat>I used the binary install for armhf, added a few files for glibc and it worked perfectly fine
<buenouanq>shiranaihito: right - I get a lot of guff for it in these communities but I have trouble caring about such people, and I certainly don't want to waste any time on them.
<brendyn>rekado: What kind ow slowdown would virtualisation on MacOS entail?
<roptat>but it takes a lot of space and it's not reboot-proof
<shiranaihito>buenouanq well, it's just random people we're talking about, and almost all of them will behave like i described here, with regard to guix (or any other "libre" software)
<shiranaihito>so "catering" to them is clearly a beneficial thing, even if it feels distasteful in some way
<rekado>brendyn: I haven’t tried it. It seems that Docker users were fine with the performance.
<buenouanq>depends on the exact situation, but I sort of disagree
<rekado>shiranaihito, buenouanq I don’t think it’s useful to make claims about how “most people” will behave.
<shiranaihito>buenouanq i meant "catering" to them in ways that would drive adoption of libre software.. i.e. supporting macos, in this case :P
<rekado>if someone decides to make Guix work on macOS, their work will be welcome if it does not make Guix work worse on GNU.
<shiranaihito>rekado it's true though, as you've probably observed in your life
<nalc>I'll see about making a guix-sd vagrant setup
<nalc>I've never thought about using a package manager inside a container, seems kinda crazy
<janneke>rekado: you got Rutger's mail?
<sirgazil>Hi guix! thank you very much for working on the new release :)
<sirgazil>I upgraded yesterday and everything went fine (and I didn't use
<shiranaihito>do i need a swap partition for GuixSD btw_
<shiranaihito>are they "obsolete" these days, or something?
<brendyn>dunno really but ive never had any issues with using a swapfile when i need one
<shiranaihito>brendyn ok.. well, i just saw the concept of a swap file, and .. yeah :p i wonder if i need one of those then
<brendyn>how much ram do you have?
<shiranaihito>the VPS has 1GB of ram now
<shiranaihito>hm.. so i guess if it runs out of memory, it's game over right away
<brendyn>i think you will need a fair amount of swap with that
<shiranaihito>does it need to be on the OS partition? i made a partition with 8GB of space, thinking it would be used for GuixSD.. and another 17GB partition for data
<bavier>shiranaihito: 6GB
<jaidmin>when do you generally use root on guixsd?
<bavier>between swap and RAM is usually more than enough
<shiranaihito>bavier ok, cool
<bavier>jaidmin: usually only for system reconfiguration or service maintenance with 'herd'
<shiranaihito>bavier do you think i could fit say, 4GB of swap on the 8GB partition meant for the OS?
<bavier>shiranaihito: it might fit, yeah
<bavier>depends on what packages you're installing
<shiranaihito>.. i.e. how much space does guixsd generally need :)
<jaidmin>okay, so i have a problem, i used it for guix system reconfigure because it didnt work without, and now i need root priveleges for shutdown
<jaidmin>or is that expected?
<bavier>jaidmin: that's expected
<brendyn>guix tends to hog a lot of space
<jaidmin>do you know?
<bavier>jaidmin: i.e. 'sudo shutdown', some of the DEs has setuid shutdown helpers
<shiranaihito>hmm.. the guixsd docs don't mention editing fstab to make the swap file permanent, but this article does:
<bavier>brendyn: I don't think a generalization like that is useful or accurate
<brendyn>bavier: I'm waiting for ncdu to finish telling me how much my /gnu/store takes up
<bavier>shiranaihito: you can point your operating-system configuration at the swapfile, which is what I usually do
<shiranaihito>bavier oh, ok
<brendyn>bavier: how do you do that?
<shiranaihito>bavier so there's no need to do anything else than "define" it in the system config?
<bavier>shiranaihito, brendyn see section 6.2.2, "swap-devices"
<brendyn>my Guix installation takes up over 50GiB of space, but that is also with many backup generations i haven't cleaned out
<shiranaihito>brendyn omg.. :)
<bavier>I ran guixsd on a small netbook for quite some with a 10GiB root partition with no issues
<brendyn>and there are over 10 million files in /gnu/store
<bavier>I kept just a few generation for backup, and that was even with doing debug builds for new packages
<civodul>efraim: any idea why we don't have qt@5 substitutes right now?
<civodul>my colleague ends up rebuilding qt by hand...
<bavier>latest eigen version takes much longer to build, maybe 40% longer
<bavier>added a lot of tests maybe
<civodul>yeah tests are a real pain in Eigen
<civodul>last time i tried upgrading there were a couple of test failures
<christopher74837>str1ngs: debian
<bavier>finished building, now they're running
<civodul>i told the developer (who was then in the office next door) but i think he dropped the ball
<civodul>and so did i :-)
<bavier>civodul: :P
<bavier>I'm hoping the latest version fixes some failures I see on aarch64
<civodul>not sure it's being tested on aarch64...
<bavier>some tensorflow people are putting it through the paces on arm
<bavier>I think I saw thunderx mentioned in some bug reports
<bavier>well, it's being tested now!
<civodul>heheh :-)
<civodul>bavier: BTW did you see ?
<civodul>ACTION is into web
<bavier>civodul: no, cool
<civodul>mb[m]1: "one last" core-updates patch: :-)
<bavier>darn, still 2 test failures in 3.3.4...
<bavier>45 minutes in the check phase
<christopher74837>hi all, I am trying to build guix-0.14 from source on Debian Stretch. Configure failes with:
<christopher74837>configure:8080: checking whether /lib/x86_64-linux-gnu/libgcrypt can be dynamically loaded
<christopher74837>configure:8095: result: no
<christopher74837>configure:8099: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'.
<christopher74837>but it clearly exists here:
<christopher74837>$ file /lib/x86_64-linux-gnu/
<bavier>christopher74837: what does config.log say?
<christopher74837>> /lib/x86_64-linux-gnu/ ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=c59a6e026fe4978b2b99cfd643839b9ccd1c8a21, stripped
<christopher74837>config log says...
<christopher74837>configure:8080: checking whether /lib/x86_64-linux-gnu/libgcrypt can be dynamically loaded
<christopher74837>configure:8095: result: no
<christopher74837>configure:8099: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'.
<bavier>hmm, that's not so helpful
<bavier>christopher74837: is there a /lib/x86_64-linux-gnu/ file?
<bavier>I think guile only looks for ".so"
<christopher74837>no, there is a
<christopher74837>i'll try creating a symlink
<christopher74837>ok, that seemed to work
<mb[m]1>civodul: LGTM! Can you start the eval as well?
<christopher74837>bavier: i'd buy you a pizza if I wasn't so broke
<mb[m]1>That guix-hpc site is really nice btw.
<bavier>christopher74837: heh, np
<christopher74837>it's compiling! WHA HA HA
<bavier>ooo, one of the eigen test failures has been fixed since release:
<civodul>mb[m]1: sure! did both
<civodul>bavier: the commit log is kinda terse
<bavier>civodul: yeah, just "not supported"
<bavier>the other failure isn't as straightfoward, only fails sometimes
<bavier>but I can at least reproduce with the right seed
<bavier>civodul: is setting a rng seed in guix packages kosher?
<civodul>well, it certainly improves reproducibility
<civodul>it's the seed used by the tests, right?
<bavier>yeah, eigen's tests can pull a seed from an 'EIGEN_SEED' env var
<bavier>it might be useful to set that to alleviate spurious build failures
<civodul>yes, indeed
<civodul>ACTION has to leave
<civodul>happy debugging!
<christopher74837>so, I just installed guix. How do I search for a package name to install?
<christopher74837>i just wanted to install something to see if it works, but I'm not sure what
<bavier>christopher74837: 'guix package -A foo' will search package names for "foo"
<bavier>christopher74837: 'guix package -i hello' is a good one
<christopher74837>ok, thx, looks like I need to start a daemon first
<christopher74837>erm, how do I do that?
<bavier>christopher74837: yes, follow all the instructions in the manual
<bavier>christopher74837: there's a section on 'guix-daemon setup'
<christopher74837>what? there's a manual?
<christopher74837>whadda know
<bavier>I hear it's good even ;)
<bavier>christopher74837: 'Setting Up the Daemon'
<bavier>my bad
<christopher74837>it's ALIVE
<christopher74837>why does the hello program need gcc installed?
<christopher74837>or the linux-libre kernel? and perl?
<bavier>christopher74837: did you enable and authorize substitutes?
<bavier>if not, your daemon will build the hello package
<bavier>in which case it'll need a gcc
<lfam>FYI, it's most likely downloading the kernel headers, but the kernel
<lfam>I mean, *not* the kernel
<christopher74837>so, erm, I just pas substitute-ruls=...?
<lfam>christopher74837: Check step 7 of the binary installation instructions:
<lfam>It applies here too
<bavier>lfam: christopher74837 is building from source
<christopher74837>already built from source
<lfam>I understand, but that is the most concise introduction to "how to authorize substitutes"
<christopher74837>installed on Debian stretch
<bavier>lfam: I suppose
<lfam>The signing keys are found in the root of the source tree
<lfam>This is full documentation of substitute authorization:
<bavier>it'd be nice if it were at least mentioned in 'setting up the daemon', imo
<lfam>Yes, I don't think it's mentioned in the instructions about building from source
<christopher74837>authorization mentioned here:
<christopher74837>it seems to have worked
<christopher74837>hmm, still installing gcc thoug
<christopher74837>ok, I passed --substitute-urls etc., that seemed to do it
<christopher74837>hello world!
<christopher74837>well, cool, not too exciting though, what else should I install...
<christopher74837>how about another scheme interpreter, don't have enough of those for sure
<christopher74837>this is pretty cool
<christopher74837>keep up the great work!
<christopher74837>now, just to get this installed at home
<bavier>christopher74837: glad its working, let us know how it goes as you continue using guix
<roptat>I think there's something wrong with the installation image...
<roptat>ping -> 100% packet loss
<bavier>roptat: in a vm?
<roptat>no in a desktop computer
<roptat>somehow lo was down
<roptat>setting it up makes the network work again
<roptat>so the symptoms were: wpa_supplicant connects to my AP, dhclient gets an ip address and I can connect to the internet, but after about 15 seconds it just stopped doing anything
<roptat>after some time it told me something like "the TLS session was non properly terminated" and I had to kill wpa_supplicant and try to connect again
<roptat>but one package was too big to be downloaded in 15 seconds, so I just used a cable to connect to another computer
<roptat>I wonder if that's all related to lo being down somehow?
<roptat>anyway, now my new system boots \\o/
<bavier>roptat: \\o/
<christopher74837>so, if I do guix pull, does that pull from some kind of 0.14 stable branch, or does that get me bleeding edge development packages?
<vagrantc>ACTION gets the sense it's somewhere inbetween
<bavier>christopher74837: bleeding-edge
<roptat>is berlin's public key authorized by default in 0.14.0?
<christopher74837>sounds dangerous
<bavier>roptat: yes
<mb[m]1>christopher74837: You can always roll back if something breaks.. :)
<christopher74837>is there like a "git log" command that shows me where I am in the guix repo?
<vagrantc>i think ~/.config/guix/pull is the actual git repository ... and i think "guix --version" shows the commit hash
<christopher74837>hi, am running guix on a Debian Stretch system. For fun, I tried installing icecat. I receive error:
<christopher74837>XPCOMGlueLoad error for file /gnu/store/kd0nnq3i0qarx4vqxcampxfj3igxn84h-icecat-52.3.0-gnu1/lib/icecat-52.3.0/
<christopher74837> cannot open shared object file: No such file or directory
<christopher74837>Couldn't load XPCOM.
<christopher74837>do I need to be sourcing some environment file or something...?
<christopher74837>maybe just need to install it through apt-get?
<christopher74837>I'll try that
<christopher74837>hmm, it is already install on debian...