<bavier>calher|leela: once you have an initial bare-bones installation, it's fairly safe to start adjusting your os configuration, e.g. incorporating aspects from the example desktop config in the manual
<calher|leela>bavier: Do I have to reboot to apply the new config.scm?
<myglc2>calher|leela: I think they were in /etc/configuration during the install and prior to reboot, but then they dissappear, if you don't copy them to /mnt/etc/, which is what I did and why I ahve a copy on my HD. There is probably a more intelligent approach.
<myglc2>FWIW, running guixSD, I just observed this: while in emacs, I added a big bunch of stuff to config.scm, opened a shell buffer and did 'guix system build /etc/config.scm' to check the build. Once that worked I did 'guix system reconfigure /etc/config.scm' which installed the stuf just built, no reboot required. Nice!
<myglc2>These were all packages, not services, so maybe not so supprising
<Jookia>Bootstrapping Guix is incredibly difficult
<calher>Can someone link me to a copy of desktop.scm?
<mark_weaver>Jookia: what do you mean? I've bootstrapped 2 out of our 4 architectures (mips64el and armhf), and I found it to be the easiest bootstrapping experience I could imagine.
<Jookia>mark_weaver: I might not have much time left but I keep getting errors in tests involving sparse files, and glib's gapplication crashing the tests- At the moment I'm pinning it down to old kernel versions + Btrfs
<Jookia>mark_weaver: Basically building Guix + guix package -i guix
<Jookia>mark_weaver: So I'm now trying with a newer kernel and ext4. Should be noted I was running tests on a btrfs partition
<Jookia>mark_weaver: If I still have troubles most likely I'll post to the mailing list about my experiences since the breakage is reproducible consistently
<calher|leela>It would be satisfying to do guix package -i sicp && info sicp
<mark_weaver>Jookia: those test issues should be reported to the upstream packages.
<Jookia>mark_weaver: They should, but I wouldn't know where to start between glib, tar and coreutils
<mark_weaver>test suites that fail intermittently, or on older kernel versions, or on kernels with different configurations, or different filesystems, are unfortunately a very common problem we've found.
<mark_weaver>there are some kernel features that are needed for the test suites of some core packages when run within the build container.
<mark_weaver>Jookia: it would be great if you could challenge hydra on the builds you're doing, to check for non-deterministic builds.
<mark_weaver>(at some point, after you work through these problems)
<Jookia>mark_weaver: Previously when I built coreutils the build was in fact non-deterministic, same with Guile I think. It was quite odd, and switching distros also changed the derivation hash (not just the files)
<calher|leela>export PATH="/home/cal/.guix-profile/bin:/home/cal/.guix-profile/sbin" was recently added to my bashrc because it said to do it when I installed openssh
<mark_weaver>calher|leela: on a GuixSD system, you don't have to do that manually. the problem is, you've removed the system-wide paths /run/current-system/profile/bin (and sbin) from your PATH, and that's where coreutils is normally included
<Jookia>mark_weaver: Maybe that notice needs to be removed on GuixSD? hmm
<mark_weaver>calher|leela: also, environment settings should go in .bash_profile, not .bashrc, because otherwise "guix environment" won't work as advertised.
<mark_weaver>.bashrc is loaded by *every* interactive shell, whereas .bash_profile is only loaded by login shells.
<mark_weaver>guix environment sets PATH and other environment variables and then spawns an interactive shell, and if .bashrc overwrites those variables then it doesn't work.
<calher|leela>Do I need export PATH="/home/cal/.guix-profile/bin:/home/cal/.guix-profile/sbin" at all?
<lfam>It's also possible to do something like `for package in $(guix package -A); do; guix build $package; done` on a home server and then use `guix publish` to provide substitutes for yourself. At least one Guix user has done this (and also shared the "publisher" with us for a while).
<lfam>It's not trivial computationally but it is possible and possible to automate
<Jookia>lfam: I plan to just provide substitutes for whatever I compile at home because self-sufficiency!
<lfam>Jookia: Indeed, it is really easy to publish whatever substitutes a given machine has in its store. And if you `guix pull` regularly, it will serve as a local cache of the lower level packages that every machine needs to download when there is an update (bash, gcc, glibc, guile, etc)
<efraim>if we can get substitutes over tor then it should be trivial to share from laptops even
<lfam>If I build multiple rounds of a package to check the determinism of the build process, and it fails, what is a good approach for comparing the differences? It seems that "--keep-failed" does not preserve the "good builds", only the final build that demonstrates the non-determinism.
<lfam>Right, the "good" build is, of course, in the store.
<lfam>Okay, that image has package definitions from the 0.9.0 release in November. It's possible that the substitute servers no longer have some of the substitutes from then. `guix pull` is analogous to `apt-get update` and will update your package definitions to the current version. It's a good idea to do it before you initialize a new system. I don't know if this is related to your error or not.
<efraim>"They" ran the garbage-collector on hydra yesterday before merging core-updates, so its likely the 0.9.0 substitutes were scrubbed
<lfam>Normally you would not need to build cmake. However, even if substitutes are no longer available, Guix will transparently build the software from source. Although that could result in errors if some upstream software project moved their old source code.
<efraim>we had this issue with the 0.8.3 substitutes also, but I don't remember if they instituted anything to prevent it from happening
<lfam>I guess it won't be necessary to garbage collect the previous release when we have more storage for the substitutes servers
<lfam>Once we have the hardware it would be good to keep the substitutes for the GuixSD USB installer and the binary Guix installer until the next version is released and built..
<lfam>kristofer: Also note that the Guix in 0.9.0 has a much slower `guix pull` than currently. So the next time will be faster ;)
<kristofer>is using --fallback ideal when the substitute server is slow?
<rekado>kristofer: only if you want to build things on your own.
<rekado>I don't recommend it, unless you have a small package that you know you can build in less time than it would take to wait for the substitute server.
***tschwing_ is now known as tschwinge
<divansantana>Guix looks really awesome. Would like to try it out. Though, as the docs state, it's missing many packages. virt-manager would be nice, to allow for easy running on VMs on there. Hopefully that's coming soon.
<NiAsterisk>hi! I've just read old issues I posted on github, seems like the bitmessage (the developer prerelease fork or whatever, works like the older version) developer now will work at some point on a setup.py, so I think why work on pybitmessage when I can just wait until they drop the setup.py themselves into their git
<NiAsterisk>an offtopic question.. how's public transporation on saturdays in brussel? I don't know if collecting all the possible busschedules right now is too verbose.. I almost *guess* that it's easy to get to bruxelles-nord from ULB, it's a big city
<mark_weaver>kristofer: when using GPT, you need a bios boot partition. I don't have time to explain the details, but they can be found easily enough on the web. if you don't want to deal with this, just use MBR
<myglc2>running ~ bare-bones.scm I don't have 'ssh', how do I enable it?
<davexunit>we mean it when we say bare-bones. it's a config for you to add to, not use as-is.
<davexunit>define* has the really nice property of evaluating the default argument forms
<davexunit>so every call to 'make-foo' is actually inheriting values.
<davexunit>if you don't specify #:inherit, it inherits from an object made of all the defaults.
<davexunit>in other news, I was finaly able to build the Aseprite pixel art editor. :)
<alezost>davexunit: I was thinking "What to choose: to use (guix records) in my script, or to write srfi-9's record and a keyword constructor?" Now I'll take your solution as it's really simple, thanks for sharing!
<NiAsterisk>good night. see (some of you) at fosdem tomorrow o/
<alezost>sneek: later tell civodul ahem, something went wrong with renaming: I've just tried to boot a system (on commit 171a0a1) and got "kernel panic". The same system on commit 6d97319 boots successfully. I don't even know whether the problem in shepherd itself or I introduced a bug to guix source :-(
<davexunit>mark_weaver: is it okay to add licenses that aren't explicitly on the FSF's list of approved licenses. The Allegro 4 library (which is in Debian, others) uses a custom license they call the "giftware" license: http://liballeg.org/license.html
<davexunit>it's similar to an expat-style license, but with some different text.
<lfam>Jhonny: You can install the Guix package manager on another GNU / Linux distro. The full system, GuixSD, can be tested in a QEMU emulator, using images created by Guix. There is also the GuixSD live USB installer image, but that is just an installer image and not a whole lot of fun.
<kristofer>that would require some hardware modification
<mark_weaver>someone recently installed GuixSD with full disk encryption on a MacBook 2,1 running Libreboot. but I have no experience with refind issues, and also I have to go now... maybe someone else can help.