<thomassgn>um, is ̈́'guix system vm config.scm' supposed to launch the vm right away?
<ryanprior>I heard that a lot of packages in npm archives can't really be imported into Guix because they aren't bootstrappable. Is there a longform discussion of that issue somewhere? Related, has there been any similar effort to look into packaging ruby gems in Guix?
<ngz>ryanprior: ruby gems are already packages in Guix. There's even an importer for that.
<ngz>ryanprior: I don't think the issue is npm archives are not bootstrappable, but because they contain cycles and infamous numbers of dependencies, IIRC.
<ryanprior>Are cycles impossible to handle in Guix? Is there a technical limitation on how many dependencies we can support?
<thomassgn>ryanprior: I guess the problem is when you pull in a complete dependency graph, like we do in guix, having these enormous amounts of dependencies that have each other as dependencies of one another things get messy very fast. I haven't really looked into the matter, but that is the gist I get from what little I've seen in mail list and similar. We can deal with some cyclical things, to a certain level, and I'm
<thomassgn>not sure how much of a hack the solutions have been... Am I making sense or did I fall of my own train here somewhere... :P
<bandrami>Smalltalk is failing on libsigsegv only being static. Is the guix-y way to fix that to tell smalltalk to use its internal sigsegv, or to tell sigsegv to build dynamic libraries?
<thomassgn>I would think to make it dynamic. It (sigsegv) would be pulled in exactly one time per req. and be linked against dynamically that way.
<bandrami>That makes sense to me too. And this seems like a good excuse to figure out how to edit a guix package and make a patch.
<thomassgn>yes. say so if you want some pointers. I'm not gonna be online all night, but for a little while
<bandrami>Thanks, I usually learn best by failing for about 12 hours straight and then finally reading the documentation (Debian refugee here). This seems like a *really* cool workflow, just kind of alien to what I'm used to.
<thomassgn>hehe, good luck. I'd recommend checking out 'guix environment' and it's --ad-hoc. super usefull if you're hacking around. Also 'guix edit packagename'. (and remember to export/set/add-to $GUIX_PACKAGE_PATH) Happy hacking
<vagrantcish>i really wish there was a simpler way to revert guix-latest, rather than picking a random version and hoping that will be running ok
<vagrantcish>if it maintained a few symlinks in ~/.config/guix/ beyond simply latest...
<reepca>sneek: later tell uniq10: Currently it just builds derivations, and only manually. See build-derivation in (guix store build-derivations). Note that while it does automatically build any inputs that haven't been built yet, it only does so one at a time - that's something that needs improving. The raw "all inputs exist, unconditionally build this derivation, don't try substituting, using builtins, etc" procedure is do-derivation-build.
<castilma>hey, I want to switch from slim to sddm. i have a different xorg-configuration which I used to pass to (slim-configuration (startx %my-startx)). but now I'm not sure, which field in the sddm-configuration I need to set.
<mbakke>efraim: The problem with mupdf is that each executable embeds a large font collection (noto).
<vagrantcish>well, i *think* i figured out why the gnuk openpgp smartcard isn't working ... gnupg/scdaemon appears to be built without libusb
<efraim>oooh! as of 0.22.2 enlightenment uses e_ckpasswd for all platforms for checking passwords, i'll read a bit and see if I should just tag it setuid (like the install scripts) or mark it as a screen lock program
<efraim>checking for libusb_init in -lusb-1.0... no
<vagrantcish>are the build logs of the substitute servers available somewhere?
<vagrantcish>looks like gnupg looks for libusb include files in various directories in /usr/
<vagrantcish>so, do i need to patch the configure script before running it somehow?
<ng0>I am trying to track down an issue that appeared in my repositories a while back. After reading some of Guix' code, I now have a question about how module imports can affect each other. The situation is like this: (pkgs sys-kernel linux linux) used to be almost just like (gnu packages linux), worked just fine. Then I started moving pieces out, into (pkgs sys-kernel linux) -> the make-linux and everything else;
<ng0>(pkg sys-kernel linux linux) -> for the linux package definitions; and (pkgs sys-kernel linux-headers linux-headers) <- for the headers. linux-headers imports (pkg sys-kernel linux) as well as (pkgs sys-kernel linux linux). (pks sys-kernel linux linux) imports (pkgs sys-kernel linux).. so Inow have a hunch after going through every possible source of error that there's an issue with imports.
<ng0>understand that I'm not asking for the kernel support, I have that covered quiet alright for myself, just the general "how are such imports handled?" question
<ng0>are there delay option? I guess select wouldn't be enough
<amz3>ng0: did you encounter a cyclic import or something
<ng0>I reduced the modules to 1, (define-module (pkgs sys-process numactl numactl) ... the weird thing is that the other repositories (ports), (ports-wip) etc have a similar naming scheme. yet pkgs only worked when the it was like this: (define-module (sys-process numactl numactl) which is what I had before
<ng0>with ports having the same structure, I can't even say it's due to the length
<ng0>is there some special meaning in guile that is already reserved with "pkgs"?
<ng0>I used to have similar issues when a "0" was in one of my module names