<dadinn>quick question: I have am just trying out guixsd booted from a usb drive. I have tried NixOs the same way before, but since I am more into lisp, I thought that guix might be something I would be more comfortable with (not a fan of curly brackets, and static typing, prefer parentheses and decent macro facility). I have ran into two main obstacles so far: 1) it seems that unlike NixOs, the GuixSD does not
<dadinn>contain the ZFS kernel modules and binaries by default. Why is this and is there a guide to set it up? 2) I don't have wired Ethernet, is there a guide how to configure the wifi WPA2 connection? Or should I just try to follow an Archlinux guide?
<lfam>dadinn: Configuring wifi in the installer image should work like it does in other systems, assuming your wifi hardware can be used with free software (we only package free software).
<lfam>Do you know what wireless chip you are using?
<lfam>Regarding ZFS, the Guix and GNU communities will need to decide if the license is compatible with the kernel. My impression is that the other distros simply don't care about these issues very much. But we do care, as a GNU project.
<dadinn>lfam: about the chip, not sure of the exact chip right now, but Fedora runs fine on it, so I suppose it should be supported...
<lfam>I haven't looked into that very closely, so I don't have an opinion
<lfam>dadinn: There are very few wifi chips that can be used with free software. Try `lspci` in the GuixSD installer image to see what you have
<dadinn>lfam: the network controller is Qualcomm Atheros AR922X
<lfam>Considering this recent statement from RMS, I doubt we will be shipping ZFS kernel modules: <https://www.fsf.org/licensing/zfs-and-linux>. But, the first of the 4 softare freedoms is the freedom to use the software as you see fit. Guix makes no effort to prevent you from using whatever software you prefer.
<lfam>That wifi chip works with free software, so it should be possible to set up a wifi connection in the normal way
<lfam>In the installer image, you'll probably set it up "by hand" using ifconfig, wpa_supplicant, etc
<lfam>In GuixSD, we have system services to set it up automatically
<lfam>We have a wicd-service, a network-manager-service, and a connman-service to choose from. There is also a static-networking service although I haven't tried it and I'm not sure how it handles wifi authentication
<dadinn>lfam: regarding zfs I am using zfsonlinux https://github.com/zfsonlinux, which is essentially an FREE layer between the OSS code of zfs OSS code (not FREE according to RMS), so it work together with the GPL kernel. In the github sources it is under spl dir. considering it is quite similar in concept to fuse, I would think it worths a look. I actually possibly would be fine with fuse for testing/recovery
<dadinn>purposes, or at least a guide with instructions somewhere to copy/paste to set it up
<lfam>The CDDL (ZFS's license) is a free license, but my understanding is that it is incompatible with the GPL, and so it can't be distributed with Linux. I'm really not an expert on this issue, however.
<lfam>Personally, I think it would be awesome to have ZFS available. If it's possible to do that within the GNU Free System Distribution Guidelines, I'd be thrilled.
<dadinn>lfam: yes, I have all my NAS/server storage running on ZFS, and with NixOS I was quite thrilled that I can set up everything in a Live env. So I am missing that.
<dadinn>lfam: lspi says the kernel driver is ath9k, so it should work. I suppose I should just follow the Arch wiki?
<dadinn>yeah, I have already booted in the live USB guix system, so I suppose the Preparing for Install is the I should read, actually I remember looking at thot wpa_supplicant.conf code before and I was thinging why I cannot find it on the Arch wiki...
<lfam>The "live USB" system is actually an installer. It's not much of a system on its own. If you just want a custom live system, you can use `guix system disk-image` to create one to your specifications
<dadinn>lfam: you mean I can't install things with `guix package -i` while running it?
<lfam>dadinn: By the way, if you are using the 0.11.0 install image, beware all the security vulnerabilities we've fixed in packages since that was released. To get the latest package definitions, use `guix pull`
<lfam>To upgrade any installed packages once you've done `guix pull`, use `guix package --upgrade .` (the . is a regex)
<lfam>And remember that Guix provides per-user package management, so `guix pull && guix package --upgrade .` is per-user
<dadinn>lfam: I would possibly like to be involved too in the future, I am already getting so excited lol (can't wait to dive into the Emacs-mode, this is the best thing since sliced bread!). What main channels (mailgroups, etc.) would you recommend to be in the flow with the community?
<lfam>Check section 7 of the manual for details :)
<dadinn>lfam: I mean is there a guix command to manage/create/delete user profiles? or everything is manual?
<lfam>But remember that no changes will persist in the live image
<lfam>You have to create an OS configuration file (there are templates in /etc/configuration), edit it, and then reconfigure. But from the live image it's more typical to install, which is `guix system init`
<lfam>What do you mean by "manage/create/delete user profiles"?
<lfam>If you mean create users, then you have to reconfigure. To manage the "profile", which is the set of software visible to a user, use `guix package` as that user
<lfam>Package management is per-user. Each user can install their own packages at will.
<lfam>The GuixSD system configuration doesn't control what packages users install.
<lfam>The GuixSD system configuration can be used to make packages available for all users, but that is a different mechanism.
<lfam>If you want to export your own user's list of installed packages, you can create a package manifest, which is described in the manual
<lfam>The config is *never* updated to reflect anything. It's something for a human to edit and then use to build or reconfigure a GuixSD system.
<dadinn>lfam: I thought package management is not per user in the sense that one package gets installed once system-wide and placed in the /guix/store, and different users can link to it differently from their profiles.
<lfam>It's per-user in the sense that users control what software is available to them
<lfam>Unlike, for example Debian, where only the administrator can install or remove packages
<lfam>But yes, packages are deduplicated in /gnu/store
<lfam>Even the list of packages available is per-user
<cehteh>there where some discussion to install packages per groups .. i would really like to have such an official blessing
<cehteh>because not all users want to care for everything
<lfam>If you are interested in the basic model, there are two papers that explain it well.
<lfam>Nix: A Safe and Policy-Free System for Software Deployment, by Eelco Dolstra et al
<dadinn>I gpt thatp I actually use similar concept in my movie/audio/ebook database, I store them in a eachs store folder, and my category folders like byDirectory/byGenre just link to them ;)
<lfam>Functional Package Management with Guix, by Ludovic Courtes
<lfam>Those papers explain the functional package management model, and the 2nd one also explains the improvements made my Guix
<Apteryx>fps: No, linting other packages doesn't work. It was because of my GUIX_PACKAGE_PATH, as Alezost guessed.
<Apteryx>It was set to GUIX_PACKAGE_PATH=/home/maxim/guix-stuff, where I had a folder "my-packages" in there containing the package I'm working on. But the problem started after I decided to git clone the guix repo at /home/maxim/guix-stuff/guix. I guess that wasn't a good idea as it must have created conflicts.
<rekado>since updating to latest master I get an error about the certificate of mirror.hydra.gnu.org
<rekado>I suppose I need to set some environment variable...?
<alezost>Apteryx: yes, adding the whole guix repo to GUIX_PACKAGE_PATH is not good: this env should contain only modules with packages: when guix looks for packages, it loads all(!) guile modules from GUIX_PACKAGE_PATH
<rekado>(oh, looks like I don't have gnutls in my Guile path...)
<alezost>Apteryx: so guix tried to load all scheme files from your git checkout including, for example, "guix/build-aux/build-self.scm"
<Apteryx>In my case it seems like setting XML_CATALOG_FILES would be sufficient, since this is only used at build time anyway.
<quigonjinn>I want to mail a package upstream, to ask them to provide a mirror for some software I want to package, because they currently send links by mail. Any recommendation on where to redirect them, to point to the benefits of functional package management for the multiple build variants of their software?
<Apteryx>And I was thinking that if there was support in autotools to just set any envar you want by passing it to the configure script, it would be taken care of without needing any special guix facility :). But it doesn't seem to work like thta.
<htgoebel1>lfam: How long is the core-update cycle supposed to take?
<lfam>Until it's ready :) Basically, we compare core-updates and master on Hydra. Once there are not too many new failures, and we have added all the features we want to add, it's ready.
<lfam>Then someone (civodul) follows the steps in 'doc/release.org' of the maintenance.git repo, and issues a new release.
<lfam>I'd share a link to the Hydra comparison page, but Hydra is not responding to me on port 80 or 443 at the moment (it must be busy)
<lfam>In order to make wip-python-build-system go a little faster, I think we should try building it without any package updates. If that works, we merge it and make a python-updates branch, and do all the updates there. WDYT about that?
<lfam>Otherwise we risk it diverging from core-updates again, and that's a pain
<htgoebel1>What do you mean with "building it without any package updates"?
<lfam>htgoebel1: I had thought that we should try updating the core Python packages (setuptools etc) before merging the new build system into master. But I'm worried about that taking a long time to finish
<lfam>In general, I'd like for these branches to be finished more quickly than we've been doing
<htgoebel1>lefam: Re. python2-tempest-lib: The inputs need to be either propagated or native. Which of both need to be verified in detail. This IMHO is the authors job.
<htgoebel1>lfam: Updating all these "core" packages on the separate branch is okay.
<htgoebel1>But keep in mind that "setuptools" will no longer be a "core" package, since only very few packages required it – most will use the version bundled in python.
<htgoebel1>Auch, I just discover that we need to verify the case: If setuptools is an additional input, does this package overwrite the one bundled with python? I hope so, but we need to verify this is deterministic.
<efraim>i think i'm the one that added python-tempest-lib
<quigonjinn>is it normal for a program ran in 'guix environment --pure --ad-hoc', not to find the header linux/limits.h?
<lfam>htgoebel1: Re python2-tempest-lib: Can you say that in an email reply? :)
<Apteryx>rekado: Do you know if I can pass multiple paths to the environment variable I am passing to make (using make flags)?
<lfam>htgoebel1: I guess that for the question about overriding setuptools, we will learn the answer when we build wip-python-build-system on Hydra
<Apteryx>I've tried the XML_PACKAGE_PATH="catalog1-path:catalog2-path" way but it doesn't work.
<Apteryx>If I use a single path it registers it correctly.
<lfam>quigonjinn: It depends entirely on the arguments to that command.
<lfam>But what you are doing with that command is creating a new enviroment that unsets *all* environment variables from your normal shell, and only has the argument to --ad-hoc on $PATH
<quigonjinn>lfam: it's a program i'm currently packaging, which uses gcc to compile at runtime.
<lfam>quigonjinn: If your shell initialization files make the mistake of setting environment variables in the interactive shell init scripts (like .bashrc or .zshrc), then --pure won't be able to unset all variables, all bets are off.
<lfam>I meant to say, check the su man page for an explanation of how the new shell is set up. Without --login, you get a bunch of bogus entries in $PATH that don't apply to GuixSD, and only apply to other distros by accident
<lfam>buenouanq: No, it would be in the xorg-server store directory instead. But on GuixSD, the supported way to have a graphical system is to add %desktop-services to the (services) field of your GuixSD configuration file and reconfigure the system.
<lfam>Check the manual section 7 for more information about how to configure the system