<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>ack, stumped after solving 8 other compiling problems across a half-dozen packages! <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>also is there something that helps with managing guix environment variables. my .bashrc is getting out of control <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>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 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 <shiranaihito>ok.. i'm trying to actually start using GuixSD, so it's time for a barrage of noob questions :p <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 :) <roptat>otherwise, you can use the partition's UUID <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 <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? <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? <efraim>I think I would look at the bare-bones.tmpl or vm-image.tmpl as a starting point <shiranaihito>wow.. i ran "loadkeys mac-fi-latin1" and entered the twilight zone <shiranaihito>fuuuck.. Vultr's web console doesn't support pasting anything, and somehow there seems to be no way to input a slash <shiranaihito>is there something special about "input stuff" with GuixSD that might affect things here <civodul>i don't think there's anything special <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>.. basically i'm wondering if i'm supposed to use guix to install GuixSD on the VPS <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 <roptat>I think you need to create a partition table on /dev/vda (I use fdisk but there are other options) <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>roptat no need to worry about "sector size" or something like that? <nalc>Has anyone got the guix package manager working on macOS? <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 <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 <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! ***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>but really, at this stage, i don't think it's that useful <civodul>and what takes time is all the QA around packages <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? <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 <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 <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 berlin.guixsd.org). <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 <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 <jaidmin>when do you generally use root on guixsd? <bavier>between swap and RAM is usually more than enough <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 <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 <bavier>jaidmin: i.e. 'sudo shutdown', some of the DEs has setuid shutdown helpers <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 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 <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 <civodul>last time i tried upgrading there were a couple of test failures <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 <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>darn, still 2 test failures in 3.3.4... <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:8099: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'. <bavier>christopher74837: what does config.log say? <christopher74837>> /lib/x86_64-linux-gnu/libgcrypt.so.20.1.6: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=c59a6e026fe4978b2b99cfd643839b9ccd1c8a21, stripped <christopher74837>configure:8080: checking whether /lib/x86_64-linux-gnu/libgcrypt can be dynamically loaded <christopher74837>configure:8099: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'. <bavier>christopher74837: is there a /lib/x86_64-linux-gnu/libgcrypt.so file? <bavier>I think guile only looks for ".so" <mb[m]1>civodul: LGTM! Can you start the eval as well? <mb[m]1>That guix-hpc site is really nice btw. <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 <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 <bavier>christopher74837: yes, follow all the instructions in the manual <bavier>christopher74837: there's a section on 'guix-daemon setup' <bavier>christopher74837: 'Setting Up the Daemon' <bavier>christopher74837: did you enable and authorize substitutes? <bavier>if not, your daemon will build the hello package <lfam>FYI, it's most likely downloading the kernel headers, but the kernel <lfam>I mean, *not* the kernel <bavier>lfam: christopher74837 is building from source <lfam>I understand, but that is the most concise introduction to "how to authorize substitutes" <lfam>The signing keys are found in the root of the source tree <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>how about another scheme interpreter, don't have enough of those for sure <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 127.0.0.1 -> 100% packet loss <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/ <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 <roptat>is berlin's public key authorized by default in 0.14.0? <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/libxul.so: <christopher74837>libp11-kit.so.0: cannot open shared object file: No such file or directory