***jonsger1 is now known as jonsger
<apteryx>can't I do: 'guix copy --to=myhost guix' to duplicate my current guix version to another machine? <apteryx>luciddreamzzz: there are substitutes for icecat, yes, if I understood your question correctly. <luciddreamzzz>ok yeah i realized that the "mirror" url's are not the best to use <luciddreamzzz>its over SSH and that would copy the package 'guix' to _host_ <apteryx>luciddreamzzz: thanks, but I think that \ is just for aesthetic (show the command on two lines instead of one ;) <apteryx>my host is configured through ~/.ssh/config and SSH works. It's just that for the 'guix' package <apteryx>I guess 'guix' is special. But it seems to support profiles; so I'll try using guix copy --to=myhost ~/.config/guix/current <luciddreamzzz>it mentions store items -- I wonder if you can do /gnu/store/* <apteryx>works with: guix copy --to=x220 `readlink -f ~/.config/guix/current` <apteryx>takes 2 seconds instead of 15 minutes of compilation <apteryx>hmm, it doesn't *install* guix, just copies it to the store of that host <apteryx>I'm not sure how to upgrade directly my profile copy to it. <apteryx>I haven't tried the .guix-profile, because guix is no longer installed to .guix-profile but to .config/guix/ <apteryx>(to be accurate I think it never was installed to .guix-profile -- it was just 'special') <g_bor>I have experienced a strange failure yesterday on one of my guixsd systems. <g_bor>I have seen that we have a bunch of daemon-log files, but those don't seem to be in human readable. Can I inspect those somehow? <g_bor>I've seen snape's mail that berlin went down a bit after midnight. <kmicu>Hi cbaines: did you contribute back your tweak for the stripping of the mount point prefix? <snape>g_bor: part of the problem is that only rekado and Ludo have access to the server, and they both seem away <snape>although, well, rekado pushed a few R updates recently <kmicu>Guix infra bus factor is 2. Still better than 1. đș <roptat>how much power does one need to run a build farm? <snape>roptat: I'd say 128g RAM, 32 cores, 4T hard drive <snape>I don't have much disk space because I only build the 230 packages I u se <snape>if I try to build all Guix packages, I run out of disk space within a few hours <g_bor>and I guess it is another matter, if you want it to provide substitutes fast :) <snape>well, it depends on your network, your nginx settings, etc <roptat>I guess it's better if you run cuirass on guix, right? <g_bor>snape: is berlin completely down, or ist it configured to not respond to ping? <snape>roptat: I think it could run on a foreign distro, but I never tried <snape>g_bor: I think it went down, the Shepherd tried to restart it but it couldn't, so it's now disabled <snape>g_bor: it doesn't respond to ping, indeed <g_bor>also, when it was down, I got an error: invalid url when provided as substitute-urls. I feel this error message is misleading. <snape>g_bor, note that Cuirass being down doesn't mean that Guix publish was down <snape>I paid like 1200 euros for the whole thing <g_bor>snape: I see, but now it works... so maybe it was down too? <jonsger>you run it at home? because of electricity... <snape>jonsger: Yes, I run it at home... it serves as a heater during winter <g_bor>also, are the build nodes able to work while the head node is down? <jonsger>french flair. I do that with my computer as my chamber doesn't have a heating. I do usually BOINC stuff... <g_bor>I mean do we spilt the evaluation, send it to build and later only assemble? <snape>I didn't know about BOINC, interesting <jonsger>I like the idea more then this bitcoin stuff <snape>jonsger: I was half kidding though, my appartement has a heating :) <snape>but I don't know how I could measure the electricity expenses, so that I can share it with Mathieu, who uses it too <jonsger>snape: but in France they usually use electricity for heating, don't they? <snape>jonsger: it depends on the place. Some do, and some use water <snape>g_bor: I think that the builds that are in progress won't stop when there is an issue. Also, there is no "assembly". Once a build is done, it's provided by 'guix publish'. What could happen is that they aren't registered to Cuirass' database, but it's not a big deal. <g_bor>snape: thanks for the clarification. <g_bor>Also, is it possible to queue more than one build to a build server? <g_bor>And would it be possible to run a second instance of the guix publish somewhere? Would that help in reducing outage? <cbaines>kmicu, no, unfortunately not. It's only a two line change though. <cbaines>I did however write a system test to reproduce the problem though, and that reminds me, I still need to submit the patch for that <kmicu>cbaines: would you be ok to share crucial snippets for setting up subvols with us, and me specifically đș Pasting them somewhere or something? <snape>g_bor: there are usually lots of builds queued, already <cbaines>which means that Grub gets configured correctly when you use a btrfs subvolume for the /gnu/store <cbaines>I was hoping to find a solution to this, I tried changing the default subvolume, and that didn't seem to help <snape>g_bor: and I don't really know about how to reduce outage, one way is to do like hydra does with its mirror, but civodul knows bettert <kmicu>cbaines: thank you very much. Itâs a good pointer for me to start investigating the subvolume issue. <g_bor>I was just wondering if anyone have any good processes in place to manage the dotfiles in your home directory, that are containing secrets, for example the gpg private keys... <cbaines>I use vcsh, along with myrepos, but I don't commit any secrets <g_bor>cbaines: I use something similar, using stow, but I also don't commit secrets. <g_bor>I was wondering how to improve on that... <g_bor>for example adding git-crypt to the mix? <snape>g_bor: I commit my secrets to password-store <snape>which is basically gpg + git <g_bor>snape: thanks, this seems like what I was looking for :) <efraim>I keep my git repository on a local machine, but I keep meaning to recreate it without secrets and scp-ing those files around <snape>g_bor: the nice thing with password-store is that you can upload everything to a git remote, and use them on other machines as well <snape>(it also has an emacs interface) <g_bor>hello guix, a bit of confusion arose here, I would like to know which one should my guix profile point to. <g_bor>I believe that per-user/username/current-guix is the one. <apteryx>hello, when fixing a bug, should I attach the patch to the bug on send it to guix-patchesĂ <snape> apteryx: it's simpler to attach the patch to the bug :-) <snape>g_bor: ls -l ~/.guix-profile -> /home/clement/.guix-profile -> /var/guix/profiles/per-user/clement/guix-profile <snape>(well, the first '->' means: 'output', whereas the second one is part of the output...) <g_bor>ok, that's the same for me, then I think this is fine. <emacsomancer>is there a way to set the swappiness in guix w/o a reboot? <bavier>emacsomancer: you can use a swap file <bavier>emacsomancer: I believe the manual mentions this and gives an example <emacsomancer>bavier: I am using a swap file, but I'm still getting a "possibly out of space" error when trying to update Icecat, and I have plenty of free space available, so I think it's not deciding to swap out <emacsomancer>(I had this issue with guix on a foreign distro and setting the swappiness in that case resolved the issue) <pkill9>emacsomancer: are you trying to build icecat? <emacsomancer>I get a message: "building /gnu/store/9kfbnv61fdhl4bhfm22vd44l3la3mfz8-icecat-60.2.0-gnu1.drv..." <emacsomancer>and then "note: build failure may have been caused by lack of free disk space" with subsequent failure messages <lfam>That message is usually correct <pkill9>emacsomancer: the main build server is down (until friday i think), i suspect guix is falling back to building it, and icecat probably need slike 16GB of RAM <emacsomancer>so I've had a similar problem with guix on a foreign distro <emacsomancer>even when I have 24G of swap, it'll fail to use it unless swappiness is set high <pkill9>actually it's not completely down, just not building new substitutes <emacsomancer>pkill9: yes, it does seem to require 16gb of ram to build <emacsomancer>but I can't figure out how to dynamically set swappiness in guixsd <lfam>emacsomancer: You might also make sure you are getting substitutes from <berlin.guixsd.org>, and then try again or wait a few hours <emacsomancer>lfam: yes, I have done those things already. I've been trying over the past 4-5 days. <cbaines>emacsomancer, you might be able to reduce the RAM requirement by adjusting the cores option, -c on the command line <cbaines>a lower number of cores should use less RAM <pkill9>emacsomancer: does it work if you write to /proc/sys/vm/swappiness ? <pkill9>it take s avalue between 0 and 100 apparently <emacsomancer>pkill9: ah, yes that does work (e.g. echo 100 | sudo tee --append /proc/sys/vm/swappiness ) <pkill9>i think there's a kernel parameter that sets the swappiness on boot, and you can set kernel parameters in config.scm, but i can't find the kernel parameter <nckx>emacsomancer: I'm curious, what other ways are there to 'dynamically set swappiness' in other distros? I've only every heard of /proc/sys/... <pkill9>everything i find says to set it in /etc/sysctl.conf <nckx>Right. That should work too though. <pkill9>oh apparenlty it sets kernel parameters at runtime, so you need to set vm.swappiness=[n] <pkill9>everywhere says to use sysctl to set 'vm.swappiness' <pkill9>oh but you only wanted to know how to set it without rebooting so you probably don't need that info <nckx>Turns out I do set vm.swappiness on one of my build boxes. I wrote my own sysctl service too. Maybe the one you linked is newer or I didn't know about it, pkill9. <nckx>And I meant thanks. Time to get rid of my abomination. <emacsomancer>i had actually tried setting it directly in /proc/sys... earlier but with a value over 100 <lfam>apteryx: Does you profile really contain those conflicting entries? <rekado>Just FYI: I caught a bad cold, so Iâm not very responsive these days. Still alive, though. <lfam>Hi rekado, I hope you feel better soon <lfam>apteryx: Hm... it seems like it shouldn't be possible to get into this state, especially since yasnippet 0.13 was added recently, long after Guix stopped allowing profile conflicts <lfam>Well, I would try removing the packages in question, updating, and them adding them back. I think it's worth a bug report or help-guix message, too <apteryx>lfam: I might have installed emacs-elpy package from my source tree since I was developing it <apteryx>but I don't see how that would create this problem <apteryx>hmm, I fired a new terminal and it is working now... maybe I had source my ~/src/guix/pre-inst-env which was now more dated that my pull'd guix. <apteryx>the sourced tree had an older emacs-yasnippet version than the one installed in my profile, which was the source of the problem. <g_bor>I will now try something shaky :) <g_bor>janneke: I'm running on highly overcommited memory right now, it's about 30G on a host where I have only 16G. <g_bor>trying to get the system I ruined yesterday, so I decided to start up another vm, which is highly over the limit :) <g_bor>looks like berlin still misses some stuff... <rekado>g_bor: probably âagainâ is the correct word instead of âstillâ. We have to keep running âguix gc âŠâ to make space as we canât use the external storage at the moment. <g_bor>rekado: oh, I got it. Thanks for the info. <g_bor>rekado: speaking of which, I will be able to access the system with the hba-s soon again. One of our main sysadmins was ill, and the hardware project was stopped, but it will be back online soon. <g_bor>I am trying to do a guix copy, but I get a backtrace. <g_bor>it is wrong arument type, unspecified in procedure length. <lsl88>Hi! Sorry for writing here too <g_bor>it goes like: guix copy --to=gabriel@ip guix <lsl88>I'm still stuck with the guix pull stuff, and I can't go on without solving it. When I rollback for another snapshot of my VM with an almost fresh install or it worked with sudo, it takes like hours. And it kind of get stuck when is is testing guile <lsl88>More than at least two hours ago it kept in: with GUILE_LOAD_PATH=/tmp/guix-build-guile-2.2.4.drv-0/guile-2.2.4/test-suite <g_bor>so you got an almost fresh install of guix on a foreign distro, 0.15.0, then do a guix pull <lsl88>does that have to do with the berlin/hyrdra stuff? <lsl88>g_bor: i restored one of the first snapshots <g_bor>Berlin should have a substitute for guile ***rcm is now known as reed_
<reed_>Hi All, I've been working on some audio processing tools and I'd like to set up a guixsd machine that is tailored for this sort of development. I know I'd like to have the realtime kernel (PREEMPT_RT patchset). Does this mean I need to make a custom kernel package? <lsl88>g_bor: but isn't it weird that it breaks down while running tests? <g_bor>actually guile takes forever to build :) <g_bor>rekado said it takes 50 minutes on 128 cores and 1T ram. <lsl88>ok, I don't have that hardware :( I I was thinking that maybe I could record another contribution for outreachy 2021 :P <g_bor>lsl88: for now I guess you best bet is to run everything with berlin as substitute urls. <lsl88>or go on playing with guix at least, which I found more useful. And I thought that I could use my retro PC for installing GuixSD on bare metal. Now i know I should not give it a try, or at least, just install it and leave it there <lsl88>find* I don't know what't happening with my Englush <g_bor>actually I've installed guisd on quite low end hardwares, when substitues are available that can work. <lsl88>g_bor: ok, I will cancel the installation and add the substitutes. Hope that by tomorrow I have my guix working. <g_bor>I also hope to have my GuixSD working by tomorrow :) <vagrantc>i don't know if it's just bad luck, but it seems some things never have valid substitutes <vagrantc>hrm. having troubles building qtwebkit again ... i suspect it needs more than the available 12GB of free space ... maybe i should try building it with fewer threads <vagrantc>at one point it was using ~7-8GB of memory and 2-3GB of swap ...