<kirisime>How do I move the store to a different partition without breaking anything?
<grumbel>kirisime: On GuixSD or on another Linux distribution?
<nckx>rndd: You can use patchelf to patch the interpreter, patchelf or (maybe) LD_LIBRARY_PATH to find shared libraries (ldd is provided by the glibc package), or possibly experimental things like https://miha.info/guix-fhs-service/
<grumbel>kirisime: Just shutdown the guix daemon, move the files over to a new partition and add it to the fstab, mount and restart the daemon should do it. As long as you don't have anything early in the boot process that depends on /gnu being there that should do it
<nckx>sturm: OK, I'll wait ;-) Do you know how it works? If it just writes jobs for cron it probably won't work out of the box, which would be why it isn't packaged. Maybe a new Scheme/mcron at would be better.
<kirisime>fps: Typical shells don't actually search through everything in $PATH to find executables every time you run one, they have caches for it. Running hash is how your shell finds out guix is actually in a different store path now because it's a new version.
<kirisime>Guix might bring up some edge case that actually requires a rehash, because it's the only program I can think of that I've actually ever needed to rehash. If not for it I wouldn't know the functionality existed.
<vixus>nckx: ah didn't think about that. Is there any way to make it more user-friendly?
<nckx>vixus: You mean only prompting for the passphrase once? By embedding the LUKS key in the initramfs. Some other distributions apparently do this, but Guix doesn't have any code to handle that [yet].
<nckx>You can also manually copy the kernel + initrd (and GRUB modules, I forgot about those) to an unencrypted partition. That could reduce security, although probably not as much as you'd think. (As in: you're already vulnerable to the attacks it would invite.)
<nckx>Just the kernel/initrd (see grub.cfg for paths) for each entry you want to boot. How to name them and adjust the configuration are of course up to you. For GRUB, you'd need to manually invoke grub-install so that it copies & finds the modules in the right place.
<nckx>I'm just saying that it can be done, not whether or not it's worth your time.
<nckx>I just enabled auto-login to X to compensate for the 2 LUKS prompts 🙂
<vixus>To be honest I wouldn't really mind except the GRUB decrypt is really slow
<kirisime>vixus: You'll look back to saying that when you realize you've spent a week building kernels.
<kirisime>Kernel compilation is kind of painful on guix in comparison to other distros though, mostly because on other systems you just call make and the build system avoids recompiling things that were built previously.
<leoprikler>that only counts when you're modifying an already compiled kernel though
<nckx>And imply you're not using a package manager at all.
<leoprikler>you'd probably still have to do everything again when the config changes
<nckx>Does the Linux build system support that? It doesn't seem like their style.
<leoprikler>even if it did, since it's one config for everything, you'd have to build all the modules then
<vixus>When I install a system using the install image, does it use the kernel bundled with the install image or build a new one (assuming I need to build a kernel)?
<leoprikler>probably, but especially if you guix pull during install
<kmicu>Hi bdju: there’s no modern wifi/bt chips working without blobs and that’s the reason you couldn’t find anything about it.
<kirisime>vixus: The install image boots with a kernel in the store, you can look at the store path in GRUB. When you write your config.scm and run guix system init, if the definition of the kernel package you use is the same as the one the image boots with, then it'll just copy the kernel. If you've run guix pull before initializing, you might get a substituted kernel from ci.guix.gnu.org. If you've actually made a modification to the kernel
<kirisime>package you use, you'll need to build it yourself.
<Franciman>maybe I should produce a wrapper around the executable
<fishinthecalcula>To build Minecraft, Malmo relies on gradle 2.14 for which i packaged ( https://paste.debian.net/1113196/ ) the zip distributable and added it as a native input to Malmo. The build process seems to accept my zip but fails with the same message I was getting when I tried to run all of this from a python virtual env which is "Failed to load native library 'libnative-platform.so' for Linux amd64.". Here is the complete
<nckx>Franciman: Packages can only install into their own /gnu/store/…name-version[-output]/ directory. You'll have to manage the copying/linking to ~ (or elsewhere) yourself, for example by creating a profile and symlinks into it.
<Franciman>where can I find documentation about profile?
<Franciman>sorry but i couldn't find an explaination of this phase in the docs
<grumbel>I think I finally figured out my channels-not-working issue, I had the guix package installed and ~/.guix-profile/bin/guix ended in the $PATH before ~/.config/guix/current/bin/guix, so the channel changes never showed up
<nckx>grumbel: You should ‘guix remove guix’, Guix should never be ‘guix install’ed so ~/.guix-profile/bin/guix should never exist.
<raghavgururajan>In my current user profile, IceCat version is "icecat-68.2.0-guix0-preview3.x86_64-linux". How can I install IceCat version "icecat-60.9.0-guix1.x86_64-linux" in the same user profile?
<nckx>raghavgururajan: You can't install both, since they will conflict and this will either cause an error or pick one at random (I forget). You'll have to use multiple profiles, or install only one at a time (which will be very fast once both are in the store).
<Franciman>when do I want to use native-inputs over inputs?
<ngz>Hello. I noticed that mame consistently fails to build on Cuirass, but the log doesn't contain any error message (on x86_64) and the package itself builds fine locally. Could this be related to a time-out value ?
<puoxond>ngz: There's a similar issue with libreoffice: ~30 hours ago it failed on x86_64, i686, and aarch64. Same as with mame the log stops abruptly (no error message). The build succeeded locally on my x86_64 machine.
<puoxond>ngz: mame doesn't seem to fail consistently. If you search for 'mame system:x86_64-linux spec:guix-master', you'll see that it failed only once in the way you described (~30 hours ago) on x86_64.
<mange>Add a new line to the end of the file that just has "parinfer-rust" (without the quotes).
<slyfox>stack trace might be more instructive to look at
<mange>Guix will evaluate the file, taking the result of the last form as the thing that should be built. (define-public ...) doesn't return a useful value, but if you finish the file with your package variable then Guix can build it.