IRC channel logs


back to list of logs

<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
<str1ngs>err --cflags *
<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
<apteryx_>When attempting to build guix
<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.
<buenouanq>post the config
<apteryx_>nevermind, looks like my 'guix environment guix' was not OK.
<marusich>It's here:
<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
<buenouanq>any ideas?
<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)?
<marusich>did you recently update systemd?
<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
<buenouanq> step 5 here is the issue
<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?
<buenouanq>we talking days or weeks here?
<buenouanq>I'll wrap it in a time and find out.
<marusich>Is there an email thread or document that describes some of the problems that prevent us from cross-compiling a whole system image?
<marusich>This limitation was mentioned here, but I couldn't find details:
<amz3>ACTION working on gnunet bindings
<buenouanq>so after hours, guix pull failed with no meaningful error
<buenouanq>is this the not enough ram thing?
<buenouanq>failed due to signal 9 (Killed)
<buenouanq>how much memory is required now?
<buenouanq>This seems to be a big problem - Is there any hope at all for GuixSD on small/embeded things?
<brendyn>benny: You need a swapfile I think.
<buenouanq>yes, I've made one and have started over
<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
<buenouanq>so yes, it was certainly that
<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>cool, what I want to do should be fine then
<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.
<brendyn>Yeah well it annoys me ;<
<rekado_>this can easily be changed.
<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
<rekado_>brendyn: what would you do instead?
<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>by way of a system config, that is
<shiranaihito>(or otherwise? :p)
<shiranaihito>so what would i use to make sure something is running, when that something is not in any kind of system config
<shiranaihito>- my Java -based SaaS app, that is
<shiranaihito>normally i'd use "monit", but that doesn't seem to be available
<shiranaihito>how would i "logrotate" the "stdout" of a Java app?
<shiranaihito>(directed into a file)
<shiranaihito>no comments?
<amz3>shiranaihito: you have to package your app I guess
<amz3>and create a service for it
<amz3>or package monit
<ng0>I think the last patch ludovic commited on 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>configure: error:
<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 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>of env?
<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
<apteryx_>Using Debian's man-db or Guix's own?
<ng0>disconneced. lfam:
<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
<efraim>can /run be mounted as tmpfs?
<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."
<efraim>looks like debian does it also
<lfam>And Arch makes /run as tmpfs and then symlinks it around to /var/run and /var/lock
<efraim>i saw that too
<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>mb[m]1: thanks
<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
<happy_gnu[m]>My printer is an Epson L300
<happy_gnu[m]>Printer: Epson L300 Series | OpenPrinting - The Linux Foundation -
<happy_gnu[m]>It only has .deb or .rpm
<happy_gnu[m]>Can I use this to install it on guix?
<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!
<lfam>I originally reported it in the summer but I'm sure it was mentioned recently:
<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>how do i have something restart a "custom" Java application if it crashes? i believe this is often recommended and works well, but it seems there's no package for it yet:
<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>Ah, cool mb[m]1!
<shiranaihito>what are s6 and pies?
<lfam>They are service supervision tools
<shiranaihito>(not what i'm looking for?)
<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.
<shiranaihito>nckx :P
<lfam>I haven't tried them. I use either systemd or shepherd, depending on the host OS
<shiranaihito>but systemd is cancer :p
<shiranaihito>(but yeah seriously too.. i bet systemd is some kind of "hostile takeover" of the linux ecosystem)
<lfam>I don't mind it so much
<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.
<mbakke>ACTION grabs popcorn
<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.
<buenouanq>GuixSD Hurd when?
<shiranaihito>btw, will something bad happen if i just build "monit" on my GuixSD? :)
<shiranaihito>make && make install, etc
<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?
<buenouanq>because you're not using it
<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?
<buenouanq>idk, i'm no expert
<buenouanq>i do not believe so though, no
<buenouanq>should be fine
<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
<shiranaihito>i'm reading this: .. but i don't understand any of the terminology, etc
<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
<shiranaihito>lfam what about on a VPS server with limited space?
<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.
<manumanumanu>I have probably set it up wrong
<shiranaihito>nckx oh ok, good to know
<nckx>Maybe the GC'ing isn't that diligent, but I'm not going to wipe my cache to find out.
<shiranaihito>nckx i don't know what that means, but "ok" :P
<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>I suspect I effed up somewhere
<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>Hello guix!
<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...
<Apteryx>This procedures returns your xorg configuration, which must be fed to your login manager service. Here's an example for slim (the default one):