<Gxsdnewb>I think i figured out why my fresh install could not decrypt itself at boot: no cryptsetup was installed!
<Gxsdnewb>also, after a fresh install, a guix package -i emacs as root downloads the emacs substitute and dependencies
<Gxsdnewb>but the same guix package command as nonroot user wants to bootstrap the entire toolchain by compiling gcc, glibc, etc
<Gxsdnewb>Is this something to do with tools missing from this users' profile?
<Gxsdnewb>what is rthe recommended way to refresh a user's profile to access all binaries of packages on the system?
<Gxsdnewb>and most importantly: how should i go about installing cryptsetup onto the guixsd install that cant decrypt itself? i can just copy the package output dir from another imstall or usb, but how would the kernel+initrd lknow where to find the cryptsetup binary?
<lfam>warning from `guix lint`: luasocket-3.0-rc1: the source file name should contain the package name
<lfam>I agree. But is this a purely stylistic warning or should I do something about it? I could ask upstream to change the tarball filename but it's not a priority for me.
<karhunguixi>Gxsdnewb, you didn't encrypt your partition in the installer?
<karhunguixi>Gxsdnewb, i would have just reinstalled. There obviously could be niftier ways, but i don't know them.
<Gxsdnewb>karhunguixi, i encrypted it manually with cryptsetup luksFormat in the live usbenv, then mounted and ran guix system init on a config.scm with appropriate mapped-devices settings
<fps>hmm, for some reason the xserver chooses a resolution higher than what qemu-kvm seems to be able to deliver. so i got this "workspace bigger than physical screen thing" which people thought was a good idea somewhere in the 80s
<fps>note to other qemu-kvm users: use -vga qxl to get larger console on ttys and not get this thing from the 80s :)
<toothbrush0>I have a weird thing going on after compiling guix from core-updates. The first operation i try (`./pre-inst-env guix package -r ghc` in this case) wants to download (and build) a whole bunch of things, including the curiously-named "/gnu/store/hg3692jqq4jmhg4qx8d7y67fspimy898-?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0".
<toothbrush0>it fails on the download, with a 410 Gone. Does anyone know if this is correct behaviour?
<taylan>that sounds like a case where a 'file-name' entry is missing in the source description, though it should still work.
<taylan>yeah, grepped the latter hash, it's the source for some patch in the coreutils recipe in gnu/packages/base.scm
<taylan>it has a file-name though. maybe fixed in master but not core-updates, dunno
<toothbrush0>i guess i'd have to do --no-substitutes to get around it?
<toothbrush0>but that's going to cause an already insanely large list of packages to build to become twice as long...
<civodul>toothbrush0: the thing curiously named is a git commit i suppose, in an origin lacking a 'file-name'
<civodul>i see it in coreutils but it does have a file name
<toothbrush0>so i'm trying to use --no-substitutes to get it to download the patch directly, at which point i'll go back to substituting, but murphy's law is that now of course it's not building coreutils, the package needing the patch
<Gxsdnewb>how should i go about installing cryptsetup onto a guixsd install that cant decrypt itself at boot? i can just copy the package output dir from another imstall or usb, but how would the kernel+initrd lknow where to find the cryptsetup binary?
<arianvp>but I also keep the code in version control
<xd1le>arianvp: yes exactly, declarative configuration is great
<fps>if i ever need to refer to it again -> it won't make it into the manual anyways ;)
<fps>arianvp: btw: did you research loading the firmware blob for your wireless further?
<Gxsdnewb>because if i dont understand the problem, it may not go away. and knowing how to install packages into a mounted chroot of another install seems useful and i should know how to do this if possible.
<toothbrush0>although maybe the "selling points" of Guix aren't clear enough? i don't know, i'm too invested to be able to judge that.
<toothbrush0>and yeah, i guess aesthetics are down to personal taste, so w/e
<Gxsdnewb>civodul: is there a way to keep all of this data without just copying it from the cow-store to another dir to prevent autodeletion? it seems gc-keep-outputs only saves .drv files whichis not everything
<civodul>toothbrush0: i don't know, i'd say freedom + transactions + APIs differentiates it from both Debian and NixOS, but then i'm biased
<civodul>Gxsdnewb: cow-store is only for the installation image
<civodul>Gxsdnewb: are you done installating GuixSD?
<Gxsdnewb>civodul: i have guixsd installed to encrypted luks, but decryption completely fails so i installed a second guixsd to unncrypted partition to debug it and discovered that cryptsetup was never installed! Now i am not sure how to install cryptsetup from a secondary install (can i chroot and guix package -i)??
<davexunit>calling it a "wrapper" is doing the project a disservice.
<toothbrush0>i am too, but i'm not confident i can explain exactly what's compatible and what's not
<davexunit>it's a "wrapper" in the sense that we put a different interface on the low-level tools.
<rekado>with the screenshots, the differntly coloured buttons (blue "TEST", violet "CONTRIBUTE", orange "Help us improve Guix", red "Report"), and the four different backgrounds (blue, graphite, gray, white, light gray) the Guix website is no longer as clear as it felt on the mockups --- I think it would be nice if it were simplified a little.
<toothbrush0>we're the smug sandal-wearing vegetarian cousin, or something like that? :P
<eiz>The bullet points are interesting facts, but they don't really explicitly say "here's why you should care about this." What's better about using Guile instead of nix? As a 100% newcomer, I'd heard of both, but I don't have enough experience to compare them.
<xd1le>rekado: wow, that is an amazing poster, nice work. :D
<xd1le>but yes, as eiz says, all these points work for nix too i think.
<Gxsdnewb>karhunguixi: does your working luks setup have an uncommented initrd section? i looked at your scm and saw all mention to initrd commented out
<taylan>asking for opinions again: mupen64plus seems unreasonably difficult to get working out of the box on guix ('guix package -i' and run command), needing a bit of user configuration first instead. is there a place I can document the needed configuration to make this situation acceptable?
<davexunit>taylan: is it just setting env vars or more?
<taylan>the emulator community seems a bit weird in their programming practices. probably more Windows oriented. they all don't use any ./configure scripts either (seen in Nestopia, higan, and Mupen64Plus so far)
<Gxsdnewb>taylor: is it also not an ethical issue that these applications are almost exclusively used for running nonlibre software?
<Gxsdnewb>karhunguixi|w: and when you booted, it asked for decryption pw and loaded everything without error? what cipher and mode are you using?
<taylan>well I hope that won't be a blocker. we also have MS-DOS emulators though.
<civodul>kmicu: a Hydra "replacement" would be nice, but in the longer term; 'guix publish' provides part of the needed functionality, that's a start ;-)
<Gxsdnewb>taylor: DOSBox can run FreeDOS. But yes, technically a FLOSS emulator of a closed hardware platform can be used to develop and execute libre code on said platform, so they should be allowed
<Gxsdnewb>rekado: how can i examine if a specific initrd file has support for specific crypto algorithms i chose (or support for cryptsetup at all)?
<taylan>civodul: it's a mix of our isolation of packages and their lack of support for search paths of multiple directories
<Gxsdnewb>i have an encrypted guixsd install that can not boot because the initrd does not have the right modules, and there is also no cryptsetup installed. so i installed guixsd a 2nd time unencrypted and mounted the 1st install at /mnt
<Gxsdnewb>civodul: i noticed that a default desktop install does not install cryptsetup or gpg which i think is a big mistake
<taylan>hmm, maybe I can do something involving propagated inputs and patching the default (generated) config file, though said config file will need to contain an absolute file name in the user's $HOME...
<civodul>Gxsdnewb: these are things i install in my profile, with 'guix package -i'
<civodul>but you can add them to the 'packages' field if you prefer
<wingo>i tried to run brasero but it traps immediately, claiming it can't find its gsettings schema
<rekado>Gxsdnewb: You can think of /gnu/store as a cache for builds. The base system doesn't require gpg nor cryptsetup. What exactly will be built/installed depends on the configuration. This is very flexible.
<toothbrush0>civodul: i think that it's perl that it's failing on.
<rekado>toothbrush0: please use a different paste site, such as paste.lisp.org.
<toothbrush0>rekado: i actually tried that one first, but it rejected it for being too big
<wingo>isn't the point of the glib-or-gtk-build-system to wrap the program and set them?
<taylan>hm, the user might install mupen somewhere else than $HOME/.guix-profile, so I see no way to patch the code such that it will generate a config file pointing to the right place (path of the profile the package will be installed to)
<rekado>toothbrush0: they say they are not actively blocking TOR, but any IP "that is causing way too much suspicious browsing behavior"; they don't say what "suspicious browsing behavior" is and TOR users often cannot use pastebin at all.
<wingo>civodul: actually in my case XDG_DATA_DIRS and XDG_CONFIG_DIRS point to nix things
<Gxsdnewb>hmm, well i think we should make a template file based on desktop.scm that includes luks support for nonlibre bios systems (needs separate unencrypted /boot) and a specific scm for libreboot systems
<taylan>so I added a little guix-specific patch to the mupen64plus-ui-console package which makes it print a big flashy notice with instructions for guix users when it fails to find plugins. this should be good enough I think.
<lfam>I am working on a package that some tests, but they have to run manually on the command line because they do not have a target in the Makefile? For example, after building I have to `cd tests && ./test`. Are there any packages I can look to as an example of how to use these tests?
<lfam>*I am working on a package that has some tests
<lfam>Sorry, that message made no sense. I will try again
<rekado>lfam: you can just replace the 'check phase and run them with (zero? (system* "./test"))
<lfam>rekado: Thanks for understanding my pre-coffee gibberish
<avoine>Is there is a way to I get my patched guix to be in the guix environment I'm building with it?
<avoine>ACTION is still trying to get btrfs file system to work
<paroneayea>davexunit: would love to know if it proves useful to you
<lfam>I'm packaging a bunch of Lua libraries that work with different versions of Lua. What about the case where the program loading the library needs a specific version of Lua? While the program has the correct Lua in its environment, how to make sure that the library gets loaded by the correct Lua version? I'm afraid I don't understand how all these pieces come together.
<paroneayea>lfam: oh, lua's specific path stuff is beyond my knowledge so I can't say
<lfam>paroneayea: Hi! It is currently beyond my knowledge as well. I am going to just build the libraries against the specific Lua version for now, and try to make them more flexible later. I guess I could adopt the Guix-Python convention of "python-program" "python2-program".
<Gxsdnewb>civodul: thank you for the command to examine initrd, i was able to find which kernel modules i am missing
<Gxsdnewb>I am not sure this is the correct syntax for my modified .scm for adding linux kernel modules. can someone familiar with Scheme syntax proofread it?
<Gxsdnewb>I am also unsure how much the order matters within the (operating-system) function, for example should the initrd section be before the mapped-devices and file-systems sections, or does that not matter?
<alezost>sneek: later tell Gxsdnewb in your system config you messed up the parentheses again: remove the closing one after "(apply base-initrd fs"