<shcv[m]>I think I just ran into an issue where my old guix system (518 days since last pull) can't process a `guix pull` <shcv[m]>failed to compute the derivation for Guix (version: "1a5384e9a702c366f3b14ed1ac3db8d3eb6640e2"; system: "x86_64-linux"; <shcv[m]>host version: "4bb9bb78c2482627b1afa2cffda68a4427a3b21d"; pull-version: 1). <shcv[m]>does guix have (or maybe "guix should have") a system that marks certain commits as transitions that old systems have to update to before proceeding <shcv[m]>probably a file in the repo that lists commit ids <shcv[m]>so during guix pull, you pull the repo, then check the file and see if there are any transition commit IDs after yours, check the first out, do the rest of the steps, repeat <vagrantc>i suspect there are some corner cases (e.g. different commits for different architectures) <vagrantc>it would definitely be nicer to handle systematically than ... asking on irc or the mailing lists <shcv[m]>true. Since it's scheme, the file could be implemented as a function that you call with your system description <vagrantc>though the times where that's happened are quite few in my five or so years of using it <vagrantc>was there a system for marking "bad" commits? vaguely recall it being proposed if not <shcv[m]>there should at least be a list somewhere with comments on who would need to pause where and why *vagrantc blinks a little at five years but there's no denying it <shcv[m]>but as it is, I have no idea what to do about my pull issue <shcv[m]>actually "guix bisect" would be interesting - automatically bisect until the pull succeeds <shcv[m]>just try it, if it fails, try a different commit and continue <vagrantc>yeah ... although the few times i have had to do that sort of thing were where "guix pull" succeeds but fails in some horrible way <vagrantc>as in pull succeeds, but it builds something that doesn't work <shcv[m]>you mean the command succeeded, but the results were nonfunctional? <vagrantc>sometimes obviously, sometimes subtlely ... but anything systematic will be an improvement <vagrantc>although it wouldn't be so hard to just write a wrapper for git bisect ... not sure what "guix bisect" would add <GNUtoo>Ah it was probably my computer: it was supposed to start gdm it didn't either <GNUtoo>So it was probably interrupted mid way somehow <pkill9>has there been any progress in p2p substitutes? ***a is now known as Guest4519
<Guest4519>guix is finished in such a short amount of time <GNUtoo>kaelyn: hi, I saw some things that could be improved <GNUtoo>(1) I think that you need to add your name to the copyrights on top <GNUtoo>Beside that I don't see anything wrong <drakonis>buuuut it should be back on the table after i'm done with my project <GNUtoo>kaelyn: I've also been playing a bit with x86_64-w64-mingw32 (mainly to test how far it could go) and we probably need to patch bzip2 to enable to build more things with it: if I try to compile other things than xz or hello world, it would try to compile bzip2 and fail. There is a patch in msys2 to convert it to autotools but I've not managed to apply it in Guix (when running make to build guix, guix would <GNUtoo>complain about max heap and similar thing (that comes from libgc) and make would fail at the end or never complete) <GNUtoo>(It would be really neat to be able project for multiple platforms to get more contributions in Guix, and it'd probably help build-testing software that are super strict with portability, like Wireshark for instance, or things like unetbooting that works on multiple OS) <antipode>pkill9: I have been working a little on extending gnunet-scheme to support DHT and CADET (to eventually support FS and maybe GNS), which I expect to be a good basis for P2P substitutes. <antipode>P2P substitutes in the general case sounds a bit too ambitious to me, so I intend go for P2P downloading of (source) tarballs first (like https://issues.guix.gnu.org/44199, but in (guix download) and with http / https / ... fallbacks) *GNUtoo would also be interested in something slightly different: reuse Tails perm configuration file (and modify it a bit) to block non-tor traffic: this way the substitute would be gotten through Tor. Though I need to actually package perm first <antipode>(NSE and DHT support are decent now, CADET is what I'm currently working on) <warren>Hi. I'm wondering if someone experienced at Guix might be interested in contract work involving using Guix as a build system for particular FOSS cross-distro portable binaries. There's already some similar examples to work from. We know Guix is good but we're overloaded so hoping to find help on this. Please DM if you're interested. *GNUtoo is curious about the work details <warren>It is probably off-topic to discuss in channel here, and it's rude to DM people, so please DM me if you would like to chat. <GNUtoo>ok, it was not to apply, it was more to understand real life usage of Guix <GNUtoo>For instance it's being used to build bitcoin binaries <GNUtoo>And as I understand in the UK there is also some state services that use guix for their infrastructure (to host web services for instance) <warren>yes, the clean bootstrap and reproducibility of guix is very attractive when you want similar assurances for portable binary distributions for anything <warren>(Here I'm describing history, not the specific use case we want to hire for now) Prior to Guix, Bitcoin used "Gitian" which used debootstrap to make a particular Ubuntu buildroot. Those binaries were reproducible but without any chain of clean bootstrap so you couldn't know how safe it was. <GNUtoo>I think the tor-browser had similar issues in the past <GNUtoo>So it's really interesting to fix things like that <GNUtoo>I've looked a bit at the way bitcoin uses guix and it seems to use the bare minimum of Guix: it creates a standalone container which has a basic toolchain, and then it somehow builds things on top of that <warren>as of Bitcoin Core 22+ they dropped these compat wrappers because they switched to Guix. They picked the particular version of glibc/gcc/etc so they don't need the symbol stripping hacks anymore. <GNUtoo>wow, I though Guix was just something on the side <GNUtoo>So I guess the idea now is to add support for platforms not yet supported by Guix like OSX and so on <ulfvonbelow>our tests that use Xvfb seem not to be waiting for the server to be ready before running the tests. This causes some nondeterministic test failures depending on how long it takes X to start up. <warren>Guix was adapted in a specific, narrow way to build it not only safely but also to result in static binaries to maximize portability across many distro targets. <oriansj>GNUtoo: guix thanks to its bootstrapping work is the gold standard for trusted builds in the crypto world *GNUtoo wonders if I could use something like that for Replicant <warren>It's also the basis for cross-compiling to Windows and OSX <clever>warren: cross-compiling to OSX!? <oriansj>with some more work, it could become the basis of all trusted builds in the world (if people have the ambition to do that work) <warren>unfortunately you need non-free blobs for OSX cross-compiling but yes. The Bitcoin devs also hacked Apple-compatible binary signing tools IIRC. <GNUtoo>+ if people package things in Guix we could probably get things like the tor-browser in Guix (assuming they block nonfree addons along the way) <drakonis>oriansj: i am not sure if that is always a good thing, but sure <clever>warren: where can i learn more? ive been wanting similar in nix <GNUtoo>Ah I see, I heard of things like that for the iphone decade(s) ago, but I didn't know it was also the case for OSX <drakonis>although i think nix has a bunch of people using it for crypto stuff <drakonis>can't control what people do with the software, even if i dont like it <oriansj>drakonis: well good is relative to one's beliefs, assumptions and goals <GNUtoo>Ah I understand, I looked at bitcoin-core before, and I guess that bitcoin != bitcoin-core <drakonis>though this discussion might get a bit touchy <clever>warren: ah, i'll have to read over that <oriansj>my view is I'll give you a bootstrap chain you can audit and what you do with that is entirely up to you. <warren>you could easily use the same approach to build various bitcoin forks <GNUtoo>There are really no free tools to build for OSX (including with limitations) ? <drakonis>you could try using something like darling as a wine equivalent to run osx tools <GNUtoo>AFAIK you could cross compile with GCC long time ago <clever>drakonis: ive also been wanting to look into pure-darwin <drakonis>you can use gcc or clang but its not going to be the same <GNUtoo>indeed, that's what I asked, if you have limitations, can you still have free tools? <clever>mach-o files also have a path to dyld (same role as ld.so on linux) <clever>but you cant actually use a custom dyld on OSX, the kernel rejects any file with the wrong path <drakonis>there are lots of restrictions on the mac world <clever>GNUtoo: OSX also doesnt allow static i believe <warren>GNUtoo: Bitcoin's gitian-ubuntu reproducible builds did cross-compile to OSX since ~2014 <warren>they used llvm back then, dunno now <iyzsong>GNUtoo: what works needed for Replicant and Guix if I want to run 'guix package -i element' on x86 or aarch64 powered postmarketOS (or guix system)? does it sounds reasonable :) <oriansj>well yeah, being forced to use OSX sounds miserable. <GNUtoo>iyzsong: one day it would be nice to not depend on distributions like Trisquel and prebuilt binaries to build Replicant, so doing something like it's done for bitcoin/bitcoin-core would be desirable I think <warren>fortunately nobody considers OSX to be a serious server deployment target, it's only popular with developers <drakonis>because apple finds new ways to screw up developers <GNUtoo>iyzsong: for now people have either to run Trisquel, Debian or use that in a chroot or LXC through libvirt <GNUtoo>iyzsong: the setup with Guix would be easier: install guix, run a script, and you'd be able to build it directly <warren>I'm interested in hiring for contract work: 1) Adapt Bitcoin's Guix build approach to similarly build portable binaries of specific other FOSS projects that we make. 2) Generalize that to be an easy to use build system for ANY FOSS project. 3) Build Guix-based docker and flatpak containers so binary distributions of such are similarly safe for more than just one binary, similar to Alpine levels of container minimalism. Maybe this already exists? <GNUtoo>for OSX what about toolchains like zig that can also build C code for mach.o ? <GNUtoo>It might need to be bootstrapped though... <warren>#2 might not be easy enough to be general purpose, maybe it's a simple consultantcy task, people WILL be willing to pay for guix adaptations like this. <warren>I wonder if my message was lost in the server split. <GNUtoo>< warren> #2 might not be easy enough <ulfvonbelow>hm, our test X servers are refusing to start now: _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. <warren>ah ok. anyhow I hope someone has the right skills and availability for this. I will EVENTUALLY figure it out myself but I'm overloaded with other tasks. <GNUtoo>What about homebrew? Does that require nonfree software to build their compiliers and so on? <pkill9>i hope deleting the cache fixes my issues <warren>GNUtoo: I would assume so? you run homebrew on OSX itself, it isn't cross-compiling *GNUtoo has followed that a bit to understand how porting a free software OS to a new platform without cooperation from the vendor worked, and it seem that behind asahilinux there was cooperation between the people working on compilers for OSX and asahilinux <GNUtoo>So things like making binaries that work on OSX was required to make all that possible <GNUtoo>though the best way to find out is probably to do the work of adding support for that in Guix... <GNUtoo>This way you're sure that it doesn't contain nonfree software... <GNUtoo>(or maybe it was for their bootloaders, but anyway they had to deal with things like that) <raghavgururajan>GNUtoo: Thanks so much for the info at #replicant. I'll look into them. <iyzsong>GNUtoo: well, it sounds more difficult for guix on OSX OS than OSX apps on linux packaged by guix. there are some free apps on other platforms (eg: android) that i have interest to run on my guix system, that's what i asked for... <apteryx>how can I fix this: gdm: Gdm: Failed to list cached users: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files <apteryx>shouldn't the gdm-service-type pulls what it needs? <iyzsong>there is an 'accountsservice-service', add it may fix the issue. <warren>somehow many private keys were stolen and their entire network is getting trashed <oriansj>warren: auditable bootstrap is needed to ensure a clean bootstrap. <horizoninnovatio>So, before I nuke my system & start again! Why does guix system slowly take up more & more disc space? I've done gc & gc -d 1w & still it grows. Any ideas? <ulfvonbelow>another thing to check would be log files, though they usually don't grow terribly fast <apteryx>has anyone gotten gdm to listen on port 177 for XDMCP? <ulfvonbelow>by nature deleting system generations requires root (and even if it didn't, the entries for old systems have to be removed from the bootloader, which requires root anyway), so it's a separate command from 'guix gc'. <apteryx>oh nevermind, it works, my 'ss' command was wrong (missing 'u' for UDP). <apteryx>now my test proceeds a bit further, stops at: gdm: Gdm: GdmDisplay: Session never registered, failing <apteryx>(I'm testing connecting via vncviewer (tigervnc) via the XDMCP server of GDM) <yuu[m]>hasn't guix packages an emacs built with native compilation NATIVE_FULL_AOT? <ulfvonbelow>this is really puzzling. Apparently libxtrans has pretty much always refused to make a sticky-bit /tmp/.X11-unix directory when non-root, and xorg has always used it more or less as it does now. But only recently has our xorg-server-for-testing begun exhibiting this behavior. <yuu[m]>how to refer to the package after the channel? we just add emacs-native-comp to my packages and done? <yuu[m]>it uses 28.1.90. how would i override/overlay that with master? can't find anything on override on the manual <nckx>Yeah, you'd add the package variable name to your package list. I use the -pgtk variant myself. <nckx>You'd modify the package the way you modify any other guix package: using (package (inherit emacs-pgtk-native-comp) (your changes) (go here)) in code, or with package transformation options (see manual) if you use the CLI (which I don't, so can't help with). <nckx>Well, I could, but it would just be manual reading storytime. <ulfvonbelow>note that package transformation options are also available in scheme <nckx>Package transformation options (including CLI) won't work here, because the emacs source is not a Git reference. <nckx>Which is fine; just use the first method. <kaelyn>sneek: later tell GNUtoo thank you for taking a look at the patches! I've actually not done much with mingw & I updated it as part of an attempt to get newer versions of dxvk building (I'd hit an error that was fixed in 9.0.0) <apteryx>hm. I tried migrating from slim to gdm, and it seems to hang on boot. has anyone experienced something like that? before the GUI comes up; I can't even change virtual terminal. <apteryx>perhaps it crashes due to my aging video card? I see: "elogind[385]: New session c1 of user gdm.", "gdm: Gdm: GdmDisplay: Session never registered, failing", "gdm-session-worker: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed", "elogind[385]: Removed session c1." and "gdm: Gdm: Child process -451 was already dead.". <apteryx>perhaps my ~/.xsession gets in the way? seems to work in a VM <podiki[m]>on the gccjit front, got the hello world to work, with manual LD_LIBRARY_PATH and LIBRARY_PATH, seems to be an upstream issue maybe (see same bug reports as in #55657) <apteryx>podiki[m]: I think it does sources it <podiki[m]>maybe that's why? though I could never figure out what files gdm uses when I briefly tried it (I thought it sourced .xinitrc but didn't seem to for me) <vivien>Dear guix, my V2 for 56892 fixes nsis, a compiler to make windows installers. It has been broken by the switch to gcc 10, but fortunately it can be updated. <iyzsong>vivien: looks good to me, i'll merge it soon, thank you! <rekado_>ci.guix.gnu.org and issues.guix.gnu.org both respond very slowly for me right now. Is this a problem for anyone else? <nckx>The Web sites? Not at all, responsive as ever, but I had to wait about ~15s (didn't time it) for a shell prompt. <nckx>Once in, everything seems normal, no SSH delays. <nckx>Could this be a firewall issue? <nckx>Does it do some clever connection tracking? <nckx>I don't see tonnes of SSH zombies in ‘herd status’, which is a relief. <jonsger[m]>rekado_: the first load was a bit slow on both (~3s), but later its fast on different browsers... <nckx><nckx: responsive as ever> means <1s here by the way, for both. <rekado_>earlier today it took >30s, now it’s ~2s <rekado_>also SSH took a long time to connect <ulfvonbelow>apparently I was wrong, and for at least half a year now none of the xorg-server-for-tests instances spun up in package builds have created /tmp/.X11-unix directories. I guess there's some alternative transport they use? <muradm>guile scheme does not understand ~ tilde to $HOME expansion? <iyzsong>muradm: i just find that (system* "sh" "-c" "echo $HOME ~/foo") works, but maybe we shouldn't use this... <Kabouik_>I heard once that there would be packaging hacks to skip the hash verification, if I want to build a package that fetches the latest HEAD commits from git every time I call guix install package <Kabouik_>That would be for a private channel of course <abrenon>I think setting it to all 0s works (at least that's what I used to do for local development before I learnt about the (local-file …) field) <abrenon>muradm: what are your fairness criteria ? (but appart from that I find it a clear and simple implementation) <abrenon>Kabouik_: yeah, I used to replace the individual characters from a working package because the length matter, I think there are like 52 of them <Kabouik_>Thanks unmatched-paren, abrenon, trying that first and then I'll try with 52 zeros instead if that doesn'twork <abrenon>^^ this is an old memory, be careful, don't rely on the 52, but rather replace all the zeros in one legit hash you find in the wild ***wielaard is now known as mjw
<pkill9> why does guix pull keep failing on a channel for referencing a variable when I have purged that variable from the repository and commited the change and pushed it, adn I've deleted the cache? <rekado_>nckx: on ci.guix.gnu.org has the root user’s ssh key changed? I can no longer connect do “ssh 141.80.167.228 -l hydra” without being prompted for a password. <civodul>rekado_: "sudo ssh hydra@141.80.167.159" works for me ***PrinceMyshkin0 is now known as PrinceMyshkin
<ulfvonbelow>the channel introduction itself is optional; without the ability to verify the initial commit, there's no point to specifying an initial commit, since 'guix pull' will use the latest one anyway. In other words, to not use authentication, simply omit the entire (introduction (make-channel-introduction ...)) part. <rekado_>just got a message from IT: “The cause of the network disruption has been found and the problem has been fixed.” <antipode>sneek: later tell ulfvonbelow: xvfb-run? <Kabouik_>I see, but I was confused by the manual page saying "the first commit where the authorization invariant holds, and the fingerprint of the OpenPGP key used to sign that commit (it’s not strictly necessary but provides an additional check)"; I thought the brackets only applied to the second part of the sentence. <nckx>rekado_: Have they mentioned Russia lately? <nckx>Hm, SSH'ing still takes 30s where it didn't a day or two ago. <rekado_>they never even announced it in the first place. <ulfvonbelow>hm, actually, what I said might not be quite accurate. Conceptually a commit id does fully specify the contents of the initial commit, whether signed or not, so it makes sense to include it even without a signature. Subsequent commits, however, would have to be signed. Note though that git commit hashes use sha-1, which is considered somewhat weak nowadays. I suppose if one wanted to try specifying only the commit identifier, my best <sneek>ulfvonbelow, you have 1 message! <sneek>ulfvonbelow, antipode says: xvfb-run? <horizoninnovatio><ulfvonbelow> "by nature deleting system..." <- Thank you, I'll have a look. <pkill9>I've bloated my config to too much complexity D: <rekado_>does anyone know how to import golang.org/x/image/tiff with the go importer? <Kabouik_>I don't understand why I am getting this git fetch error with my package, the url seems right: https://p.teknik.io/Raw/nEIND (the first part of the paste is the package.scm, the second is the error log when trying to install it) <nckx>GborBoskovits[m]: Load of? <nckx>Oh, berlin. It was very low. Like 3-4 or so. <nckx>I don't know what you consider interesting. It showed that connections would immediately spawn a Shepherd SSH service, which would then twiddle its thumbs for ~30s (but sometimes less, so it's not a hard time-out as I originally thought), then lets you in. <nckx>So that would point to something like PAM (or a network dependency) timing out, I guess? <ulfvonbelow>Kabouik_: builds are run in an isolated container. The only exception is that fixed-output derivations can be built with network access, since their output is fixed. This requires that a hash of the output is specified. Since you didn't specify an output hash, the source origin doesn't result in a fixed-output derivation, and it doesn't get network access. <rekado_>still can’t import gonum.org/v1/plot. <unmatched-paren>rekado_: Try `guix import go github.com/gonum/plot` then rename the result to gonum.org/v1/plot, maybe? <ulfvonbelow>a good question would be "wait, then how are package transformations like --with-commit implemented?", and the answer is "undocumented magic called <git-checkout>" <rekado_>unmatched-paren: … really? I can’t get it to work. <pkill9>tyupical, my problems all caused because I didn't commit a deletion to the git repository <rekado_>unmatched-paren: oh… without the https:// prefix. <Kabouik_>I see ulfvonbelow, so maybe replacing the has with zeros abrenon said above might work and give it network access in that case <Kabouik_>Oh actually it did, the build log shows a different error. <unmatched-paren>It's just that all the non-default ones happen to start with a domain name, by convention. <ulfvonbelow>Kabouik_: you can either use a git-checkout object instead of an origin object as the source - in which case you may want to look at ~/.config/guix/current/share/guile/site/3.0/guix/git.scm around line 694 to see how that's defined - or simply use options->transformations from (guix transformations) in conjunction with the with-commit or with-branch options, which will in turn use a git-checkout object internally. <Kabouik_>But I would want to use latest commits every time the guix install package is called. Using (with-commit ) would force me to specify a commit, wouldn't it? <nckx>--with-branch=PACKAGE=BRANCH <nckx>Kabouik_: <replacing the hash with zeros … might … give it network access in that case> Yes, but useless network access, as whatever you download will not match the bogus hash and abort. You can't think your way out of the isolation. There is no hidden networking switch inside a build container. ***meo is now known as statusquo
***statusquo is now known as meo
<Kabouik_>So does that mean that there is no way to build a package with latest sources all the time (meaning the hash can't be known in advance and has to be skipped), or does that imply that the only way might be using guix transformations in conjunciton with --with-branch=PACKAGE=BRANCH (which I'm currently trying to do, but this is not trivial for me) <ulfvonbelow>there is a way - the aforementioned git-checkout objects - but it's not documented well in the manual, whereas ((options->transformation '((with-branch . "my-package=master"))) my-package) is <nckx>Kabouik_: git-checkout will do just that, but it doesn't do it by ‘enabling network access in the build container’. Since that was a possible (not unreasonable but wrong) interpretation, I wanted to point it out. Think of it as checking out the source for you in ‘user mode’ (not in the daemon), ‘writing’ a source form with the latest hash, and passing that to the isolated daemon build environment. <ulfvonbelow>although you'll probably also want with-git-url in addition to with-branch, since the original package isn't using a git reference <ulfvonbelow>probably more straightforward to just use git-checkout <nckx>I'll admit I'm kind of biased against transformations & towards anything that produces a more regular-looking Guix package, like git-checkout. <nckx>I think the former use the latter under the hood though. <Kabouik_>So git-checkout it is; now I have to understand how to use it and what to delete from my current .scm file. I'm about to create a monstrosity. <Kabouik_>Me writing guile: (potato git-checkout "potato"). <Kabouik_>See, I'm already missing brackets there. <unmatched-paren>Oops. I accidentally created a new issue and forgot to add a v5 for my latest aerc patchset... <nckx>Do you know how to merge them? <ulfvonbelow>Kabouik_: a <git-checkout> can have as fields 'url', 'commit', 'recursive?', and 'branch?'. It's like a <git-reference> in that regard, except that a <git-reference> can't specify a branch. <ulfvonbelow>the form for creating a <git-checkout> is git-checkout, like so: (git-checkout (url (package-home-page nnn)) (branch "master")) <ulfvonbelow>you use the git-checkout form in place of the origin form, and the git-checkout form has no sha256 field <Kabouik_>Oh, so I don't even need to put a sha256 function and make it false <ulfvonbelow>Correct. When instructed to build the package, guix - running as your user, unrelated to the daemon - will download the repository, figure out its hash, and send it to the store. <unmatched-paren>Does merging issues not make mumi display all the emails on the original issue? <unmatched-paren>I sent "merge 55903 56909 56914 56910 56911 56912 56913 56915 56916 56917 56918 56919 56920 56921 56922 56923 56924 56925 56926 56927 56928 56934 56930 56929 56931 56933 56936 56935 56932 56941 56938 56939 56937 56942 56940 56943 56944 56945 56946 56947 56948 56949 <pkill9>is it possible to add guix subcommands through a channel? <pkill9>i'd like to add my own little tools under the guix command <Kabouik_>My (git-checkout…) should be enclosed in a (source…) record, correct? <unmatched-paren>i wasn't following your conversation so i can't answer your actual question <Kabouik_>It's not pedantic, and it's actually useful. See how I tried to be smart and call it a record instead of a function just now? :> <ulfvonbelow>but yes, it should look like (source (git-checkout ...)) <pkill9>unmatched-paren: can't you add it to a channel and have it compiled in on a guix pull? <unmatched-paren>yeah, (source ...) is a field of <package> that accepts a file-like object, such as local-file, computed-file, origin, or git-checkout <pkill9>is that documented anywhere? doesn't appear to be in the manual <unmatched-paren>although that still doesn't solve the problem of GUIX_EXTENSIONS_PATAH <unmatched-paren>Hopefully this aerc patchset is merged before 0.12, but I'm not counting on it. <unmatched-paren>The message i sent to issue 56909 is not appearing on issue 55903... <Kabouik_>So I think the package is now correctly formatted according to your advice (many thanks, and sorry for being this slow, I'm trying ot read docs at the same time to better understand), but I need to use a use-modules for git-checkout. I already have a use-module (guix git-download) but apparently that is not enough for git-checkout. So my question is, how do I know which module to load when I call something new in my code? I <Kabouik_>checked git.scm L694 but can't see a reference to the module function. Or is it use-module (guix git)? <Kabouik_>At least locally. Now I'll try to git push, guix pull, and guix install. <ulfvonbelow>note that I don't think you need to guix pull to get an updated version of that particular package, due to the way it's defined. <Kabouik_>This git-checkout will be very useful for me, since I am interested in some third-party software that's only on git repos I trust and not having to manually download them and check the hash will be more convenient for me when updating <zamfofex>vivien: I remember you once wanted to use Emscripten for something. I suggested just using ‘clang --target=wasm32’, but you say you wanted to be able to use e.g. ‘readline’. Here’s another suggestion: Have you considered using ‘zig cc --target=wasm32-wasi’? Zig is packaged in Guix, and it features a powerful C cross compiler based on Clang. If you want to use the compiled code in a browser, you can use ‘@wasmer/wasi’ <nckx>unmatched-paren: Mails will be word-wrapped to 72 characters. Anything exceeding that will be parsed as a new (and invalid) ‘(verb)NNN (args)NNN’ line. You should get a mail from Debbugs on both success and failure. <apteryx>hmm. switching slim-service-type to gdm-service-type in my config really does lead to hang at boot <nckx>Which MUA do you use and would you miss it if it were to mysteriously disappear? <nckx>Strange. I use emacs too. Must be smtpmail/mu4e/$something doing that. I thought it was a Debbugs limitation. Good to know. <nckx>It's especially annoying with title changes, because you can't split them like you can merges. <unmatched-paren>Specifically, I'm using a slightly outdated version of aerc from guixrus while I wait for the non-outdated patch I just sent to be reviewed, which thanks to Go isn't going to happen anytime soon :) <nckx>Oh, MUA = mail client yes. <unmatched-paren>Mhm, I had to look up 'mail user agent' because I'd heard of the acronym but I wasn't sure what it referred to <pkill9>unmatched-paren: i don't see where in gwl's package it shows how to add subcommands to the guix command <pkill9>I'm looking at the package definition actually, probably the actual package contains <unmatched-paren>pkill9: rekado_ knows more about extensions than i do (and they appear to be be the original developer of gwl) <rekado_>pkill9: you need to define a command in guix/extensions/ <Kabouik_>It seems that (source ) cannot take a (patches ) field, previously my patches field was in a (origin ) <apteryx>does GDM work with only ratpoison as installed WM? <apteryx>I don't have gnome or something else; it hangs at login time before any graphics are displayed <horizoninnovatio><ulfvonbelow> "by nature deleting system..." <- Well, that freed up about 1Gb! Looks like nuking & reinstall before I run out of disk space! <mrvdb>Is there a way to get notifications from certain issues? <Kabouik_>How do I get more information on each Scheme functions/record/field, namely to see which fields a function can take? I'm trying to add a (patches (search-patch "xxx.patch")) to (source (git-checkout …)) but that complains about "extraneous field initializer". <Kabouik_>Specifically, I think that's my main issue with Scheme/CommonLisp so far: I am used to R where I can do ?command to know how a command is used and which arguments it can take, or same with bash <Kabouik_>I'm missing that kind of manual for lisp <unmatched-paren>though since guix's record-type* system is entirely custom-built, it might be a bit tricky to get information for it <Kabouik_>Yes I assume my issue understanding lisp comes from the very nature of lisp, while I'm used to using functions/commands that are less flexible in R or bash <Kabouik_>I'm not a emacs user yet (I use Kakoune) so geiser might confuse me even more <Kabouik_>The errors are not very verbose. Obviously there's something wrong with trying to use (patches …) with (git-checkout …), but the error is not giving many hints <Kabouik_>That was the discussion above with ulfvonbelow and nckx, I use it so that my package can download the latest commit and build from it without imposing a hash check <Kabouik_>And it works, the only issue is I'd want to apply a patch to the source before it gets built (either from a local patch, or from the raw git URL of my private channel) <Kabouik_>It didn't (the details are above and I could try to summarize but I'm afraid I may do incorrect shortcuts) <Kabouik_>Basically this was related to build containers being isolated with no network <Kabouik_>And therefore failing to fetch from github.com <unmatched-paren>Sorry for making you say everything twice, but why aren't you just locking the origin to a commit? <Kabouik_>The package I want to use is nnn file manager, which is receiving multiple commits a day; I just want my custom package to update it to the latest all the time instead of doing that manually and applying my patch every time <unmatched-paren>The German version, specifically, seems to want to reference nonexistant nodes. ***Guest1073 is now known as Guest95
<unmatched-paren>Anyone else getting this @ref texinfo error on the latest commit when `make`ing? <Kabouik_>On other distros, I just used to git pull regularly, apply my patch manually, and compile and install. But with guix, making my own package seems to be better than compiling manually from the cloned repository, so I wanted my package to do the pulling and patching all by itself <Kabouik_>Also, on other distros, I usually just ended up not upgrading nnn at all because I was too lazy to apply my patch and custom make options every time, so here again a package.scm doing the work for me was better <Kabouik_>Is it? This is a genuine question, if it is, I am missing something <unmatched-paren>Guix is a functional package manager, which means that for a set of inputs it will -- in theory -- always produce the same results <Guest95>Hello. Am I right that package cairomm-1.14 propagates 2 versions of libsigc++( libsigc++ and libsigc++-2)? The same problem as this which has been fixed: <Kabouik_>Well, I named my package "nnn-git", so if it always pulls the latest commit and does the same operation on it, it does what I want, and in that way is not redundant with the nnn.scm from the guix channel (which is fixed to a specific version and hash) <unmatched-paren>These 'inputs' include actual inputs, native-inputs, and propagated-inputs, along with the version of Guix, the arguments, the phases, the source, and the machine <unmatched-paren>A package that might create a different output without changing the inputs is broken. <Kabouik_>To produce the same results from a set of inputs, I would indeed favour nnn.scm and not nnn-git.scm. But there are some packages whereby I'd like to keep close to remote git and not be using fixed versions if they don't have ties with the things I would want to keep reproducible (like R analyses for instance) <Kabouik_>I see, but then I was told that packaging third-party software not in official channels is the best way to use third-party software. I understand that one of the advantages of guix is to make everything reproducible, but I'd like to be able to adjust the mix between reproducibility and flexibility when a third-party software I like is being updated, without having to repackage with a new hash <unmatched-paren>I don't really see why you'd want to stay on HEAD at all times; if a change you like is made, sure, change the package to incorporate that change. But surely you don't need to automatically pull in every little change made to the software, especially when doing so goes against the grain of the package manager you're trying to use? <unmatched-paren>I'm using aerc, and I'm perfectly happy with a pretty outdated version, even though they're getting lots of commit activity <Kabouik_>I don't know, nnn and nmail for instance are among the tools I use every day and they get bug fixes or new features regularly, but those are not necessarily immediately bundled into git releases. Yet, I'd be happy to enjoyr or even test those new features when they arrive. <Kabouik_>For instance at some point I wrote a few plugins for nnn (not in common lisp, as you may expct :p), I needed my local nnn binary to be up to date all the time for that <efraim>unmatched-paren: sometimes I run 'rm -r -- doc po; git checkout -- doc po' and then rerun bootstrap configure and make <podiki[m]>Kabouik_: you can just use the package transformations to always build from latest git commit <Kabouik_>civodul: thanks for the reference page. It does say that (origin ) needs a hash known in advance. And git-checkout doesn't appear to allow patches. So I guess transformations might in the end by the best way for my specific case here (with --with-branch=package=branch and --with-patch=package=file), but those are CLI so I need to translate them in Scheme for my .scm filew <Kabouik_>podiki[m] yes, that's what I was starting to think too <Kabouik_>Also it says "Package transformation options are preserved across upgrades: guix upgrade attempts to apply transformation options initially used when creating the profile to the upgraded packages.", so maybe it's fine if I just don't create a custom package.scm with the transformation, and instead just install `nnn` from the Guix channel with those transformations in CLI, as apparently both the latest-commit transformation and <Kabouik_>the patch transformation should be conserved in guix upgrades. <podiki[m]>you can also see the code in a manifest; e.g. install the package with the transformation and then guix package --export-manifest <Kabouik_>Actually guix package --export-manifest just shows installed packages, not their scm file, and nnn@4.6 doesn't get installed with --with-branch=nnn=master because "guix install: error: the source of nnn@4.6 is not a Git reference". --with-patch=nnn=$HOME/path/to/my.patch works though, and that's already good news. <podiki[m]>yes, --export-manifest makes a manifest (to install packages) not the package code <two[m]>i see cmake can't build anything in unicode folders <civodul>kaelyn: hi! i've just applied and tested the MinGW upgrade, will push soon! <Guest95>Hello. Am I right that package cairomm-1.14 propagates 2 versions of libsigc++( libsigc++ and libsigc++-2)? The same problem as this which has been fixed: <civodul>Guest95: hi! do you mean that the bug came back? <Guest95>civodul: i mean that there has been fixed a problem like this but with different package glibmm-2.64 <Guest95>civodul: and I suppose that cairomm-1.14 needs the same <kaelyn>civodul: I haven't been certain how to test the version upgrade more thoroughly as I wasn't sure what packages work with it (and if I try to set a mingw target e.g. through "guix build --target=x86_64-w64-mingw32" I always get an error related to tar being available bootstrapping. I also noticed in your output it is referencing a mingw 8.0.0 path <civodul>Guest95: ah, i see; would you like to submit a patch? <civodul>kaelyn: i tried "guix build gzip --target=x86_64-w64-mingw32" and similar commands <kaelyn>I've had some success using the toolchain with package variants that use `(cross-gcc "x86_64-w64-mingw32")` <Guest95>civodul: I'm sorry I'm a novice, so I just wanted to make someone notice this and solve it if possible <kaelyn>I also see the same error with the gzip build without the mingw update <two[m]>added glibc-locales to the container, fixed! <kaelyn>(I'm trying it with my update now to see if the error is the same or not, now that I have a build target that sort of builds) <civodul>kaelyn: right, so i guess this is something we'll have to address afterwards, or it's going to be much less useful :-) <apteryx>I don't get it; on some machine I have both berlin and bordeaux keys in /etc/guix/acl, 'guix weather linphone-desktop' says ci.guix.gnu.org has it, yet 'guix shell linphone-desktop' fetches the substitutes, but 'guix upgrade' attempts to build it <civodul>apteryx: hi! "guix weather" ignores /etc/guix/acl <civodul>ah sorry, that answer is irrelevant :-) <civodul>is 'guix upgrade' building the same derivation? <apteryx>the one it attempts to build has a different hash <civodul>ah! now you need to play "find the differences" :-) <muradm>when 56690 and 56699? :) (seatd/greetd fixes groups configuration for permissions) <civodul>the entire reviewer team* is working at full speed! <muradm>when fail2ban-service-type 56608?.. :) <muradm>civodul: some are sneeking against the order :D <apteryx>muradm: have you been running the fail2ban service for a while? <apteryx>do you see it actively blocking ports? <unmatched-paren>Note that 56690 and 56699 fix an issue which breaks logins completely for greetd/seatd users who are using anything more complex than agreety :) <muradm>apteryx: never mind, you can reoder among my things :D greetd/seatd thing is more impactful :) <muradm>apteryx: yes it runs, but i think i will be adding somethings to later on <muradm>especially configurations for existing services <apteryx>civodul: perhaps I was simply tricked by grafts builds, looking like real builds (I saw sources getting fetched) <kaelyn>I think I may have bitten off more than I can chew... I wanted to update dxvk to a newer version, but newer versions need to be compiled with mingw. I got it almost building (with the mingw upgrade), with dxvk failing during configure because it can't find the vulkan library. I'm tryng to figure out how to build vulkan-loader with mingw, and that is so far the hardest part to even get to build <apteryx>muradm: replied to the fail2ban ticket <civodul>drakonis: applications for the reviewer team? sure! <Kabouik_>I don't think there are transformations for changing compile options, are there? Just realized that my transformed procedure works but there was a non-default compile option in my original package project. -.- <drakonis>civodul: i'd like to participate more often <civodul>drakonis: that'd be much welcome; you're also welcome to ask if you're unsure how to proceed, perhaps that can help improve the whole process <drakonis>i had been busy with things and drifted away a bit <drakonis>plus i can finally get a machine that doesn't actively punish me for owning the wrong gpu brand :v <drakonis>not like i've been doing a lot of things that requires a gpu anyways <drakonis>tonight i'll be getting my ducks in a row and have guix back on the machine <muradm>apteryx: thanks i will look at it <muradm>apteryx: i already have tests for fail2ban, which tests configuration, runtime status etc. <muradm>i also was wandering on blocking test, but could not find a way, so made extensive runtime tests ***Kabouik_ is now known as kabouik
<apteryx>muradm: OK, these tests are now in the original submission, right? <muradm>apteryx: no, last time i was submitting seatd/greatd i was asked to separate commit with test, so i decided to postpone it to make things easier with one commit <apteryx>OK :-) I personally like to see related things grouped, especially implementation + tests, but that's workable either way. <muradm>apteryx: same here, was surprise for me <pkill9>how do you specify static networking in guix config now? <pkill9>becaus ei get "no target of type 'static-networking' for service 'static-network-interface'" <davidl>pkill9: (service static-networking-service-type <davidl> (value (string-append myip "/" (cadr (string-split mysubnet #\/))))))) <davidl> (name-servers (list mygateway))))) ***Dynom_ is now known as Guest688
<pkill9>thanks,i got it working now with (service static-networking-service-type (list %loopback-static-networking)) or something like that <sudognu>How do I know all the versions of a package? <kabouik>Can I inherit the hash from an existing package if I want to just do a modification of the same package using the same source, but different compilation options? <sudognu>emacs-next-pgtk seems to break with exwm (with DooM Emacs) <kabouik>This would save editing the hash in the modified package, it could just inherit it from the base package <kabouik>Meaning the modified-package.scm would not need to be maintained since its content wouldn't change with updates <sudognu>kabouik: probably not, IIRC the hash depends on its contents/manifest and Guix is picky about build tools too <sudognu>I.E you can't jump from the first rust to the last, have to build each version in order <sudognu>kabouik: shouldn't Guix autodetect your modified package? <sudognu>you can give it a different name or version, or maybe edit the channel repo. <podiki[m]>not sure I understand, when you inherit a package only the fields you specify will override the original: so don't touch origin and just change build options for your variant <kabouik>I need to touch (origin) because I'm applying a patch <podiki[m]>(the build hash of course changes, but I assume you mean the source hash) <kabouik>But yeah then the hash will change since it will be compared after the patch <podiki[m]>which hash do you mean? there is the source hash (if you inherit and don't change it will be the same as origianl source) <antipode>The hash you put in the sha256 of the origin is only over the source code. <podiki[m]>and there is the /gnu/store/<hash>-pkgname-version hash, which changes on any changes to the package definition itself as well <antipode>Any build tools or configuration flags or phases are irrelevant for what you put in the sha256 field. <antipode>kabouik: The hash is only over the unpatched source code. <kabouik>I think in my case it would be the source hash, but since I want to apply a patch to it, inheriting it from the base package wouldn't help anyway (and is not easily feasible because I need (origin) to apply a patch anyway) <antipode>kabouik: WDYM with not easily feasibleN? <antipode>There's a nice procedure package-with-extra-patches <antipode>like (package-with-extra-patches the-original-package (list (local-file "add-this-too.patch")) <antipode>How would inheritance be hindered by patches? <kabouik>I tried earlier to just install the package already in Guix channel with the transformations I wanted. To summarise, I want three custom changes: use latest git commit, apply a patch to the source, and compile with an extra option. I came to realize that using the latest commit goes against the Guix reproducibility philosophy, so I started leaning towards dropping that from my wishlist, and just writing a custom.scm that would <kabouik>contain the patch and the compile options. But then, I don't really want to edit it regularly to change the hash and versions, I'd prefer inheriting all that from the Guix-channel package. <kabouik>And if I ever want to get the latest commit, I guess I can always install with --with-branch=package=master anyway <kabouik>I will look into the package-with-extra-patches you mentioned, didn't know about it <podiki[m]>well a source hash has to be updated only if the source is updated...you could just use a particular version rather than inheriting, or just accept that there is always some package maintenance <podiki[m]>also, for nnn I count 3 version related commits in the last year <kabouik>But to make a variant that is just a patched package from Guix channel, having to manually maintain the variant for the hash and version seems just error prone, since I would have to keep an eye on the base patch all the time for no added value <kabouik>Yes, that was the point of the "latest-commit" on my initial wishlist, the package is not getting updated often; but nnn itself is changing on a daily basis <kabouik>But I understood that building packages from latest commits beats the point of guix reproducibility, so I got it that it's better to stick to fixed versions (and occasionally use CLI transformations if I need bleeding edge commits) <podiki[m]>sounds like you want a variant package that inherits from nnn, changes the build option (that needs a package definition), but adding a patch and using latest commit can be done with package transformations at install <podiki[m]>then everytime you install it pulls the latest commit <podiki[m]>(I have a manifest where I use transformations to always use latest commit on some branch for some packages) <kabouik>I was able to install nnn (guix channel) with CLI transformations (latest commit + patch), but not quite able to transform that into Guile (the errors I got were probably easy to fix, but I didn't find how yet and seeing an example would help). <kabouik>Can I see those packages? Though if I remember correctly my issue was to transform the --with-patch=nnn=my.patch into its Guile equivalent <podiki[m]>what do you want in the end? if you just want to have the package installed as you want it, sounds like you are mostly there (you could us a manifest to have the transformations functions explicitly) <kabouik>I have looked everywhere how to show the manifest of an installed package (with its transformations) and no dice; are you saying it's possible? Damn I looked for like one hour in the man :< <podiki[m]>if you installed a package with transformations, "guix package --export-manifest" will output all packages installed (in the default profile) with the transformations you used <kabouik>Because then I could just use the "transformed" package as an .scm file in my private-channel, instead of having to rely on CLI commands to get the transformation on different machines <podiki[m]>this manifest can be fed to e.g. guix package to update all packages installed to latest version <podiki[m]>yes, sounds like you want a manifest, that you can share to install same packages elsewhere <pkill9>has anyone tried using guix on alpine linux? <kabouik>Hold on, when I use --export-manifest, I'm just getting a list of packages, not a scm content. And if I try specifying a package name, it just errors out <kabouik>Ok, similar to what is in your git file, I see the transforms at the top <podiki[m]>guix package --export-manifest (no other args needed) will output that <podiki[m]>you can copy/paste it or do guix package --export-manifest > my-manifest.scm <podiki[m]>the cookbook link I sent should be helpful, sounds like what you want (for reproducing packages on another machine) <unmatched-paren>davidl: when you want to paste a code block longer than 3 lines, could you please use paste.debian.net, 0x0.st, paste.sr.ht, or something similar? <kabouik>I know how to export the output to a file.scm but my misunderstanding there is I was expecting that the manifest to look like a package-specific scm files, with transformation in it. <podiki[m]>no, it is a list of packages generally, though can have Guile code that modifies them; this is used by e.g. guix package to install packages <podiki[m]>it does not export the full package definition, those live in Guix itself and are not needed for a manifest (Guix looks up the package name to know what it means) <kabouik>Actually, reproducing packages on different machines is part of what I want, but it doesn't exactly cover all the needs. What I wanted is a custom package with my patches, that I could decide to install or not on different machines. A manifest is a bit more all (packages) or nothing. <kabouik>nnn is not all that important in the end, it's just the package I chose to experiment and learn (slowly, as you can see). <podiki[m]>you could even use some code that selectively adds or not package there probably <podiki[m]>I use several manifests for organizational purposes, for instance <kabouik>My goal in the end really is to learn packaging third-party software from git, with or without custom changes (patches, latest commit or fixed versions with hash, compile options), and nnn was interesting because it is already packaged for Guix channel so it gave me an example, and also opened new possibilities (inheriting, hopefully to avoid duplicating maintenance too). <shcv[m]>I'm contemplating packaging doom-emacs for guix so I can get all of my home setup into guix home; which approach do you think is best? <shcv[m]>1. Just install the doom utilities, and then leave everything else (.doom.d, .emacs.d, all of the straight.el packages) in mutable userspace <shcv[m]>2. Pass in the config files, and build the whole .emacs.d as an immutable blob by invoking `doom install` and `doom sync` during the build phase (rebuilding from scratch every time) <shcv[m]>3. Go all in and make configuration records for the doom configs, and try to somehow redirect straight to use separately installed packages managed by guix <apteryx>shcv[m]: can't doom-emacs use the Guix-provided Emacs packages instead of reinventing the wheel? <shcv[m]>apteryx: well, the default is to use straight.el to install packages, but that can be disabled / overridden I think <antipode>I'm wondering, do other people here also charge phones with laptop chargers? <kabouik>I do, occasionally, but prefer slow chargers when I have one at hand to preserve my phone battery. <kabouik>Or when I don't need quick charge of course. <shcv[m]>antipode: I have a usb-c charger that I sometimes use for both my phone and laptop when traveling, but it's not as good as my dedicated phone and laptop chargers for their respective devices <kabouik>My USB-C charger has a 65W port and a couple slower USBA ports. When traveling I usually take only that too, and will plug the phone to the slow ports when I have time, to the fast one when battery charging is more important than preserving it from the extra wear. <antipode>Because to me it kind of seems a weird thing to do. <antipode>kabouik: Do you have sources for fast chargers (laptop chargers?) causing extra wear? <gnucode>woo hoo! I just sent in a bug report that shows that auto login to tyy doesn't work for all ttys. <kabouik>Well, at work I use a laptop and don't bring a phone charger, so if my phone needs juice during the day, I just unplug the laptop (use its battery) to recharge the phone a bit, without dealing with multiple chargers. <kabouik>antipode I just take that from a friend who is into repairing electronic devices, I could ask him sources <antipode>OTOH avoiding separate chargers was the main reason of the EU for pushing for a single charger standard ... <kabouik>I believe the charge rate is not the actual issue for battery wear, but the heat it causes is <kabouik>My phone goes above 45°C when fast charging from a low battery level <gnucode>unmatched-paren: do you use erlang often? <unmatched-paren>i'm trying to package lfe, 'Lisp Flavoured Erlang'; or rather trying to upstream the lfe package in guixrus <unmatched-paren>and it seems as if though BEAM binaries are installed in lib/erlang/rebar3_proper/ebin, actual executables are not in bin <unmatched-paren>seems like rebar has a feature to create binaries for running BEAM output binaries <warren>Yesterday in chat (see logs) I wrote we're looking for help from someone who can adapt Guix to build other FOSS into portable Linux binaries. https://twitter.com/rocky_linux/status/1554844007356051457 We're also interested in someone with skills and interest to work on this grander goal: Use guix to bootstrap and demonstrate a reproducible core of packages for Fedora or Rocky Linux. Those distros would need a lot more more work to adopt it later but <warren>merely demonstrating that it is possible to make the core reproducible would inspire them to take it seriously in the long-term. <vagrantc>warren: might also be worth mentioning on #reproducible-builds on irc.oftc.net or rb-general@lists.reproducible-builds.org <warren>ugh it's effort to setup IRC bouncer for a second IRC network ***mark_ is now known as mjw
<civodul>apteryx: great to see that it's used there! <civodul>nckx, rekado_: "ssh berlin" also takes ~20s here; i don't see any clues in /var/log/messages <unmatched-paren>Huh, adding (inputs (list)) to shadow the inputs from gdamore-v1 made it work <apteryx>civodul: for me too (35 s to be exact) <efraim>is it slow even after connecting or is it just the initial connection that's slow? <rekado_>when I connect first it takes about 30 seconds <rekado_>then I open another terminal (while still connected) and try connecting again <civodul>a quick "strace -p1 -Tt" :-) suggests that shepherd accept(2)s immediately but then sshd doesn't print anything to /var/log/messages until seconds later <civodul>actually looking at /var/log/messages is enough <efraim>well multiple connections could be grouped using ControlMaster, I meant more does the server have a high load and typing in that connected terminal take a long time to return also <apteryx>it's also slow connecting to self locally <apteryx>seems some authentication related problem, perhaps <apteryx>also, I wonder why 'guix install strace' there goes building it <apteryx>can't it uses the substitutes it provides itself? <civodul>i went through that too! that's because of test failures, i think it depends on the kernel version <unmatched-paren>Could somebody merge some patch adding go-github-com-google-shlex? There are about a gazillion patchsets adding it, and I don't really want to duplicate that effort... again... <unmatched-paren>There's also go-github-com-xo-terminfo, go-github-com-go-ini-ini, and go-github-com-emersion-pgpmail <unmatched-paren>Go doing Go things, but it would be really nice if we finally had these oft-added packages in Guix so we don't continually duplicate them <kabouik>So… I ended up inflating my nnn patch, which no alters not only `nnn.c` and `nnn.h`, but also the Makefile so that my custom compile options become default after the patch is applied. This means I can get all I want with `guix install nnn --with-patch=nnn=$HOME/.config/guix-private-channel/my.patch` (and even latest git if I add --with-git-url=nnn=https://github.com/jarun/nnn.git). It's not exactly what I wanted in the first <kabouik>place, but I have to change my plans because (1) I'm not learning Guile/Guix as well as I hoped I would, (2) my plans where not very guixy apparently so it's best altering them than skewing the philosophy I'm trying to blend into. <kabouik>Seeing that I do have a private channel working, there's still a little frustration that I can't use it directly to get the nnn I want from a new machine (and cherry pick what I want on a per-package basis, so not with manifests), but I can download the patch from the git repo and install manually with the above guix install command and transformations. <unmatched-paren>kabouik: You could still use those transformation options from Scheme <rekado_>a manifest is just Guile code, so you could also generate things on demand based on input or state. <unmatched-paren>if your patch is in the same directory as nnn.scm, and it's named nnn.patch <unmatched-paren>Hmm, wait, doesn't (current-filename) not work when the code is compiled? <kabouik>Let me try that, I have to seek through my git history to find a commit where I had a nnn-custom.scm in which I was trying guile transformations <kabouik>That should be enclosed in a (define transform… ), correct?