<raingloom>heyy, so, i'm refactoring my machine configs to use declarative modules, and for some reason this doesn't work: guix system vm --load-path="/whatever" --expression="(use-modules (raingloom machines some-hostname)) some-hostname" <raingloom>some-hostname **is** defined as a public symbol and i can see it in a REPL and it **is** an operating-system object <raingloom>(also it kinda sucks that (use-modules) doesn't work now. i had some conditionally loaded modules. but eh, i won't miss it too much.) <raingloom>well, the module file also returns some-hostname at the end, so i guess i can just use it like that, but it sucks big time that now i can't parameterize my OS. <jeko>How did I end up with many nginx processes running ?! <schemescrub>3 old gist, and i'm a scheme scrub, but this user was able to modify %desktop-services and %base-services in the same config <schemescrub>i'd be highly grateful for just a bit of spoonfeed on this one <ces>Hey, can anyone ls their /boot/efi and tell me if it is normal to only have EFI here <mbakke>schemescrub: what are you trying to achieve? The error is because of the duplicate (services ...) field. <mbakke>%desktop-services is a superset of %base-services, i.e. %desktop-services includes all the %base-services and some more <schemescrub>i was trying to configure ssh and a desktop environment on the same machine but had failed to realize desktop is a superset of base <ces>I get a wierd error when i try to reconfigure, =grub-install: error: efibootmgr failed to register the boot entry: Input/output error.=. Anyone have a clue about this? <helaoban>hello guix: hello guix: I feel like I'm missing something obvious, but where do I get libstdc++? Shouldn't "gcc-toolchain" give it to me in "${GUIX_ENVIRONMENT}/lib"? <c4droid>Hi, swap-devices is support lvm device? I change my guix installation from original partation to lvm, when I set swap-devices to lvm mapped devices, guix report "Wrong type" error ***sturm is now known as Guest32245
***luke-jr- is now known as luke-jr
<helaoban>sorry, I should clarify: why isn't there a symlink to libstdc++ in $GUIX_ENVIRONMENT/lib ? <PotentialUser-44>it just freezes there and nothing happens. I also got same issue when booting GuixSD install from USB but it worked after a few reboots. <PotentialUser-44>Hardware is AMD Ryzen Pro 1300, RX560 GPU, ASrock A320M HDV R4 and I'm booting through UEFI <helaoban>ok so I understand that I need to specify the "lib" output of gcc in order to have that link. Why is libstdc++ factored out into a separate output? <bdju>is anyone else using quaternion on guix system? clicking links doesn't open them in the default browser I have configured for xdg-open. also, I don't know how to set a dark theme. <mroh>bdju: I thought, I have fixed this xdg-open issue maybe a week ago or so. Is this on a recent system? <bdju>mroh: (fyi, I'm the one from the matrix channel) I don't think xdg-utils missing as a dependency was the problem since that was already on my system. it seems more like the normal xdg config isn't being applied. <bdju>btw, which browser do you use? I wonder if what you use is in the list of default browsers to try, whereas I'm using qutebrowser which definitely isn't (but it *is* configured as my default and working with other programs) <bdju>oh, and as for the recency of my system, I maybe haven't updated in a few days <bdju>guix (GNU Guix) 6cf7b5e2adcd48b804a108931de46a791d56cb87 <abcdw>Is there some good template project for guile? Want to write a simple cli utility, would like to have some basic example. Interested in project structure and dependency management. <PotentialUser-35>Hello, I just installed the 32bit version and instead of a login screen I get. "Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please contact a system administrator." <PotentialUser-35>When I looked at the logs /var/log/gdm/greeter.log There's this error that spawns others. (.gnome-shell-real:338): Clutter-Critical **: Unable to initialize Clutter: Unable to initialize the clutter backend: no available drivers found <abcdw>efraim, ok, will try, thank you. <luhux`>remove (gdm-service-type ...) and add (sddm-service-type ...) in config.scm ***hji- is now known as hji
<luhux`>The reason I recommend sddm is that gdm has never run correctly on my machine <luhux`>I don't understand this, I am a wm user.. <mange>If you want to use %desktop-services (which includes gdm) you can use something like the example in "(guix) Using the Configuration System" in the manual, at the end of the "System Services" section. <mange>You can remove the gdm-service-type from your system, so then you can add sddm without any potential for conflict. <bdju>do any other qutebrowser users here have issues with sites using those cloudflare checks? they seem to loopp forever instead of completing after "5 seconds", so a bunch of sites are inaccessible ***Jin[m] is now known as Coyo[m]
<jeko>Hey civodul ! Yesterday I checked my port numbers, my host name (same I use to ssh to the machines) but still can't deploy. <jeko>I restarted ssh daemon, checked if any other process were using the port... <jeko>Also I upgraded Guix on the host <civodul>i'd check the hosts and ports in the deploy config file <civodul>and then try to connect to those from the same host <jeko>everything is fine when I connect to it <jeko>in /etc/ssh/authorized_keys.d there is the right key <jeko>if I do `guix system delete-generations` then `guix gc --list-live | grep ssh` I should see only one sshd-config, isn't it? <civodul>jeko: to see the sshd_config file in use, you should run "herd status ssh-daemon" and then "cat /proc/PID/cmdline | xargs -0 echo" <civodul>kisaja[m]: it's possible to use Slim instead of GDM; that's what you had in mind? <civodul>mothacehe: it just occurred to me: for the discovery code, can't we use call-with-output-file/atomic instead of resorting to file locks and all? <jeko>civodul: Ha! I was looking for such command, thank you ! And the config is OK. I will continue the investigation later ^^ Thank you for your help ! <crazyfrog>Hello to all! I already tried to get help a six hours ago but didn't get any respone. Does anyone know why GuixSD freezes at this point? <crazyfrog>CPU: AMD Ryzen 3 PRO 1300, Motherboard ASRock A320M HDV R4, GPU AMD RX560 2GB <civodul>leoprikler: thumbs up for closing a 2016 bug! :-) <jeko>crazyfrog: I have no clue <crazyfrog>I would provide more information if I could :( <crazyfrog>I tried disabling CSM, enablind/disabling fast boot and nothing helps <crazyfrog>I tried disabling CSM, enabling/disabling fast boot and nothing helps <kisaja[m]><civodul "kisaja: it's possible to use Sli"> to choose wayland or xorg <cbaines>crazyfrog, you could try removing "quiet" from the boot options in grub, and see if that gets you more information <mothacehe>cbaines: hey! thanks for the Cuirass/SQLite analysis, I just replied! <cbaines>mothacehe, you're welcome, I'm just replying to your reply :) <mothacehe>note that on Berlin I managed to have a very small WAL file <mothacehe>I think so but my monitoring is based on running a ls once in a while <mothacehe>At the time I found that complex queries with large WAL files behaved bad <kisaja[m]>civodul can i configure slim to use wayland or xorg <cbaines>Indeed, I've been tracking the WAL size for the Guix Build Coordinator, and you can clearly see a correlation between WAL size and read performance <mothacehe>I also noticed that we had a ~1GiB WAL file for Guix itself <mothacehe>-rw-r--r-- 1 root root 6.0G Dec 7 10:31 db.sqlite-wal <cbaines>crazyfrog, hmm, although searching the internet for amdgpudrmfb or "amdgpudrmfb freeze" seems to give some results <crazyfrog>ah I see, seems that it is related to linux-libre kernel build? <crazyfrog>I wonder if I can chroot into GuixSD system from installation media and then rebuild kernel <cbaines>crazyfrog, potentially, I've heard AMD GPU's have some dependency on non-free firmware. I don't know how dependent they are on it though <cbaines>crazyfrog, is this something that's just broken, or a new installation? <jonsger>cbaines: usually they should run in 2D without hw acceleration even if no firmware gets loaded <cbaines>crazyfrog, there's maybe some option you can pass to Linux so it doesn't try loading the broken graphics stuff <cbaines>that at least might allow the system to boot <jonsger>I think, but I think you need to do some dance on the cmdline for the kernel or so <crazyfrog>well I can build my own kernel and it might work fine <jonsger>I think I didn't get my AMD GPU really working with linux-libre <crazyfrog>hmm is there any command in guix to do easy chroot into system? <crazyfrog>if not then how do I chroot into GuixSD system? <crazyfrog>will /mnt/dev/<partition> /mnt/guixsd && chroot /mnt/guixsd /bin/bash work? <cbaines>mothacehe, I've pushed those Cuirass commits now <mothacehe>cbaines: nice, thanks! I like to deploy on berlin right after changing important stuff in Cuirass, to discover issues as soon as possible. <mothacehe>that means updating Cuirass package in maintenance basically <mothacehe>cbaines: I also see that there are other sqlite-finalize statements we could turn into sqlite-reset <mothacehe>oh sorry ignore the last sentence, I was read an older version of database.scm ***guix-vits is now known as vits-phone
<cbaines>cool, I was wondering why I couldn't find any <cbaines>it seems I removed the last of them! <crazyfrog>Hmm I chrooted to my GuixSD install and when I try to run guix pull it says that connection refused to var/guix/daemon-socket/socket <crazyfrog>Okay this problem solved, now to building kernel... <jonsger>at least 18 builds of icedove in the last month with only 3 new releases ^^ <jonsger>oh, I manually counted successful builds :P <civodul>someone could crunch all that data and draw conclusions about scheduling etc. <mothacehe>mmh cuirass doesn't seem to start them at all, which means something else is triggering those builds <mothacehe>cbaines: there's something doing huge amounts of requests to the Cuirass API, causing database workers starvation. Would it be the Data service? <civodul>mothacehe: i have a script building ~ludo/critical-packages.scm on berlin... <civodul>but, guix-modular is just the derivations leading to guix <civodul>so they can be built as a side effect of other things, for x86_64-linux <mothacehe>civodul: ok that's probably what's happening <cbaines>mothacehe, I can stop the Guix Data Service polling just in case. I'd check the NGinx logs though, as they'll include user agents, it's probably bots that are the significant factor <civodul>mothacehe: that doesn't explain guix-modular on non-x86_64 though <mothacehe>cbaines: the ideal would be that Cuirass could swallow those huge bursts <mothacehe>but right now it causes temporart (~2 minutes) 504 errors <jonsger>paali: my guess would be missing dependencies <kisaja[m]>civodul: "The SliM project has been abandoned (last release was 2014)" i get why wayland isn't an option <jonsger>kisaja[m]: I use sddm for my wayland session <kisaja[m]>is sddm using less ram than gdm? i mean is 'simple' really simplejonsger: <paali>Please please help, I am in censorship prison... <lemes>I was looking through some files from guix/scripts and noticed that a few of them use cons* when defining %options and some others use list. Is there a reason behind this? <paali>luhux: You made suggestions that I do not remember, if possible, comment: <kisaja[m]>so manual should suggest same 'remove' option of gdm for sddm, as is for slim already (to replace gdm)? <civodul>lemes: i think it's just convenience, dependending on how many options are being added to the list <civodul>(cons* a b c lst) is equivalent to (append (list a b c) lst) <kisaja[m]>switched to sddm, entered sway from menu, systray isn't shown in 13status <civodul>paali: hi! the link doesn't seem to work for me, it says "please wait" but i never get the file <paali>civodul: But it works for me! <rekado_>FWIW I also only see "Notification is not defined" <rekado_>maybe try a different paste service? <civodul>hmm on Guix System, why do we have 6 entries in GUILE_LOAD_PATH instead of 2? <civodul>(should be just ~/.guix-profile/share/... and /run/current-system/profile/share/...) <jeko>When `guix deploy` to a target machine, I should see an ssh connection attempt in the logs of the target machine (ie /var/log/secure), right ? <civodul>sneek later tell paali that looks like a shadowsocks packaging bug, probably worth reporting to bug-guix@gnu.org <jeko>civodul: cool so I am getting closer to my problem haha *jeko should learn how to use emacs-guix to explore guix's source code <bavier[m]>civodul: I'm having trouble using a `gcc-toolchain` package from `guix pack` on a foreign system. Are there tricks involved, or maybe just bug? <civodul>bavier[m]: did you source the pack's etc/profile? <civodul>that's about all it should take, i think <bavier[m]>yes. It's a `-R` pack. Do the wrappers warn if `-RR` would be needed? <bavier[m]>there are a few symlink jumps that `gcc` has to go through to find `cc1` in the libexec dir, and that's not working right now. <civodul>bavier[m]: -R is userns only; the wrapper errors out if userns aren't supported <civodul>dunno maybe you should send details to bug-guix :-) <civodul>i haven't tried gcc-toolchain in a pack <bavier[m]>sure, I'll try to untangle these symlinks and then send a message. <bavier[m]>I made a package for an up-to-the-minute "gcc-dev" package so I could try out the latest aarch64 support, but still need `guix pack` to run it on this system :) <civodul>oh nice, so you're building GCC straight from Git? <civodul>would be worth sharing, including with the GCC folks <bavier[m]>did we settle on a loose convention of a "guix.scm" file in the top directory? or something like that? <civodul>yes, like you write: that's the loose convention :-) <mroh>our new `(define true-but-soon-false ...)` is often called in a political environment after voting ;) <civodul>perhaps the person asking didn't expect to modify the package definition, though <civodul>jorge[m]: sí, puedes ejecutar "guix upgrade PAQUETE" <jorge[m]><civodul "jorge: sí, puedes ejecutar "guix"> Gracias estaba colocando update. <civodul>well not necessarily now, but sometime <vagrantc>civodul: i bumped up the verbosity on guix's test suites ... but i don't see a similar mechanism for gnutls ... any idea how hard that would be? <civodul>vagrantc: both use Automake; the output is saved in individual .log files and the summary is in test-suite.log <vagrantc>civodul: with guix there's a --brief=no|yes flag that i found helpful ... e.g. it displays each individual test fail/pass rather than a summary for each file ... but no such thing in gnutls <vagrantc>though with hanging tests, not particularly helpful <civodul>vagrantc: ah yes, --brief is for the srfi-64 test suite driver, but GnuTLS doesn't use that <civodul>in reauth.scm, there's a "Debugging" comment; you can uncomment the following lines <vagrantc>civodul: when i set --brief=no it gives me much more useful output for (nearly?) all the tests <civodul>i think --brief=no lists all the individual srfi-64 tests no? <civodul>anyway uncommenting these two lines in reauth.scm should help <vagrantc>wow, the reproducer for that appears to actually work ... i was admittedly a bit skeptical about the /dev/shm /tmp symlink steps to set up the environment <PotentialUser-99>I'm new to Guix; And I, like some people, have trouble connecting to Shadowsocks. <mdevos>basically, the Guix package definition is apparently somewhat incorrect, so it needs to be changed slightly *mdevos starts emacs etc ... <mdevos>the stackover entry seems somewhat incomplete, the package input definition isn't listed <mdevos>PU-99: just wait a little! I'm writing a patch to Guix <mdevos>I'm trying to avoid copy-pasting the stackexchange code, contributions there are CC BY SA apparently <leoprikler>Well, the solution is not complete anyway, but couldn't BY-SA be relicensed as GPL v3 after making a modification? <mdevos>leoprikler: wouldn't that be GPL3.0-only, and no GPL3.0-and-later? <mdevos>I think I have an alternative solution: create a config.json with correct paths <vagrantc>you can't relicense something without the author's permission, though you can add a different license for additional code as long as the licenses are compatible <vagrantc>at least, that's my amateur take on licensing :) <vagrantc>well, you can also license things incompatibly, but that does nobody any good <mdevos>I've abandoned the config.json path, config.json.example is also used for configuration <mdevos>not just for locating libraries etc. <leoprikler>In this case, it appears the author themselves noticed and added a clause allowing their code to be reused under GPLv3+. <mdevos>leoprikler:I just noticed the update <cbaines>vagrantc, I'm not seeing guix pull issues. Maybe you're encountering an out of date keyring branch issue? <mdevos>(about shadowsocks) it builds, let's see if it works <mdevos>ok, it builds, does anyone know how to test it? I don't use shadowsocks myself <leoprikler>I think there's a reason this thing went unnoticed since 2018. <leoprikler>You could paste your package description for PotentialUser-99 to try out, but you'd probably have to write it in a way that they can `guix build -f` it. <vagrantc>cbaines: i was referring to leoprikler's comment about an imposter amoung us <vagrantc>as in ... that's the main place i'd really worry about an imposter :) <mdevos>I'm running a slightly out-of-date guix, there is a theoretical chance it won't build <mdevos>or I made a copy-paste paste mistake <cbaines>vagrantc, did anything interesting happen in the #reproducible-builds meeting? <mdevos>If someone can confirm it works, I'll send it to the list <mdevos>(I know nothing about shadowsocks) <vagrantc>cbaines: a little underwhelming, but we've been setting up occasional topic-specific meetings. <leoprikler>Well, given that they've only posted a patch, you will have to check out Guix from source and apply that. <mdevos>then build guix, then ./pre-inst-env guix install shadowsocks <zimoun>leoprikler: thanks for the patch about very old #23874 :-) <leoprikler>It was the least I could do for this year's advent calendar :) <cbaines>"The /proc/sys/kernel_unprivileged_userns_clone file is specific to <cbaines>Debian and Ubuntu packaged linux kernel" <leoprikler>Sadly, there aren't too many old bugs that I feel confident solving. <zimoun>cbaines, thanks. I have not yet received the vagrantc answer. Time to fetch my emails. :-) <PotentialUser-99>leoprikler: Can you tell me step by step what command to enter in the terminal? Sorry 😅️ <zimoun>leoprikler: I am sure you could close one more :-p Kidding, thank you for your patches. <leoprikler>zimoun: I've replied to a few, currently waiting on input. <leoprikler>PotentialUser-99: I'm not too big a fan of copying shell commands to/from IRC, but <vagrantc>why oh why is the /proc/sys/kernel/unprivileged_userns_clone thread continuing /o\ <vagrantc>someone early on in that thread pointed out it was debian-specific, and people keep recommending to check it ... multiple times ... <vagrantc>so i figured i'd point out in greater detail how specific it was ... but still <lfam>vagrantc: The thread doesn't make it (adequately) clear whether or not the sysctl knob is Debian-specific, or if unprivileged user namespaces are Debian-specific <leoprikler>that being said, I've already confirmed, that this won't work. <vagrantc>lfam: i guess i'm just more aware of the specificity... <zimoun>vagrantc, lfam: I am confused. The commit introducing the “issue” is trying to fix #31977 on foreign distro (CentOS). <zimoun>So it does not seem Debian-specific. <lfam>The fix for 31977 changed a conditional check in our code. But I think that the conditional itself is "not even wrong" <zimoun>vagrantc: you mean included in linux-libre, right? <lfam>The string 'unprivileged_userns_clone' doesn't exist in the linux source code <vagrantc>or rather, doesn't have patches to disable it <zimoun>So why Guix System says: «please set /proc/sys/kernel/unprivileged_userns_clone to "1"» <lfam>Based on a misunderstanding <lfam>Now we are learning about it :) <vagrantc>it should only say that if the file is present <zimoun>what is the best? Add a Debian-like patch to linux-libre allowing the thing or only fix the Guix error message? <vagrantc>guix has the feature enabled out-of-the-box ... in Debian the file is always present, disabled by default (the patches are to make it enableable at run-time rather than kernel build time) ... not sure about CentOS <vagrantc>but i would only have guix mention that file if it is present and set to 0 <vagrantc>feel free to quote me on any bug report; i'm not following them directly <vagrantc>if the file is not present, it is either running a kernel that supports it out of the box, or a kernel that has it disabled and there's no reason to enable it ... or CentOS's patches are different from Debian/Ubuntu and need to detect some other way <vagrantc>s,no reason,no way short of recompiling, <zimoun>vagrantc, thanks. I am not sure to come with something but now the issue appears clear. :-) <civodul>lfam: i'm pretty sure /proc/sys/kernel/unprivileged_userns_clone used to exist <civodul>but i doesn't exist in the 5.9.10-gnu kernel i'm running <lfam>Could be, civodul. That would explain why people are having new problems <lfam>We could boot an old installer to check <vagrantc>i'm pretty sure debian has been carrying that patch for 5-10 years ... so unless guix was also carrying that patch ... <leoprikler>PotentialUser-99: I've sent an updated patch as 45106. <civodul>vagrantc: aaah, it could be that we only checked on Debian back then?... <vagrantc>apparently debian has carried the patch since 2013 ... <civodul>i checked on a Debian derivative with 3.13.0-165-generic and it has that file <civodul>i think perhaps the hint referring to that file was written by davexunit in the early days <civodul>it could be that davexunit and the rest of us were only looking at Debian when we wanted to see what "foreign distros" are doing <vagrantc>oh, that's roughly the first year or two of guix? <vagrantc>so i would guess a lot of foreign-distro users at that time <jonsger>davexunit: /proc/sys/kernel/unprivileged_userns_clone I guess <davexunit>that file existed and still exists on Ubuntu <vagrantc>looking at the patch in debian, it probably originated in ubuntu <davexunit>is something in the container code assuming it exists on all systems or something? <civodul>and there's a hint in linux-container.scm <zimoun`>davexunit: yes, the fix of bug#31977 leads to bug#45069 <davexunit>I guess at the time I didn't realize that this was an Ubuntu patch and not a mainline kernel feature <davexunit>but if it were just an ubuntu patch then containers wouldn't work on guix system... <zimoun`>davexunit: see ’unprivileged-user-namespace-supported?’ in gnu/build/linux-container.scm, I guess. <vagrantc>well, the patch from 2013 claims it should be a temporary fix :) <jonsger>openSUSE doesn't have it, only unprivileged_userns_apparmor_policy <davexunit>I guess this procedure could fallback to another test, like calling clone with the user ns flag and seeing if it succeeds. <zimoun`>At the end, I am happy to dig in this old bug#31977 :-) Positive collateral. :-) <cbaines>is anyone available to set me a password on berlin? <jeko>zimoun`: hey! few weeks ago you made a demo of guix.el for emacs-doctor mailing list. do you know if there is a record available ? <nckx>Why does the userns topic refuse to die? What's wrong with my suggestion to just *try creating* one, instead of sniffing (non-Debian-specific but non-mainline) files? What'm I missing? <nckx>(The file's actually present on my Guix System through some random patchset on the Internet. Strange times.) <zimoun`>jeko, I do not know. I have an item to make a small email with details but… you know. :-) <vagrantc>nckx: so you have some random patchset on your Guix System build that doesn't behave like the Debian/Ubuntu patch? <zimoun`>it seems you are interested, I will do an effort to do it asap. :-) <vagrantc>nckx: it seems like trying to create a file that isn't actually used by the kernel just to make guix container work seems ... not quite right? :) *jonsger wants to discuss about wayland packages... <zimoun`>I have a machine with 64 cores and “guix build -m bioconductor.scm” with 300+ packages… but only 1 core is really working. Do I have misconfigured something or the guix-daemon is as lazy as I am ? <lfam>zimoun`: What's the value of --max-jobs? <nckx>vagrantc: No, I mean it's the same patch (presumably). It creates /proc/sys/kernel/unprivileged_userns_clone; that never existed in Linux proper. <zimoun`>These values need to be chosen with care, otherwise «all build users are currently in use;» <lfam>You could make more build users too, of course. 10 is probably not enough for 64 cores <nckx>vagrantc: It seems like container support was added using trial & error. ‘Oh, I had to do X to get it to work, let's throw an error if X can't be done.’ <davexunit>nckx: my proposal is to try calling clone with just the user ns flag <davexunit>if you can fork that way and exit 0, return #t <vagrantc>that seems better; test for the feature ... <davexunit>when I originally wrote that procedure I thought this file was present everywhere and thus was a canonical way to test for the feature <nckx>I'm rebuilding my kernel with NS support to do some trial & error (& hopefully get a patch out of it beyond ‘why don't we just’) but I'm on iteration 3 and losing patience. Now I had to enable CONFIG_POSIX_MQUEUE or ‘guix environment -C’ throws a fit... why? <vagrantc>davexunit: i think it was more of a Canonical, Ltd. way ... heh. :) <nckx>I'm sure it doesn't use POSIX message queues. Who does. <zimoun`>lfam: yeah especially with bug#42371. *nckx files it in the ‘file a bug, maybe, later’ box. <davexunit>vagrantc: yes, seems so. didn't realize that back in 2015 or whenever. <vagrantc>and the reason it's cropping up now is someone "fixed" it by making it break on guix system? <nckx>I think that's the gist of it. <vagrantc>oh, wonder if this is one of the tests i had to disable for the guix builds in Debian <jonsger>is it possible to copy a file from an input? <nckx>Yes. But your question is quite broad. <jonsger>nckx: so how would I copy bin/foo from an input to the output of a new package? <jonsger>where bin/foo is just a wrapper script not an actual binary <lfam>I wonder, what would be the easiest way to send a "failing test suite reproducer" to an upstream project? <nckx>jonsger: (copy-file ...) or its variant (install-file ...) + (assoc-ref inputs "foo"). <nckx>(install-file (string-append (assoc-ref inputs "grep") "/bin/grep") (string-append (assoc-ref outputs "out") "/bin")); something like that. <nckx>Wrapper scripts created with wrap-program should be self-contained (no relative paths) so it should just work. <nckx>If someone else wrote the wrapper, you might have to get out the substitute* cannon. <jeko>Day 3… I still can't figure out why guix deploy can't connect to the target. 😭️ <nckx>jeko: I've only used guix offload, not guix deploy, but my first step is always checking whether ‘sudo -i ssh <remote user>@host’ works. If it prompts you interactively for anything, that was the/a problem. <jeko>nckx: i'm going to try that right now ! <nckx>I don't have anything to deploy to or I'd have more useful suggestions :) *nckx guix deploys guix to their laptop running guix, because system reconfigure is too boring & reliable. <jeko>nckx: asking for password is the king of interactive prompts you are talking about ? <nckx>Hm, no. More things like populating (root's) known_hosts, which Guix doesn't do by default but does rely on. <nckx>I guess you could try explicity passing -i <identity file> to skip the password prompt, and maybe trying without sudo -i (if deploy doesn't run as root like offloading does). <nckx>jeko: It was just a wild sugguesstion. What happens when deployment fails? Any error message? <jeko>nckx: the only thing I get is "guix deploy: error: SSH connection to 'yournextmeal.tech' failed: Connexion refusée" not much verbose <jeko>I successfuly deployed as a regular user in the past <nckx>jeko: And you've configured your machine-ssh-configuration with (port 2222), not 22? (Yes, I peeked.) <nckx>jeko: And now you're deploying as...? <jeko>yep, I can easily "ssh root@yournextmeal.tech -p 2222 -i ~/.ssh/id_rsa.pub" <jeko>I am still trying to deploy as a regular user I mean doing `$ guix deploy …` (not # guix deploy …) <nckx>You don't have any custom cypher suite settings or anything that could interfere with Guix's slightly-less-capable-than-OpenSSH-no-it's-not-OpenSSH libssh client? <jeko>I remember having installed openssh-server and then it felt not working <nckx>jeko: I recommend sending a bug report to bug-guix at gnu dot org if you haven't done so already. <nckx>I'd love to help but can't do much. <nckx>A quick test deploying to a VM here works. <jeko>could you share your config file ? <nckx>Uhm, I just deleted it, but it was just a shameful copy-paste from the info manual. <nckx>Be sure to include your configuration file if you file a bug. If you redact it, try to do so in a way that keeps it working without modifications. <nckx>Then I'll try to reproduce that. <jeko>sure, thank you for your help! good night !