<pkill9>i m currently running guix on slackware, trying to package everything i can with guix
<ng0>I have some working builds though.. just with current master it fails
<ng0>what was on c.n0.is moved to git://code.crash.cx/ng0/guix/guix.git
<pkill9>has anyone developed some kind of wrapper/interface that could be used to install guix software like with those .flatpakref files that flatpak uses?
<pkill9>e.g. you open them with the wrapper and it would automatically install the package specified in it to your profile and fetch the substitute from a specified server
<niebie>you could use guix archive --authorize < pubkey && guix package -e "(package def)" i guess
<niebie>pkill9: are you installing this on a system with guix already installed? i'm pretty sure a batch script that authorizes the substitute server and installs an arbitrary s-exp that defines a package would do what you are asking
<Apteryx>snape: interesting. I'll use system as last resort.
<roptat>Apteryx: look inside what you're sourcing. if it's just a bunch of export, you can use setenv
<Apteryx>eh, now I understand what the test does is check that it can
<pkill9>When i run `guix pull` on the GuixSD livecd (after running `herd start cow-store /mnt`), it tries to compile gcc. Is this normal? I'm running the ISO from the website
<lfam>pkill9: I wouldn't say it's abnormal, but I don't recommend doing `guix pull` before installing
<lfam>We test the installation image more thoroughly than the current HEAD of the master branch, which is what you'll get with `guix pull`
<pkill9>hmm, i'm pretty sure yesterday i was told to do that, or maybe I misread
<lfam>Well, there are situations where it could be warranted, but not in general. Can you give more context?
<lfam>I *do* recommend doing `guix pull` as soon as possible after booting into the newly installed system
<pkill9>basically yesterday i ran out of memory after running `guix system init` (into VM so it's not critical), and they said it probably started trying to compile everything because it's likely out of date, and that i should run `guix pull` first
<pkill9>but it may have just been that i didn't give the VM enough memory for a normal installation so i'll see
<lfam>Sorry, but that was bad advice. `guix pull` also uses a lot of memory, so it won't help you with OOM
<lfam>I'm reading yesterday's chat to get the context now
<lfam>We try to keep substitutes that correspond to the latest release image, and ideally the previous one as well (at least for a while)
<lfam>I do agree with the others' feedback that swap is a last resort, at least if you are using a spinning disk. It will be very slow and I worry you will get bored and give up :)
<lfam>On an SSD it will still be quite slow, but perhaps acceptable
<lfam>So, I do agree that it's a good idea to initialize the system with something close to the bare-bones template, and then reconfigure into a bigger and more complex configuration, at least the first time. Otherwise, if there is a problem, the feedback loop could be annoyingly slow
<lfam>I think 512MB sounds small, although I'm not sure exactly what the limit is for system init, or what might have exceeded it
<pkill9>apparently due to a known bug, atleast 1GB of RAM is needed to install Guix
<lfam>Yes, I'd say you'll want at least 1GB for `guix pull`, but ideally ~1.4GB so that you don't have to swap. And that number will grow slowly as we add packages, until we fix the bug
<lfam>But, I think one shouldn't need to `guix pull` to install, so perhaps there is some other issue with the installation process in particular
<pkill9>it died due to lack of memory originally when i just ran `guix system init /mnt/etc/config.scm /mnt` (i had ran `herd start cow-store /mnt` also), so maybe that's a separate but related issue to the RAM required to run `guix pull`?
<pkill9>by died i mean i just threw an error about 'out of memory' and the process just said 'killed'. The error looked like it came from the kernel infact
<lfam>Yeah, that sounds like a classic OOM, handled by the kernel
<pkill9>does guix's git downloader only download with depth=1?
<pkill9>cos if not then it would be good to do so as it's much smaller download size, unless it has a use for all the commit history
<lfam>pkill9: No, it does a full clone. We're actually discussing this on the mailing list currently. Some Git servers don't support shallow cloning, so it will need to be optional
<lfam>It doesn't use the commit history. It does a full clone, checks out the specified commit, deletes the .git directory, and what's left is the result
<efraim>i'm not sure that guile-git supports shallow clones
<pkill9>ah, i didn't know it wasn't supported on some servers
<lfam>I also wonder about upstream performance (the full clone may be a cheaper case than calculating which blocks to send for a shallow clone), but ultimately it's not really the client's problem
<lfam>And we don't really fetch that often because we cache sources on our servers
<wigust>Guix does a full clone, then can serve substitutes without “.git”, as I see.