<str1ngs>if I git clone guix. then do guix environment guix, then ./bootstrap . ./configure fails with No Guile development packages were found. I've manually tested with pkg-config --clflags guile-2.2 and that works fine
<marusich>Like I said, this config file has not changed; it used to work just fine.
<marusich>I suspect that running "guix pull" has introduced some kind of non-backwards-compatible change that I don't know about. Seems like maybe it has something to do with UUIDs?
<marusich>I see that Ludo made some changes related to UUIDs recently; I wonder if it's related.
<marusich>Is there any way to get more information from Guile or Guix about the error? The message is unfortunately not very helpful.
***luto__ is now known as luto
<marusich>Oh, apparently you need to explicitly request a backtrace from Guix now using --on-error=backtrace
<marusich>That is why I didn't get one. That was...surprising to me.
<marusich>Kind of neat that you can enter a debugger with --on-error=debug, though!
***kensington_ is now known as kensington
<marusich>OK. The problem was that I did not include a "dependencies" field in my "file-systems" declaration.
<marusich>Apparently, if you try to use my config as written, it fails now even though it worked before. Now, you must add a "dependencies" field to the "file-systems" declaration like: (dependencies mapped-devices)
<marusich>I discovered this by manually comparing my config file with the provided example files in the Guix source tree, specifically ./gnu/system/examples/desktop.tmpl. The stack trace and debugger did not help me in this case (or I didn't know how to use them well enough to get the help I needed).
<marusich>After I added the "dependencies" field, "guix system reconfigure" worked without error. However, even if I remove the "dependencies" field, it now still works.
<marusich>I'm very confused, but happy that I was able to run "guix system reconfigure".
<buenouanq>failed to issue method call: Unit name guix-daemon is not valid.
<buenouanq>running it manually so I can build my beaglebone image so it's not a big deal, but I don't like when things don't work
<marusich>buenouanq, did you recently modify the file so that it became invalid? is the unit file a file, or a symlink (I recall systemd doesn't like too many levels of symlinks or something, sometimes)?
<amz3>buenouanq: well you will always need memory/swap to do further updates
<buenouanq>plan is to burn the BBB install image I'm attempting to make to a 2GB microSD card, boot to the card, install GuixSD on the BBB"s onboard eMMC, and put in a larger SD card with a swap partition after
<buenouanq>question is, can I do the install to the eMMC with just the half GB of onboard RAM?
<buenouanq>or do I need to use a larger card for install and have a swap partition on it
<buenouanq>I suppose I could also use a USB flashdrive for the swap if the first approach doesn't end up working.
<clacke[m]>As long as you don't compile guix (run guix pull), it doesn't require a while lot of memory.
<ng0>I think the last patch ludovic commited on configure.ac needs some adjustment. I can no longer execute any make related action in an guix environment --fallback --no-build-hook --pure guix environment, which used to work before. at least make and make clean recursive encounter:
<lfam>It sounds like the environment is not being set up correctly
<lfam>apteryx_: It used to be part of the Guix codebase but is now separate
<apteryx_>I knew that, but I hadn't realized it now had to bundle its own guix.
<apteryx_>I guess that's a good way to make sure it'll always work even guix in the user/system profile has evolved
<apteryx_>Changing of topic, I can't seem to make the guix manpage-database (index.db) on a foreign distro (Ubuntu 16.04). It works well on GuixSD and is now very fast thanks to Ludovic's patch moving the database generation from man-db to a custom Guile solution. I'm not sure if it used to work at all.
<apteryx_>(if it used to work before the man-db --> guile switch on a foreign distro).
<apteryx_>The interesting thing is looking at strace output I see it's writing the correct output with write calls, but on the terminal nothing appears. Hmm.
<lfam>efraim: I think so. I googled it and the first result says "... in Red Hat Enterprise Linux 7, the /run directory is a temporary file storage system ( tmpfs ) that bind mounts the /var/run directory."
<nckx>lfam: Not check; just assume. ‘Oh, your /run isn't volatile? Well you're not Standard™ Linux® lol so us leaking creds is NOTABUG!’ (Yes, I'm in a grumpy pessimistic mood tonight and will end my tangent here, but that's very close to things I've already seen happen. :-)
<lfam>Building this "by hand" on GuixSD should work if you are using the tools from the gcc-toolchain package
<taylan>hey peeps, what minimum disk size would you recommend for a basic desktop GuixSD installation, OS-only? (my home directory will be on another partition.) the size of /gnu on my on-Debian Guix installation seems to be about 8G after I install it freshly and add all the packages I normally use. I was thinking maybe 20G to be sure, since the store may grow a lot when core packages are updated.
<lfam>taylan: I suggest a few tens of gigabytes. Basically as much as you can afford
<manumanumanu>because guile is looking for libsodium in some other guix folders
<nckx>shiranaihito: Sorry. Longer: I thought I had a script set up to ‘guix gc’ after almost every guix operation, but it might not be on this machine after all. So I'm not sure how much of the 5 GiB is actually garbage, and I'm not going to ‘guix gc’ while I still have to rebuild some packages. But 5 GiB a reasonable maximum size IMO.
<manumanumanu>lfam: but of course, setting it with LD_LIBRARY_PATH works
<lfam>manumanumanu: I have to go now so I can't keep helping, but you may need to use the toolchain from the gcc-toolchain package
<emsyr>I need to find a configuration guide for xorg-server. I'm having hard time to set up the graphical display and it seems that the generic guides for other distros are not suitable for guixsd.
<Apteryx>emsyr: what is particular about your setup that it requires a specific configuration? I've not had to configure Xorg in a very long time.
<emsyr>Apteryx: Two main problems: 1. Xorg loads fbdev driver instead of vesa for the graphic card, 2. It does not load synaptics.
<emsyr>I don't know whether I need to add parameters inside config.scm or in configuration files. Another problem is that (if I have understood correctly looking at Xorg.0.log file) xorg configuration file for guixsd are inside /gnu/store and the attributes there are only read-execute not write. So I cannot make modifications there.
<Apteryx>Let's try fixing 1. for a start. It seems there's a xorg-configuration-file procedure (from the (gnu services xorg) module) that can take a #:drivers argument. Per the manual (check the section titled 'X Window'), that args default to the empty list, but you may pass it a list of drivers to try in order. You could try: #:drivers '("vesa").
<emsyr>Apteryx: Thank a lot for for the hint! I'll try it and I'll come back later...