<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.