<troydm>hey all! I'm trying to install guixsd on virtualbox machine, I've booted livecd made config.scm and doing guix system init /mnt/etc/config.scm /mnt however after that it tries to download files into / of livecd apparently instead of /mnt as I keep getting No disk space left on /
<vagrantc>there's some sort of cow-mount feature you need to enable to make the /gnu/store write to the installed filesystem
<vagrantc>it's documented in the guix installation manual stuff
<rekado>has someone here built a kernel with a different configuration file?
<rekado>I’d like to build linux-libre with the purism kernel config and see if that’s any better.
<rekado>the PureOS kernel conf is way shorter than ours. Is there a reason why so many settings are explicit in our kernel conf?
<efraim1>I'm fighting with the arm64 kernel config right now, right now I've started with Armbian's kernel for the pine64 and can't get ahci.ko
<rekado>efraim1: in building a custom kernel do you edit the included config file or start from a known good config from another system?
<rekado>I wonder if there are special kernel config settings that *must* be there to make GuixSD work.
<rekado>guess I answered my question: the build fails.
<efraim>rekado: I started with an assumed good kernel config from Armbian and then edited it to add ahci.ko and other bits we needed, I might go with my other attempt which was 'modules for all the things'
<cbaines>rekado, I've got a Librem 13 as well, and I'm running GuixSD on it. We can compare problems if that would help?
<efraim>I know that one produces everything needed but it takes 4x as long to build
<cbaines>I think I remember reading you're having issues with the backlight, but that seems to work fine for me?
<efraim>I tried starting from Debian's but I couldn't figure out their split config system
<pch>but I am looking more into handling run time dependencies, where package creator specifies its dependencies and if the actual installed version is not the same, then the installation atleast fails, or downloads it eventually
<cbaines>pch, could you give a concrete/specific example?
<pch>cbaines: i want to use guix for our software development where we want to deploy different applications (guix package) on the production platform and it could be that an application has a strict dependency on version of any other application.
<cbaines>If you have guix packages for applications, each package will be for a specific version. If you want to use multiple versions of a bit of software, then you'll want to keep around multiple packages.
<cbaines>When declaring the inputs (dependencies), if you pick the packages you want (with the versions you want) then it should be ok
<cbaines>pch, this is a bit of a mental shift from other systems like Debian, where you have constraints which are solved at installation time
<cbaines>that's not how the guix tooling currently works
<pch>No, having or managing multiple versions is not the intention. The deployed system should have one and only one application version installed but I just want that at-least i can produce an installation failure if there is a version mismatch
<cbaines>pch, ok, perhaps look at the problem from a different angle. Just take two of your applications, how does one find the other when it needs to? Does it use a environment variable, some configuration, an absolute path, ...?
<pch>I implemented the same with another package manager (OPKG) which maintains the information about which package is installed with which version
<pch>and you can specify installation dependencies during package build like "DEPENDS "xxx-pkg(>=3.1.3)"
<cbaines>What I'm trying to get at is that Guix packages don't contain the version constraints for their dependencies. Rather than doing analysis of the constraints at package installation time, with Guix, your better off structuring the packages so that they always use the dependencies you intend
<pch>so that means GUIX does not track package versions?
<cbaines>So, instead of failing when a dependency is used at an invalid version, build your packages so that they only ever use the dependencies they are built with
<cbaines>pch, it does have that information, version is one of the fields in the package record
<cbaines>and the inputs (native-inputs, inputs or propagate-inputs) just have the version information as well, but there isn't any way I've seen to record constraints (e.g. A => 1.3) in the package record
<pch>yes, i could not find it too, thats why i started with that
<cbaines>My suggestion would be to focus on making version mismatches impossible by building packages in a rigerous way
<cbaines>This is how many of the packages contained in the guix repository are built
<pch>there is a package version field, what is it actually used for?
<cbaines>The main pattern is using absolute paths for referencing dependencies
<cbaines>So if you have some software that needs to run guile say for some reason, you could run guile from the $PATH, but this might be different, so you can hardcode the full path /gnu/store/fn930...-guile-2.2.3/bin/guile in to your package, and then you'll always use exactly that guile
<cbaines>The tooling that supports this is the store, package definitions, and more ...
<pch>So, this would implicitly mean (for me) maintaining different version of the same package on the system
<atw>pch: you might find this helpful: https://research.swtch.com/version-sat. It contains four traditional assumptions about package management, including "4. Two different versions of a package cannot be installed simultaneously." Guix does away with this assumption :)
<ngz>Hello. I'm trying to build a Python library, but run into an error: "OSError: Could not locate nacl lib, searched for libsodium.so, libsodium.so.23, ...". However libsodium belongs to propagated inputs (as it is the rule in the Python world, IIUC). Does that ring a bell?
<rekado>on this laptop my configuration just assumes a BIOS, but grub-install errors out trying to find modinfo.sh
<efraim>ng0: mine often hangs at python2-efl, I set the timeout to 1800
<civodul>rekado: you should check how it looks for .so files
<rekado>rebooting is painful, because you lose the progress of “guix pull”. It would be great if we could more easily use a later version of Guix from the target disk.
<rekado>it also seems impossible to properly stop the cow-store service. I haven’t been able to unmount the luks container because of that.
<efraim1>I think it'd be nice for `guix pull' to basically 'make clean; git pull' and then with some combination of nice and ionice do the compiling
<ng0>I made the observation a very long time back that chroot into half-finishied, partly broken installations is essentially impossible.. half-way possible, but should be explored more if we could even do that
<efraim1>whoops, 'mcron -d' spiked my CPU usage to 51 and led to a kernel panic
<efraim1>maybe in the future it should be 'nice mcron -d'
<ng0>I mean ofc the issue with chroot is by design, but to make use of chroot or document steps how to would create a bridge for people used to chroot working
<efraim1>cleaning up arm-trusted-firmware isn't going to be fun :/
<ng0>did anyone every experience emacs freezing over ispell starting?
<ngz>ng0: I do, particularly when opening tex documents.
<ngz>BTW, I'm trying to build a Python library, but run into an error: "OSError: Could not locate nacl lib, searched for libsodium.so, libsodium.so.23, ...". However libsodium belongs to propagated inputs (as it is the rule in the Python world, IIUC). Does that ring a bell to anyone?
<ng0>someone once upon a time posted 2 pakage count scripts.. the second one says:
<ng0>what does mcron need to run a file that executes a curl command successfully? could figure it out myself, but some quikc pointers why the cert verification fails even with environment variables exported would be nice
<amz3>nobody wants to drink something in bruxelles after 21:00?
<ng0>so on the spirit of quick examples and me being in the process of writing job applications.. how do you insert the secret? my self constructed problem is that my old set of configs is public, while the new set of configs is still a template based prototype.. so the shell file was my way around this.
<ngz>I'm trying to build a Python library, but run into an error: "OSError: Could not locate nacl lib, searched for libsodium.so, libsodium.so.23, ...". However libsodium belongs to propagated inputs (as it is the rule in the Python world, IIUC). Any idea on how I could debug this?
<civodul>hey ngz, i thought i had replied, but no :-)
<civodul>ngz: can you chekc how that python lib looks for libsodium.so?
<civodul>i suspect it does that by walking $LD_LIBRARY_PATH or $LIBRARY_PATH, or maybe just /usr/lib & co.
<ngz>civodul: The last message is File "/gnu/store/pav9c00s4m9g35cylpiy9zv54vwk37q2-python-libnacl-1.6.1/lib/python3.5/site-packages/libnacl/__init__.py", line 81, in _get_nacl, raise OSError(mesg)... then the error.
<ngz>So I assume this comes from libnacl, which cannot find libsodium. Yet, libnacl (which I had to package along the way), has libsodium as a propagated input.
<lfam>civodul: I think there are a handful of broken packages, but I expect those to get fixed soon after we merge core-updates into master :) But <https://bugs.gnu.org/30298> should be fixed first
<civodul>right, but having libsodium has a propagated input doesn't necessarily help
<lfam>Basically, the guix-daemon is broken on foreign distros, AFAICT
<ngz>Interestingly, libnacl builds without tests, but fails to build, with the same error, if I activate tests.
<ng0>apteryx_: I guess I also have to (use-modules (whereever gnutls went))? because even with gnutls in global profile I get errors about (gnutls) modules not being available
<lfam>Off-topic... all the dinner planning messages are making me very jealous! And hungry ;)
<apteryx_>ng0: nope, the job as shown is complete except for the secret variable.
<ngz>civodul: In libnacl, there is a _get_nacl() function that tries to locate libsodium. Basically, it first tries ctypes.cdll.LoadLibrary('libsodium.so'), then ctypes.cdll.LoadLibrary('/usr/local/lib/libsodium.so') ...