<kqb>Hello, I have a machine-global guix setup. When I run "$guix pull" and "#guix pull" ("#" is the root shell and "$" is a user-shell) it pulls the image *twice*. Please give me a documentation reference of how I get guix to only pull this *once*.
<mark_weaver>paroneayea: set the 'recursive?' field of the git-reference record, and then git-fetch will fetch the submodules
<rekado>"emacs rocks" just demonstrates one really cool feature in a really short video.
<mark_weaver>kqb: anyway, I don't think it's a daemon issue. it probably has something to do with the way that "guix pull" works, but I've never learned much about that since I never use 'guix pull' and think that using git is a far superior method
<rekado>we could have a video for one of the uses of "guix environment"
<rekado>then another for "guix package --roll-back"
<mark_weaver>codemac: choose an older version of the system from the GRUB menu
<codemac>I'm not on guixsd :( but I think i'll have something figured out soon :)
<Jookia>Woo, cleaning up and documenting a patch series for Guix :D
<Jookia>Uh-oh it seems I can't include 'gnu system grub' in the build directory
<Jookia>mark_weaver: Would you happen to know why include 'guix packages grub' in gnu/build/install.scm causes guix to say "guix: system: command not found Try `guix --help' for more information.", or why it finds no code for 'gnu system grub'? I have a feeling this is to do with build isolation
<mark_weaver>Jookia: the module name is (gnu packages grub), starting with 'gnu' not 'guix'
<Jookia>mark_weaver: (gnu packages grub) gives this error: "no code for module (gnu packages grub)"
<mark_weaver>and data that is passed from the client side to the build side ends up being serialized in the inputs to the derivation
<Jookia>Instead of passing grub-configuration would it be better to have a grub-build-config that reads that? This seems perhaps a bit overkill though having an intermediate format
<Jookia>I'm coming at this from two angles: Changing/adding things to be used when install-grub is run, and also down the line being able to replace install-grub and grub-configuration with install-uboot and uboot-configuration, for example.
<Jookia>Though thinking more about it, it may be a better idea down the track in my hypothetical land to not have multiple -configuration but instead use grub-configuration (or renamed to boot-configuration) for u-boot and have some install-specific flags
<mark_weaver>Jookia: if we want to pass down a composite, extensive object, it should probably be either an association list (i.e. a list of key-value pairs) or a keyword list, similar to 'arguments' in packages.
<mark_weaver>well, you can ask civodul, and admittedly this is an area where my knowledge of guix is not strong, but although civodul is reasonably fond of using records for things, I notice that he has not so far used records for passing data between the client side and build side, and I guess he has a reason for that.
<mark_weaver>one complication is that Guile's reader cannot read records as data.
<mark_weaver>the main difficulty is that at read time we don't know the set of record definitions.
<mark_weaver>the reader needs to be able to do its job without knowledge of the set of bindings or record types, etc.
<mark_weaver>on the other hand, we could generate an expression that, when run, calls the record constructor to create the record.
<Jookia>I see. So with a composite object, is it possible to define it's schema or a constructor, similiar to a record? I assume it'd just be a function, yes? Then I could put that in the build-side code which the host-side code can read, then in the host-side make a grub-configuration -> that-record and pass it
<mark_weaver>I'm sorry, I don't have time to think about this more right now. Please ask civodul.
<mark_weaver>partly it's that I know that civodul already went over thinking about these issues when he wrote core guix, and can probably answer your questions much more efficiently, whereas I would need to think it through myself.
<lfam>yvm: GuixSD uses the linux-libre kernel, which is based in linux but removes all the non-free parts, many of which are drivers. If your video card can work with free software, then it should be possible to make full use of it in GuixSD.
<davexunit>we can use the XPRA X11 bridge to do things like run IceCat in a container (via call-with-container, of course) and only share particular pieces of the file system with it.
<davexunit>isn't it a little worriesome that your web browser *could* read your ssh/gpg keys or anything else in your home directory?
<taylan>it most certainly is, perhaps more than a little :P
<NiAsterisk>hi! just a quick question before I leave for the hackerspace for flashing (no equipment here at my home yet) libreboot, I read about some virtualization issues o gm45 hardware with libreboot, is qemu | kvm somehow involved and/or required with one of guix environment subcommands?
<davexunit>NiAsterisk: I think the issue is that we currently hardcode the kvm stuff into our qemu VM stuff, but someone has proposed to make it optional.
<davexunit>and AFAIK, librebooted intel laptops have no hardware virtualization support due to lack of microcode
<NiAsterisk>oh wait a sec. right. I bought one of the last intel CPU generations without it :D
<mark_weaver>The Libreboot X60 and T60 has virtualization support
<mark_weaver>on the Libreboot X200, T400 and similar, the problem is buggy microcode in the CPU, iiuc.
<davexunit>cool, but I swear I read in here that at least one model doesn't work.
<mark_weaver>the cow-store puts something on /mnt, and it might be bad to blow that part away
<mark_weaver>or at least it would probably require rebooting the USB installer
<rekado>finally got around to setting up guix over network for the cluster users.
<rekado>one comment says: "this is exciting like the first time I discovered `sudo apt-get install`"
<rekado>(after that user tried installing as a user and --roll-back)
<rekado>I'm going to polish this a little and then write about it.
<rekado>I would actually like this to be part of Guix.
<rekado>right now it's a wrapper that starts socat for socket redirection over TCP, tells guix to use that socket, and then runs guix, and cleans up after itself (to be sure that no stale sockets remain and no socat processes keep running)
<alezost>rekado: oh great! ISTR you faced some big problem on this "guix over network" way
<rekado>yeah, for a long time IT didn't mount the profiles read-writeable, so I couldn't do anything.
<rekado>we're still having a lot of trouble with the network, and performance over NFS is still abysmal, but with a switch upgrade next week this *might* change.
<rekado>profiles with many files take a very long time to be upgraded.
<rekado>having libreoffice installed in a profile is enough to slow down building the next generation of the profile considerably
<paroneayea>interesting that showing others helps us see problems that we can overlook when it's just us...
<pecg>mark_weaver: in order to make /dev/sda1 for /boot, config.scm needs to have filesystem definition in (file-systems (cons )), am I right?
<pecg>so the file-systems symbol can get a list (constructed list, thus cons) that has the definition for the encrypted root and the unencrypted boot
<pecg>are these systems the same ones that are mounted during boot?
<pecg>The same ones I used to put on /etc/fstab, when using other distributions?
<pecg>Maybe I wrong, but I'm almost certain that (file-systems) is a function that takes a list argument used to (among other things) generate /etc/fstab, tell GRUB what filesystems to look after, and so on
<pecg>or am I over thinking and over analyzing everything?
<mark_weaver>pecg: it's true that 'file-systems' takes a list argument.
<mark_weaver>however, 'file-systems' is not a procedure, but rather is a field of the 'operating-system' record that you're constructing.
<yvm>Is there a howto how to build custom kernel in GuixSD?
<mark_weaver>it should be (file-systems (cons* (file-system ...) (file-system ...) %base-file-systems))
<mark_weaver>yvm: no howto, but just add a package definition for your kernel and specify it via the 'kernel' field of the 'operating-system'
<yvm>Got it. Thanks. I think I just need to read manual more.
<pecg>mark_weaver: Great, I have it, just like that
<fhmgufs>Back to my question: Maybe you didn't understand what I mean: I would like GuixSD to manage everything starting from PID 1 to the user interface but not the things below (firmware, bootloader, kernel).
<fhmgufs>And by the way: How can I find out, how much packages depend on a package?
<lfam>fhmgufs: `guix refresh -l` should tell you. If the package is only in your local source tree (for example, if you are working on a new package or are changing an existing package), then `./pre-inst-env guix refresh -l`
<mark_weaver>however, it might be better to instead use a wrapper around the program that sets that variable.
<lfam>This is somewhat off-topic, but the merging of all those store directories into the resulting profile makes me think of The Aleph by Borges.
<lfam>"In Borges' story, the Aleph is a point in space that contains all other points. Anyone who gazes into it can see everything in the universe from every angle simultaneously, without distortion, overlapping or confusion."
<pizzaiolo>has the 'deco' command already been renamed to 'herd'?
<janneke>mark_weaver: if I do that '("."), it becomes a huge path
<lfam>pizzaiolo: Yes, of course for you it depends on whether or not you've updated your system since the change
<mark_weaver>janneke: if it's just a small number of programs that need to be told their HOME location, then maybe use 'wrap-program' within a custom phase, to create wrapper shell scripts for each of those programs that runs the real program with FOO_HOME set appropriately