IRC channel logs
2023-01-23.log
back to list of logs
<Guest53>but would also be interested in a guix example <webantipode>Guest53: You can't, encrypted files will confuse Guix' garbage collection. <webantipode>Unless you are very careful to _not_ encrypt the ~/.guix-profile and all other GC roots. <rekado>only if it needs to read anything from the encrypted home (e.g. .guix-profile or GC roots) <rekado>same issue with GC roots on transient NFS mounts <surpador>Are there any known problems with perl-gtk3? The very basic example code on CPAN <https://metacpan.org/pod/Gtk3> throws a bunch of critical errors, and I'm not sure if I'm doing something wrong or there's a problem with the package in Guix <elb>so what's the best way to test a patch to the guix package tree on my own system? <elb>assuming I've checked out the guix tree and inserted a package <elb>ok, I think I found it in Building from Git <elb>ok yeah this is what I need, the other thing was ... not helpful <elb>or at least I didn't understand it <surpador>If you haven't build yet, you'll probably need to build first, but yeah then just prefix Guix commands with `./pre-inst-env` and it will work on your local tree <elb>yeah I'm building, but when that's done, it's the ./pre-inst-env I needed to know about <elb>I did the guix shell -D guix --pure bit to get a bootstrapping environment, it's now building <elb>perfect, patch on its way :-) <mirai>I've managed to tame the docbook-xml packages <mirai>no longer it is needed to cargo-cult substitute* magics or other kinds of regex trickery <surpador>If I'm patching a package to look for a data file in the store instead of a system directory (e.g., in #$output/share instead of /usr/local/share), should I also patch the provided man pages to note that change? <mirai>surpador: the build system may already handle this <mirai>the pulseaudio manpages show this <mirai>but in case your build-system doesn't, I think it'd be nice to patch them as well <mirai>its better than pointing to "imaginary locations" <surpador>Ok, got it. Yeah, doesn't seem to be working for the package I'm working on <mirai>if possible, try to get it fixed upstream <mirai>if the manpages are processed through M4 for example, it shouldn't be too hard to change it to depend on DESTDIR from the build system <surpador>Oh gotcha. I'll take a look at it and see what I can do. Thanks for the help! <Guest53>webantipode: rekado: Oh! I've been blabbering about my approach to Erase Your Darlings, in which most state is relegated to `/persist` because the root is constantly rolled-back or even tmpfs'ed; <Guest53>In applying the same approach to `/home`, the GC roots are going to be in a separate (BTRFS) volume anyways, so I might actually be able to implement this <Guest53>(doesn't add as much as a single-user w/ FDE, but since when has utilitarianism stopped me?) <Kolev>Can I install Guix inside a container? <Guest53>am going to bed, spelling (and debugging) are rapidly deteriorating <Kolev>Could not install Guix inside container. <efraim>I keep hearing about zig switching to self hosting but right now it looks like even in 0.10.1 it can still be bootstrapped from the C source and then it recompiles itself <civodul>i saw a post about them ditching the C++ code base <civodul>maybe it's for the next release or something? <efraim>From the best I can find they have an alternate stage1 at github/zig/zig-bootstrap which (now, after the 0.10 branch) uses a wasm binary built with zig to bootstrap stage2, which would then build the stage3 final zig. right now stage1 is build using C++ <efraim>it looks like the 0.10.1 release builds and passes tests AND greatly decreases the memory needed to build it. If so we can use 0.10.1 to bootstrap future zig releases if necessary <efraim>took about 3x as long to run the zig tests as to build zig on my machine, 18 minutes to build, 50 to run the tests <ssb>Kolev, I tried that and failed (someone please correct me if I'm wrong) -- there is no user-friendly way to do that. Yes, there is 'guix system container' but the resulting container is read-only, you cannot using "guix build" or whatever inside it. I found no other way to install full-fledged system in the container, and no way to use ('chroot' into) existing guix system from a foreign system. I think that <ssb>is a major omission. <rekado>ssb: you can use “guix build” inside the container if you expose /gnu/store to the container (rather than just the default subset), bind the daemon socket in the container (or share network to talk to the daemon on the outside), and have a “guix” executable to serve as a client. <rekado>since this will talk to the daemon outside of the container it will modify /gnu/store, which is fully exposed, so the results are visible in the container. <ssb>rekado, that assumes you already have working guix daemon outside the container. Which is not my case, unfortunately. <ssb>that is the whole idea -- to have working guix system inside a container (forget chroot, okay) from another, foreign system. <mroh>did someone wrote an udev rule that refreshes the avahi substitutes discovery cache on laptop lid open? <civodul>mroh: hi! i don't think udev has anything to do in there, but i agree the cache isn't getting refreshed <paul_j>There is a small typo in the blog post he put up - there is a line about half way through: (write-derivation drv (current-output-port)), which I think should be (write-derivation manual-drv (current-output-port)) <gabber>i need to acquire an IP address via DHCP (with WPA athentication) but i also need to configure entries in resolv.conf. what is the way to go? (static-networking) won't allow leave the addresses-field blank and i'm not sure how to otherwise set resolv.conf <apteryx>anyone else using gglobal in emacs? 'find reference' never seems to produce anything, although git grep finds some <apteryx>interesting, after 'rm GPATH GRTAGS GTAGS' and issuing 'gtags' manually, global -r now returns something <apteryx>I guess it's down to gtags vs ctags (by default ggtags-create-tags prompts and if you say yes it uses ctags) <bjc>you probably want the ‘extra-special-file’ service, and you'd put that in the top-level ‘services’ field, not in ‘modify-services’ <bjc>that said, if you're using dhcp, that file may get clobbered by your dhcp client anyway. i'm not sure <gabber>bjc: thanks for the hint! i'm not sure about your assumption; i have a somewhat unusual (?) network config where i have to define nameservers and domains in my resolv.conf but still retrieve my actual IP via DHCP -- at least that's the way it works on my Debian machine <bjc>yeah, it'll depend on how your dhcp client is set up. i think the default is to have it write out resolv.conf based on the nameservers your dhcp server sends, but ymmv <mirai>resolv.conf is handled by nscd iirc <apteryx>network-manager on my desktop system <mirai>Could #60634 get some eyeballs on it? The later it gets, more and more documentation keeps getting added with the inconsistent styles <tschilptschilp23>Hi guix! Do you have a hint using emacs-orgmode tramp remote command execution from guix on foreign hosts? My problem is, that I receive a '/bin/sh: 1: /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/bash: not found' when issuing a small script on a host after authentication. Is there a way to tell tramp to use the remote shell? At work in our debian/ubuntu world this conflict does not appear, as it's all '/usr/bin/bash'. <apteryx>jokes in the source: (define-public global ; a global variable <gnucode>so, I put my guix-deploy.scm file in a public repo...Is that considered bad practice? Is that the same as putting my root password online? <tschilptschilp23>OK, got it. I must specify 'bash' and not take the semi-wildcard 'shell' ;) <greenfork>Hi, I'm trying to find information on what is stateful and what is stateless in Guix System. I don't seem to be able to find it in the docs, could you please share a link to some resources on this? <gabber>greenfork: what do you mean exactly? are you referring to the "package manager" or the system? IIUC you can configure your operating system, your custom software package as well as your very personal home configuration in a stateful manner <greenfork>gabber: I have read bits about "not changing anything in /etc because it will be overwritten with the next reconfigure", I'm trying to understand what would be an "ecological" way of keeping state on my system but as little as possible <greenfork>What to do and what no to do. I'm deploying Guix System on VPS so it is referring both package manager and the system <gabber>there's a small paragraph in the manual (section 1.2 GNU Distribution): "With Guix System, you _declare_ all aspects of the operating system"). usually you want to put *everything* into your system-config file, because then your system only relies on changes in there. what state do you want to keep? what do you mean by ecological? <PotentialUser-19>Hey two quick questions: Does Guix work on aarch64, and what's the experience like compared to NixOS? <gabber>PotentialUser-19: yes and i don't know NixOS. But if you ask for opinions here people will most probably tell you how much better Guix is in every aspect possible ;) <greenfork>Right now I will need a file for a SQLite database, some directory for videos. And I assumee I might compile a program that is not declared through the config.scm file. Are there any "dangerous" directories that I cannot touch so that my things don't get overwritten? <PotentialUser-19>Lmfao that's fair and to be expected. I guess I should ask about what sucks then, like what are the pain points you experience gabber? <greenfork>"Ecological" means being in harmony with the rest of the system, following conventions, not interfering with the intended way of the system configuration <mirai>PotentialUser-19: the perceived vantage from NixOS is that they've been longer <gabber>greenfork: i see. i would try to configure all aspects of the system (that is, stuff that should /just work/, without any specific data) through a system config file. i'd configure everything that goes into /etc through the config-file. if you need (empty) files and directories you could manage them like-wise -- but i guess Guix is adaptive enough to be used in a manner that suits you best <greenfork>gabber: Alright, I understand that following just these basic conventions should keep me out of trouble, thank you <mirai>PotentialUser-19: it's written with a programming language (than a DSL) <mirai>you get more flexibility here <mirai>In theory, the syntax is also "easier" (it's just parentheses) <mirai>there's also some interesting guix utilities (weather, etc.), you'll have to read the manual <PotentialUser-19>Okay. And does guix only work with GNU/Linux or does it work with GNU/Hurd as well? <mirai>I've never tried the hurd kernel <mirai>I'm not too sure about this part but in theory you could bolt guix on other kernels <jpoiret>i've tried it once in Qemu and it's surprisingly easy to just spin up a hurd machine <mirai>be it *BSD or Windows NT (when hell freezes over) <jpoiret>you'd need something like linux namespaces, which i don't think these two have <jpoiret>well, or you could run the daemon without any isolation but then that would make things harder to diagnose <gnucode>I am seeing some weird behavior in guix deploy. I have changed the nginx service, but after I deploy it, the nginx service still doesn't have https support.... <gabber>gnucode: did the service restart? <gnucode>gabber: it said it did. And I rebooted, but after running guix system list-generations ... guix deploy is not creating a new generation. So for some reason the old configuration is still in use... <gnucode>I was using the -x -- sudo herd restart nginx command. <gnucode>gabber ok now it is working. It seemed like "guix deploy config.scm -x -- sudo herd restart nginx" did not actually deploy the latest config.scm. But "guix deploy config.scm" did. Weird. <gabber>gnucode: might be a bug? or something to be more clearer described in the manual? sorry, i lack experience with that command <gnucode>gabber it took me 2-4 hours to reset up my server with guix system. I am estimating, because I don't know the actual time. Suppose your server crashes, you lost all your backups and all that you have is your config.scm. How long would it take you to reset up your server do you suppose? <gabber>gnucode: i don't have such a server running ATM, but if i had all the system specifics in my config.scm i'd be way faster than with most other distros :) <mirai>gnucode: are the certs present? <gnucode>mirai: I had to configure nginx to run w/o certs first. Then I set up certbot. Then I ran /var/lib/renew-certificates <gnucode>but I also just set up the default firewall...and possible locked myself out of the service again. and blocked http and https traffic... <mirai>and did you herd restart nginx <mirai>this is a native guix install right? <gnucode>mirai nginx works now. That's fixed. It's guix system. Now I'm onto the new problem of "Oh dear Lord I set up the firewall and now I cannot connect." <mirai>what's the nftables service config? <gnucode>mirai: that's what I used, except that I forgot that I set up ssh to use a nonstandard port... <gnucode>I had an ssh session going on the non standard port, and I figured that " ct state { established, related } accept" would let me current ssh session stay alive. Apparently not. <gnucode>Apo11o[m]: what's the issue with Jekyll ? <mirai>gnucode: are you familiar with nftables? <mirai>I see that %default-nftables-ruleset comes with this description: This service comes with a default ruleset %default-nftables-ruleset that rejecting all incoming connections except those to the ssh port 22 <gnucode>mirai I set up my ssh to run on a non standard port. It's not accepting connection on port 22. :) <gnucode>ssh -p 24953 joshua@gnucode.me That's how I connect. Except I use a different port. :) And no I'm not really familiar with nftables. Trynig to get better at it. <mirai>any reason for setting nftables this way? <gnucode>mirai I want to use endlessh on port 22. :) <Apo11o[m]><gnucode> "Apo11o: what's the issue with..." <- Just found this https://issues.guix.gnu.org/57083 I’m not familiar with ruby but setting up themes etc. with gem and bundled produces errors. Will check again if someone has posted any solutions <gnucode>well linode's lish worked for me to turn off nftables. <mirai>gnucode: oh, you want to plant some pranks there <apteryx>I figured out my emacs-ggtags issue; ctags (the tags generation backend it suggests by default) doesn't support GRTAGS (reference tags) <apteryx>you can use the builtin pygments plugin like 'GTAGSLABEL=pygments gtags' which supports it (but it's much slower) <apteryx>I'll add a note to the emacs-ggtags description <gabber>apteryx: IIRC the standard "ctags" is somewhat ancient -- i usually generate tags with the universal-ctags package (i.e. `guix shell universal-ctags -- ctags -e -R`) <apteryx>our global package is confused to use universal-ctags by default <apteryx>the tags created with 'ctags -e -R' are not picked up by emacs-ggtags, it seems <gabber>huh. i have never used ggtags -- but the -e implies Emacs style ctags (i don't know whether and/or how these are related) <gabber>how can i distribute a set of IP addresses to client with dnsmasq? i'm missing fields like "dhcp-range" or "dhcp-option" in dnsmasq-configuration in Guix. <old>I want to update lttng-modules (kernel module) from 2.13.6 to 2.13.8. However, the build is not reproductible anymore. How does one usually fix that? <old>I would for starting to see which files are not the same between two rounds <gabber>old: there's utilities to inspect differences in binaries e.g. diffoscope. i'd suggest that if there isn't something more obvious that you could deduct from the sources itself (like including the build date/time or some random number being included) <old>gabber: But how can I get the final two directories for comparaing the outputs? <old>I only get the first succesful output <apteryx>old: ./pre-inst-env guix build lttng-modules --no-grafts --check --keep-failed <gabber>how did you find out the builds aren't reproducible? <apteryx>then diffoscope /gnu/store/...-lttng-modules...{,-check} <apteryx>old: basically you need --keep-failed, or -K <old>gabber: with like apteryx shown <old>Okay thank you I will try that <old>I do: `./pre-inst-env guix build lttng-modules --rounds=2 <old>ahh okay it works nice. Thanks apteryx <apteryx>you can export GTAGSLABEL=default in your ~/.bash_profile in the meantime, if you want reference tags. <apteryx>or GTAGSLABEL=pygments, but that's very slow and I'm not sure what are the advantages <old>Looks like the Build ID of some kernel module are different <apteryx>you can probably take a peek at debian or yocto to see what they do to have them reproducible <apteryx>perhaps we can set it to some static value <old>Looking at the assembly generated is sometime relocated someplace else <old>Eeh maybe. It could be the order of the files passed in the Makefile that is not deterministic <old>If that is the case, the linker can do the links in different way <old>generating different offset in the final binary <apteryx>if that's the case, there's the 'sort' function in Mak <old>I've also looked at the full diff history from 2.13.6 and 2.13.8 <old>I think it's the kernel or the linux-build-system. I'll try to test on a common kernel version to remove that variable <apteryx>if it was the kernel or linux-build-system, every kernel modules we build would have reproducibility problems, no? <old>No necessary. I'm trying with some CONFIG_ turn-off <old>things la RETPOLINE=n and SPECULATION_MITIGATIONS=n <old>Indirect calls are pass through a trampoline for security measures, which could be the reason it's not reproducible <old>Is there a way to get the CONFIG_* of a kernel btw? Without looking at the auxiliary files in gnu/packges/aux-files/linux-libre <gnucode>man I really do not understand nftables... <gnucode>I thought the default ruleset would block http and https...apparently not. <lechner>gnucode / i publish my deployment specs, too. why is it a security risk, please? <gnucode>lechner I was not affirming it was a security risk. I was asking. Is it a security risk? <dokma>One thing that irritates me about apt is that I cannot say: "I have this package installed because I wrote this script that uses it, don't count it as unused." <dokma>Does guix have some way of handling locally made dependencies? <vagrantc>dokma: a bit off-topic, but you can totally mark packages as manually installed in debian :) <lechner>dokma / in debian, aptitude can track such relationships for you <vagrantc>but guix can handle that even more explicitly <vagrantc>guix will never (barring huge bugs) remove anything in a currently available profile <gnucode>mirai: (service nftables-service-type) is apparently good enough for me. that's pretty cool. <lechner>Hi, do i have to explicitly declare the input 'gnutls' if my program uses a module (guile-irc) that in turn uses gnutls? <lechner>even though guile-irc already declares the input gnutls? <dokma>vagrantc: that just lists them as manually installed or I can say my script /path/blah.scm depends on this package, don't uninstall the package if that script exists? <dokma>lechner: what is the name of this feature? <lechner>dokma / you can use the keys m/M to mark and unmark in aptitude. will get more for you in a minute <lechner>dokma / in aptitude, you can also search with '/' for '~i ~!M' for automatically installed packages to clean up manually (with '-') <lechner>dokma / i think the apt equivalent is apt-marks <daviid>can someone here confirm that guix do package gir files 'in sync' with their lib version? <vagrantc>dokma: don't quite follow what you mean exactly ... but too much discussion of debian-specific details seems a bit off-topic <mirai>lechner: unless guile-irc has gnutls as a propagated-input <mirai>I think you'll have to include it as well <vagrantc>guile needs to propegate inputs? i thought the compiled .go files would include references? <mirai>gnucode: I personally prefer the applications (http, etc.) to handle proper auth than to employ firewall filtering <mirai>unless it's strictly something that doesn't need access from the outside <mirai>vagrantc: I'm not too sure about this, it's my take from the description of propagated-inputs <mirai>it might not be necessarily true for some build-systems though <lechner>i am not sure i will ever understand the prerequisite handling in Guix <apteryx>vagrantc: I don't think it does record any load-path in its .go, so you must propagate in guile just like you'd do in python, unless it's a script you can wrap <lechner>i added gnutls, but somehow that seems wrong to me <vagrantc>ok, if apteryx says so, i'll back off :) <lechner>apteryx / some people say propagated inputs are evil <vagrantc>that would actually explain some things for the guix package in debian ... about why i need to constantly rebuild the guile-* and guix packages all the time. <vagrantc>propegated inputs are an unfortunate necessity <vagrantc>they make it hard to have mutually incompatible things in the same profile <apteryx>lechner: they are prone to conflicts, but for dynamic languages without baked run path, they are necessary <apteryx>it's best to avoid them where possible <lechner>apteryx / why are the inputs declared in guile-irc at all, then? <apteryx>if your guile irc bot is a script rather than a library for example, it's best to define the guile as regular inputs (not propagated), and wrap the script with GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH. <lechner>i switched to the guile build system. do i have to do anything for the PATH stuff? <apteryx>I think so; since installing binaries under bin/ is not handled by the build system directly, even less wrapping these <lechner>apteryx / i just declared 'gnutls' as an input. do i still have to do anything else? if so, do you have an example? <apteryx>what does it use from gnutls? scheme modules? <apteryx>so guile-irc should propagate it instead, it seems <apteryx>confirmed by guix gc -R /gnu/store/j7sj5hp6g3jzj38y03b6khlsd6jn6mz4-guile-irc-0.3.0-1.7d08ce6 <apteryx>it doesn't keep any known reference to gnutls <apteryx>so it should propagate its runtime inputs for users to have what they need <futurile>I keep being told that there is no such file or directory - when there is. So obviously 'user error' - but cannot figure it out for the life of me! <futurile>I don't have enough guile knowledge to know how to debug it - so a git stuck! <jpoiret>futurile: probably need to (mkdir-p (string-append out "/share/applications")) first <lechner>Hi, what's the gexp way for (assoc-ref inputs "guile") please? <lechner>just (which "guile") if i need the executable? <jpoiret>you want #$(this-package-input "name") <jpoiret>i'm not saying there aren't any instances in the Guix codebase :) <futurile>jpoiret: that works - and now I feel a bit "duh" - thank-you <jpoiret>but it's better to say either #$(this-package-input ...) or #$(this-package-native-input ...) depending on if you need it for compilation or to run <jpoiret>i mean, if you need it natively or for the target... :p <lechner>jpoiret / thanks for the pointer. i changed it <jpoiret>let's say it's better hygiene, that way more "novice" Guix hackers will not try to use (which ...) instead of #$(this-package-input ...) when e.g. patching exe paths, which would result in cross-compilation problems! <lechner>Hi, is there a #$(this-package-output) or is it just #$(this-package) ? <mirai>+ (lambda* (#:key inputs #:allow-other-keys) <mirai>+ (let ((xsltproc (search-input-file inputs "/bin/xsltproc")) <mirai>use search-input-files instead of which <lechner>i have before and remember people like that better. jpoiret? <lechner>mirai / it's called search-input-file (singular), isn't it? <mirai>I recommend the search-input-file over this <mirai>you're not supposed to directly reference the dependency (or so I heard) <lechner>okay. i'll switch, although i hope my fix for "env -S" is temporary <mirai>note that you have a specific phase for handling shebangs <mirai>I think it was called 'patch-shebang <lechner>should there be a warning for references to phases that do not exist? <apteryx>jpoiret: doesn't install-file do mkdir-p on the parent itself? <lechner>mirai / i don't know, because it linked to an earlier build but the string was not replaced <lechner>it worked when running after 'patch-source-shebangs but i have no idea why <lechner>maybe cwd is being changed in between <lechner>i don't think it find the input file to modify <jpoiret>lechner: search-input-file is best if you can use it <jpoiret>but if you have to refer to a specific dependency by name and search-input-file isn't enough, this-package-input is the way to go <jpoiret>but for some reason it seemed to have solved their problem? <jpoiret>futurile: by the way, rereading your snippet, I realize you aren't using the new g-exp format <lechner>thank you all for helping out a noob. my technical acumen is poor but i have endless optimism for the project <jpoiret>lechner: no need to self-deprecate, the distinction between all of these methods is 1) tenuous 2) not documented enough 3) nowhere does it say what style should be used preferrably <davidl>so I wanna submit a package called wayvnc, which I have added to gnu/packages/vnc.scm. It had 2 dependencies which I also added there, which don't seem to be used for much except as dependencies to this package and possibly others by the same author. Do I have to split this to 3 commits, or can I just submit a package like "gnu: add wayvnc with dependencies..."? <davidl>(2 dependencies not already in guix*) <jpoiret>that's just the way it is, but that also means you don't have to think about it <jackhill>hmmm, flatpak doesn't seem to plumb through fonts into the container propery. I'm guessing they don't like our unusual paths :/ <lembrun[m]>i'm trying to run qemu-guest-agent-service-type but the service just poops itself at startup <lembrun[m]> '/dev/virtio-ports/org.qemu.guest_agent.0' does not get created for whatever reason <lechner>Hi, why would a Guile script running in 'guix shell' say "no code for module (rx irregex)" even though guile-irregex is an input. The error also occurs when the inputs are propagated <lechner>but there is no temporary profile in GUILE_LOAD_PATH or GUILE_LOAD_COMPILED_PATH. I am using the Guile build system with 'guile-3.0' as an input <dokma>lechner: yeah, that just marks packages as being installed manually, meaning don't uninstall this package even though nothing depends on it. <jpoiret>lembrun[m]: there's probably a bug with qemu virtual machines right now with 6.1 <dokma>lechner: what I need to say is: "I'm installing this package because my script /path/blah.scm depends on it. If the script is present, the package is needed, otherwise, if nothing else depends on it, the package can be removed." This is quite different from marking a package as installed manually. <lechner>dokma / maybe you need to package your script <dokma>lechner: yeah, that would be one solution. But it is a huge overkill for a small script. <dokma>let's say I write a 10 line script that needs some package. <jpoiret>lechner: do you have `guile` listed as an input for `guix shell`? <dokma>All I need is to quickly tell my package manager that this script depends on some package. <dokma>I don't think apt has this ability. <dokma>But I suspect guix might have, which is why I'm interested in it. <jpoiret>lembrun[m]: the lore conversation I posted above <jpoiret>I'm not sure this is the issue but it might be <jpoiret>lechner: can you post your package definition? <lechner>dokma / debhelper will only need a few files from you. d/copyright, d/control and d/install <jpoiret>can you first paste the etc/profile file from the profile guix shell creates? <jpoiret>i'm pretty sure you need to propagate your guile libraries by the way <jpoiret>it's true that Guile is not just interpreted, you can compile it and so it will hold references 🙄 <jpoiret>yeah no they were right, I'm just spreading disinformation <jpoiret>well yeah here's the deal, your input libs should be in native-inputs <jpoiret>why that isn't the case for packages in guile-xyz.scm i don't know <jpoiret>it's a nightmare, some of them are in propagated-inputs, some in native-inputs, and some in inputs <lechner>jpoiret / changing inputs to propagated-inputs yields the same profile <jpoiret>ah, that's a shame, let me try on my own machine first <lechner>jpoiret / please run the bot like this, if needed guix-helper-bot --channel="#felix" <jpoiret>i'll just try with a sample package first, it's not directly related to your package <jpoiret>what command line are you exactly using? <jpoiret>ohhhh, my bad, that's how you want to use it <jpoiret>let me find the "idiomatic" way to do that <jpoiret>i'd suggest wrapping the script using wrap-program, and adding GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH through it <jpoiret>you can look at guile-smc's package definition <jpoiret>but make sure not to use (assoc-ref inputs ...) <lechner>thanks! yeah i know all about search-input-file now <jpoiret>it'll probably be hard to use search-input-file for this though, i'm not sure what the best way of writing it would be <jpoiret>the good shortcut would be to wrap with GUILE_LOAD_PATH set to its value inside the build environment, but I'm not sure of how it would interact with cross-compiling <jpoiret>(that's how a lot of packages do it) <rekado>lechner: see also goggles-bot-program in maintenance.git:hydra/modules/sysadmin/services.scm 