IRC channel logs
2023-05-17.log
back to list of logs
<f3n1x>i've 1.- created an /opt folder 2.- and added it to $PATH in .bashrc , 3.- downloaded the hugo binary, 4.- made it executable . Why does bash say ' bash: /home/fenix/.local/bin/hugo: No such file or directory ' though ? I'm puzzled <gnucode>It's good to see the work is progressing on updating the Hurd packages. <gnucode>I don't know if ya'll know but the Hurd is actually making huge strides towards 64-bit support. and it boots! <Kabouik_>The kmonad package is not available for arm/aarch, I can't see why in the package definition. Would it be hard to add? I remember successfully building it on armhf a few years ago with cabal or stack, but a Guix package would be ideal since there's already one for x86_64. <bdju>anyone here use pcmanfm-qt and able to launch it in wayland mode? `QT_QPA_PLATFORM=wayland pcmanfm-qt` does not seem to work, I get `Could not find the Qt platform plguin "wayland" in ""` <bdju>I can't drag and drop files into gajim and I want to see if launching pcmanfm-qt in wayland instead of xwayland fixes that. my gajim is running in wayland <bdju>I believe I used to set that variable in my .profile but had issues so stopped doing so, so all my Qt stuff is in xwayland <efraim>2 things though, polaris seems to be stuck. and the riscv64 machines are now always busy building substitutes for guix pull <ulfvonbelow>is it not supposed to be possible to disable authentication for guix system commands? <ulfvonbelow>I'm trying to run 'guix system init' from a local repository and it's complaining that my commits aren't authorized. <ulfvonbelow>on a related note, how exactly is one supposed to use a local repository with authentication? <ulfvonbelow>the necessary introductory commit is just going to change every time I have to rebase <ulfvonbelow>not that that even matters in this case, since 'guix system init' is completely ignoring my channels.scm <ulfvonbelow>as in my channels.scm points to HEAD of my local repository, and has my openpgp-fingerprint, and 'guix system init' is still trying to authenticate starting from some random ancient guix commit <ulfvonbelow>I'm puzzled why it's even authenticating. If the guix that is running is authentic, the guix package included in that guix is also authentic. <attila_lendvai>looks like something broke on my laptop WRT tlp. i connected the AC, but i had to issue a sudo tlp ac to restore my CPU's max frequency. i've seen this a couple times in the past few days. <chomwitt>Hi. My homeconfig.sch starts with (use-modules (gnu home) ... Where can i see what that line does ? <elevenkb>Hey there y'all's my interactive development experience is quite poor. Two main difficulties: <elevenkb>1. I often have to evaluate the define-module form twice. This is just annoying can deal with it. <ennoausberlin>Hi. Are there any known problems with the new kernel or gdm? After reconfigure I get the infamous "Oh no! Something has gone wrong" screen when X comes up <ennoausberlin>The machine is a virtual server and was working well for more than two years with guix <cbaines>efraim, I'm glad you like it efraim :D <cbaines>polaris is off at the moment as it wasn't doing much <efraim>well that would explain why it's not doing anything :P <davidl>does guix build -f pkg.scm and guix build pkg use the same version of guix for every step of the build? How are different channels handled? <cbaines>I've retasked rochor (the RISC-V SiFive Unmatched board I have) and got it building more things, and trying to build the prometheus node exporter, so we'll see how far it gets with that <cbaines>davidl, assuming pkg.scm evaluates to pkg, then I think those commands are equivalent <cbaines>I guess channels might affect pkg if it uses inputs from channels <davidl>cbaines: I thought so too. But somehow one fails and the other succeeds. Yes, probably an input is from a channel and that's why it fails to evaluate one of them when using guix build instead of guix build -f. <davidl>cbaines: last line of fail log says: ice-9/boot-9.scm:1685:16: In procedure raise-exception: <davidl>In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f <cbaines>right, depending on what you're doing in pkg.scm, the environment might need setting up to match to get guix build pkg to work <davidl>so that's an input that doesn't exist I guess. I now re-ran it with guix build -L /path/to/my-channel pkg and it works the same as guix build -f pkg.scm <davidl>cbaines: Im surprised about this behaviour though. I would expect that guix build would be able to use all the package paths that you have pulled in from all channels. So essentially there are issues with having a package in a separate channel when it depends on other packages in its own channel, or that's at least what appears to be the issue. Other packages in the same pkg.scm file even build just fine. <davidl>cbaines: to be precise, the package that failed with guix build pkg.scm depends on a package defined in the same file as itself. <davidl>cbaines: is there some common way to fix the environment in this case? <cbaines>I don't use channels so I'm not sure how they're meant to work <cbaines>(or rather, don't use multiple channels) <davidl>cbaines: okay. I might try a regular guile-style add-to-load-path (current-file... something) <jpoiret>davidl: guix build should Just Work™ <jpoiret>specifically, `-f` doesn't change much <ulfvonbelow>anybody know why 'guix system init' is causing guix to try to authenticate itself? <andreas-e>efraim: Yes, these monitoring pages are really addictive. <andreas-e>cbaines: The aarch64 comparison on master is interesting. It illustrates the shortcomings of cuirass, cf. the bug reports I submitted. Most aarch64 build failures are spurious and related to disappearing derivations or lack of topological sorting, I think. <efraim>I also find it interesting that the guix build coordinator is having a hard time increasing the x86 substitutes while the x86_64 substitutes are so high <jpoiret>ulfvonbelow: are you using your own config file? <cbaines>efraim, part of that is milano-guix-1 only builds x86_64-linux and not i686-linux <jpoiret>guix authenticating itself should be happening only when (current-guix) is used. But then again I remember seeing it for my reconfigures as well <cbaines>so there are three build machines for x86_64-linux (including the fastest milano-guix-1), but only two for i686-linux <cbaines>x86_64-linux builds are also prioritised over i686-linux <andreas-e>Why does the activity page say "agent: {bay,harbour}front", but not so for the other machines? <ulfvonbelow>I see now that it uses (current-guix) in %installation-services <cbaines>andreas-e, I think it's just the build started message that tells you the agent <ulfvonbelow>still confused why (current-guix) would require authentication, it's literally already running <jpoiret>it's a convenience feature so that we don't have to update the guix package twice in a row <jpoiret>ulfvonbelow: current-guix basically builds guix again <ulfvonbelow>but it's already being run, it's too late for authentication to do anything useful, and any result it gives is going to be taking its word for it <ulfvonbelow>it seems like more of a historical accident as far as I can tell <ulfvonbelow>but anyway, now that I know it's because the install system is using (current-guix) I'm much less grumpy <jpoiret>ulfvonbelow: well, you're trusting your current guix, correct? <ulfvonbelow>yes, on account of having already authenticated it and added only my own commits on top <rekado>apteryx, efraim We need to reconfigure bayfront for DNS changes (ns1.gnu.org). <jpoiret>if so, then that guix will authenticate what it's trying to build to make sure that it isn't building something wrong <jpoiret>oh, are you having trouble with the authentication not passing then? ulfvonbelow <jpoiret>ulfvonbelow: you can locally add (arguments (list #:authenticate? #f)) to the definition of current-guix <jpoiret>there's no easier way for now unfortunately <ulfvonbelow>thanks, that sounds like exactly what I need. Much easier than trying to change %guix-channel-introduction every time I rebase. <flypaper-ultimat>Hey guix! I work at a research institute and packaged some softwares that i hope to upstream / add to guix-science. Would creating a channel under github.com/$INSTITUTE/mychannel.git under gpl3+ and adding the definitions there hinder eventual upstreaming? <flypaper-ultimat>(While I'm working out how to unbundle bundled libraries & how to submit a proper patch) <dcunit3d>i would look at some of the forks of guix-science and see how the network is merging in updates <dcunit3d>flypaper-ultimat: i'm not really sure, so i'd love to hear what people say. i know that you want to keep the channel that a channel depends on to an absolute minimum. if you're simply adding some packages, then creating a fork may work (but i think depends on your ability to have your PGP key added, either in upstream or on fork, and to disambiguate this fork of guix-science channel from within guix) <dcunit3d>so, that said, i would hate to supply the wrong information here. <civodul>flypaper-ultimat: hi! nice! you can check with #guix-hpc where guix-science people are more likely to hang out, but basically feel free to submit a merge request :-) <civodul>and ping folks if you don't get feedback in a timely fashion <civodul>i'm getting lots of "make: INTERNAL: Exiting with 603 jobserver tokens available; should be 5!" <davidl>jpoiret: I agree, I would have liked to file a bug report with some better quality information but I don't think I will get around to it in the foreseeable future. TL:DR: make external channel-specific packages work to build when depending on other packages in the same file (or external channel). <davidl>jpoiret: but then if the last statement in that file is bash-coding-utils (the package variable), then you can build it with guix build -f bash-coding-utils.scm <davidl>jpoiret: you can also temporarily work around it with guix build -L /path/to/channel bash-coding-utils.scm <jpoiret>hang on, so you're pulling from that channel but you can't build the package with `guix build`, is that it? <jpoiret>does guix describe show your channel? <davidl>I have 3 external channels, so, before I would submit a full bug report I would have to create a smaller reproducible example. <davidl>but I believe this is probably just how channels work at the moment. <jpoiret>but if it's from the same file, I don't think there's any channel interaction <davidl> 2054:2 6 Exception thrown while printing backtrace: <davidl>In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f <davidl>ice-9/boot-9.scm:1685:16: In procedure raise-exception: <davidl>In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f <davidl>Im pretty sure an input is not found, that the #f is a package that doesn't evaluate. <davidl>jpoiret: I gotta leave again, but will read up later if you reply more about it. And just by the way, this package I have some javascript in the html manual to remove and then Ill probably try and resubmit it to Guix later. <janneke>so, our libpciaccess is too old for the hurd with rumpdisk, let's find out how many users it has... <janneke>hmm, 3615 -- let's add a -17 version for hurd <vcarvalho[m]>Hey everyone, is anyone versed w/ guix home? I'm trying to use the home-fish service in my config but it keeps defaulting to bash-5.1. Isn't it a matter of specifying `(service home-fish-service-type)` in the home config? <bjc>no, because only the super user can change your shell, and ‘guix home’ has no way of escalating privileges <bjc>you have to set your shell in your machine config, if you're using guix system, or plain old ‘chsh’ otherwise <vcarvalho[m]>I see. Thought I could put that onto the user config. Thanks for the clarification <janneke>(eh, what's the /r/ doing here, we never had that?) <janneke>(ah, it's an abbreviation for archive) <attila_lendvai>guix home reconfigure says: In procedure fport_write: Input/output error -- without a backtrace, even with --debug=10000. hiding the backtrace from the user is *not useful*, because anyone serious about guix must learn the basics of scheme... <bjc>is it intentionally hidden? lord knows most of the time guix bleeds scheme all over me whenever anything is wrong~ <attila_lendvai>heh, there's --debug and --verbosity, which confused me. but setting both still leads to the same output. <jpoiret>attila_lendvai: it's an error in C code so I don't think it can reliably trigger a backtrace <jpoiret>or it might be an error happening in a daemon/builder <attila_lendvai>bjc, i don't know what's behind this, but having to struggle to get backtraces is the most frustrating thing i have with guix. i had countless times when i had to patch the codebase to squeeze out a backtrace, and sometimes it involves black magic... because of all the staging, and different versions of guile and libs are generating code that is then run in another environment... <bjc>huh. that's very different from my experience. i get lots of backtraces, but they're almost never useful <attila_lendvai>bjc, right, and that's the second most frustrating thing... :) coming from common lisp, i'm used to not having to do any debugging, because in most cases looking at the backtrace is enough to identify the issue. <janneke>so. we now have a working pci-arbiter, rumpdisk still b0rked... <apteryx>I'm trying to debug a process running in the least-authority-wrapper; it seems using strace in there doesn't work (hangs shepherd?) <apteryx>I'll attempt to replicate with unshare <janneke>hmm, did we drop the glibc local-clock_gettime_MONOTONIC.diff patch? <cbaines>wooo, persistance pays off, there's now a substitute for guile-fibers@1.1.1 for aarch64-linux <apteryx>civodul: match-record is very nice to use by the way :-) <old>There was symbols in libraries of clang-runtime@15.0.6 <old>there are no symbols now in clang-runtime@15.0.7 <apteryx>tip for stracing inetd-style services: strace -p1 <apteryx>works best in a test VM where only the service under test is running <mirai>would setting the default value for the 'origin' record-type 'modules' field to '((guix build utils)) trigger rebuilds? <cbaines>mirai, generally changing a fixed output derivation won't trigger rebuilds <mirai>cbaines: what kind of changes will alter the output? <cbaines>mirai, to a fixed output derivation? <mirai>the motivation for the 'origin' change is that simply almost every instance of (snippet ...) usage also comes with a (modules '((guix build utils))) <mirai>cbaines: perhaps it would have been clearer if I stated that I didn't understood the sentence. What does “fixed” & “derivation” mean? <cbaines>yeah, always clarify things that aren't understood <cbaines>so packages and the origin bits are data structures from which derivations are constructed, which is what the guix-daemon actually builds <cbaines>given you're thinking about rebuilds, it's sensible to think about the effect on the derivations <cbaines>a "rebuild" happens when the output of the derivation changes, since you need to build that new derivation to get the new output in the store <cbaines>for most derivations (like those for packages), the output(s) depend on the input derivations <yewscio_g>Hello all, what's the best way to go from a derivation to an output path? I have defined a derivation using a gexp and applying gexp->derivation, but then when I supply that as the :#builder to trivial build system guix complains it is not producing the output path, even though the gexp's derivation exists in the store. I'm missing something, and cannot find it in the docs. <cbaines>at the edge of the graph though, you don't have any input derivations, but instead just blobs of data represented by fixed output derivations <cbaines>package origins generally map to fixed output derivations, since the output of the derivation is dependent on the hash you provide <cbaines>yewscio_g, could the error message mean the gexp you've written is not producing the output path? <yewscio_g>I suppose, though I have indeed run (mkdir #$output) within the gexp. Is the output path something that needs to be passed into the procedure? <mirai>cbaines: yes, it makes things clearer now. Thanks! <cbaines>yewscio_g, providing that bit runs, (mkdir #$output) should be sufficient <apteryx>is it possible to see shepherd errors? in strace, I could know the problem easily: 164 write(2, "Backtrace:\n 3 (primitive-load \"/gnu/store/myb88j97gv89kiagysv6vmkdcx4?\")\nIn ice-9/eval.scm:\n 191:35 2 (_ #f)\nIn gnu/build/linux-container.scm:\n 300:8 1 (call-with-temporary-directory #<procedure 7f8b4d2d4b90?>)\n 397:16 0 (_ <apteryx>\"/tmp/guix-directory.W5M1Im\")\n\ngnu/build/linux-container.scm:397:16: In procedure statfs: /var/log/rsyncd.log: No such file or directory\n", 381) = 381 <apteryx>so my file-system-mapping /var/log/rsyncd.log failed because it doesn't exist yet <apteryx>I should map the whole /var/log writeable <yewscio_g>cbaines: https://paste.debian.net/1280502/ Here is the code I am using; It currently creates a derivation path correctly, but does not create the output path at all. Mostly wanted to use it as an excuse to explore creating a package using a gexp, I have learned a lot but would like to see it through to completion. <cbaines>yewscio_g, I'm not sure you're using the computed-file bit correctly <cbaines>computed-file is for building a derivation (through a gexp, which is the builder for that derivation) that creates some output (file) in the store <cbaines>maybe try just passing the gexp without the computed file bit as the builder? <yewscio_g>cbaines: Yup, that was the issue. Feeding the gexp directly into the #:builder allowed it to build correctly. Thanks! <apteryx>ACTION managed to make or rsync service run with a least-authority wrapper that has the rsync daemon run it in its own namespaces except for net and user <mirai>apteryx: how does the least-authority wrapper work? <mirai>does it return a “package” object? <mirai>unrelated to the above, I suspect that using (substitute* …) as an alternative to .patch to be a bad idea <mirai>substitute* doesn't fail so the current “substitutes*” may: 1. patch incorrectly; 2. fail to patch what's pretended; 3. no longer applicable <festerdam>Hi, all. I noticed there's currently no GNAT package for Guix (as far as I know, since I'm currently not using guix). And it seems, from reading previous logs of #guix, it is due to the fact that gnat itself is written in Ada, which makes GNAT «the bootstrap nightmare». I thought GCC is also written in C how come it and all the software that depends on it is available on guix? I then read chapter 20 <festerdam>from the Guix Reference Manual (Bootstrapping). Am I correct in my assumption that the reason GNAT isn't shipped as a bootstrap binary is due to the aim of keeping those "bootstrap binaries" to the smallest size possible (hence a simple c compiler rather than gcc is used for bootstrapping)? So this means that a GNAT package for guix would require a simple Ada compiler for bootstrapping? <mirai>in theory this should be checked closely when the package is updated but I suspect “guix refresh -u …; git commit -m …” is where things stop <mirai>apteryx: I wonder about the services whose configuration records have a field that accepts “package” objects <mirai>usually within the service start method there's a #$(file-append package "/bin/foo") <mirai>perhaps the “package” field should instead contain what amounts to (file-append package "/bin/foo") instead? <apteryx>it'd break the current convention for no real gain, I think <apteryx>it's easier to specify the package whole and let the service deal with it <mirai>in this way the service can be made to use the least-authority-wrapper or not <mirai>I don't like much the idea of a service implicitly using least-authority-wrapper with no way to change it <mirai>it tends to be too rigid and there's no escape hatch <apteryx>I'd need to see an actual problem in practice with it to consider it. Currently I'm fine with it being hidden in the implementation. <apteryx>I think it'd be nice to have a policy that recommends the use of least-authority-wrapper unless there's a technical reason preventing it <mirai>iiuc the least-authority thing acts like a container <mirai>pretty sure there's situations where extra “commands” (or accesses) have to be added in order to make things work <mirai>though the example I'm thinking is <mirai>mympd can communicate to mpd via socket or TCP <mirai>and for mpd, who knows what kind of directories or contraptions have been configured, especially if escape-hatches are used (no introspection ability) <apteryx>usually you can inspect the confige to infer the right mount points to expose in the container <mirai>if you were to least-authority-wrap them like how wesnothd-service-type is done you're likely to get many kinds of broken configs <apteryx>that'd be a technical reason not to use least-authority-wrapper then, at least when the escape hatch is used <mirai>apteryx: does the file-mapping preserve symlinks? (i.e. do they keep working?) <apteryx>I think they should, assuming they point to a location also exposed to the container <mirai>let music-directory="/media/X" but "/media/X/Y" is a symlink to "/media/K/Z/W" <apteryx>wouldn't work if you've only exposed /media/X <mirai>well, that would constitute a case for having the wrapper parameters tinkerable, no? <apteryx>I'd err on the side of 'too risky to use here' and not use least-authority-wrapper <apteryx>to keep it stupid simple -- things are already complex enough :-) <bjc>to me, it sounds like authority configuration/containerization should happen at runtime <bjc>firejail accomplishes it with wrapper programs that are preferred in the path. it's not perfect, obviously, but i don't know of any other way, short of messing with the kernel's exec mechanism <mirai>to make things clear, I think least-authority-wrapper is a good idea and I'd like to use it (for instance, I wouldn't miss if mpd gets UTS, cgroup and mnt removed) <mirai>yet if mpd came wrapped I'd find it unable to use at all due to symlinks, etc. <mirai>if the package field was instead a “executable” field then it would be possible to use it flexibly <apteryx>I don't see why the package field is hindering that, though? <apteryx>ah, you would provide your own wrapped executable? <mirai>it could be a wrapped executable or the plain one <mirai>and you could also set a “guix least-authority-wrapped default” for it <mirai>to have the ability to opt-out or modify, so to speak <apteryx>I don't think that'd be easy, because the wrapper script needs to be built with the knowledge of the rest of the config <mirai>which is accessible, by using let-forms <mirai>as long its valid scheme code <mirai>config.scm isn't a DSL after all 🙂 <apteryx>perhaps a topic worthy of discussion on guix-devel? <apteryx>I think perhaps it should support both inputs, if that's possible <mirai>I suspect #61342 is relevant to the convo as well <apteryx>on the other hand specifying a package for a field is probably already a bit niche <apteryx>I suspect most users are happy with the default one <mirai>apteryx: either a package or a “path to exe” ? <apteryx>the thing is that both will have the same type, a file-like object <mirai>apteryx: package variants :) <civodul>janneke: you can use "guix archive -t" <janneke>civodul: TITS (that is to say), somone on the fediverse asked if binaries were available, unless i prepare something they would still need guix to extract them <apteryx>guile-ssh and guix has means to open an SSH session, but not to close it; is it OK to leave it lingering? <janneke>okay, using Debian Salsa's glibc hurd time patches rumpdisk still crashes, but differently <gnucode>I am trying to install a graphical IRC client on a talos II power9 machine. ffmpeg is not building which is stopping pidgin from building... <gnucode>janneke: nicely done with updating the Hurd packages by the way! <gnucode>I am sure that I could configure pidgin to work without sound... <gnucode>but I'm not sure how to do that. So I guess I will look for another irc client <janneke>gnucode: updating the hurd packages wast mostly (98%) jpoiret <gnucode>I'm actually running the Hurd on real hardware: a T43. I was demonstrating to a friend just now how "grep -r" causes issues...now I have filesystem corruption. haha <janneke>yeah, i guess when we (jpoiret) get netdde integrated and we get rumpkernel done, guix/hurd might just install on real iron <janneke>gnucode: oh, you're already running it on iron! is that debian or guix? <jpoiret>`grep -r` doesn't work on debian/hurd? damn <gnucode>jpoiret: grep -r does work on the hurd! <gnucode>BUT it does not work on a filesystem node that is exposing a website. <janneke>ACTION thinks using Debian is cheating ;-P <gnucode>cd gnucode.me; ls; (that works). But "grep -r the" in the gnucode.me directory doesn't work, because httpfs does not support a sitemap. http is not a filesystem protocol persay. <gnucode>janneke: what do you mean by how many bits? <gnucode>also fsck seemed to work. Looks like I do not have to re-install. <gnucode>also I am using the stable debian release. Not the the latest version. <janneke>64bits is the new hot thing, haven't you heard? not sure it's 100% there yet, tho <janneke>ACTION has been preparing their x60 (32 bits machine) to install guix/hurd -- for when rumpdisk works... <janneke>there was also talk about SMP support, dunno what the status of that is... <gnucode>janneke: there has been a lot of ongoing work lately. <gnucode>bug-hurd@gnu.org has been really fun reading lately! <civodul>janneke: you could use "guix pack" to prepare binaries for non-Guix users <janneke>civodul: sure, i was just hoping i could give them a guix-publish url... <janneke>ACTION has a terribly lazy inclination <apteryx>re my earlier question about guile-ssh sessions; it provides 'disconnect!' <apteryx>rekado: any idea what the 'hydra' fake sysadmin user is used for on the berlin build machines? <apteryx>ah, it's used for offloading it seems <gnucode>so I guess I am going to try to package bitcoin-knots for guix. I've never actually created a package for guix before. <gnucode>well not one that I would care to upstream. <janneke>gnucode: i understand that bitcoin-core is using guix because of their trusted bootstrap, which is amazing; do(n't) they have (these/such) guix packages? <gnucode>janneke: not that I'm aware of...I'll reach out to the developer. <gnucode>I personally do not use bitcoin. I have been helping a friend set up his talos II machine. (Chimera linux and I installed guix on it too). <janneke>gnucode: yeah, i'm sure dongcarl would be helpful <janneke>it would be great if they have packages to upsream! <janneke>ACTION now wonders why they didn't think to ask about this before... <gnucode>janneke: what irc channel does dongcarl hang out in? <gnucode>janneke: who is carl dong? is he the bitcoin knots developer? bitcoin-knots is a fork of bitcoin-core <janneke>ACTION has no knowledge whatsoever about bitcoin <janneke>ACTION started their career working for digicash.com and after their demise in 1997 never found enough courage to look at digital money again <gnucode>my friend was showing me the lightening network. He send a tiny fraction of a bitcoin in under 3 seconds. I was impressed. <gnucode>what vpn servers do ya'll use in guix? <jonsger>ACTION is happy that janneke is looking at stuff like bootstrapping or the hurd nowadays :) <janneke>we used to think it was essential (and very probable) for privacy (payer anonimity) to win the ratrace with several parties creating terribly naive legacy account-based systems such as *cough* paypal <gnucode>hmmm bitcoin-qt on power9 builds, but aborts when you try to run it. <festerdam>janneke: What about GNU Taler? I heard some banks were interested. <janneke>nobody being: national or federal governments, banks, supermarket chains, consumer interest groups.. -- but that was in the mid/late 90s <janneke>festerdam: yeah, i guess finally awareness has risen somewhat <janneke>ACTION fears that bitcoin's raison d'etre is more of a speculative investment opportunity that may as an unintended side-effect happen to accelerate the collapse of our climate (and civilisation?) than a digital cash, privacy-respecting payment system <bjc>it's white paper was pretty explicit about creating digital gold, so yeah <janneke>so colour me pretty uninterested in bitcoin -- apart from their--me being terribly opportunistic--very early adoption of trustet bootstrap <civodul>apteryx: yup, offloading! funny we still have things called "hydra" 10 years later <civodul>ACTION has been wandering deep down into the importer rabbit hole <Kabouik_>Do I need some extra Guix package that git didn't pull as a dependency? <civodul>Kabouik_: hi! maybe you need the nss-certs package? <apteryx>civodul: is it OK that I commit an export for openssh-configuration-authorized-keys? I have a use for it for the config of node 129 <civodul>apteryx: sure! i guess it's just out of laziness that we didn't export these <apteryx>yeah; it can be useful when inheriting and extending a base config <apteryx>I also wondered if I could work around the lack of accessors using match-record <apteryx>by the way, I'm still puzzled as to why deploying to node-129 hangs on: guix deploy: sending 0 store items (0 MiB) to '141.80.167.186'... <apteryx>I used --no-offload and --no-substitutes, so it shouldn't have to do with attempting to use itself for substitutes or something <civodul>yes, match-record lets you access all the fields <civodul>as to why it hangs, perhaps it's hanging on the operation that immediately follows? <Kabouik_>That didn't seem to help unfortunately civodul <_graywolf>I'm trying to run a command under `guix shell ... -C ...`, however /usr/bin/env is missing in the container. Is there a way to get it except for the -F flag (which I would like to avoid)? <apteryx>_graywolf: yes, see the --symlink option <_graywolf>Ah, I see. Is that something I can specify in the manifeset to keep the invocation command line short? <Kabouik_>I'll just use git config --global http.sslVerify false, as I couldn't find any obvious and cleaner fix. <_graywolf>The command line looks simple enough, so assuming I get it working I'll stick with that <apteryx>it's a strange error: error: evaluate-populate-directive: unbound variable <apteryx>hm. I'm not sure what's wrong. what are $GUILE_LOAD_PATH and $GUILE_LOAD_COMPILED_PATH set to? <_graywolf>(btw it fails on GuixSD as fail, I just tested that) <_graywolf>In guix repl `,use (gnu build install)` works fine <apteryx>did you try to provide your manifest with -m ? <apteryx>I should try it later but I must go leave for a bit <_graywolf>No worry, thanks for help anyway :) I should go as well (almost midnight here), so I'll try it some more tomorrow and write to the mailing list if I do no figure it out <Zelphir>Hello! I have a question regarding handling of data a program: I am trying to write a kind of "Guile shell", implementing things like `cd' or `ls' or `cut'. Usually such commands take their input from a file or stdin. I have the choice in my implementation, when making a pipeline of commands, to pass results as a list or write to a pipe output port, which I could make the current input port for the next command. I am wondering, what the cost of a huge <Zelphir>result of a command is. Which way of passing the result would be better in terms of having to hold less data in memory. I mean, somehow the data must be held (unless I find a way to make streams or so), but, assuming data is just lines of text, is it more efficient to write data out to a port line by line and then read it in again in the next command, from the current input port, or would it be more efficient to pass as a list? I guess passing as a list <Zelphir>would require to collect all results first, which might be bad for letting the commands run in parallel. <Zelphir>Is there a way to pass data as not-a-string but structured data, but working like ports?