<colony>yeah that might be whats happening. Its downloading and building a whole bunch of stuff.
<iyzsong>if you see downloads from ci.guix.info, then that's ok. between step 7 (authorize the public key) and step 8 (Applicaiton Setup), you may want to run 'guix pull' to update guix to the latest version.
<colony>Yeah I did neglect to run that `guix --authorize` step. I just overlooked it. I'm killing the job and retrying now. Thanks for pointing that out
<raghavgururajan>I wanted to ask this. What is life cycle of package management/processing in Guix System? For debian, it's like upstream-->package-->incoming-->unstable-->testing-->frozen-->stable. So how it is like for Guix????
<raghavgururajan>Ah! I see. Thanks!. So there no segregation of repositories? For example, Parabola has organised packages into different repositories like core, extra, testing etc.. So just one repo in guix??
<atw>there is one official repo, but there are also channels, which serve as extra sources for package definitions
<raghavgururajan>Yo Guix! Can someone provide me a resource where I can learn general overview of guile scheme programming and extensions? I would like try packaging for first time in my life, so that I can contribute to the project. I am so excited.
<kmicu>It is a convention, it can be anything. On NixOS there is a rolling release channel with no versions and a stable channel with Ubuntu-like versioning (e.g. 18.09). At the same time Nix has a seperate versioning (e.g. 0.12.2).
<raghavgururajan>I am confused now. I thought rolling model means there is no versioning.
<kmicu>On Guix System and NixOS we can have both. They are not limited by traditional distros limitations. User can choose a stable releases like in Trisquel or rolling release like in Parabola (or both e.g. stable release for core sytem and rolling release for a user profile).
<raghavgururajan>Ah I am getting it. It's like hybrid. All packages are versioned, so one choose to use any (latest version or most stable version).
<decent-username>I'm trying to install Guix on my Debian machine and I kind of did. But when trying to install a package it complains about not being able to install a locale. guile: warning: failed to install locale
<raghavgururajan>Check whether the locale of your current debian system is available in guix or check whther the naming convention for locales is different between debian and guix?
<iyzsong>decent-username: in short, install the glibc-utf8-locales packages as both root and user running guix, and make sure the user has the 'GUIX_LOCPATH' enviroment.
<decent-username>iyzsong: That's what I have to do. But how do I do that? It's not in the repositories apt uses.
<tune>I think you can just install it with guix itself
<kmicu>mikadozero: could you execute ‘aspell --help’ in your shell and check ‘Available Dictionaries:’ section?
<kmicu>(There is a comment in aspell package to ‘export ASPELL_CONF="dict-dir $HOME/.guix-profile/lib/aspell"’ or set ASPELL_DICT_DIR but I assume aspell should pick up installed dict-s in a fresh shell.)
<mikadozero>kmicu: That work and aspell begins spell checking my config.scm
<colony>Hey all, i'm still getting the locale warning on guix package commands even though, as far as i can tell, I have a locale installed and the appropriate environment variables set. See https://pastebin.com/dmF86Xu6
<lfam>raghavgururajan: The list does not distinguish them
<lfam>colony: Okay, first of all, you can ignore those warnings safely. They are just *warnings*
<phenoble>Ok, so I'm trying to build/install the hello package, but that fails in the substitute step in fport_read with the Error "Is a directory". It looks as if the path that I am to supply to guix there was (now) a directory, but used to be a file in a previous version of guix.
<phenoble>Unfortunately I can't check what is the case, because I can't access that file hierarchy.
<phenoble>ah, ok, a typo - acl was supposed to be that file renamed
<phenoble>Now substitute vfails with "invalid access control list", looks like the public key is not valid
<apteryx>hello! I'm using the recently added docker service/package in Guix (for work), and I may have stumbled on some bug. When a dockerfile has a 'COPY' or 'ADD' directive, the relative path is taken not from the CWD where docker was run, but rather from some /var/lib/docker/tmp/docker-builderXXXXX/... path, so it fails finding anything.
<apteryx>if someone else is also using Docker, I'd be interested to know if this problem is reproducible on you side.
<lfam>Has anyone tried packaging magic-wormhole for Guix?
<apteryx>nevermind about the Docker issue, it's working the same on a non Guix system.
<ng0>I had a GuixSD running on 1984 a long time ago. And given that guixsd becomes reliable etc they'd offer it in addition to debian. Hetzner is special. IN-Berlin says that you can ask them to mount an ISO, there's just too little people to support GuixSD
<ng0>this was never on-list, it was me as a customer of IN-Berlin
<ng0>i have config values somewhere for in-berlin.
<g_bor>ng0: So there is no pre-baked solution, but there are some opportunities, if you want to create your own. Is that about correct?
<jackhill>I've managed to dd the Guix install image to a disk on linode, and then sucessfully guix system init from that. It works, but more things need doing (like figuring out why the default kernel can't see the disks in paravirt mode).
<g_bor>civodul: I have a question. I packaged prometheus, it seems to work, but the tarball includes a vendor directory, with a bunch of things, in source form. Should I give it a try to get those unbundled?