<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 <buenouanq>Will a 2GB microSD card be enough for the BeagleBone image? <apteryx_>Now I'm getting this: ./nix/libutil/gcrypt-hash.hh:23:20: fatal error: gcrypt.h: No such file or directory <marusich>Has anyone seen a problem like this when running "guix system reconfigure"? <marusich>I'm using the same OS configuration I used previously. Last time I ran "guix system reconfigure" using this config file, the invocation succeeded. <marusich>Since then, I have run "guix pull", and now I get this cryptic error. <apteryx_>nevermind, looks like my 'guix environment guix' was not OK. <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)? <buenouanq>no, everything on this is very old, has been untouched for a long time <marusich>how does the unit file compare to the one that the manual recommends currently? <buenouanq>should be the same, I just downloaded it minutes ago <marusich>Maybe if you share the contents of /etc/systemd/system/guix-daemon.service, somebody else can help. I don't have systemd running on my system, so I can't play around much at the moment. <buenouanq>can anyone who's maybe done this give me an estimate on how long it will take to build the armhf install image on a beaglebone black? <marusich>Is there an email thread or document that describes some of the problems that prevent us from cross-compiling a whole system image? <amz3>ACTION working on gnunet bindings <buenouanq>so after hours, guix pull failed with no meaningful error <buenouanq>This seems to be a big problem - Is there any hope at all for GuixSD on small/embeded things? <buenouanq>this should be mentioned on the BBB blog post <buenouanq>but I'm talking about putting GuixSD on routers and stuff that doesn't have enough internal memory nor SD/USB/etc slots <buenouanq>I will not be satisfied until I have GuixSD running on my microwave oven ( '-') <clacke[m]>buenouanq: I have 1 GB RAM on my VPS and thats not enough to do guix pull -- it eats 1 GB of swap before it dies <buenouanq>I recall the number being between 2 and 3GB. <buenouanq>And this had something to do with Guile itself. <amz3>buenouanq: check 'dmesg' to see if there is more info <buenouanq>worry now is, once I make the image, will I be able to install it without the swap? or do I need to include a swap on the install SDcard? <buenouanq>amz3: Out of memory: Kill process 1309 (guile) score 712 or sacrifice child <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. <buenouanq>the pull I'm doing now will build an up to date install image so I won't bother with that step during the actual install <buenouanq>in the meantime, where can I find beaglebone-black.scm ? link in the blog post is dead <rekado_>buenouanq: the memory consumption is considered a problem, but it’s hard to fix. It’s being worked on by Guile developers. <brendyn>Guix package modules are pretty abitrary. Gimp and inkscape have their own modules and there is no general image-editor module <rekado_>brendyn: that’s because it *is* arbitrary. <rekado_>for newer packages the module name is often more generic. <rekado_>what annoys me is that alsa-lib is in linux.scm and that pulseaudio has its own module. <brendyn>change is easy, but figuring out what is best is hard. <rekado_>but that’s because it predates the audio module. <brendyn>I wish we could simply not use guile modules at all somehow <brendyn>every other distro pretty much has a file per package <clacke[m]>if you're on a really weak machine, would it be a really bad idea to just not compile the packages and just interpret the things <clacke[m]>or is there no convenient interpreted mode in guile and that would just mean it would compile the whole thing every time? <clacke[m]>even if interpreting would be slower in CPU time, if it meant not eating 3 GB memory it would be valuable <shiranaihito>how do i add things to a user accounts "PATH" env variable? <shiranaihito>so what would i use to make sure something is running, when that something is not in any kind of system config <shiranaihito>normally i'd use "monit", but that doesn't seem to be available <amz3>shiranaihito: you have to package your app I guess <amz3>and create a service for it <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: <ng0>configure: checking for guile 2.2 <ng0>configure: checking for guile 2.0 <ng0>No Guile development packages were found. <ng0>on commit 3853f86fdf3982daeec67ea786045ef51c76f42e <lfam>ng0: What's the output of `guile --version`? <lfam>With a `guix --version` of 48a716c484c45594de86aa91c2ba5e80eb931a63, I can do build a fresh clone with `guix environment --pure guix` <lfam>I mean, "I can build a fresh clone..." <lfam>Did you `guile --version` in the environment set up by `guix environment`? <ng0>can#t really work on Guile atm or anything else, but I can try to help. <lfam>I can't reproduce the problem <ng0>I did a guix gc recently without updating packages since then fwiw <ng0>so maybe some problem there <ng0>thouch I'd expected env to work.. <lfam>`guix environment --pure guix` will give you Guile if you previously gc'd it <ng0>and I got that.. which is why this is weird <lfam>env is in coreutils. You can add it with --ad-hoc <lfam>guix environment --pure guix --ad-hoc coreutils <ng0>sorry, env meant guix environment <ng0>env works, or otherwise I would not be able to run scripts <lfam>Maybe there is something in ~/.bashrc that is messing up the environment? <apteryx_>I hadn't realized emacs-guix depended on its own guix version. <ng0>I had a messed up .bashrc before and cleaned it up.. and worked in the guix_dev.sh enter (the line I pasted before) since then without issues <lfam>If you can share the result of `env` that would make it easier to debug <ng0>hm.. lowest case: have I tried to turn it off and on again? no. I'll be back <ng0>but env itself works <lfam>Yes, from within the guix environment. <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>It works for me on Debian <ng0>I have other computers which pull from this, I was just hoping to build a system-image before I swap disks and install the new system. maybe it's just local and not the repo. <ng0>fwiw, outside of the env the same happens <ng0>apparently the last time I've run make and pushed to remote was c0c5feda4c38d6ba2189ec84b063dbfe0154794c <ng0>so not that long ago <ng0>I suspect 142182514b84ee233bc27e574df2ca2074291525 to cause some issues. <ng0>but I can just look into it on monday <lfam>apteryx_: I guess I don't know! I just know that all the man pages work for me <apteryx_>that's a uesful data point. thanks! I'll see if it works in a --pure environment. <apteryx_>if I can find the package which provides lesspipe I should be able to test that ;) <apteryx_>Oh, it works from the --pure environment. I guess it was loading some libraries from the Ubuntu 16.04 <shiranaihito>amz3 "you have to package your app I guess" <-- well, maybe some day i will, but that's not something i should be doing now <ng0>ACTION away for a while <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." <lfam>And Arch makes /run as tmpfs and then symlinks it around to /var/run and /var/lock <lfam>On Debian it's mounted rw,nosuid,noexec,relatime <lfam>While /run/lock is rw,nosuid,nodev,noexec,relatime <lfam>And then I also get /run/user/$UID <nckx>AFAIR systemd assumes /run is tmpfs, so most ‘mainstream’ ‘modern’ distributions using it have taken the hint. <efraim>I wonder how that would work on GuixSD where we have /run/current-system/profile/bin <nckx>Which is a roundabout way of answering: yes, and some software will eventually assume it is and not work otherwise. <lfam>I wonder how much software will actually check the type of the storage? <mb[m]1>ng0: Sounds like your previous Guile was GC'd. Did you try to run "./configure" again? <ng0>oh, configure.. didn't think of that one :D <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>Heh, I saw one of those recently ;) <ng0>that one was too obvious for me <efraim>Has anyone used krita recently? I'm trying to package kdenlive and kio cant figure out how to open any URIs <mb[m]1>lfam: impressive work on core-updates. Will try to chime in later and tomorrow :) <lfam>mb[m]1: Okay, I think the patches are fine but I wanted a review of the ones I sent in. Still struggling with the Pandas test suite <lfam>efraim: I used krita recently but I didn't do anything with a URI <shiranaihito>so what can i use to make sure a Java app stays running, without having to package "monit" myself? surely there's *some* package for that purpose already? <nckx>Is ‘error in finalization thread: Success’ and several ‘error in finalization thread: Bad file descriptor’ console messages while booting GuixSD a known thing? <nckx>It seems like the kind of thing Guile likes to spit out sometimes. Or it's really an error. <lfam>nckx: Yes, I remember seeing them mentioned on one of the mailing lists recently <nckx>Ah, OK. Then I'll say no more. Thanks! <buenouanq>it's just a cry for attention, you have to talk to your guile often so it doesn't get lonely <mb[m]1>shiranaihito: Shepherd can restart a service if it fails. <shiranaihito>mb[m]1 yeah but there's no service for a SaaS app i built :) <ng0>you can write services yourself. <ng0>it's not like you are limited to what's in master <mb[m]1>shiranaihito: You can declare it in your config.scm without having to share with the world. <shiranaihito>mb[m]1 oh ok.. so i guess "writing a service" for Shepherd would involve setting up some kind of startup and shutdown scripts for my app, and then it should be alright? <nckx>lfam: Thanks! It's all somewhat over my head, but I'll take civodul's patch in that second thread as ‘it's just a harmless warning that will go away eventually’. <lfam>shiranaihito: We have a few service supervisors packaged. On GuixSD the most complete solution will be to write a shepherd service <lfam>I see we have s6 and pies. I'm surprised we don't have runit <shiranaihito>lfam and it can be done roughly as i described? i'd write startup and shutdown scripts for my app, and Shepherd would use them to manage it? <mb[m]1>lfam: I think I actually have runit somewhere, will send it in if I can find it! <lfam>That's the idea, yes. Shepherd can be used outside of GuixSD, too. <lfam>They are service supervision tools <lfam>I think they are what you're looking for, right? You have a service you want to run with some level of supervision, right? <nckx>buenouanq: Heh. I realised a while ago that I'm finally getting comfortable enough with Guile to just smile and ignore some errors instead of freaking out. A good sign. <shiranaihito>oh, so.. theoretically i could use one of those then? :p -any recommendation? <nckx>Living with Guile: it's like living with a cat. <lfam>I haven't tried them. I use either systemd or shepherd, depending on the host OS <shiranaihito>(but yeah seriously too.. i bet systemd is some kind of "hostile takeover" of the linux ecosystem) <lfam>If you are worried about a takeover of the linux ecosystem... don't look too closely at this thing called GuixSD ;) <nckx>‘Linux’ ‘ecosystem’... I'm pretty sure if you add ‘open-source’ Stallman will appear in your dreams. <nckx>Which, you know, if that's your thing, no judgement. <efraim>Whoops, was testing code for lumina and shutdown the computer by accident <efraim>I think I can mark that as working <shiranaihito>nckx not sure what you mean.. systemd is in linux distros specifically, not in all open-source? <nckx>shiranaihito: Oh, sure. Not correcting your statement, just amusing, as always, mainly myself. <nckx>Seeing the words ‘Linux ecosystem’ in this channel just made me realise how long ago it's been since I last saw them used, and what that says about me. <nckx>I guess I'm a GNU hippie now. That is all. <shiranaihito>btw, will something bad happen if i just build "monit" on my GuixSD? :) <buenouanq>you lose all the benefits of guix and I sort of doubt it will work because of the nonstandard file hierarchy <shiranaihito>buenouanq hmhm.. well that sounds undesirable :) but how does the losing of benefits happen? <shiranaihito>i mean, can't something just stay under /usr/local/bin or something like usual, with Guix doing its thing on other stuff? <buenouanq>yeah, but that subverts the whole point in functional package management, or package management in general even <shiranaihito>obviously i'd "lose" (=miss out on) Guix's benefits with regard to monit, but .. what about other stuff? <buenouanq>just as guix can work on other distros it shouldn't hurt anything, no <shiranaihito>buenouanq but in this case, the point of building monit separately would be to get to use it and move on with my life <shiranaihito>that benefit might outweigh the drawback of not having it managed by guix <buenouanq>but you could instead take the time to learn how to package things, not lose the benefits, and maybe even help others in the future with your work <shiranaihito>but alright, basically i wanted to know if building something separately would mess up Guix somehow, but .. it seems it won't? <vagrantc>shiranaihito: you're going to have to manually resolve all the library dependencies and includes and so on <vagrantc>shiranaihito: which is probably more difficult than using a tool, such as guix, to do that for you <vagrantc>unless you're also installing all the library dependencies... <shiranaihito>vagrantc oh, hm.. right.. so even if i want to build monit from source, it might depend on something that's not available under GuixSD and then i'm screwed? :) <vagrantc>shiranaihito: even if it is available in guix, you'd probably have to pass all the /gnu/store/* relevent to building the package <shiranaihito>ah, right.. yeah, i'll see if i can manage with something else <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 <lfam>Then you probably won't need as much space since you won't be using a graphical desktop <taylan>lfam: might it really grow that much, if I make sure to GC before/after major updates? <lfam>I can't really judge it since I don't use a desktop on my GuixSD and I do lots of Guix development. But it seems to be much less space-efficient than Debian <shiranaihito>ohh right, should i run "guix gc" after every package managing operation? <lfam>Just when you need to free up some space <nckx> shiranaihito: the VPS I'm connecting from (which also runs nginx, knot, smtpd, dovecot, tor, and other things that I'm stupid for running on a single machine) has a /gnu/store of 5.0 GiB. <nckx>That's with diligent GC'ing and a pretty custom configuration, but it gives a general idea. <manumanumanu>I am trying to link libsodium using guile, but it isn't looking in my .guix_profile/lib directory. <nckx>Maybe the GC'ing isn't that diligent, but I'm not going to wipe my cache to find out. <lfam>manumanumanu: Can you explain the context some more? <manumanumanu>lfam: sorry, I have libsodium in my .guix-profile/lib, but that libsodium doesn't show up either in ldconfig or when I try to load it using guile that I installed using guix <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...