<sebboh>I have decided that guixsd shall be pronounced as "GEEKS-dee". The s got merged into the x... <sebboh>Also it's like like geeks-D, it's more like geeky with just the slightest little d thrown in there. <sebboh>I will be tickled pink if anybody else already pronounces it like this. <pkill9>i'm gonna pronounce it that way in my head now <shpx>XD with a weird haircut gXD <buenouanq>were any of the service issues we were having worked out while I was gone? <buenouanq>still trying to acquire a spare machine I can work through this stuff on <g_bor>I've been wondering how can I do this: build all dependencies of a package, but do not build the package itself. I see that I can do this with the sources... <marusich>g_bor, if by 'dependencies' you mean 'inputs', then something along the lines of what 'guix environment my-package' does is what you're thinking of, right? <g_bor>Oh yes, you are right, I just had a feeling that sometimes guix environment build more than what is strictly needed. <marusich>That might be true. Ricardo mentioned in chat and also on the email list (I think) that "guix environment" might be building more than just the direct dependencies (and it might not be intended). <g_bor>Ok, thanks. I've also seen that mail, and also noticed some extra derivations built... But for my present use case I guess this is acceptable. ***Gamayun_ is now known as Gamayun
<g_bor>Do we have to increase a version number of a package to get guix package -u upgrade that, or does it check that a package receipt is updated? <g_bor>Also, if we need to add a new version, for example because we added a patch, what is the comparison function for versions? <janneke>g_bor: the derivation (predicted build result) needs to be different for -u to happen <janneke>that's when version is the same or higher; if you change the derivation but guix/utils.scm:version-compare decides the new version is older, no "upgrade" happens <g_bor>Thanks, that is very useful information. <g_bor>I'm sorry that you could not make to FOSDEM. <g_bor>:) I gave a short talk there where I could introduce the gcc-ddc effort we started together, and I could finish it just a few days before the event, so now we have a working ddc of gcc 4.7.4. <janneke>i've been busy moving, and will still be for a while <g_bor>I've been moving four times in the last two years, so I can understand... <cbaines>guix lint seems broken: ERROR: ERROR: Wrong type to apply: #<syntax-transformer uri?> <janneke>cbaines: latest master, ./pre-inst-env guix lint hello, works for me? <cbaines>Interesting, using ./pre-inst-env works for me as well <janneke>cbaines: seems there have been some/an abi change <cbaines>Oh well, at least I can get guix lint to run that way now, thanks janneke :) <cbaines>I've just updated the guix package in my profile, and I'm able to run it without ./pre-inst-env now <pkill9>what's the link to the patch queue again? <pkill9>the page with the list of submitted patches pendign approval <g_bor>I intend to mark #30104 as easy, so that outreachy applicants willing to work on guile tools can have a look at another build system, and fix this trivial bug. Actually all that needs to be done here is already in the mails. I nobody comes up, I will fix this. WDYT? <janneke>pkill9: okay, the url is in the manual @Submitting Patches <bnw>OriansJ`, hi but do I know you? <sneek>bnw, OriansJ says: that the stage0 vm is going to be gaining support for 256bit address space and registers. <OriansJ`>bnw: we talked about you writing a lisp operating system If I remember correctly. <bnw>OriansJ`, no. Sorry but I think you mistaken me for someone else. :-) <OriansJ`>bnw: Sorry about that. Its just rare to find people who take an interest in bootstrapping work and I certainly enjoy those conversations. <bnw>ACTION is just a temporal guix user. But still don't have a lot of time hacking it. <thorwil>hi! how does one handle building in-development stuff on guix sd? where on a common system, say for some unfinished library, one might git pull from time to time and install to /usr/local? <janneke>thorwil: not entirely sure what you mean (never installed anyting in /usr/local), but i guess the answer is: create/update a package and install it (or enter into an environment where you install it) <thorwil>janneke: one aspect is that i'm left wondering whether a piece of software that won't run right out of a build tree can be gotten to work without writing a recipe for it <janneke>thorwil: well, technically nothing forbids you to do ./configure --prefix=/usr/local|$HOME; make; make install -- but creating a package description in trivial (for well-behaved software) and so much nicer in Guix[SD] <thorwil>i guess fetching from git via recipe is OK? <playX>How i can install gtk3 devel for gtk-rs? <cbaines>playX, guix doesn't often have separate development packages. Have you tried using the gtk+ package? <atw>what package provides ldd? <efraim>Otherwise i believe binutils does <atw>Also, is there a way to search hydra to figure that out? <wigust>atw: From my little experience with Hydra, no. But you could use ‘find /gnu/store -iname '.*binary.*'’ or ‘packages.debian.org’ to figure out a possible package name. <atw>wigust: yeah, debian has this, and I apt-file works locally. A way to search a substitutes server might be cool. <atw>figured out my GTK issue. My WM was setting LD_PRELOAD. <thorwil>is there a way to install guix sd from another distribution, something like copying data and then continuing in a chroot? <efraim>You can do a guix binary install and run 'guix system reconfigure my-config.scm' to convert your system <rekado>the hash for liblo appears to have changed. <rekado>hydra only has 89% of substitutes for a manifest I want to build on x86_64. Part of the reason is the hash mismatch. <enderby>hi guix-ers, i recently upgraded guix packages on a foreign distro, and now emacs complains my user has no home directory. and 'screen' says "getpwuid() can't identify your account!" <enderby>i found some workaround to run emacs, "emacs -q -l path/to/init.el", but now that screen is complaining about something similar. I'm wondering if there's a better solution <nckx>rekado: are you already investigating liblo or shall I? <rekado>nckx: I haven’t checked yet. Need to finish my paper first :-/ <nckx>rekado: OK, I'll have a look. <soundtoxin>I got some errors when running updates. I'm hoping someone can tell me what steps to take to figure this out. <soundtoxin>guix system: error: failed to load '/etc/config.scm': <soundtoxin>/etc/config.scm:5:0: In procedure allocate-struct: Wrong type argument in position 2: 24 <soundtoxin>I'm not completely sure what 'position 2: 24' refers to. Should I look for something wrong in my config? I haven't made any changes recently that I can recall. <efraim>If you're running from git you'll need to run 'make clean' <nckx>Let's see if SF serves different things to guix proper. <nckx>Bingo: guix download mirror://sourceforge/liblo/liblo/0.29/liblo-0.29.tar.gz → 1grhp5i29v1krrn1m36n68ls6vakvbw4x60im26b7h55rkvx61vs <nckx>Which, if I remember correctly, is the hash of the empty file. <nckx>Time to add JavaScript support to (guix download). <efraim>I just got the 1grhp... hash from hdparm from sourceforve <rekado>after reconfigure: guix system: error: exception caught while executing 'eval' on service 'root': <rekado>ERROR: find-long-options: unbound variable <rekado>the result is that services cannot be started any more.