<bgardner>Good morning Guix, has anyone worked out a method to declare NFS mounts yet? My last effort a month or so ago had no luck (NFS works, but you can't get entries into fstab without hand-editing).
<apteryx>I may have missed the answer and I'm sorry if I did, but I still have the following question: it seems that gcc-toolchain doesn't not include libstdc++? Do I need to to install the libstdc++ package along gcc-toolchain?
<mikadozero>I have just completed a: guix system reconfigure --no-substitutes
<mikadozero>Is it correct that that means all the programs on the system have been built from source?
<rekado>mikadozero: not necessarily. It just means that for *this* reconfiguration no binaries were downloaded from the build farms.
<rekado>if there are parts of the system that already existed in /gnu/store they would not have been rebuilt from source.
<mikadozero>How would I have everything built from source even if the system has previous substitutes?
<rekado>there is no way to do that recursively, AFAIK. /gnu/store is a cache and it will be used unless you tell Guix to rebuild something with “--check”.
<rekado>whether an item in /gnu/store was built from source or fetched as a substitute is recorded in the database, but isn’t exposed through a user interface.
<mikadozero>It would be nice to be able to build the entire system locally and ignore any substitutes that were already on the system.
<mikadozero>So if I wanted everything to be built locally could
<roptat>mh... there's every dependency of guix already in the store, so you'd have to start with a guix built from source, outside of the store
<mikadozero>I accomplish that with a new install and always using --no-substitues?
<roptat>so I guess, you'd boot on a live-CD for another system, install dependencies for guix using that system, checkout the git repo, bootstrap, configure, make and then run the daemon with --no-substitutes, and ./pre-inst-env guix system init ...
<roptat>with the no-substitutes as an option to the daemon in your new system's configuration
<roptat>I don't know if anything simpler would work
<roptat>For instance, I think the guix live-cd already has a store, so there are some things that will be used from it
<mikadozero>roptat: Okay so it could be done by bootstrap the system and have the daemon configured to use --no-substitutes.
<roptat>yes, as long as there is no store to start with
<roptat>then you'd build everything from the bootstrap binaries up to your system
<mikadozero>rekado: Is there documentation I can look at for bug reporting?
<apteryx>mikadozero: I can't seem to find bug reporting guidelines in the Guix info manual, but basically 1. search for existing bugs before entering a new one 2. state your guix version (guix describe) and steps to reproduce the issue. 3. Mail it to email@example.com.
<mikadozero>Is there a different process than bug reporting for feature requests? For example: - Add bug reporting to info manual - Be able to rebuild entire existing system from source
<polezaivsani>rvgn, and since you sound like you did more than once, please tell how good of a fit guix might be to configure computers? i.e. what's Ansible, Cheff and the rest are being used for now.
<rvgn>In my experience, I think guix can be a fit for literally anything. You know how there are particular distros focused for particular purposes? Guix can be molded to literally anything with just one configuration. More to that, it can be reproducible.
<roptat>polezaivsani, ansible and the like have the ability to deploy and configure systems remotely, which guix cannot yet, but they don't provide reproducibility, only some sort of fix-point guarantee (the environment created will influence a future run of the same config in such a way that it creates the same environment) I don't remember how they call that
<polezaivsani>guess i'll take a stab at it once i up my guile game a bit
<roptat>and we are working on a guix deploy thing :)
<roptat>in the mean time, people are using some scripts to deploy stuff remotely and it seems they are pretty happy with the result
<roptat>I guess you could use ansible to reconfigure remote machines though ^^
<polezaivsani>like setup guix on a remote host first and then run the same config as you'd do locally?
<roptat>I was thinking of ansible as a tool to automate ssh'ing to the machine and running some commands, which would be "install the new config file, run guix pull to that specified commit and reconfigure the system"
<roptat>but people use scripts that actually build the remote system locally and send guix store items to the system once that's done, and then it's very quick to reconfigure on the remote system
<rekado>roptat: once installed you can also do that without ansible :)
<mikadozero>When trying to redirect the output of guix challenge I found out that it does not output anything to stdout and only stderr even when there is no error. I was not expecting it to do that. Is there a reason for it?
<kmicu>polezaivsani: nix (disnix, nixops) already replace those use cases. Guix can do the same ― we only need to throw engineering hours at it, nothing more.
<kmicu>(You could also use disnix/nixops to deploy Guix if you like layers of indirection 😹)
<mikadozero>For the guix challenge I just ran 39 of 41 packages that were marked as differ where guix related packages. Would guix related packages have an issues with being non-deterministic?
<polezaivsani>yeah, that sounds like lots of fun, kmicu :) and frankly i won't mind lots more indirection once it's all orchestrated via guix and not my fallible self
<mikadozero>Guix related meaning it says guix in the package title.
<kmicu>polezaivsani: Changing remote boxes by sending a declarative configuration (which is reproducible) is sweet. But it also has some downsides like being angry each time you need to touch your debian box xD
<polezaivsani>kmicu: you mean it would turn into the only way to configure them? as in you don't mish and mash guix config and e.g. manual installations?
<polezaivsani>i got used to it mostly with my current setup; dont know how painful it is for a large scale ops though
<kmicu>I’ve had in mind that after using 100% declarative approach I cringe every time I need to manage a statefull (and update-in-place) system like Debian.
<polezaivsani>yup, i imagine it would hurt some... like kicking a bad habbit ;)
*kmicu imagines a future with GuixWRT and Guix System as popular as CentOS/Debian in VPS offerings.
<eubarbosa>lol, eager to install chromium, takes too long...decide to install it as I go to sleep...
<kmicu>(Where ‘Too Big’ means it’s not a distro for embedded devices. Removing stuff would take more time than starting from scratch.)
<apteryx>some embedded boards are powerful and can be equipped with enough storage for Guix (some people are running Guix on ARM boards for instance). It might be possible to turn those into routers, using USB network adapters?
<kmicu>(Folks have issues with adding support for Fish and for embedded devices we need to remove bash xD).
<kmicu>(OpenWRT is not about powerful single board computers but those drawing 4W and having ~32MB of RAM.)
*kmicu should talk about libreCMC (not OpenWRT) cuz it’s FSDG like Guix System.
<apteryx>kmicu: OT, but talking about libreCMC, I ordered a second hand Netgear WNDR8000 to install it on it!
<kmicu>Nice, not only libre but also environmentally friendly cuz second-hand 👏
<apteryx>yeah, I'm looking forward to see how it performs
<g_bor>I was thinking about that it would be nice, if we could upload the tarball generated by guix build --source ungoogled-chromium somewhere, or provide the link from the build farm, so that interested parties can have a look at that, run their license checker, or whatever. Wdyt?
<rvgn>IDEA+DOUBT: Is it possible to make qubes-like OS with guix?
<vagrantc>of course it's possible, question is really of how much work it would take :)
<apteryx>any idea why our libstdc++ package version is reported as 4.9.4? AFAICT it should be based on the same version as our GCC package (which is, 5.5.0) (in gcc.scm: (define-public (make-libstdc++ gcc) ... ) and just above: (define-public gcc gcc-5)
<apteryx>it seems to be a bug with regards to the package inherit mechanism