IRC channel logs
2025-12-06.log
back to list of logs
<FuncProgLinux>Installing guix on a foreign distro (openSUSE via zypper in guix) has wrong instructions for the unprivileged daemon: <FuncProgLinux>which: no nologin in (/home/fplinux/.npm-packages/bin:/home/fplinux/.deno/bin:/home/fplinux/.local/bin:/usr/local/bin:/usr/bin:/bin:/snap/bin) <FuncProgLinux>That happens because the $(which nologin) command returns nothing on OpenSUSE since it's at /sbin/nologin. I've fixed it but shouldn't that be a warning for new users who might not have a clue? <mwette>FuncProgLinux: Try installing as root (and # . ~root/.profile maybe). Most unixes have nologin in /sbin or /usr/sbin, I believe. <mwette>Maybe script should check for root-like environment. <FuncProgLinux>mwette: I used the manual steps since those list OpenSUSE installation as "zypper in guix". I think that particular system is an exception. AFAIK when something is in /sbin it's not mean to be in the $PATH thus why the $(which nologin) is not caching it. <mwette>I think there are errors in the manual. You should also look at the install.sh script from guix.gnu.org -- e.g., update /etc/subgid needed. And when you guix pull to get the updated stuff and replace /etc/systemd/system I think the guix-daemon.wants dir may need to go away. <mwette>Things in /sbin were originally (1970s or 1980s) meant to be in root's PATH only. <Noisytoot>I upgraded relatively recently and now mpv seems to be affected by the same 100% CPU usage on wayland bug that I patched it for on alpine <basicnpc>If my project depends on some other libraries, but I want to make some quick changes on the libraries, what should I do? Should I patch the library? Or is there some easier, temporarily mutable way? Or can I temporarily make that lib not read-only, and make change directly in guix store? <pomel0>sorry for the late question, but my laptop with guix hasn't been updated in a week or so (probably a bit longer) and when trying to run `guix pull` it tells me the SSL certificate is invalid (same with browsing the web and trying to update flatpaks) <pomel0>any way I can manually update the certificate to update guix? <pomel0>I also see shepherd somehow occuping 200% of my cpu sometimes <ieure>pomel0, Guix system or foreign distro? <ieure>pomel0, Is your system clock accurate? `date' will tell you. <pomel0>who would've though disconnecting the bios battery would reset the system's date? <pomel0>checking the system date with `date` it shows the correct time <ieure>ntp may have fixed it in between the two commands. <pomel0>but guix pull will still not work? <ieure>FYI there are a lot of Guix users around the globe, good chance someone is online here 24/7. <pomel0>but it's not just guix it's flatpaks and sites too that are not working because of ssl <pomel0>so maybe shepherd checks for system time before ntp can fix it? <ieure>Don't think Shepherd has anything to do with thiat. <pomel0>but the other thing, my system is going really slow <ieure>What's your $SSL_CERT_DIR set to? Does the directory exist? <ieure>htop in a terminal will show you what's eating CPU <pomel0>ieure: that's the problem, top shows shepherd as 100% cpu usage <ieure>For me: SSL_CERT_DIR=/run/current-system/profile/etc/ssl/certs <ieure>I can't reproduce your problem, FWIW, I can pull fine. <ieure>Is it full of symlinks into the store? <pomel0>I wish I could answer you, but my system is hanging just by using sudo lol <pomel0>I can't think of any reason it's doing this <pomel0>do computers have something like processor leakage? lmao <pomel0>ieure: it's full of .pem files, my ssl certs folder <pomel0>after that, maybe I'll roll back? see if that does anything? <ieure>Probably a good idea, I might try a reboot into the current generation first, just to see if Shepherd stops freaking long enough to investigate more. <pomel0>I mean I assume this is an issue with me not updating my system in a long time, but it's weird that the non updated system has new errors that weren't there before <pomel0>yeah it's working with a rollback <pomel0>but thank you rollbacks for existing <pomel0>problem is... I don't really remember the changes I made to the config lol <bdju>Trying to attach to my tmux session over ssh like I do all the time, getting this error suddenly: open terminal failed: not a terminal <bdju>The guix machine is the remote end, zsh as shell, ran upgrades decently. Trying to ssh with my phone running termux. I can still ssh to other non-guix (arch) machines fine from my phone. <rrobin>does anyone happen to have a mirror of the guix days 2020 videos? I am looking for the 'Bootstrapping the Java Ecosystem' one but all links seem to be down <bdju>I figured out the tmux issue, need to restart tmux after upgrading from 3.5 to 3.6. There's an open issue mentioning it on their GitHub repo. <untrusem>I get this when I try to run appimages in a guix shell <untrusem>guix shell: error: statfs: : No such file or directory <Rutherther>well then it's most probably that the appimage depends on something of the base system that you still do not have in the environment <untrusem>but yeah it uses shell container with fhs <Rutherther>I don't think it has much relation to the github issue you sent <Rutherther>not all appimages run on all systems, the appimage has to be carefully made so that it's self-contained <Rutherther>running podman in guix shell --container is special because it makes container inside of a container. As long as your application isn't doing that, it could be fine to run if you add proper packages to the environment <Rutherther>in case it is actually doing that, that would have to be taken care of in how guix crafts the container and is not really easily customizable, for now... <untrusem>so I think its trying to access guix binary <Rutherther>why would it do that? - what app are you running? <Rutherther>no, that's very early, well before the appimage runs <Rutherther>this is the shell itself running. You need to run the strace in the container, not "strace guix". "guix shell ... strace -- strace appimage". The output you sent is the shell/other program finding guix in PATH <Rutherther>and it did find it at ~/.config/guix/current/bin/guix, so it's not even any error <untrusem>i straced the ./run-app-image.sh helium.appimage <untrusem>the thing it is not entering the container <untrusem>it errors out and throws me back into the shell <Rutherther>it is expected that you arrive back in your original shell when the child process exits, that's the feature of using "guix shell -- command". When command finishes, the whole guix shell is finished <Rutherther>if it isn't running the container, the error is elsewhere, not in the appimage <Rutherther>then okay, the issue is not the appimage at all for now, it's how the guix shell is ran <untrusem>thought it error out when it can't find fusermount binary <Rutherther>I see then, yeah, this is a problem. I suppose the issue is that it tries to find "fusermount", but we have "fusermount3". So probably will need a new package that will symlink it <Rutherther>of you can try setting FUSERMOUNT_PROG env var to "$(guix build fuse)/bin/fusermount3" <hanker>what's the guix-ish way to install a symlink to a program in my $PATH ? <Rutherther>to make a package with trivial build system and do symlink to the original package <Rutherther>hanker: ie. https://paste.debian.net/1412564/ it wouldn't have to be a package, but packages are easier to work with, easily put to manifests, unlike "computed-file" (but it's still possible to get that into a manifest, just not as easily) <hanker>perfect, that's just what I needed <basicnpc>If my project depends on some other libraries, but I want to make some quick changes on the libraries, what should I do? Should I patch the library? Or is there some easier, temporarily mutable way? Or can I temporarily make that lib not read-only, and make change directly in guix store? <basicnpc>And by the way, are there some famously well written and versatile guix configs that I can read and learn from? <identity>basicnpc: there is no way to make anything in the store temporarily mutable, this would violate the basic principle of immutability. monkey-patching a cache (which is what the store is, in essence) only leads to spilled tears <identity>your best bet is to take the package definition and apply a patch through the ‘patches’ field of the ‘origin’ record <basicnpc>If I really want, sudo undo readonly.. and modify the store, will guix be able to recover by itself? <identity>basicnpc: it will be a headache to write to the store and a slightly smaller headache to repair the store, let me just say <identity>that would void you warranty. if you had one, that is <janneke>basicnpc: not sure what you mean by 'quick changes on library', but if you mean binary patching, you can always write a new 'lib-patched' package using the copy-build-system, patch the binary, and use/depend on that new package <janneke>but what identity says: just change the library's package; changing the store can only end in tears <basicnpc>For example, adding a working python manhole in a python lib, to better inspect that internal of that lib. <janneke>basicnpc: if that's all, why don't you copy over the python package from the store, edit the file, and juggle with PYTHONPATH? <basicnpc>Yeah.. I was just wondering if there's some easy way to 'fork' some package in the guix store. <janneke>basicnpc: you can probably do everything programatically too, overwriting anything in a python module at runtime? <basicnpc>Right, there are workarounds. But wouldn't it be great if I can jump into a store, get into edit mode for some package, and have whatever the result saved as another package? <basicnpc>That 'temp package' will be usable before it's gc'd. <basicnpc>And it seems to be a better workflow than the workarounds we have. <basicnpc>Why? I'm not saying that we should literally edit the package. But that guix should provide an interface for that kind of temp change. <janneke>for me, before we had guix, reproducibility has been one of the hardest and most annoying problems to debug and fix <janneke>now it doesn't matter what computer you're on, or who is on it, and you can be certain if it works for you, it works for everyone (given they use the same guix commit) <basicnpc>Yes, but I'm saying the end of the edition can be identified as a new hash, and in our own project, we just depend on that new hash. <Rutherther>basicnpc: the workflow you envision is very hard to do. All packages depend on the source of the package, the hash depends on what the source says to build. If you just save the result as another directory in the store, it's impossible to refer to it from other packages. That's why you instead change the source so that you can have something you can refer to <janneke>basicnpc: in that last scenario, you wouldn't modify the store, but "just" adding a package using an unusual, (non-declarative, non-reproducible?) package build? not unlik my copy-build-system suggestion, so that could be acceptable, if you can pull it off -- also, what Rutherther says <janneke>basicnpc: what you would probably want, if that if you have a package in your store, anoyone else can also create that package in their store; or after a guix gc, power failure, disk corruption, you should be able to re-create it yourself? <Rutherther>"(package ... (inputs (list hello)))" refers to a specific "hello" derivation, the one that is calculated based on the guix source - it's not full guix source, it's the part that does the actual build. If you go to the store, fork hello and do random modification to it, what do you put to inputs here so that you refer to this new package? You don't have anything because you do not have the source for it. The equivalent way to do it is to instead... <Rutherther>... express what you mean in Guile (or even bash and cal bash from guile) and add that to steps of a new "hello-mine" package. Then you put "hello-mine" to inputs <basicnpc>Rutherther: I'm not suggesting we literally going into the store and start to modify. I'm suggesting guix to have an interface for me to do this effectively and safely. In the end of the edition, there will be a new package in the store, with a new hash that guix automatically computes which is referrable by other pakcages. <Rutherther>I know and I am saying it's very hard to do without going declarative. And that's what guix already does <janneke>ACTION would not want to have a package to have been "magically" appeared in a store; if you get to depend on that kind of workflow, sooner or later you'll get bitten by "but it worked before, how the hell did i do that" <Rutherther>if you do already have the steps declaratively, what you're saying is already possible. And even if something like guile is not comfortable to you, it's very easy to make a procedure, like "bash-modify-package" that will take original package and return a new one based on a bash script you apply to it, after it's been built <basicnpc>Hmm. Can I then make some change in a git repo, compute the git diff, and use that git diff file as a patch? <janneke>sure, that's basically what git is for <basicnpc>With that patch, a new hash will show up in the store. janneke - and then you know where that comes from - it comes from the original package which was then patched by a git diff. <janneke>git diff > ~/src/guix/gnu/packages/patches/foo.patch should work <basicnpc>Right, so instead of using guile and say 'modify whatever regex' or 'modify whichever line by..', can I say 'modify the package with this git diff'? <janneke>or commit, and git format-patch -1; copy 0000*patch ~/src/guix/gnu/packages/patches/foo.patch <Rutherther>sure, there is even "--with-patch" transformation to conveniently do it in CLI <Rutherther>ie. "guix build my-package-depending-on-hello --with-patch=hello=./my.patch" will rebuild both hello and my-package-depending-on-hello with that patch applied on top of hello <janneke>basicnpc: i did enjoy your questions, though, as they remind me why my wish/frustration that i cannot resume a package build (that takes hours or days) after editing something minor in /tmp/guix-build--drv-0 is a stupid idea... <ekaitz>question time! is our guile 3 stuck at 3.0.9 because of the release? <Rutherther>ah, I think it was here on IRC. efraim has mentioned that guile 3.0.10 is broken on 32-bit systems + it's a full world rebuild <Rutherther>if we could not compile guix in i686 and armhf it would definitely be a problem <ekaitz>OH yes there was an issue with that <ekaitz>i'll take a look and talk with efraim about it <Rutherther>but on top of that, yes, even if this was solved, we currently shouldn't really bump it anymore because of the release <ekaitz>Rutherther: great, thanks for the help <ekaitz>also thanks for the work you are doing in the release team <basicnpc>Given that there are so many different platforms, how does guix solve the 'work on my machine' problem? <Deltafire>i think Linux is doing the heavy lifting for that <basicnpc>So it depends on how well linux handles it..? Were there historical events where that promise/goal broke? <Deltafire>i don't think there is a promise or goal that guix should run on every machine <Deltafire>guix promises reproducible builds, so if a package if broken on your machine, it's most likely broken on everyone elses <identity>ekaitz, Rutherther: in the mean time, Guile 3.0.11 was released, with fixes for 32-bit included, so i guess we can just bump Guile somewhen after Guix 1.5 release, along with any other world-rebuilding changes? <ekaitz>identity: in fact, my question went a little bit in that direction <ekaitz>we could try to put it in guile-next first? <Rutherther>identity: definitely. it could even be merged to next-master, but I don't know if QA could get to it in that month since there are 3 branches in the queue <cbaines>I think add-compress-debug-symbols-phase might have a core-updates sized impact, so a Guile update could potentially happen along with that <cbaines>qt-team looks a reasonable size and has been built <cbaines>hopefully haskell-team is similarly well sized <dckc>Hi. I'm struggling to use `guix deploy` to boot a virtualbox vm using a physical hard drive. <dckc>Current challenge: boot stops at a UEFI shell; and even if I manually invoke grub, it says error: you need to load the kernel first. <dckc>my config.scm is there, as well as a README and Makefile that detail how I'm going about it. <graywolf>Is there a way to force guix copy to copy item even when it already is on the other end? <dckc>help me understand why you would want to do that? it seems like a noop <graywolf>The item on the other end is corrupted, and cannot be repaired (no substitutes). So copying it from laptop (where it is ok) seemed like a good solution... <dckc>ah... so "already on the other end" is... complicated :) <Rutherther>graywolf: I think the easiest is going to be to turn your computer into a substitute server <graywolf>hm, thanks for the suggestion, will give a look, hoped there would be a push-based solution though <Rutherther>no unfortunately there aren't very good ways for restoring from corrupt state <Rutherther>if you do know the derivation, you can also do "guix build --repair" on it <Rutherther>In fact I think you should be able to find the derivation, at least in the sqlite database, not sure if guix exposes it through a command <ente>if I want to do hybrid suspend (i.e. suspend to disk AND to ram, in case the laptop battery runs out while suspended), what's the way to do this on guix? <ente>(nothing happens if I do that) <Rutherther>ente: I am not sure, but sanity check... do you have enough swap configured? enough meaning more than your ram <ente>(i.e. I have 4GB swap and currently only 2.5GB RAM are in use because I've just booted the system) <ente>but yeah could be that as a safe-guard hibernation is prevented in such a case <Rutherther>I don't think that's how it works. I think you need more RAM than is fully available, not just more than in use <ente>or that I don't have a resume= device set on the kernel commandline or something like that and that's why it fails <ente>anyway I thought this was a 15 minute project, not a 2h project so I'll leave this for later <Rutherther>but I might be incorrect here. It's just that from what I understand about it, it just puts the whole ram to that file, it doesn't really try to change the layout to really fit to that 2.5 GB <ente>afaik hibernate can even use compression to squeeze the RAM into the swap so there is some more logic behind it <Rutherther>for me hybrid-sleep has started working after I added big enough swap, which for me means 32GB <Rutherther>but I don't really want to try going into hibernation now, because I don't have that resume= configured and since I use encrypted partition, I am afraid that I won't be able to boot back into the session <Rutherther>by started working I mean the laptop went to sleep <ente>yeah full disk encryption is when it started to become complicated and I gave up on hibernation <ente>haven't used hibernation for a long time but it irks me especially since hybrid sleep is available now and my battery is getting old <ente>a bit sad that it's not something that works out of the box on most linuxes <ente>even when you have enough swap <graywolf>so, the answer seem to be -o remount,rw and very careful rsync <Rutherther>I have on my bucket list to make some tools to help with corruption recovery:) <graywolf>luckily these days it happens much less often compare to few months back <Rutherther>if you were hitting that root file system not cleanly unmounted, then that has in fact not been solved till few days ago, so you might better upgrade if you haven't <Rutherther>shepherd that contains the fix has been added to guix... I think 2 days ago? <Rutherther>although yes, it seems less people were encountering it for past few months, but I don't think anyone has an explanation for why <graywolf>the 1.0.9? Oh, I should upgrade then. Thanks for the reminder. I just got into the habit of always running sync && sync && sync after every reconfigure, but this time I got sloppy (since it was just a vm) <Rutherther>Yes. There is still one PR pending to make it even better, but with 1.0.9 it should be ensured root will be remounted ro <Rutherther>in case you ever encountered it again please do report it along ideally with your configuration. It's unacceptable that people would be running sync to not get corruption <basicnpc>Deltafire: So if it builds on this platform, it must build on other supported platforms? <identity>basicnpc: unless there is a ‘supported-systems’ constraint, sure <Rutherther>basicnpc: no. If it builds, it should work. That doesn't imply that it builds. Though yes, Guix is definitely also trying to achieve that the software actually does build <identity>if something does not build on a weird architecture it is usually worth a bug report upstream so you can confirm that weird architectures were not supported to begin with <basicnpc>ACTION still wonders how this is possible, given that on different platforms the eventual machine codes are different. <basicnpc>If a program is written in a way that is going to fail for a specific program, how would that be treated in guix? <Rutherther>basicnpc: yet on every architecture when you do 1 + 1, you get 2. The results are what's important. To make sure you get the same results, compilers are created and higher level abstracted languages that can be compiled to any machine code. C is already platform-agnostic thanks to compilers like gcc. Even though different instructions are used for stating that you want the result of 1 + 1, you get 2 on all platforms, because gcc makes sure to use the... <Rutherther>sure it can sometimes happen you do not get the same results, but it's usually a bug then of something and ought to be fixed <basicnpc>I see! Most of the time it should be fine. <basicnpc>i use borgbackup for backup. How do I write a service that supports it (like one for restic)? <noe>is CI getting DOSed by AI crawlers again? <Rutherther>sorry I do not understand the question, mirror like how? <Rutherther>do you mean you want to be ale to download it, but ci is down? <noe>I’m trying out the github actions thing <noe>codeberg is also down 😭 <noe>Yeah looks like the build is broken <n|phreak>Hello , using vanilla emacs on guix system , I installed a couple of modules and then did a geiser-add-path and load-from-path to make sure that guile sees the path and then tried to (use-modules (module1 module2)) and I still get no code found <ieure>n|phreak, Syntax error, I think. (use-modules (module1) (module2)) <ieure>Each argument to use-modules is a module specifier, which is a list, ex. (gnu packages databases) is one module. <jnms>Using guix system, can I authorize my own local commits to a channel, even though I'm not in the .guix-authorizations? <ieure>You can make your own channel. Or disable authorization with --disable-authentication. <jnms>It's for testing core patches, oh well. A global "also trust this key" would be nice. <Rutherther>you can either use pre-inst-env without signing or time-machine with --disable-authentication <Rutherther>I think an alternative is also changing the .guix-authorization and making a different introductory commit, one signed by you. (Then you would have to go and change the introductory commit in channels.scm) But I haven't experimented with that, yet <luca>I've actually done exactly that. The downside is that when rebasing master you need to --allow-downgrades for everything <ieure>Anyone here running LibreBoot on a ThinkPad T480 or T480s? <ieure>I was given a broken T480, which I fixed, and I'm considering LibreBooting it. <ieure>The only other machine I installed LB on (ThinkPad X60) lost the ability to set battery charging thresholds after the switch. Wondering if that's also the case with the newer machines. <bdunahu>It looks like substitute* can't be used to match something that is multi-line? That is how I understand the substitute function in utils.scm. What is the alternative? <bdunahu>Okay, that seems less burdensome than what I'm doing, thanks! <Rutherther>substitute would be mostly used for replacing absolute paths with different paths... like /usr/bin/bash with /gnu/store/..../bin/bash <n|phreak>ieure -- interseting cause I used the syntax from the example from the guile api using info <Hamled>For a headless server where users are primarily expected to log in via remote shell rather than at a tty, are shepherd user services not supported? It seems like it exists XDG_RUNTIME_DIR to be set, and from what I can tell that is supposed to be managed through a login service like greetd <Rutherther>Hamled: XDG_RUNTIME_DIR is just the default location for the socket, you can put the socket wherever. And you can also set XDG_RUNTIME_DIR env var to wherever. People who do not use a greeter nor elogind typically use something like "/tmp/user.$UID". No need for the greeter to set it up. <Rutherther>in case your server is elogind, you should be able to make a system shepherd service that will switch to the user as if it logged in as the user. And at that time elogind should create the runtime dir. <Hamled>okay, if I configure the runtime dir variable in like home-bash-service-type will it be available for the home environment activation script or do I need to set it in some other way <Rutherther>rather use the home-xdg-base-directories service, setting the runtime-dir. That will set it before shepherd starts. But you will still need to make sure it's created, if you use something like /tmp, you would need it to get created through ~/.profile / shell profile, yeah,. I cannot really help now where to put it to create it before shepherd starts, I don't have time to investigate, sorry. I am afraid putting mkdir to home-bash is going to execute... <ferorge>hi everyone! i have a Guix system with base-services and i want run X server by startx command and run ratpoison as wm. How I do that? It's possibly? <ferorge>I do not find a guide to run the services included in desktop-services. <Rutherther>ferorge: should be fine, use the startx command service type. Make sure to NOT install the startx / xinit to your profile, those aren't supported on guix system <ferorge>Rutherther: I add startx-service-type to config.scm? <Rutherther>ferorge: yes, to list of services. It's called "startx-command-service-type" though. And to restate the rest of what I said, do not put xinit to packages field or anywhere, ie. not "guix install xinit" and so on <vagrantc>has anyone successfully set up libvirt-service-type on aarch64? <vagrantc>seems to only work with (firmwares (list ovmf-x86-64)) ... not (firmwares (list ovmf-aarch64)) ... <Rutherther>vagrantc: you happen to have aarch64 uefi device that is supported by mainline linux, at least partially? <vagrantc>Rutherther: i have virtual machines that boot UEFI <Rutherther>Ah right, still would be good if you could try the artifacts yes :) <vagrantc>i can run virt-manager from Debian on the mnt/reform just fine ... but trying to configure it on guix system as well <janneke>how do i get the command-line (pid) of a shepherd process (sshd) again, with shepherd 0.10.2? <vagrantc>also updating a Debian system that has an old guix system install running inside a UEFI VM <Hamled>Rutherther: okay thanks for your help and suggestions! <ferorge>Rutherther: I've been reading for about two months now, looking for information and trying different configurations. <Rutherther>janneke: does herd status ssh show you the pid? On 1.x it seems it doesn't include that information anymore <vagrantc>hrm. apparently the ovmf-aarch64 does not contain some random .json file ... but ovmf-x86-64 does ... and the service needs that? <janneke>no command-line, there's also no sshd to be found in ps -ef --width=2000 <Rutherther>hm, does it really use a process then? Isn't it just a socket <janneke>you can run a (binary)daemon without giving it a pid? <janneke>it does say: Running value is ("#<input-output: socket 27>" "#<input-output: socket 28>"). <janneke>but i'd like to check the sshd_config! <Rutherther>yeah looking into the service it does use an inted socket <Rutherther>For shepherd 1+ it also contains "Command:" line that contains the config. So shepherd 0.10 didn't have that line yet? <Rutherther>okay, then the only way of getting the config I know of is looking at /run/current-sytem/boot, looking for the shepherd config. In the shepherd config, find the .go file with ssh. Then to get the original scm file, "guix gc --references <the go file>" and one of the results here should be the original scm for the service <Rutherther>inside of this file you should definitely find the sshd_config <janneke>yes...but i switched generations and didn't reboot...so i'd like to check if it is still running the sshd-config from the booted system, or from the current system <janneke>i know that the current-system's sshd config is correct, i would just like to make sure looking at the process's cmdline... <Rutherther>Heh. Yeah. If you restart it it should run the new one though <janneke>ok, that was what i was thinking...let's just trust that then; thanks <Rutherther>note that it usually does say that the service is going to be replaced <janneke>after/when running system switch-generation you mean? <Rutherther>after you run switch generation, if you do "herd status X" it should say something like will be replaced after restart. I forgot the exact wording <zeropoint>hi guix, is there a way to make a mixed-text-file as executable in the store? as opposed to copying the script out of the store and marking it as executable? <identity>zeropoint: ‘program-file’ is one way to do that <zeropoint>so (program-file "name" (mixed-text-file "name" ...)) ? <zeropoint>looks like that does what I want cool, thanks identity