IRC channel logs


back to list of logs

<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
<ryanprior>That's useful info, thanks.
<vagrantcish>$ guix system --help
<vagrantcish>guix: system: command not found
<vagrantcish>Try `guix --help' for more information.
<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>just like all the profiles and so on
<pkill9>yeah i agree
<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
<vagrantcish>how easy to implement... no idea
<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
<efraim>and a 200MB download
<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).
<efraim>that's unfortunate
<mbakke>It's fairly simple to prevent that, I just didn't bother until a bug report emerged :P
<civodul>Hello Guix!
<mbakke>Bah, nckx keeps stealing my commits! :P
<civodul>heheh :-)
<civodul>hey mbakke, congrats on the 'staging' merge BTW!
<civodul>i'm really grateful that you allow us to move forward
<mbakke>It's a team effort!
<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>this parted/linux bug is annoying
<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_>Perhaps its because fc-cache monospace returns Nimbus and not Dejavu? Does one set the default font alias for something like monospace in the file ~/.config/fontconfig/fonts.conf as per
<divansantana_>mbakke: I did try a reboot. I'll try that.
<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!
<bavier`>good day guix
<mekeor>hello bavier` :)
<mbakke>divansantana_: Glad it helped!
<mbakke>Is anyone bisecting the parted issue?
<civodul>mbakke: no, not at the kernel level
<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>well, "dépôt" is rather good :-)
<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"
<roptat>but they are not the same
<civodul>in that case, you could write "dépôt Git" and "dépôt Guix" when you need to disambiguate
<roptat>mh… that's a possibility
<roptat>but I'd be better to have a word that's clearly different
<civodul>or: "entrepôt", "fonds"
<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>heheh :-)
<civodul>i understand them, but i need to think about the translation
<roptat>thank you :)
<roptat>"entrepôt" sonds good
<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
<roptat>nope it does'nt
<civodul>but that's probably not a language issue
<roptat>I'll use that, thanks
<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 :)
<civodul>"magasin"... would be fun :-)
<snape>from Littéraire. Lieu renfermant des choses diverses, en grande quantité : Un magasin d'idées, d'images.
<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>guix build foo --log-file
<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>vagrantcish: --log-file gives you URLs like:
<vagrantcish>civodul: ah, nice.
<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
<vagrantcish>at least, for an arm board
<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
<vagrantcish>checking libusb include dir... not found
<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
<janneke>OriansJ: *nice*
<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>Obviously I can't link to my package recipes here (I'll explain their intention and design etc in a near future once the design is all finished up)..
<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
<ng0>but it's weird
<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.
<amz3>hardcode ftw
<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
<civodul>janneke: that's perfect, thank you!
<janneke>good, yw
<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. :)
<vagrantc>bavier`: which smartcard?
<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