<marusich>So, buenouanq, if it is incorrectly showing up twice, this might be a potential bug of interest to the linux-libre devs. First, you might consider asking them if (1) the patch is actually part of linux-libre and (2) it's intended that it shows up twice. Perhaps the authors could help you understand more. :)
<marusich>Sometimes, on low memory machines, running commands that cause Guix to build things don't work because there isn't enough memory. If the OOM killer decides to kill a build process, it's no good.
<marusich>If you haven't taken the steps to do that, then it's not automatic.
<marusich>See the "swap" discussion in: (guix) operating-system Reference
<buenouanq>well even with the swap on it's halting in the same place
<buenouanq>I've also installed GuixSD on this machine in the same way before and not had this problem...
<marusich>I'd start by determining what killed the process; hopefully there are messages in /var/log/messages that will make that fact clear.
<marusich>From there, you can investigate as to why the process was killed.
<marusich>If it was the OOM killer, then the immediate cause would ostensibly be that your system ran out of memory...which can happen for a lot of reasons, I'm afraid. For example, if you have a million tabs open in Icecat, it's possible that memory pressure would be great enough to cause the OOM killer to kill a totally unrelated process, such as a build process for guix pull, or the guix process itself.
<marusich>You can see if you're swapping heavily with vmstat and free. If you are, you might consider adding more main memory. It's entirely possible that when you installed GuixSD earlier and did not notice any issues, you simply happened to not be doing anything that was memory intensive.
<marusich>I suppose adding more swap space might also help, but I'm not too familiar with how the OOM killer works in detail, so I don't know if that would actually help in that case.
<buenouanq>this is on a macbook, so I assuming adding more memory isn't an option
<buenouanq>and I currently have nothing else (except gnome/xorg) running
<marusich>Well, adding more swap should be fairly straightforward, so you might try that. You can also look into tuning the "swappiness" of the Linux-libre kernel; I don't know if that's related to OOM killer behavior though.
<buenouanq>it still hasn't moved beyond compiling... 75.3%, but it is using the swap now
<marusich>So, I'd suggest verifying first whether or not the OOM killer was actually killing the process. Then, if it was, maybe look into ways to alleviate that problem.
<marusich>While it's running, you can also have some fun watching top to see what's using memory.
<buenouanq>marusich: /var/log/messages | tail has 3 things of interest:
<buenouanq>Out of memory: Kill process 1593 (guile) score 661 or sacrifice child
<buenouanq>Killed process 1593 (guile) total-nm:1425360kb [...]
<buenouanq>oom_reaper: reaped process 1593 (guile), [...]
<lfam>buenouanq: It ran out of memory with 6 gigabytes of swap?
<buenouanq>but now that the swap is on it should be able to work though right?
<lfam>Yes, although it will be slower than using RAM
<lfam>I realized my comment about "larger modules" is confusing (I began a message about them earlier but stopped). The (gnu packages python) module is ~16000 lines of code, with lots of stuff going on inside. Compiling that module is where most people notice this issue
<buenouanq>lfam: how is that going to work out for SoCs and small things in the future?
<ryanwatkins>Anybody know how one might npm install -g using guix?
<lfam>buenouanq: The issue needs to be fixed in Guile, since the memory use is really too high for many systems, including lots of ARM devices that we aim to support
<marusich>ryanwatkins, if you mean "How do I use NPM, installed with Guix, to install stuff?" I think the answer *should* be: first install npm ("guix package -i npm" or whatever the package name is), followed by "the usual" npm stuff.
<marusich>I don't use npm, but in theory if you want to use a package manager like npm, you ought to be able to do so, even if you have installed it using Guix. It's entirely possible that it might not work, though, for example if npm tries to modify things that are in the store...
<buenouanq>instead, guix packages of whatever you're wanting to add should be made
<marusich>ryanwatkins, if npm is trying to modify stuff in the store, then it won't work unless somebody changes either npm or the way it's packaged (or both) to make it possible for it to do its job without modifying files in the store.
<lfam>I didn't follow too closely when this was previously discussed, but I think the issue with packaging things from NPM is that the NPM dependency graph is full of cycles and software without source code
<buenouanq>somehow something to do with being root maybe?
<lfam>Each user has their own `guix pull`, so perhaps the user who didn't have this issue was using an older version of Guix from before we switched to Guile 2.2 (the version that introduced this issue)
<buenouanq>does the 13.0 install image not use Guile 2.2?...
<marusich>It's a shot in the dark, but you could also try doing "guix pull" from a specific Git commit (from around the time that you think the "guix pull" command previously worked OK). How to do this is described in the manual: (guix) Invoking guix pull
<lfam>0.13.0 is when we introduced Guile 2.2, but perhaps the installer was still using Guile 2.0. I don't know for sure
<buenouanq>I'm just going to stop trying on this machine until it's been fixed I guess.
<marusich>buenouanq, the long iteration team really makes it painful to troubleshoot...I know :(
<buenouanq>Cause it's not simply `slow' it screeches to a hault.
<efraim>pmikkelsen: I haven't ever touched our haskell packages, I hear there is a "stable branch" or something, I think it was strongly suggested on the mailing list at some point to target that
<pmikkelsen>There is something called stackage which is a project keeping a list of packages that works together, and they have a LTS version. I am planning to target that, as it will also same me alot of time debugging build errors :)
<thomasd>jonsger: i just mean at the command line, when you want to set up an environment for your work, type “guix environment --ad-hoc dependency1 dependency2 ...”. Of course that requires that packages exist for your dependencies.
<ng0>what I need to gather from narinfo for now is just a short human readable description. like "normalized archive something." next line: "the long descriptive line for narinfo, example: 'duration of a videostram'"
<ng0>ie: what would you like to read in libextractor for it
<ng0>if there's no long text, it can just be "narinfo" "narinfo" or "narinfo" "normalized archive info(?)"
<ng0>efraim: a service probably makes sense if we don't want to add every Mate related package to "mate" meta?
<ng0>and if there's some dbus'ing etc we would need to do
<marusich>I'm doing well. As for your question, if a package builds reproducibly, there will be no difference in performance (of the built software) because it is identical, byte for byte, to what was built on Hydra.
<marusich>It will take much longer to build the software locally than to download a substitute from a substitute server such as Hydra.
<marusich>As for trust, basically, if you believe that the Hydra server and its operators are safe to use, then you can be confident that any substitute from Hydra which passes authentication and is used by Guix is "the same" as what you would have gotten if you had built the software locally.
<marusich>By "the same," I mean extensionally equivalent: even if the software is not identical byte for byte with what you might have built locally (which can happen if the build is not deterministic), it is identical in the sense that its behavior should be the same (because it was built from the same source that you would have used).
<marusich>The short answer is: No, software compiled locally will not perform better (or worse) than software compiled on Hydra; they should behave the same.
<marusich>I suppose building locally is better for privacy in the sense that you do not have to trust Hydra, but since you are already trusting the Guix devs not to provide you with a tainted version of Guix, I don't think you gain a lot of additional privacy/security by choosing not to trust Hydra.
<happy_gnu[m]>someone told me that there is a problem with the new version with guile 2.2 and suggested to give more ram to the VM
<happy_gnu[m]>and as the link I shared suggested that is better to compile I am compiling everything
<happy_gnu[m]>which I had talked to you before marusich I would have used binaries :/
<marusich>In practice, I have found that it can take around 8-12 hours, in the worst case, to compile some things without substitutes on my laptop (CPU is 2 cores: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz) with 8 GB of RAM. Substitutes make a huge difference; they bring the total time for me down to minutes.
<marusich>happy_gnu[m], you can always try out "guix challenge" to have fun checking whether or not your local builds match what Hydra is offering. If you find something that is not reproducible, it's probably a bug in the packaged software that should be reported.
<happy_gnu[m]>when somone asks Sussman about some function and he answers something like "it doesn't matter how it works, all you need to know is that it does what I just said"
<joshuaBPMan>Hello, I'm unable to successfully run sudo guix pull; guix is complaining that I do not have guile-git. I can successfully run sudo guix; But running sudo guix pull and I get an error that says that guix new needs guile-git...? I have a git repo of guix as well.