<attila_lendvai>yep, i'm already fooling around in qemu. now, how can i inspect a shepherd service (start, stop forms, etc)? <attila_lendvai>i got to: herd eval root (slot-ref (car (lookup-services 'bee-mainnet-0)) 'start) but it didn't help much, because it's a scheme closure <jlicht>attila_lendvai: what are you trying to do? It almost seems like you are using the shell to interact with the shepherd; why not use guile? <jlicht>e.g. (begin (use-modules (gnu services herd)) (start-service 'bee-mainnet-0)) in a marionette-eval <attila_lendvai>jlicht, i want to test my service in a qemu vm, because last night i killed my dev laptop GUI be `herd stop my-service` -- something went wrong. <attila_lendvai>jlicht, my start form is broken still, and my activation-service-type extension will be complex. i want to mess around in the VM to see what to code up in scheme. <attila_lendvai>jlicht, this is a complex service that generates/starts multiple shepherd services <jlicht>so ideally.. some kind of interactive marionette? Where on the host side, you can use e.g. geiser to feed forms and see stuff hapening on/in your QEMU vm? <jlicht>Perhaps some of the folks who worked on/with marionette know how to get it to talk to you; it does not seem to be a very complex backdoor REPL, looking at gnu/build/marionette.scm <attila_lendvai>for now i'm making progress, and the resistance is not guix/shepherd, but setting up the actual app/config/env <guixy>By default the mpd service makes the mpd user with a home directory in /var/run. Shouldn't that be /var/lib? <the_tubular>Is this a dumb idea : Give a fixed time where no packages can't be pushed to the guix repo so the farm has time to build everything and people can pull from it ? <sneek>KE0VVT, ArneBab says: if you install via guix, just call wisp. <attila_lendvai>i'm playing with `guix system vm myfile.scm`, and it stopped working and i have no idea why. i get into a guile repl, and prior to that: no boot file passed via '--load'. nothing changed in how i invoke the wm, only in my service, probably some error <attila_lendvai>when i quit the repl: Kernel panic - not syncing: Attempted to kill init! <attila_lendvai>i'm starting with: /gnu/store/[hash]-run-vm.sh -nographic -append console=ttyS0 ***user3456_ is now known as user3456
<attila_lendvai>FTR, what led to this undecypherable error mode was that i used passwd:uid on a string in an activation-service-type extension (i should have called getpwnam) <attila_lendvai>FTR, qemu -append *overrides* the earlier -append in the run-vm.sh script. (WTH, append overrides?) <attila_lendvai>FTR, here override semantics is useful: $(./pre-inst-env guix system vm swarm.scm) -m 2048 <apteryx>attila_lendvai: yeah, got bidden by qemu's poor CLI ergonomics before too <apteryx>not to say that Guix's very own is perfect *apteryx is cross-building rust 1.54 for i686-linux <attila_lendvai>i'm looking for an invoke/quiet with setgid/setuid support. i shouldn't need to write my own fork for this... <guixy>By default the mpd service makes the mpd user with a home directory in /var/run. Shouldn't that be /var/lib? <attila_lendvai>it seemed like a good idea to use (invoke [...] . args) as an API, but it makes it totally unextendable <ns12>When I install something using 'guix install', is it normal for Guix to download a dependency multiple times? <ns12>For example, when I install litecli, Guix downloads cups-minimal, pango, and cairo twice during the install. Is that supposed to happen? Why can't Guix download only once? <apteryx>it could be various versions, or variants of the same version <apteryx>that's sometimes used for bootstrapping <apteryx>if the hash is not the same, Guix isn't downloading the same thing multiple times, but different things. <apteryx>if you want to review dependencies you can use tools like 'guix graph' or 'guix size' <ns12>I don't understand why Guix has to download cups-minimal-2.3.3 twice. <apteryx>seems to be it's just the way it's showing its progress? <ns12>apteryx: How do I find out whether or not I am using multiple daemon jobs? <ns12>Does using multiple build jobs cause the same dependency to be downloaded multiple times? How? <apteryx>they are printed many times as the downloads progress <apteryx>sudo ps -eF | grep guix-daemon | grep max-jobs <apteryx>if you haven't configured anything you won't see any match, which means your daemon is using 1 job <apteryx>but even without multiple jobs, I think the same output can appear many times in the UI as the download progress <apteryx>it's a limitation/problem in the UI where the build plan gets populated as the process occurs, and new items are being added to the list and the output refreshes, causing the same items to appear again <apteryx>it doesn't mean they are *downloaded* multiple times; just printed <ns12>apteryx: Thanks for explanation. <apteryx>sneek: later tell ciodul it built! /gnu/store/gx035nyr0msd2zakphv111hjxd9xscy6-rust-i686-linux-1.54.0 <apteryx>seems the cross-compiler generated an ELF32 binary for cargo and rustfmt, but rustc itself is ELF64... retrying with some changes <apteryx>also there'll need to be some top level syntax glue, similar to what was done for pkg-config or polkit <apteryx>and I have interrogations about if graphes from different architectures can be combined in Guix (never tried before) ***wielaard is now known as mjw
<sneek>mothacehe, you have 2 messages! <sneek>mothacehe, nckx says: When (manually) restarting a CI build, would it be feasible to automatically restart all dependent packages that were marked as ‘dependency failed’ because of that package alone? <sneek>mothacehe, nckx says: If that is already the case, it's not clear from the UI. A dependent (gnome-shell) remained ‘failed’ even when all dependencies became green. Maybe it was being rebuilt in the background though, I didn't wait around and manually restarted it. <mothacehe>nckx: that's indeed the case, failed builds are automatically restarted when their dependencies are all successfully built <ArneBab>KE0VVT: yikes — looks like something in the package does not work yet. Thank you! <jpoiret>apteryx: did you try making slim depend on elogind in shepherd? i'm just worried that slim's getting too old for it to work properly <ArneBab>KE0VVT: can you use (import (language wisp)) in guile? <ArneBab>KE0VVT: guile -c '(import (language wisp))' <vivien>I’m not sure I understand everything with the libsoup 2/3 duality on core-updates-frozen, so someone reviewing 52188 would help me greatly :) <ArneBab>@all how can KE0VVT try guile-wisp release v1.0.6 with guix without us creating a new package? <raghavgururajan>apteryx: Are you using linux-libre or linux-libre-lts in your config.scm? I am reading that 5GHz issue could be power management related. <rekado>ArneBab: is it okay to upgrade the Guix package? Or is this a pre-release? <florhizome[m]>Can I sent patches from icedove? Or do I need an emacs mail setup ... <florhizome[m]>i would like to set up notmuch ( I created a new mailadress that supports IMAP :D) sometime but I <florhizome[m]>> <@florhizom:matrix.org> Can I sent patches from icedove? Or do I need an emacs mail setup ... <florhizome[m]>> i would like to set up notmuch ( I created a new mailadress that supports IMAP :D) sometime but I <florhizome[m]>btw icedove looks pretty „fresh“, last time I installed thunderbird it went really hard on my cpu and the ui is much cleaner now <efraim>I have tor failing on core-updates-frozen on aarch64 and powerpc <efraim>doh, it's the same test which tails on i686 <rekado>the PHP tests on aarch64 are flakey. <PurpleSym>zimoun: I thought I fixed the builds for i686. Do we know why this test fails and did it succeed earlier? (I can’t find any earlier successful builds in cuirass3) <zimoun>PurpleSym: I do not know. The test T14028 systematically fails. The patch trivially skip it for i686. <zimoun>The test about Quasiquotation. Maybe, it uses something that has changed. Bisect is not an option with GHC. ;-) <PurpleSym>I’ll build GHC with your patch after lunch, zimoun. I’ve been bitten too many times by “trivial” changes like this :) <zimoun>PurpleSym, yeah I agree. Me too. It took all this morning to be sure it correctly builds. :-) Thanks for taking care of GHC. <liltechdude>Hello! It is possible to manage mail list with guix? <PurpleSym>zimoun: But the first build in on master and the second on c-u-f. <zimoun>PurpleSym, yes but I think Cuirass is lost with the merges «Merge branch 'master' into core-updates-frozen» <PurpleSym>Okay, let me build GHC twice then. With and without the patch. <apteryx>jpoiret: hello; I don't think it's because slim is too old; I haven't yet tried your suggestions (adding dbus or elogind as requirements to it, or even booting with gdm), but will do ***Guest8167 is now known as chrislck
*chrislck has done $guix home reconfigure ~/guix-profile/home-manager.scm and regrets it bitterly <sneek>I think I remember abcdw in #guix 12 days ago, saying: jlicht: hi!. <chrislck>anyone knows how to roll-back guix home beyond the initial generation? where's the original configuration saved at <rekado>efraim: this time php built fine on aarch64 <rekado>I built it on grunewald; it previously failed three times on pankow. <attila_lendvai>so, i can copy-paste into a qemu vm started by `guix system vm foo.scm` by copy-pasting the content of the run-vm.sh, and editing it to add console=ttyS0 to the -append line. this is rather cumbersome... is there a way to atomate this? i'm willing to write code, too. <rekado>you could also just call run-vm.sh with extra arguments <jlicht>I believe qemu's append overrides previous append-ed stuff <jlicht>which might be a bit silly considering the name <efraim>rekado: I assume that was on master then <rekado>I mixed up my cuirass browser tabs… <rekado>but still: these builds are marked as failed on cuirass, so it doesn’t hurt to fix them :) <attila_lendvai>if i were to add a CLI option to guix system vm to disable/enable qemu graphic mode... what would you call that? <attila_lendvai>oh well, #:graphic? #false still opens a separate qemu window (as opposed to using the terminal it was started in). i need to patch system-qemu-image/shared-store-script to also include -nographic, but... well, we'll see what the maintainers think about it. preliminary feedback is welcome! <apteryx>attila_lendvai: the usual workaround is to copy that /gnu/store/...run-vm.sh script somewhere and edit it to your needs <attila_lendvai>apteryx, that's what i was doing, but it's a serious slowdown in my cycle <apteryx>not pretty, but gets the job done. a patch to qemu so that later args take precedence above earlier one, and an -append that truly appends would be great patches for QEMU in my opinion *attila_lendvai is patching guix system vm to properly propagate the #:graphic? option, and adding a CLI arg for it <attila_lendvai>how about calling it --same-terminal or --same-tty? i need help with this. <attila_lendvai>it will make guix system vm read/print into the starting terminal <apteryx>zimoun: I'll look into it later if nobody beats me to it! Thank you :-) <GuiGuiGuix>Hello, I'm trying to configure a remote printer with cups but failed either by using gnome-printer or cups admin :( <GuiGuiGuix>the printer with gnome is well detected canon... but the address is null <nckx>attila_lendvai: Probably ☝ that. <attila_lendvai>nckx, you mean --no-graphic, right? i also went with that, and it's working. i'm preparing the commit. <nckx>GuiGuiGuix: How exactly are you adding the printer to the CUPS Web admin (let's ignore gnome-printer) and how does it fail? I don't quite understand what is null here. <nckx>My answer got delayed by little meddlesome paws. <nckx>With little adorable claws. <zimoun>apteryx, cool! Thanks. Wait v2 later today. :-) v2 will fix julia-* packages for i686. <GuiGuiGuix>nckx: I try to access the admin cups portal either but does not work with root or current user <nckx>But how exactly does it fail? Note that CUPS does not have a Web interface by default, so if you visit localhost:631 and just can't connect, you need to make sure you have ‘(web-interface? #t)’ in your cups-configuration. <nckx>Run ‘sudo touch /etc/cups/cupsd.conf’ and try again. <nckx>I fixed such a bug but it might not be on master yet, or the fix was incomplete. <GuiGuiGuix>this is my first week with guix with a new laptop so far except intellij and the printer everything works fine :D <ss2>nckx: oh, thanks for pushing 892f1b7273d57b25940700877a02618fe826cc08, that allows inferiors in services. <nckx>YW ss2, although it was a purely selfish act. <nckx>Coincidentally also CUPS-related. *apteryx tries the i686-linux cross-built rustc in a 32 bit VM <roptat>GuiGuiGuix, intellij is hard to package, but at least I was able to run it by downloading the binary version. I had to create myself a shell with the dependencies, in a container so I could mount FHS locations from the profile <roptat>that way, I can provide dependencies where it expects them to be <apteryx>cross-compiled 'rustc --help' on 32-bit VM runs \o/ <apteryx>but cargo --help doesn't: /gnu/store/6fkn8fc0m642xlnbblv3026cpp4i2411-profile/bin/cargo: error while loading shared libraries: libz.so: wrong ELF class: ELFCLASS64 <nckx>I wouldn't, but ask in #guile. The seeding example is explicitly ‘for non-security-critical applications’. It never mentions what security-critical ones should do… <attila_lendvai>damn. i have a command that i'm unable to run in herd (but it runs fine in guix repl). "< /dev/urandom tr -dc _A-Z-a-z-0-9 2> /dev/null | head -c32 >password-file". in herd arcivation form the system call returns 2, and i have no clue why. i'm replacing the tools with the full store path. <attila_lendvai>i guess i should forget guile's random. it straight out starts up with the same seed every time, and "To seed the random state in a sensible way for non-security-critical applications, do this ..." <apteryx>for the gnu-build-system, we can set #:target; what about #:host? <nckx>apteryx: What about #:host? <apteryx>for compilers, it'd would act as #:target, I guess. <apteryx>or perhaps it's enough that I use #:target and specify a different --host in the package build system <nckx>I'm not sure Guix follows that GCC?/Autotools? naming scheme to such a tee. <nckx>I missed the context that you were building a compiler (but a non-GNU one, so I don't even know if that would help). <zimoun>does Berlin use real i686 hardware to compile or “-s i686-linux” on x86_64 machines? <nckx>zimoun: Do you have a bug that needs real i686? I think I have one lying around. <apteryx>nckx: more context: the wip-cross-built-rust branch <nckx>So… cross-built Rust as part of the normal dependency graph on some architecture? <zimoun>nckx, I do not know. I suspect Julia packages to pass tests on real i686 but they fail with “-s i686”. <apteryx>janneke: do you know if xz-mesboot is supposed to be cross-compilable? it's failing while attempting to cross-build ld-wrapper (from x86_64 to i686) <apteryx>to reproduce: ./pre-inst-env guix build -e '(@@ (gnu packages commencement) xz-mesboot)' --target=i686-linux-gnu ***iyzsong- is now known as iyzsong
<janneke>apteryx: we never tried that before... <janneke>hmm, isn't xz-mesboot still --system=i686-linux? <apteryx>what do you mean? you are wondering if it builds with --system=i686-linux? <janneke>the bootstrap up to gcc-5.5 (?) is built as i686-linux, only after that a cross-build is done to x86_64-linux <janneke>apteryx: $ file $(./pre-inst-env guix build -e '(@@ (gnu packages commencement) xz-mesboot)')/bin/xz <janneke>/gnu/store/r1zsxj7wlvw1aa1ifv3nyrrjag44pc9s-xz-mesboot-5.0.0/bin/xz: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, with debug_info, not stripped <apteryx>what I'd like is to be able to cross-compile ld-wrapper, but this pulls these cross dependencies which don't build *jgart yet another way to tell if you're in a guix shell/container <apteryx>is it looking for the GUIX_ENVIRONMENT variable? <jgart>Yup, it just checks to see if it's set and says the "right thing" if you're in or out of a container/shell <jgart>I might rename it to something shorter but maybe it doesn't matter <roptat>jgart, really setting $PS1 depending on $GUIX_ENVIRONMENT is a lot easier and you can passively know whether you're in an environment or not <roptat>just add what the hint gives you to your .bashrc (that time it's really .bashrc) so you get a different PS1 inside the environment <yewscion>Hello All, is there a mechanism I'm not seeing to specify additional channels in a guix home spec? Or is that meant to live separately from the home configuration? <roptat>yewscion, I think it's supposed to be separate, in ~/.config/guix/channels.scm <yewscion>roptat: Alright, thanks! Just want to make sure I do things in a canonical way. <apteryx>grep the sources; you can send commands directly to the socket <apteryx>or look at the system test examples, they use that IIRC. <attila_lendvai>is there any strange restriction in a herd activation form wrt calling (SYSTEM ...) and/or setgid/setguid? i guess herd is running as root, right? <roptat>attila_lendvai, maybe it doesn't have access to $PATH, or a different value? <attila_lendvai>i'm using full store paths to the binaries. maybe it cannot access /bin/sh? (the C system call wants that) <attila_lendvai>my code works in a root guix repl, but not in the activation code of a shepherd service. i get an error from the system call, i.e. it's not some package issue. <attila_lendvai>fork and setuid/setgid to the service user is also involved, but AFAIU permissions and everything is fine <bdju>I have a video call interview in a few days. Does anyone know if it's possible to screenshare from Sway on Guix System? I'm not sure if I'll need to, but it's a concern I have. <attila_lendvai>correction: the system call fails even without fork and setuid involved. <attila_lendvai>a clue is that system* works, but system doesn't. must be something with /bin/sh. the service user's shell is nologin, but the C system manpages explicitly talk about /bin/sh, not the user's shell <podiki[m]>bdju: I haven't used Sway, but hopefully wouldn't be any different than another distro, likely depends on the video call software you are using <attila_lendvai>it's the same after changing the user's shell to bash from nologin <podiki[m]>(though may depend on master vs core-updates-frozen for software versions needed?) <bdju>podiki[m]: well, the weirdness would be related to wayland, and I might need certain things in place that might not be packaged <bdju>jpoiret: thanks for the info. is there a guide on how it's configured somewhere? <podiki[m]>bdju: I have yet to use wayland, so can't comment there sorry. (I do plenty of video conferencing on X with guix that is fine at least) <bdju>well, I don't run a display manager right now, and iirc startx doesn't work on guix system. so I would have to do quite a bit of setup to get X going at this point. I'd sooner use a different machine probably <bdju>(also, I don't really want to use X if I can help it...) <apteryx>sneek: later tell civodul hi! "ld-wrapper-cross" appears as a native-input in cross-gcc, but is there otherwise a way to get a handle to it in a cross-built package? I'd like to add it to the PATH of the cross-built 'cargo'. <ArneBab>rekado: sure it is OK to upgrade! I just didn’t have the time to do it … <zimoun>apteryx: In fact julia-* is broken for master on i686. Therefore, it is a bit longer than expected. :-) I will send a v2 fixing all Julia things for i686 on core-updates-frozen tomorrow. I guess. The fix for julia itself remains the same for v1 or v2. Wait just avoid to let CI build some julia-* that I know are broken. :-) <cryptograthor>Hi, first time here. Running into issues on installing from a USB, I get the message "/mnt/boot/efi doesn't look like an EFI partition"; $ fsck -N /dev/nvme0n1p1 (the efi partition) says the system is formatted as vfat as expected. What else should I look at? <nckx>Hm, and yet that error is triggered only by ‘grub_strcmp (fs->name, "fat")’ in GRUB. <nckx>Are you sure it's actually mounted there? <cryptograthor>though, ls /mnt/boot/efi reveals an empty directory (not sure if that matters) <nckx>If this machine ha{s,d} a previous OS on it, that's unlikely, but if you just created/formatted the partitition yourself it's expected. We can't say. <attila_lendvai>FTR, converting (system ...) to (system* "/bin/sh" "-c" ...) solves the issue. still no idea why system doesn't work inside a shepherd activation form. <cryptograthor>it's a fresh reformat. Running guix system reconfigure /mnt/etc/config.scm, I got a message about being unable to determine system provenance <nckx>What does ‘mount | grep /mnt/boot/efi’ return? <nckx>Thanks. I've got to go now. I told cryptograthor to reinstall Guix System (something was clearly wrong with GRUB in a way that would be hard to debug remotely). If someone here might hold their hand, it would be wonderful. <cryptograthor>To configure the efi partition, is this correct use of mkfs? $ mkfs.fat -F 32 /dev/nvme0n1p1 # efi <rekado>yes, that (with /dev/sda1) is what I ran as well. ***Myrcies is now known as myrcy
<roptat>cryptograthor, I'd expect you to run guix system init instead of reconfigure, if you're in the installer ***ss2`` is now known as ss2
***mark_ is now known as mjw
<lilyp>attila_lendvai: w.r.t. random, most programming languages (IIRC guile included) use Mersenne Twister by default, which is *not* cryptographically secure <the_tubular>I'm trying to figure out what are the "*-minimal" package in guix's repo <the_tubular>reading the package definition isn't really helping me <lilyp>attila_lendvai: The kernel random-number generator is designed to produce a small amount of high-quality seed material to seed a cryptographic pseudo-random number generator (CPRNG). It is designed for security, not speed, and is poorly suited to generating large amounts of random data. Users should be very economical in the amount of seed material that they read from /dev/urandom (and /dev/random); unnecessarily reading large quantities of <lilyp>data from this device will have a negative impact on other users of the device. <dissent>hey guix, i successfully used guix lint and build on a package i'm attempting to add. this was in admin.scm. when i attempted to lint and build another package it reads "unknown package". what could be the issue here? <lilyp>i.e. don't read from urandom directly into passwd; that's wasteful af <lilyp>dissent: if it only exists in your local checkout you might need to build that first and use pre-inst-env <lilyp>it could also be a hidden package or something in which case you need to eval your way around it <attila_lendvai>background: i'm using /dev/urandom to generate a password when a service first starts. this is what upstream does also (in their debian package). <dissent>lilyp: thanks for the response. will attempt to figure it out. <roptat>the_tubular, they're "minimal" variants that have less dependencies, in general <the_tubular>Yes, this is what I could gather, are the features comparable ? <roptat>since there are less optional dependencies, there are less features <roptat>depends on the package, for instance wpa-supplicant-minimal is the same as wpa-supplicant, but it can't use dbus <roptat>or emacs-minimal would let you edit files, but without graphics, multilingual support, network capabilities (or at least without SSL), ... <dissent>that is, rebuilding the previous package definition <jgart>dissent, have you been using ./pre-inst-env for building packages in a checkout? <dissent>jgart: yes. managed to succesfully build `fff`. <dissent>jgart: that is where i lost all my confidence haha. <jgart>you might need to patch some binaries for fff <jgart>check out other shell packages in guix <dissent>jgart: check out our matrix chat. I sent you the definition I came up with. <roptat>yeah, I'd replace some of these calls. I saw a call to "file", which we don't provide by default I think <roptat>the lazy way would be to propagate, the right way is to substitute* that to a store reference to file <jgart>dissent, see ytfzf for the long way <jgart>raghavgururajan, and I had to take a patch for that one <jgart>but try roptat suggestion first with substitute* <jgart>grep for examples of others using substitute* <jgart>In other words, you have to get any executables in fff to use the ones from /gnu/store/... explicitly <jgart>for example, line 154 above is calling `file` <jgart>we need `file` from `/gnu/store/uuid.../bin/file` <jgart>dissent, not to be confused with `/usr/bin/file` <jgart>I wish there was a less tedious way for bash programs... <jgart>but for now, you have to go through and read all of fff and find those places that you need to patch up with substitute* <jgart>substitute* is a macro found in guix/build/utils.scm if you want to read more about it <dissent>jgart, going to put a pin in this one for now. going to have to do some travelling tomorrow and will pick it up on thurs. <dissent>haha i thought this was going to be easy. <dissent>jgart, how difficult do you think pqiv will be? <jgart>There might be something in the manual for substitute* <jgart>dissent, way easier/less tedious since you won't have to patch anything like with fff <jgart>dissent, the above advice of reading nix expressions to get an idea will definitely not work for go or rust packages in guix <dissent>jgart, yeah i had a look at some of the rust packaging. was thinking to add bat-extras but that one might also be painful. <jgart>see trayer-srg patch on the issue tracker <jpoiret>jgart: re fff. Just like bashtop, I don't really like programs written in bash <jpoiret>always read like obscure incantions to me <jpoiret>and patching them for guix is pretty annoying <jpoiret>maybe someone could write a bash parser in guile, that would make it easier :)) <jpoiret>(otherwise have fun trying to substitute* "dd", only to rewrite every other line) <jgart>yup I agree, we need a better way to package shell. I'd like to have fff in guix but it's annoying to have to patch shell code <jpoiret>jackhill: i didn't know gash had a bash parser (although it's pretty logical when you think about it) <apteryx>wrapping in with coreutils should go a long way <jgart>apteryx, can you point to an example of "wrapping in with coreutils" <jpoiret>but anyways, all those "fancy" tools written in bash don't really look reliable to me <jgart>I think I might know what you mean but it might be clearer... <apteryx>jgart: emacs is wrapped in such a way <jackhill>jpoiret: well, it might not cover all of bash, just enough to do what it needs, but could be a start <jgart>I remember having a conversation with alphapapa in which he was surprised at the work required to package shell for guix <jgart>That conversation is somewhere on github... <jpoiret>well, that's because when you write shell scripts, you implicitely assume all your dependencies' binaries are findable in the PATH <jpoiret>for compiled code, we have pkg-config, include dirs, RPATH, etc... <jpoiret>tbh, when C code hardcodes some system("stupid-binary", ...) we also have to patch it by hand <jgart>> I don't understand this. I have studied Guix a little ... <slyfox>yeah, there should be no major difference in patching binary paths <jpoiret>the difference is that bash scripts rely way more on external binaries <jpoiret>I think that to explain Guix, you first have to explain the basics of the FHS and its shortcomings, maybe that could clear up why we need to hardcode things <jpoiret>ouch. Yeah, that was what i was worried about when doing so for bashtop. Maybe the gash parser is good enough to patch simple binary calls though <jackhill>it's a very interesting idea that would make a lot of things easier if reliable <dissent>sounds like fff is not so necessary xD <KE0VVT>ArneBab: I cannot use (import (language wisp)). 