<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... <vagrantcish>that seems like a pretty straightforward feature request <pkill9>also i find running guix commands as my user when it doesn't have ~/.cofnig/guix/latest doesn't automatically use root's ~/.config/guix/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. ***Piece_Maker is now known as Acou_Bass
<efraim>was someone working on making mupdf smaller? <kmicu>Hi efraim. What is your expectation? Its closure smaller than 100MiB and output smaller than 30MiB? <efraim>i'm showing the output at 275 MB <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). <mbakke>It's fairly simple to prevent that, I just didn't bother until a bug report emerged :P <mbakke>Bah, nckx keeps stealing my commits! :P <civodul>hey mbakke, congrats on the 'staging' merge BTW! <civodul>i'm really grateful that you allow us to move forward <civodul>but i always find that the most difficult part is to keep an eye on it and hit the "merge" button when it's ready <civodul>there's no shortage of bugs these days! <civodul>i wish it would "solve itself" without any intervention <nckx>mbakke: Good. Revenge! I've thought the same about you many times. :-) <nckx>mbakke: Sooo deary me what's this file/xz core-updates-next thing. Was it not... the next core-updates? <mbakke>nckx: there was a loose discussion on guix-devel about including some updates that wouldn't rebuild the world. I sent a message about it just now. <mbakke>nckx: btw I have a discussion with Xathura upstream about fixing the plugindir. Also surprised you didn't have to edit the Zathura patch. <divansantana_>So running guixsd, new install! Hooray. On laptop. I notice fonts don't look right. Or similar to my arch setup. Not sure how else to explain. <mbakke>divansantana_: I have occasionally had to run `fc-cache -f` to make newly installed fonts available. <divansantana_>mbakke: hmm. Great! That fixed the monospace issue, it now uses dejavu and looks better. Will remove ~/.config/fontconfig/fonts.conf and see if it goes back to nimbus <divansantana_>mbakke: removed ~/.config/fontconfig/fonts.conf to undo my changes, ran fc-cache -f and rebooted. All is 100% working. Basically all I needed was to run fc-cache -f. Thank you! <mbakke>Is anyone bisecting the parted issue? <civodul>i'd like to investigate based on what we have <civodul>but if someone bisects in parallel, that'd help! <roptat>civodul: I need your help on terminology. How would you translate "store" in French? make it different than the translation of "repository" :p <civodul>i don't have a better idea, but i'll think about it <roptat>I don't like this, there's a sentence in the manual that says that the configure script in the "dépôt" makes sure you don't corrupt your "dépôt" <civodul>in that case, you could write "dépôt Git" and "dépôt Guix" when you need to disambiguate <roptat>but I'd be better to have a word that's clearly different <roptat>also, I'm having troubles translating "such as raising an s-expression or wrapping it, swallowing or rejecting the following s-expression" <roptat>I think I don't understand the concepts <civodul>i understand them, but i need to think about the translation <civodul>"relever une s-expression ou l'envelopper, absorber ou rejeter la s-expression suivante" <civodul>that still doesn't help someone who's never heard of Paredit i'm afraid <civodul>but that's probably not a language issue <civodul>BTW, does anyone have CUPS working with an HP LaserJet printer? <civodul>it still doesn't work for me, and i'm not sure what's missing <snape>civodul, roptat: there is "magasin" too :) <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? <efraim>I had that one available locally <efraim>well, `guix build --no-grafts foo --log-file' <vagrantcish>do you have to explicitly specify a log file for each build? it doesn't automatically create one? <efraim>it automatically creates one, i don't remember if it does automatically if it fails to build <vagrantcish>failing to build would almost be more important than success :) <civodul>and indeed: checking for libusb_init in -lusb-1.0... no <vagrantcish>i tried making a custom build of gnupg and added libusb to the inputs, which then it doesn't find the lisbusb headers <vagrantcish>ACTION ponders dusting off the novena and actually trying to run guixsd on it <vagrantcish>has sata and 3.8GB of ram and a quad-core processor ... might actually be useable <efraim>i bought a cheap 120GB ssd from China for $35 to go into an iBook G4, there's an option for a sata port :) <efraim>looking at gvfs and at gnu/services/desktop, gvfs has an $out/share/dbus but isn't registered for a dbus service, anyone running gnome think it might be needed? <vagrantcish>after adding libusb as an input to gnupg: checking for libusb_init in -lusb-1.0... yes <catonano>efraim: I rn Gnome abitually but I don't now what gvfs is, exactly <efraim>i think it has to do with automounting usb stick and similar things, but I don't remember exactly <catonano>anyway the Gnome desktop in Guix has several integration issues, gvfs isn't the most urgent, in my opinion <efraim>guix system: error: more than one target service of type 'screen-locker' <efraim>Oops, forgot to recompile enlightenment <janneke>civodul: hope that's nitty-gritty enoug ;-) <sneek>Welcome back janneke, you have 1 message. <sneek>janneke, OriansJ says: adding octal and binary really makes M1-Macro live up to the name mescc-tools <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 <amz3>ng0: you can import with @ form too <amz3>like: (define my-package (@ (pkgs sys-kernel linux) linux)) <ng0>I can paste the error message, but it won't be very useful since I can not push this right now <amz3>more like: (define linux (@ (pkgs sys-kernel linux) linux)) <amz3>I think you can use that trick to break cycles, but tbh I never encountered such issue in guile, not sure what happens exactly in your case <ng0>just a sec, I'll make a paste. <ng0>I rarely encounter cyclic dependencies.. is this how such an error would look like? <ng0>I'll dig throzugh some headers to see if I can find more <ng0>oh.. right. select and hide would be something to work with. I think what you told me was just inside package definitions <ng0>eh. I think I don't even need the other import. leftovers from changing structure <vagrantcish>ok, i've managed to convince gnupg to use libusb in scdaemon ... now i wonder if it will actually work <ng0>yeah. when I drop the use of the %VERSION-hash in linux-headers, I can make it work. <ng0>the thing was with re-arranging what already worked for months, I wanted to reuse code that keeps changing in more than 1 place <ng0>provide VERSION and matching HASH and not end up with an endless long file <ng0>there must be a way, but for now I'll hardcode the versions and checksums. <vagrantcish>alright! gpg --card-status seems to work... but i had to disable 'check as one of tests stalled indefinitely with libusb <efraim>ng0: I remember you were working on mate's screen locker and couldn't get it, I couldn't get enlightenment's to work,so I just set the binary as setuid and that worked well enough <efraim>The other part of the screen locker service is a Pam extension, I should check if it does fail to log in if I provide the wrong password <ng0>yeah, seemed to me like setuid would be the way to go <ng0>okay, next question since I switched that recently too: can there be a "." in the load-path of guile? I moved some of my modules to a ~/src.nmae/name/ ... <ng0>the module names are still "normal" <ng0>but the "." is in the total path <ng0>nope.. issue remains. even with strange modules moved. <ng0>was better when I didn't declare namespaces. <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 <bavier`>vagrantc: nice; maybe I can finally start using my smartcard <vagrantc>bavier`: i think it's time to file a bug ... due to the 'make check' issue, it's not really ready ... but works-for-me. :) <bavier`>vagrantc: I got one of the cards from FSFE <bavier`>I don't recall the specifics right now <vagrantc>it might be possible to use pcsc-lite/pcscd instead of the built-in libusb stuff ... not sure