IRC channel logs


back to list of logs

<ng0>pkill9: around 2GB RAM should be enough
<ng0>pull on 512 MB RAM works (I've tested it recently) but you will need a big swap file and lots of patience. capital lots.
<niebie>ng0: swap is usually a crutch for poorly written systems - if you are forced into swap things are rather dire
<pkill9>ng0: do you provide a public server for substitutes for your guix fork?
<pkill9>for your custom modules
<pkill9>which was here
<ng0>ah okay, I thought some part of me went into overdrive and worked on something I can't remember :) the costume modules that's something else.
<ng0>well I have a substitutes server.. but it's super experimental.
<pkill9>tbh i want to rent a VPS and build stuff on there
<pkill9>then get them as substitutues
<ng0>the experimental bit is that I still have to get the cronjob right for updating the IP @ 1984s DNS.. so it looses connection every now and then
<ng0>and in general it drops connection every now and then
<ng0>so it's really nothing I could recommend right now
<pkill9>ah np, i should do it myself really
<ng0>at some point some packages will be in a more stable place offered. but not today.
<pkill9>i was just thinking of your chromium build
<ng0>chromium currently fails
<ng0>so no luck there
<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 moved to 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
<pkill9>yeah with guix already installed
<pkill9>yeah that would do it
<niebie>you would have to include the public key and the package definition, but i think it does what you want
<ngz>I'm packaging a game that provides music and sounds either as ogg or as flac, the latter adding 230Mo to the closure. I'm not sure which one to include. Any advice?
<ng0>why the choice?
<ngz>sound quality
<ng0>I mean why do they have either / or
<ng0>I know how ogg and flac differ, but I don't know the game to decide
<ngz>You can always download the other format later. It's just an installation choice.
<ng0>230MB isn't that much when it comes to games today imo.
<niebie>high quality sound is expensive in bits
<ng0>ngz: package ogg and add flac as a variant later on?
<ngz>I'll go with ogg and let a comment in the package definition
<ngz>So we can add flac later, if needed.
<ngz>Thank you for the advice :)
<ngz>Hmmm does Guix expect binary to be installed on $output/bin or is $output/games fine?
<pkill9>i don't think it expects it anywhere, it will just put whatever is output, into the profile, so i think it is fine
<ngz>It does, actually =/ `patch-dot-desktop-files' is looking for executables in "bin/" directory.
<ngz>I renamed "games/" to "bin/"
<Apteryx>patch incoming for a revamped way to enable tests for emacs-build-system packages \\o/
<Apteryx>as well as emacs-elpy, for those who need a capable Python dev environment.
<apoorvasingh[m]>I'm Apoorva Singh. I'm new to this community and interested in taking part in this round of Outreachy.
<apoorvasingh[m]>I have intermediate knowledge of C++, HTML,CSS, JS and hav used all of them in projects and am willing to expand my knowledge. How can I start contributing?
<rekado_>apoorvasingh[m]: welcome!
<rekado_>apoorvasingh[m]: have you installed Guix yet?
<apoorvasingh[m]>No I haven't. I'll do that.
<rekado_>apoorvasingh[m]: I recommend to install the “binary release”, which is available here as “GNU Guix 0.14.0 Binary”:
<rekado_>we offer a script to make the initial installation easier:
<rekado_>you can run it to download the binary, check it, and set it up on your system.
<rekado_>(it’s a recent addition, which is why it isn’t mentioned on the website yet)
<apoorvasingh[m]>Thank you so much. I'll start setting it up.
<rekado_>apoorvasingh[m]: thanks. Let us know if you run into any problems.
<apoorvasingh[m]>rekado_: the script is running. how do i download the binary version now?
<rekado_>apoorvasingh[m]: did the script give you any output?
<rekado_>it should download the binary automatically
<apoorvasingh[m]>ACTION uploaded an image: Screen Shot 2018-02-13 at 1.55.06 PM.png (19KB) <>
<rekado_>it requires that you have a copy of the public key to validate the signature, though
<apoorvasingh[m]>this is the output
<rekado_>oh, that doesn’t look right.
<apoorvasingh[m]>sorry, I'm a bit confused how to go about it
<rekado_>another thing: I’m afraid you won’t be able to install Guix on a Mac.
<rekado_>do you have a GNU+Linux machine that you could use?
<apoorvasingh[m]>No i don't
<rekado_>oh, that’s unfortunate.
<rekado_>at the moment Guix cannot be used on a Mac. It’s for GNU+Linux systems only.
<apoorvasingh[m]>that means I woulnd't be able to contribute to the project?
<apoorvasingh[m]>oh :/
<rekado_>yeah :(
<rekado_>I’m sorry.
<apoorvasingh[m]>Thanks a lot for helping. Appreciate it :)
<rekado_>I have just updated the info on the Outreachy page to tell people that they will need to have a GNU+Linux system.
<rekado_>thank you for your interest and for your patience.
<apoorvasingh[m]>rekado_: Can i use a virtual machine or install ubuntu to install it?
<apoorvasingh[m]>Really want to contribute to this project and learn
<rekado_>yes, you could use a virtual machine
<rekado_>I didn’t even think of that :)
<apoorvasingh[m]>Great! Thanks
<rekado_>while you’re getting your virtual machine set up, let me comment on the error you posted
<rekado_>that’s probably because you saved the script as “script” and then tried to run it as “sudo script”.
<rekado_>this will look up “script” in the directories listed in the PATH environment variable.
<rekado_>it won’t be the script you saved.
<rekado_>instead you would need to run “sudo ./script”
<rekado_>to tell it to execute the script in the file “script” in the current directory.
<rekado_>(you also need to make it executable with “chmod +x script”)
<apoorvasingh[m]>Okay. I'll keep these pointers in mind. Thank you!
<lorslara>how can I change theme of slim?
<roptat>hi Guix!
<roptat>yesterday I tried to compile a new package that depends on boost and it fails at some point saying g++ can't find -lboost_filesystem and others
<roptat>but the g++ line contains -L"/gnu/store/...-boost.../lib"
<roptat>any idea?
<rekado_>ACTION successfully built a new pandoc after dozens of updates to haskell packages and a switch to ghc-8.
<rekado_>roptat: what build system does this package use?
<roptat>the gnu build system
<rekado_>is this at the configure stage or later during the build?
<rekado_>ACTION is about to push ~160 haskell package updates and additions
<rekado_>ACTION builds a couple more packages that depend on haskell to minimize breakage
<efraim>fun times
<roptat>rekado_: at the end of the build
<roptat>there's no configure step
<roptat>what's the status of the update for java by the way?
<OriansJ>good job rekado_ :D
<rekado_>roptat: I don’t know what the current status of the Java update is. g_bor might know.
<snape`>whoo I just found about the "--touch" option of "make". Combined with "--keep-going", it avoids recompiling everything when you checkout an old commit, and go back to the original commit.
<Apteryx>Why can't I run "source" in a build phase?
<Apteryx>or maybe I can.
<Apteryx>I'm trying to invoke source with (invoke "source" ...)
<snape>Apteryx: because it's a shell builtin
<Apteryx>snape: any way around it?
<Apteryx>the virtualenv I'm told I shoudl activate for running tests can *only* be enabled with a "source" bash command.
<snape>I don't know
<mbakke>Apteryx: I try to avoid virtualenv and just invoke the test command directly. It often works out of the box in the build container.
<snape>(it's probably a bad practive, but FYI source works in 'system' command)
<Apteryx>one test fails when I do that:
<Apteryx>I think I'll just fake it with (setenv "VIRTUAL_ENV" "/tmp") ;)
<Apteryx>looking at the sources of elpy it'll be enough.
<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>i gave the VM 1.5G of RAM now
<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.
<lfam>JGit discussion about implementing shallow clones:
<lfam>Also very interesting and semi-related discussion of Git server perf issues about shallow clones:
<lfam>Basically, GitHub had to deprioritize that package manager's traffic due to perversely bad performance going from shallow -> full clones
<lfam>The GitHub engineer says "I would urge you to consider how CocoaPods could be distributed without using Git operations, which are intrinsically hard to scale."
<lfam>Something to consider as the world tries to use Git for everything
<wigust>“CocoaPods can help you scale your projects elegantly.”, yeah.
<lfam>We all want to create elegant tools :)
<bavier`>I was wanting to implement an arch-linux updater, but the lack of shallow-cloning in libgit2 was a bit of a show-stopper
<lfam>Hm, that will complicate things
<efraim>cbaines: your gpg key on savannah is missing the -----END PGP PUBLIC KEY BLOCK----- line
<cbaines>efraim, ah, ok I can try and fix that
<cbaines>thanks for letting me know :)
<cbaines>I've just tried updating it, but it still appears to be truncated... maybe I have to wait a bit
<bavier`>expect@5.45.4 source hash mismatch
<bavier`>oh, SF download links not working atm:
<bavier`>We're sorry -- the Sourceforge site is currently in Disaster Recovery mode, and currently requires
<bavier`>the use of javascript to function. Please check back later.
<bavier`>substitute servers are still serving the right source though
<bavier`>which is a nice workaround
<ng0>ah damn.. another libpng-apng source hash change
<ng0>oh, my bad. old code