IRC channel logs


back to list of logs

<maximed>PotentialUser-19: the development images aren't signed with PGP keys.
<maximed>They are generated by the CI.
<maximed>Technically, these are substitutes that are signed by the CI machine.
<maximed>However, that's a nix(?) signature, not a GPG signature.
<maximed>So it's not a signature you can verify if you don't already have guix set up.
<civodul>maximed: that's a raw libgcrypt signature sexp :-)
<civodul>see (guix pki)
<PotentialUser-19>ok thank you, then i will stick to the latest release until i installed the system.
<vagrantc>hah. of course tests/keys/* were formally just in tests/ and renamed. :)
<lechner>Hi, I have a patch to upgrade xcb-proto to 1.15. Is the new mentors process documented anywhere? Thanks!
<vagrantc>lechner: i don't think it's sorted out yet
<vagrantc>lechner: definitely targeted at core-updates: Building the following 7431 packages would ensure 15670 dependent packages are rebuilt:
<lechner>vagrantc: thanks! should i mention the core-updates part?
<vagrantc>lechner: anyone reviewing ought to look, but doesn't hurt to be upfront just in case :)
<lechner>vagrantc: thanks for the pointer!
<vagrantc>lechner: it's also all documented in
<vagrantc>though the long list is admittedly a little on the intimidating side :)
<lechner>vagrantc: yeah, i'm still getting friendly with that list one by one
<vagrantc>i vaguely recall some sort of "fsck" like think for /gnu/store, but not finding it amoungst all the plausible commands.
<vagrantc>there's "guix build --repair" ... does that just check everything?
<vagrantc>or does it require specific paths?
<jackhill>guix gc --verify=contents,repair
<vagrantc>that's it! thanks!
<macrobenis[m]>mr guix I need help
<macrobenis[m]>xorg is being xorg and not liking me
<macrobenis[m]>To elaborate: keyboard and mouse are not working even after I installed libinput
<iyzsong-w>macrobenis[m]: how you start 'xorg'? and gave a link of the 'Xorg.0.log' file here.
<macrobenis[m]>using sx.
<iyzsong-w>is your user in the 'input' group, it need permission to access /dev/input*
<macrobenis[m]>umbra@entropius ~$ groups
<macrobenis[m]>users netdev audio video input wheel
<macrobenis[m]>sorry about that was rebooting
<iyzsong-w>okay, maybe then we need to see the log file for more information..
*macrobenis[m] posted a file: (5KiB) < >
<iyzsong-w>macrobenis[m]: seems no permission for '/dev/tty0', the user also need to be in the 'tty' group.
*macrobenis[m] posted a file: (30KiB) < >
<macrobenis[m]>after a small reboot i am back with another log file :D
<iyzsong-w>macrobenis[m]: looks better now, why it terminated successfully, what's in your ~/.config/sx/sxrc
*macrobenis[m] posted a file: sxrc (0KiB) < >
<macrobenis[m]>i could have just typed it out
<macrobenis[m]> * `exec stumpwm`
<iyzsong-w>you should put '#!/bin/sh' in sxrc first, and make it an executable by 'chmod +x'.
<macrobenis[m]>also still no dice with the shebang
<iyzsong-w>macrobenis[m]: um, try 'sx sh -c xterm' to run 'xterm' or some other X prog.
<iyzsong-w>macrobenis[m]: did the stumpwm start, but without mouse/keyboard now? maybe you removed 'xf86-input-libinput' from 'xorg-configuration'?
<macrobenis[m]>It always started
<macrobenis[m]>Libinput is installed
<macrobenis[m]>Xterm runs and shows up but I can't type anything as if there is no input
<iyzsong-w>macrobenis[m]: did you use the 'xorg-server-service-type'?
<macrobenis[m]>this is all in userland
<macrobenis[m]>little bit of a noob to guix but anything xorg I configure through guix-home
<macrobenis[m]>Wayland works perfect
<iyzsong-w>okay, if you use that service in system, then libinput will be available to xorg. if you install 'xorg' and 'xf86-input-libinput' into profile, it won't find it unless you pass some commandline flags...
<macrobenis[m]>was able to use my existing sway config of like 2 years with no problems whatsoever
<macrobenis[m]>nothing xorg related is in system for security reasons
<iyzsong-w>see 'ModulePath set to' in the Xorg log, that directory should contain xf86-input-libinput, but i guess it doesn't in your case.
<iyzsong-w>it can also use (need writing) a xorg home service, just like the system wide 'xorg-server-service-type', to add the needed commandline flags to set this 'ModulePath'.
<macrobenis[m]>ah i see
<vldn>hey :)
<vldn>how to copy a local textfile to the source directory? (writing a package definition..)
<vldn>or maybe better, how to access the source directory?
<iyzsong-w>vldn: something like in the 'phases': #~(copy-file #$(local-file "./foo") "./foo") <local-file> will be 'ungexp' into a store path when making the package's derivation.
<vldn>like you do with "out" or $output"
<vldn>ah ty will try
<macrobenis[m]>i think ill just use wayland and xwayland instead of xorg for now because i just want to get setup :) thanks for the help
<iyzsong-w>macrobenis[m]: sure :)
<vldn>    (snippet #~(copy-file #$(local-file "dwm-config.h") "config.h")) works :) ty very much!
<iyzsong-w>cool :o
<char[m]>I have confirmed that just adding #:use-module (gnu packages commencement) to haskell.scm causes tcc: unbound variable. I think it has something to do with cycles, but I do not understand.
<char[m]>even (module-ref (resolve-interface
<char[m]> '(gnu packages commencement))
<char[m]> 'gcc-toolchain) causes it but at 14% instead of 11%.
<mlan>Hello guix
<Aurora_v_kosmose>Just so I don't make a fool of myself, I'll ask here first. But, would this involve bypassing manual review of such patches? Because the malicious NPM-style malware patches might not trigger any failures for tests.
<maximed>char[m]: As written in a comment at the beginning of (gnu packages commencement), that module may not be imported.
<maximed>Whether (module-ref ... ...) would be fine depends on the context
<maximed>(it can be done in thunked or delayed context, but not elsewhere)
<maximed>So FWIW it cannot be put in (inherit ...) or directly in (properties ...)
<raghavgururajan>Hello Guix!
<bdju>when is the next guix iso planned for release? it would be cool to have Sway in there as one of the default picks
<jpoiret>bdju: in the gui installer?
<maximed>Aurora_v_kosmose: --with-latest/--with-branch does not do any review (it's just some automated code, so it's not really in a position to review code)
<jpoiret>i'm feeling lucky, it's time to reconfigure on staging
<jpoiret>bdju: the issue i can see with sway as default is that you'll need a bunch of other apps too to have it be useable
<vldn>how to prettyprint text with lot of regex e.g. "'§//'';''§\'" something like this, without intreptate that as gexp or something?
<maximed>vldn: I don't see the relevancy of G-exps here?
<maximed>G-exps don't care whether they contain regular expressions or not.
<maximed>Is this about pretty-printing Guile code in Guix?
<avalenn>Hello Guix!
<bdju>jpoiret: gui installer, yeah.
<bdju>well, could ship it with basics like grim and slurp and wl-clipboard then
<jpoiret>i'm talking about a default terminal though
<jpoiret>the rest can be user-installed once there's a terminal
<bdju>foot or alacritty then
<bdju>probably foot is the better choice
<jpoiret>foot handles fonts in a unusual matter, no?
<jpoiret>FTR, i am interested in adding a default "minimal" desktop experience with possibly sway and greetd
<jpoiret>but the out-of-the-box experience needs to be polished still
<jpoiret>maybe wayfire + wf-shell would be a better choice
***donofrio__ is now known as donofrio
<mothacehe>rekado: hey! I have root@ Permission denied (publickey) when trying to ssh the aarch64 nodes using berlin root account
<pmk>Hey guix. Does anyone here use emacs-guix? For me it fails to start guix repl. I am using version 0.5.2 which as far as I can tell is the lates.
<nckx>pmk: I got the same error last week.
<nckx>jpoiret: <unusualfootfonts> How so?
<jpoiret>emacs-guix is out of date i think
<jpoiret>nckx: i think it doesn't use fontconfig at all
<nckx>It's definitely not feeling too good.
<nckx>jpoiret: I think you're thinking of another TE, or perhaps a very old version of foot.
<jpoiret>oh, my bad then
<nckx>Mine certainly does.
*nckx hugs their foot.
<nckx>(Big fan.)
<jpoiret>it's literally written on the README that they use fontconfig
<pmk>Thank you both!
<jpoiret>i may switch from kitty to foot then
<nckx>jpoiret: Thinking about it a bit more, maybe there's something ‘different’ in how they handle fallback fonts. Still using fontconfig, but… different? Very vague because I don't know more.
<nckx>But certainly shouldn't be a blocker.
<nckx>jpoiret: And I haven't tried kitty. Maybe we should both switch for a week for a hi-larious reality TV show.
<jpoiret>"They Switched Terminals For a Week, See What Happens Next!"
<jpoiret>kitty takes a long time to start (because GPU-accel apparently)
<nckx>Narrator: ‘…jpoiret is upset because the subpixel rendering is slightly wrong, whilst nckx is catting 4-GiB files to kitty to demonstrate it's 4% slower.’
<nckx>That's actually been my experience with alacritty, the ‘accelerated’ TE, but then I don't have a mining rig GPU so I have obviously failed as a consumer.
<jpoiret>vte benchmarks everyone, the apex of human intelligence
<jpoiret>because My VT is Faster Than Yours, and You Should Feel Bad™
<nckx>Meanwhile people obsessed with ‘bloat’ are using the Linux framebuffer, literally orders of magnitude slower than any of them.
<nckx>We do amuse ourselves.
<jpoiret>they may be using kmscon though
<nckx>Is that xcellerated?
<jpoiret>I mean, no reason it couldn't be as fast as a Wayland VT
<jpoiret>I don't think so, now that you're asking
<jpoiret>but it could
<jpoiret>it's been dead for years though (which I why I kind of dread using it for the installer and proposed switching to cage)
<nckx>Have you been around that long? How time flies.
*nckx looks up cage.
<nckx>Ah, it would be more like running a TE in an X root window? Or am I butchering the comparison?
<reyman>Hi there !
<nckx>Hi reyman.
<reyman>I finally take time to look at the jres2022 (fr) presentation of guix, great !
<reyman>i have one question about package management, what's the difference between guix upgrade ? and guix system reconfigure --xx.scm ? from the point of view of one user logged into guix os
<ardon>Hi Guix! I get this error on virt-manager: "spice-client-error-quark: Could not auto-redirect USB device at 3-39: Could not open usb device (insufficient permissions)" when trying to redirect a USB device to a virtual machine. I've added a `spice` group to my system configuration, and added my home user to it, as well as the following udev rule . However, after doing all of this, it still prompts me for
<ardon>insufficient permissions. I found this recent thread on SE , how would I go about adding a polkit rule as the one they mention in Guix?
<nckx>reyman: Short answer: the first is run as a regular user, and updates the packages installed by that user (using ‘guix install’, or a manifest). The latter must be run with root privilegeds and updates the OS (your ‘guix os’, which we call Guix System).
<jpoiret>nckx: yes!
<jpoiret>first tests indicate foot feels nicer than kitty, more tests to follow
<nckx>Guix allows each user to install their own packages: bob can type ‘guix install gimp’ and then type ‘gimp’ to run, well, the GIMP, just like on a regular distro (but notice the lack of sudo). When alice logs in, she won't have the GIMP in $PATH or on her desktop unstill she also chooses to install it. The profiles are separate.
<bdju>jpoiret: I'm not aware of unusual stuff with fonts in foot... unless you mean prioritizing emoji or something
<nckx>reyman: When running Guix on another distribution, say Trisquel, that's it. But when you run Guix System, there's also a ‘system profile’ managed by root, that provides a set of base packages.
<nckx>The ‘guix system’ commands manage that system, and aren't used on other distributions where Guix is just a package manager.
<nckx>jpoiret: Yep, that's why I use it. No arguments. I just like the feel.
<reyman>ok i understand, that's overlap if one user (me) use one os (me), i have a .scm for my home, a .scm for system, and package could overlap.
<reyman>i run a guix system reconfigure without sudo, and that seems working because my user is wheel. Sudo is not needed in this case i see ?
<maximed>reyman: FWIW you can make the packages field in the system configuration almost empty (maybe only nss-certs) and install everything in the user's profile, to avoid overlap
<nckx>Yeah, if you are the only user the choice of what's a ‘system’ package is entirely yours. Most people would advise you to keep your system profile small (not include a Web browser etc.) because to upgrade your kernel you'd need to update the entire profile.
<nckx>reyman: No, it will fail.
<maximed>The download step ‘let's download the required packages for the new system’ will work
<maximed>but the actual reconfiguration will fail
<nckx>It will build everything but fail at the very end, when Guix actually (and almost atomically) switches to the new ‘profile generation’. But that's not a disaster, just run it again with sudo and everything will already be built and the switch will be almost instant.
<nckx>But Guix does not do any (icky) ‘oh, you're in the wheel group, time to do some magic’ magic.
<reyman>ok ! good to know ahah, i cut he compilation of linux kernel ... and rerun with sudo :)
<nckx>maximed is an optimist and says download instead of build, in practice you'll see a mix of both :)
<nckx>reyman: You can just let it finish to save the time you've already invested in building Linux.
<nckx>Otherwise Guix will start from the beginning. If you let it finish, the result will be cached.
<nckx>* Linux-Libre, to be precise.
<reyman>ahah ... ok, also good to know
<maximed>I often put at least a day or so between "guix pull" and "guix package -u/guix system reconfigure" to avoid having to build too much locally
<nckx>Normally I'd be surprised that you're building Linux-Libre but I did see an update scroll by…
<reyman>why @maximed ?
<nckx>reyman: Guix has build servers that build all packages. Your guix command will first check if such a pre-built package exists, and download it instead of building locally.
<nckx>This is optional but should be enabled by default.
<reyman>ok, good to know, if i want to have guix on multiple machine like say a rpi4 and my current machine, i have two .scm for each, and the same .scm for user, that's good
<nckx>The link above is to that build server. It implies that prebuilt packages (‘substitutes’) should be available, at least if you're on x86.
<nckx>aarch64 builds are currently broken because of hardware trouble.
<reyman>ok !
<maximed>reyman: if the two machines are on the same network, maybe have a look at --discover and whatever the option is for announcing in guix publlish
*nckx AFK for coffee kletsing.
<maximed>(+ substitute authorisation)
<maximed>That way, one machine can share a locally built package to the other machine
<maximed>And with some luck, a machine can get a substitute (pre-built package) from the other machine even if the ‘official’ build farm is down
<reyman>And, to be sure, guix pull download new source code of package + guix only, this is guix upgrade that do the job isn't it ?
<maximed>"guix pull" downloads the new version of Guix (including packaging definitions, but not the source code of the packages)
<maximed>guix upgrade actually upgrades the packages (according to the package definitions in the version of guix you have pulled)
<maximed>(guix pull ≃ apt get update, guix upgrade ≃ apt-get upgrade)
<reyman>ok :) thanks @maximed
<pmk>Is there any way to find which profile "owns" a specific directory in the store?
<nckx>‘guix pull’ is ingeniously designed to make you think it's rebuilding the world, but no, it's just updating Guix + the package ‘repo’.
<maximed>pmk: a directory can be used by multiple profiles
<maximed>pmk: Maybe try guix gc --referrers /gnu/store/s5pd3rnzymliafb4la5sca63j86xs0y0-hello-2.12.1/bin/hello ?
<pmk>I see. I will try that, thanks!
<maximed>(to find out where the HASH-hello-2.12.1 store item is used)
<vldn>Someone using SX and Starts xorg manually?
<vldn>My Keyboard and mouse doesnt Work after Start
<vldn>I'm using the xorg-server-service-type as suggested by a few others
<iyzsong[m]>vldn: make sure you uninstall xorg-server from your profile, sx should start '/run/current-system/bin/X'
<reyman>@nckx ahah :)
<pmk>I am trying to debug a multithreaded application that I compiled in a guix shell container. When I start it in gdb I get this warning: `warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.` I did install both `gcc-toolchain:debug` and `glibc:debug` and I did set `libthread-db-search-path` to
<pmk>`/gnu/store/xgarlnscgbm9l04karj15xpc4nn14ak1-glibc-2.33-debug/lib/debug/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib` in my gdbinit but still the issue persists. (`/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33` is where the executable finds `` according to ldd).
<pmk>any ideas?
<guixuser-87>Hi ! Is there someone who has NFS mounts working? I'm using the (service nfs-service-type), I've installed nfs-utils and libnfs on system level, but NFS filesystem entrys ain't working and manual mounts aren't either. (mount.nfs: Protocol not supported) Thanks.
<rekado>mothacehe: oh, I’m using the MDC local IPs for that.
<rekado>mothacehe: (pankow), (kreuzberg), (grunewald)
***jesopo is now known as jess
<lechner>iyzsong[m]: It might be helpful to document your X advisories somewhere, if they aren't already. I have/had similar problems in userland
<attila_lendvai>using home services: if i want to set some gnome defaults using `gsettings set ...`, where would i put it?
<iyzsong[m]>lechner: yes, but i feel some difficult for docs, since i'm not a native english speaker, and i do not have internet access at home (only mobile data) now, hope i 'll back into hacking guix soon..
<reyman>I need to mount a smb share at university, i suppose i need to use the PAM mount service to do so ?
<reyman>I'm interested if someone have an exemple with (gnu home)
<reyman>or using file-system ?
<ekaitz>hi, i'm using guix shell with a manifest and even if I update the manifest it's still using packages from a previous build, how can I make totally sure that it's using the current manifest to build? it's like something stays cached
<ekaitz>oh forget it, it's just me
<ekaitz>in any case, there's some caching happening, how can I clear everything? `guix gc`?
<maximed>ekatiz: "guix shell --rebuild-cache etcetera"
<maximed>However, it should be using the latest manifest (unless the manifest loads another file, which the caching code doesn't know about)
<maximed>(no need to gc the entire store)
<apteryx>ekaitz: the idea of 'guix shell' is that as a user, you need not care about managing the cache yourself
<apteryx>I think it sets a temporary 'root' to avoid its cache being garbage collected, which gets refreshed when you use it. Thus, over time, unused 'guix shell' environments get garbage collected.
<ekaitz>ooh ok maybe it's because I'm loading another file and mixing stuff
<ekaitz>thank you!
<ekaitz>any idea of why the strip phase would drop a lot of "unable to recognize the format of the input file" messages?
<acrow>glad to be back with guix
<maximed>ekaitz: Is it trying to strip .go files?
<ekaitz>maximed: nope, they are c libraries, (.a)
<maximed>Also, are you compiling a cross-compiler?
<ekaitz>yes, it's because of that?
<maximed>ekaitz: I guess
<ekaitz>can I supress the warnings somehow?
<maximed>maybe it's calling "strip" on the cross-compiled libraries, instead of only on the (natively-compiled) compiler
<maximed>ekaitz: Maybe, I don't know
<maximed>In the gnu-build-system module there are some #:strip-??? arguments
<ekaitz>now you mention it... yes it's trying to strip the cross compiled things :D
<maximed>maybe one of them is relevant?
<ekaitz>okay I'll take a look into it
<maximed>Or maybe: fix the strip phase, such that it uses the right TARGET-strip / strip for everything
<maximed>Alternatively, a big hammer would be to delete the strip phase entirely.
<ekaitz>leaving it with the errors is the super big hammer option right? :D
<ekaitz>even if it fails, could it be breaking anything? it shouldn't right?
<apteryx>is there any texinfo expert here? I'm trying to understand the root cause of
<maximed>ekaitz: the binaries wouldn't be stripped, but that only costs some disk space
<ekaitz>maximed: doesn't sound dangerous
<apteryx>it seems our pxref for the Introduction node of the geiser manual is OK, so the issue is either at the level of the Geiser manual source (but it looks fine --
<apteryx>so perhaps a bug in texi2html?
<apteryx>when I serve the Geiser HTML doc locally with 'make -C doc http', the Introduction page is at http://localhost:8082/#Introduction, while the next node 'Installation' is at http://localhost:8082/geiser_2.html#Installation, which seems odd
<lechner>iyzsong[m]: Hi, I would be happy to write it up for you. I am new to Guix but have sufficient experience to translate any bullet points or irc messages, if needed. Also, my X is likewise spotty
<civodul>apteryx: probably that's because Geiser renders its manual with texi2html rather than makeinfo
<civodul>and texi2html has a different naming convention for HTML pages
<civodul>(there's no point in using it these days IMO)
<iyzsong[m]>lechner: thanks! i can anwser questions in irc later, we should talk later. going sleep now 🥱
<maximed>I get errors about things not implementing Debug when compiling rust-git-config:
<maximed>If I apply the compiler's hint, then the error disappears, but other errors about Debug appear in use sites.
<maximed>Does this sound familiar?
<vagrantc>yay, first time i can recall seeing guix build reproducibly on debian: ... unfortunately, test suites seem to be failing on 32-bit architectures
<apteryx>civodul: I see! Thanks for tipping in. I'll try adjusting Geiser to use makeinfo, if that's not too difficult to compare the result
<maximed>vagrantc: which tests fail?
<vagrantc>maximed: FAIL: tests/channels.scm - latest-channel-instances #:validate-pull FAIL: tests/channels.scm - channel-news, no news FAIL: tests/channels.scm - channel-news, one entry FAIL: tests/channels.scm - latest-channel-instances, missing introduction for 'guix' FAIL: tests/channels.scm - latest-channel-instances, authenticate dependency
<vagrantc>maximed: and for more fun
<vagrantc>(guess it used to build reproducibly on armhf, too)
<civodul>vagrantc: is that before changing the OpenPGP keys?
<vagrantc>civodul: fixed that issue, that's why it builds on amd64 and arm64
<vagrantc>civodul: thanks for the pointer to that, by the way, it was non-obvious from my rough read of the test suite failure
<maximed>IIUC, the test failure has been resolved?
<vagrantc>maximed: only on amd64/arm64
<maximed>FWIW there's a bug in guile-git w.r.t. endianity (it assumes size_t = big endian) (I've sent a PR upstream)
<maximed>maybe there's a 64-bit assumption somewhere as well
<vagrantc>og, that sounds plausibly related
<maximed>(or maybe a false lead)
<vagrantc>i've bumped the priority on the reproducible-builds infrastructure, to see if it fails there also ... but is the current status
<vagrantc>i'll also try a local build
<vagrantc>there are other issues around the probably real soon now removal of guile-2.2 from debian, which guix in debian itself isn't a blocker, but dependencies of it's dependencies still use guile-2.2 ...
*vagrantc is tempted to fix that by breaking the other packages...
<lechner>rekado: thanks for xcb-proto!
<vagrantc>if i CC only ... do i need to keep in CC ?
<maximed>vagrant only is required I think
<maximed>Though FWIW, if you add both NNNN@ and, then I've observed that no new bug entry is made, it's just added to NNN@ IIUC
<maximed>* vagrantc:
<char[m]>What package do I need to install to get GUILE_PKG m4 macro?
<maximed>char[m]: I'd assume 'guile'
<maximed>No clue how autoconf finds the .m4 though (autoconf doesn't have search paths)
<char[m]>I have guile already and pkg-config too
<maximed>char[m]: FWIW, maybe you could try "guix shell --pure -D gnunet-scheme" and run autoreconf etc. inside?
<maximed>(gnunet-scheme is a Guile library that uses autoconf and the GUILE_PKG macro)
<lechner>char[m]: my package cannot find GUILE_PKG, either
<maximed>* apparently ACLOCAL_PATH is set
<maximed>I'd give running autoreconf inside "guix shell autoconf automake pkg-config guile" a try.
<rekado>also use ‘guix shell --check’ to be sure you’re not overriding variables
<jpoiret>currently reconfiguring on staging 8)
<voroskoi>how can i export encironment variables in a guix shell manifest file?
<maximed>voroskoi: Currently, you can't (except for search paths). Though it's definitely something that could be implemented
<maximed>There were some ideas for that in ML.
<voroskoi>ok, thanks
<maximed>which environment variable?
<voroskoi>This time CC
<voroskoi>but it woukd be useful to set secrets and so
<maximed>ok, that's not currently supported yet
<maximed>Though for secrets this seems problematic because the store is public
<maximed>(unless with secret you mean: this environment variable points at that file, which contains secrets, instead of password=1234)
<voroskoi>yep, something like that
<PotentialUser-95>i defined a custom package with a higher version to override an existing one, but guix show does not pick it up
<jpoiret>PotentialUser-95: how/where did you define it?
<peonerovv>hi. i was trying to compile dwm with some patches pre-installed. one of the patches requires Xft.h. It in tern requires ft2build.h. I installed freetype but the header files are in the .guix-profile/include/freetype2 and not .guix-profile/include where Xft.h is looking. What am I supposed to do?
<char[m]>maximed: I dont have guix on this system. Im trying to build one of the dependencies (guile-sqlite) so I can build guix.
<PotentialUser-95>in .config/guix/system/.. , guix build -f works , guix package --install-from-file also works
<unmatched-paren>peonerovv: are you making a guix package for your patched version?
<jpoiret>so in ~/.config/guix/ PotentialUser-95?
<unmatched-paren>because that's probably the best thing to do
<jpoiret>in any case, Guix won't pick up packages defined in random files
<unmatched-paren>sometimes compiling from source can be a bit weird on guix and nix
<jpoiret>you can either modify a local checkout of Guix, or add your own channel
<jpoiret>the manual describes how to setup your own channel
<unmatched-paren>because of how different it is to a standard distro
<jpoiret>what's the use case? you want a new version of an app installed in your profile, or you want a library used by lots of guix packages to be a newer version PotentialUser-95?
<unmatched-paren>peonerovv: see and for examples of patched dwms
<jpoiret>in the former, you can just guix package --install-from-file, for the latter, you'll need to upgrade the package in your own guix checkout, or use package transformers
<peonerovv>unmatched-paren: no? I'm just compiling it with make? Im not totally sure what you mean. I installed guix a few days ago and am still not very familiar with it
<unmatched-paren>peonerovv: as you have experienced, you may hit problems just compiling it with make
<PotentialUser-95>jpoiret the latter, i want to bump this
<peonerovv>yes, so what do i do?
<PotentialUser-95>to have an extra option
<jpoiret>peonerovv: freetype uses pkg-config
<unmatched-paren>the Guix Way(TM) is to write a new package for your patched dwm that inherits the original dwm
<unmatched-paren>those links i gave have examples
<unmatched-paren>peonerovv: if you want i can help you with making a package
<jpoiret>PotentialUser-95: you want the updated xkeyboard-config to be used by the whole system? if so, the only way would be to modify guix source itself to update it
<peonerovv>yes, that would be appreciated, Im very confused
<jpoiret>note although that that package has many dependents, and a patch to upgrade it would go through a core-updates cycle (ie a merge into master every ~6 months)
<unmatched-paren>peonerovv: ok, you'll want to create a `.scm` file for your patched dwm. what are the changes that have been made compared to vanilla dwm?
<PotentialUser-95>its following this, basically i want to have access to xkb in order to feed it a custom file, but it since it doesn't look for files in /etc/
<unmatched-paren>peonerovv: in that file you should have something like:
<PotentialUser-95>any easier alternative is welcome (that doesn't imply fiddling with session)
<peonerovv>unmatched-paren: this is the link to this particular config (it's not mine)
<unmatched-paren>then below the use-modules you can write your package:
<unmatched-paren>peonerovv: thanks.
<unmatched-paren>peonerovv: now you'll probably need to import (gnu packages suckless), which defines the dwm package
<unmatched-paren>in the use-modules form
<unmatched-paren>(define my-dwm (package (inherit dwm)))
<unmatched-paren>my-dwm is now bound to a new package that is exactly the same as dwm
<unmatched-paren>and you can just fill out the fields to override them:
<unmatched-paren>(package (inherit dwm) (name "my-dwm"))
<unmatched-paren>a field is just a (key value) pair
<unmatched-paren>at least, for `record-type*`s like package
<unmatched-paren>and the home-page too: (home-page "")
<jpoiret>PotentialUser-95: seems kinda hard
<unmatched-paren>now, you'll need to hash that git repo, since guix requires a sha256 checksum to check that the download hasn't been modified/tampered with
<unmatched-paren>clone the repo, cd to it, and run `guix hash -rx .`
<jpoiret>xkeyboard-config would need a patch i think
<Aurora_v_kosmose>maximed: That's not the part I was particularly worried about. The "automate 'update trains'" part is what I understood as a suggestion to use that to automate updating packages too.
<unmatched-paren>this will spit out a sha256 hash
<unmatched-paren>peonerovv: you following me? have i explained everything well enough?
<peonerovv>i am following slowly, just not keeping up with you
<unmatched-paren>peonerovv: sorry, i'll slow down :)
<unmatched-paren>tell me when you're done with what i've already said and i'll continue
<peonerovv>ill report when im done or if i have any questions. thanks!
<unmatched-paren>oh, yeah, i *think* you may need to override (version) too: (version (package-version dwm)) for a reason i'll explain later when i show you how to reconfigure the package's source
<nckx>Aurora_v_kosmose: I don't read it that way, ‘update trains’ is explained in parenthesis. You might be reading your worries into it.
<nckx>Machine-prepared patches can be reviewed as much as human- ones.
<PotentialUser-95>jpoiret what do you mean patch ?
<peonerovv>unmatched-paren: the my-dwm.scm file you provided doesnt have the same parts as the examples you gave me, where and how am i supposed to import (gnu packages suckless)?
<jpoiret>well, it's possible you'd have to modify xkeyboard-config's source
<jpoiret>to be able to have layouts defined in multiple directories, one of which could be /run/current-system/lib/whatever/
<unmatched-paren>peonerovv: just in that (use-modules) form: (use-modules ... (gnu packages suckless)
<Aurora_v_kosmose>nckx: Ah, I see.
<unmatched-paren>(use-modules ... (gnu packages suckless))
<Aurora_v_kosmose>nckx: That's certainly possible.
<unmatched-paren>replace ... with what you already have of course
<unmatched-paren>peonerovv: remember, use-modules is just guile's import statement
<peonerovv>but in the examples you gave me they use define-modules and not use-modules
<nckx>Not to import modules. To define the name of the current one.
<unmatched-paren>peonerovv: ah, that's because they're in a channel, so they need to be in modules. you're just making a standalone file, so there's no need to define a NEW module, you only need to import othrs
<unmatched-paren>(define-module)'s #:use-modules MODULE is basically syntatic sugar for using define-module and then use-modules
<nckx>Aurora_v_kosmose: I agree that review is important. I don't think automation threatens that though, an optimistic view could even be that it makes review more likely since the insane bottleneck pressure we currently put on human reviewers is reduced.
<nckx>A bit rosy, but not illogical :)
<peonerovv> so it should be (use modules \n   (guix packages suckless))?
<unmatched-paren>peonerovv: (use-modules \n (guix packages) \n (gnu packages suckless))
<unmatched-paren>(gnu ...) stores the guix builtin packages, services, etc
<unmatched-paren>whereas (guix ...) contains guix itself, i.e. the internals of the actual package manager
<unmatched-paren>and its APIs
<unmatched-paren>like (guix packages), which provides stuff for defining packages
<unmatched-paren>(gnu packages ...) provides the actual definitions of various packages, like suckless.scm's dwm package
<peonerovv>i have never programmed in lisp or guile so this is very confusing to me
<peonerovv>but ill do what you say
<unmatched-paren>peonerovv: imagine some imaginary C-like language with a module system. this (use-modules) is basically equivalent to -- in our imaginary language -- something like `import gnu.packages.suckless.*, guix.packages.*`
<peonerovv>ok, i think i understand
<peonerovv>now after that i put in "(define my-dwm (package (inherit dwm)))"?
<Aurora_v_kosmose>nckx: I see.
<unmatched-paren>peonerovv: yeah!
<unmatched-paren>that my-dwm is now bound to a package that is functionally equivalent to the original dwm
<unmatched-paren>and you can gradually override its fields
<unmatched-paren>to create a slightly modified version of the original dwm
<peonerovv> so now what?
<unmatched-paren>peonerovv: you'll want to add (name "my-dwm"), (version (package-version dwm)), and (home-page "URL-OF-NEW-DWM-CONFIG") to the package object
<jeandudey>hi! I'm trying to package PySDL2 for Guix, but it requires that the library is available on LD_LIBRARY_PATH to search it (using Python 3 ctypes.find_library), any ideas on how to make PySDL2 find the library path?
<unmatched-paren>and then do that hashing thing i told you about, and keep the hash somewhere
<unmatched-paren>now you need to override the source, to download the dwm code from that repo instead of the suckless repo
<unmatched-paren>(source (origin ...))
<unmatched-paren>(origin) is another record
<unmatched-paren>now add (guix git-download) to your use-modules to import things that let you fetch git repos
<unmatched-paren>inside origin:
<unmatched-paren>(method git-fetch)
<unmatched-paren>(uri (git-reference))
<unmatched-paren>(file-name (git-file-name name version))
<unmatched-paren>(sha256 (base32 "THAT HASH YOU MADE"))
<unmatched-paren>git-reference is yet another record, and you need to fill it to tell guix which commit to use, etc
<unmatched-paren>so, figure out which commit is the latest on `master` of that repo
<peonerovv>what am i supposed to put into "URL-OF-NEW-DWM-CONFIG"
<unmatched-paren>peonerovv: that link
<unmatched-paren>oh, yeah, silly unmatched-paren...
<unmatched-paren>since you're using a git commit instead of a version, you need to replace (package ...) with (let ((commit "COMMIT AT HEAD") (revision "0")) (package ...))
<avp_>Hello Guixers! I'm trying to package this
<unmatched-paren>(let ((NAME VAL) ...) EXPR) binds the symbol NAME to VAL inside EXPR
<unmatched-paren>it's like a temporary define
<unmatched-paren>outside the (let) form, you won't be able to access the NAME variable
<unmatched-paren>as the ... shows you can bind multiple values inside a let
<unmatched-paren>and then you need to replace (version (package-version dwm)) with (version (git-version (package-version dwm) revision commit))
<avp_>When Guix tries to download remserial from the official site by URL "" it gets 405 "Method Not Allowed", but when I try to use wget or a regular web brower, downloading works fine.
<unmatched-paren>back to git-reference. you can now do (commit commit) and (url "THAT CODEBERG URL") in (git-reference ...)
<unmatched-paren>and hopefully, the package is now complete! you then need to make the file return the package object by putting `my-dwm` on its own at the bottom
<unmatched-paren>and you can run `guix shell -f my-dwm.scm` and try running `dwm`!
<unmatched-paren>hopefully this will work, if not tell me :)
<nckx>avp_: I can't reproduce that with ‘guix download’. Ugly work-around: using <>?
<avp_>nckx: Thanks, I checked 'guix download' myself and I see that it dowloads the archive indeed. That's strange. Could it be that a regular 'guix build' uses differend request parameters?
<avalenn>Is it possible to use plain-file and to set executable permission bit on resulting file ?
<nckx>avp_: It must! Strange indeed.
<nckx>Guess I'll point both at my server & see what differs, if anything.
<peonerovv>unmatched-paren: on another thought, i think it would be better to do it with stock dwm, since this one is on an old version is unlikely to be supported.
<unmatched-paren>peonerovv: you mean to apply that repo's patches/modifications?
<unmatched-paren>instead of just cloning it?
<peonerovv>yes, but i can do it myself. you said that this the "guix way" and im kind of interested in finishing it. i just think that it might be better with regular dwm. And just one thing to clarify - I would be able to modify the source code, right? Since this is the way dwm is configured
<unmatched-paren>peonerovv: yes, you would
*unmatched-paren afk
<nckx>avp_: Sorry, can't reproduce it with url-fetch either:
<nckx>When built, it downloads a file with the right hash, same as ‘guix download’.
<avp_>Well, I'm using Tor proxy with Guix -- maybe this is the source of my problems.
<nckx>That sounds plausible.
<maximed>jeandudey; it doesn't actually need LD_LIBRARY_PATH (LD_LIBRARY_PATH leads to fragilities, so we try to avoid it)
<maximed>Usually, we can avoid it by modifying the call to Python's equivalent of dlopen("") to dlopen("/gnu/store/.../"), by using substitute* + search-input-file in a phase.
<maximed>I don't know what the Python equivalent of 'dlopen' is though.
<peonerovv>unmatched-paren: so in that case, what are the changes I should make to that file?
<avp_>nckx: Does 'guix download' uses the same proxy settings as the 'guix build'?
<nckx>‘guix build’ doesn't download anything itself, it just fires off a build job to the daemon.
<nckx>If you're setting your proxy settings (=variable?) only in your shell, that won't work.
<nckx>For example.
<maximed>jeandudey: Maybe have a look at the definition of 'python-screenkey'?
<nckx>See the penultimate paragraph of <> avp_.
<maximed>(Lots of activity on #guix today!)
<nckx>(…or grep for ‘proxy’ :)
*nckx nods.
<maximed>sneek: what is LD_LIBRARY_PATH?
<vagrantc>ugh. i never manage to figure out how to modify-phases when a package inherits from another ... halp?
<nckx>avp_: Don't bother following either link though.
<maximed>sneek: LD_LIBRARY_PATH is fragile and can be avoided by using search-input-file, substitute* and an extra phase, see the package definition of 'python-cairocffi' for an example.
<sneek>Got it.
<maximed>sneek: what is LD_LIBRARY_PATH?
<sneek>I could be wrong, but LD_LIBRARY_PATH is fragile and can be avoided by using search-input-file, substitute* and an extra phase, see the package definition of 'python-cairocffi' for an example.
<maximed>sneek: botsnack
<jeandudey>maximed: thanks, I've got it working by adding a `setenv` just before the 'check phase to ensure that the module loads correctly
<nckx>vagrantc: You're starting from %standard-phases, not the phases of the inherited package. You need to capture those, then modify-phases those. I'll seek an example…
<vagrantc>nckx: thanks!
<maximed>jeandudey: That's not sufficient -- it is sufficient for making the 'check' phase pass, but the resulting pysdl2 will be broken.
<maximed>Because when it will be used in a dependency, LD_LIBRARY_PATH isn't set anymore.
<vagrantc>nckx: maybe ,phases ?
<nckx>…or grep for 'modify-phases ,phases' yourself vagrantc. See zile-on-guile for a sane example.
<nckx>vagrantc: ?
<maximed>vagrantc: I think a ) is missing afet ,flags)
<nckx>That won't do anything on its own, you need to ‘capture’ a variable in the (#:phases HERE) too. It can be called whatever; but yes, phases is common.
<nckx>vagrantc: ☝ re ,phases
<jeandudey>maximed: you're right, I guess I could just remove the search routine on the library directly and replace it with the input file. The 'check phase passes but, yeah fails when trying to use it
<maximed>(Shouldn't there be a #~ (or `) before (modify-phases ?
*unmatched-paren back
<unmatched-paren>peonerovv: you'd need to either add extra build phases or use a patch
<nckx>maximed: Yes.
<unmatched-paren>but for now, try this, and see whether it works :)
<peonerovv> with the codeberg link you mean?
<nckx>vagrantc: In this case `(modify-phases …), not #~, because it depends on whether the inherited package (vtk here) uses gexps or not. That's unfortunate.
<unmatched-paren>peonerovv: ?
<nckx>Eventually gexps will take over the world, I'm told, so it's temporary…
<unmatched-paren>you'd basically just have to override (arguments)'s #:phases
<vagrantc>nckx: i'll believe you :)
<unmatched-paren>with a modified version
<unmatched-paren>that applies the correct modifications
<nckx>vagrantc: More people should.
<unmatched-paren>OR use (origin)'s (patches) thing
<nckx>I bring important tidings.
*vagrantc will be sure to add this information in a comment verbatim
<peonerovv>so do i still have to do this source override thing? since im going to use stock dwm
<vagrantc>i didn't think it was allowed to use stock dwm on principle :)
<singpolyma>I mean, there is no "stock" it doesn't compile until you make a config.h somehow ;)
<unmatched-paren>peonerovv: depends on whether you use (patches) or not. personally i would just do the phases thing, it's easier than generating a patch with diff
<unmatched-paren>unless the changes are large enough to warrant a patch
<maximed>nckx,vagrantc: FWIW, you can use #~(modify-phases ...) in the inheriting package even if the inherited package uses `
<singpolyma>Snippet also an option yeah?
<peonerovv>maybe? sometimes they clash with each other or are for an older version and you have to patch them manually
<unmatched-paren>singpolyma: oh, yeah, that too.
<maximed>the problem is using `(...) in the inheriting package if the inherited package uses #~.
<nckx>I broke master that way.
<singpolyma>#~ just looks like noise every time someone brings it up. Someday I'll find a package actually using it and break my brain
<maximed>(i.e., the other way around than nckx wrote?)
<peonerovv>but i can deal with patches later. can we make this file compile just stock dwm for now?
<nckx>you're right, I swapped them.
<unmatched-paren>peonerovv: sure. just remove the (source ...) replacement.
<unmatched-paren>or use (source (package-origin dwm)) i guess
<nckx>vagrantc: I am fallible after all, good bye.
<maximed>singpolyma: Have a look at the configure-flags of 'bamm'
<nckx>singpolyma: It's quite common already and only getting commoner.
<maximed>or qtltools or bless
<unmatched-paren>peonerovv: probably also remove the home-page replacement
<maximed>FWIW I recommend just always writing #~(...) in #:phases instead of quasiquote
<maximed>singpolyma: How is it noise?
<singpolyma>maximed: just another string of symbols to know about
<vagrantc>maximed: thanks, i'll be sure to pick the appropriate line noise :)
<peonerovv>do i keep the git-download git-stuff in the file as well? you wrote that it should be in the (origin), but now that its deleted...
<unmatched-paren>peonerovv: oh, yes, good point
<maximed>OTOH you don't have to remember how the quasiquote/unquote noise works in #:configure-flags & #:phases
<unmatched-paren>remove the (let ... (package ...)) and replace with just (package ...)
<unmatched-paren>and remove (version ...)
<unmatched-paren>also, you don't need the (guix git-download) import anymore
<unmatched-paren>this should hopefully just build stock dwm
<maximed>vagrantc: Another recommendation: don't do (arguments `(#:tests? ... #:phases ...)), but do (arguments (list #:tests? ... #:phases #~(...) ...))
<vagrantc>maximed: yeah, that is a bit more readable in general ...
<maximed>According to htgoebel, civodul and me, it looks a little nicer.
<vagrantc>though when updating packages, i try not to change conventions i don't understand :)
<maximed>And htgoebel says (or implied or something, I don't remember the details) that the ` and , is complicated and might best be avoided
<maximed>which seems pluasible to me
<maximed>Maybe "guix style" could be taught to perform quasiquote/quote -> list in 'arguments' (and basic G-expification of #:phases for consistency?)
<peonerovv>unmatched-paren: i accidently closed the chat and now I cant see what you wrote before. this is hard to follow, since im not really sure what exactly you are talking about. im sorry if im asking to much, but can you write this file and maybe add comments where they are needed and then put the link here? like you did before
<unmatched-paren>peonerovv: sure!
<peonerovv>thank you!
<maximed>peonerovv: a copy of all the discussion is available at
<peonerovv>thank you too
<unmatched-paren>peonerovv: contains a dwm package inheriting stock dwm with no changes
<unmatched-paren>peonerovv: this is how you might modify the source code
<unmatched-paren>peonerovv: for example:
<unmatched-paren>you'd need to use substitute* on the default config.h file
<unmatched-paren>to modify it to your liking
<peonerovv>i think it might be easier to just modify the file itself
<unmatched-paren>peonerovv: with a .patch file?
<unmatched-paren>also, small mistake: (package-origin dwm) should be (package-source dwm) i think
<peonerovv>no, myself. config.h contains keybindings and such
<peonerovv>.patch files are usually making changes to dwm.c
<unmatched-paren>peonerovv: as in, replacing its contents entirely with your version?
<unmatched-paren>you would probably use a patch file for that.
*unmatched-paren afk
<peonerovv>no, just making so that terminal opens with super+return and not super+shift+return for example
<peonerovv>i wouldn't need a .patch file for that
<sneek>Welcome back maximed :D
<nckx>Yes to list, no to #true (of which you seem a fan :)
***mark_ is now known as mjw
<peonerovv>So something happened, but I'm not sure if I can run dwm, I'll have to deal with some other stuff that doesn't work. Thanks for help anyway!
<peonerovv>I'll go now
<maximed>unmatched-paren: because there's only a single thing inside the 'begin', it doesn't need to be wrapped in 'begin'.
<unmatched-paren>maximed: i know, but it makes it easier to add more if necessary
<reyman>I'm searching exemple of filesystem mounting of smb:// in guix home, someone already try this ?
<lilyp>does anyone know why openssl checks fail on c-u?
<davidl>Im defining a package and wondering is there any way to use PCRE in guix substitute* function - if not, are there any suggested/typical workarounds? I need to use a negative lookbehind.
<lilyp>you can invoke sed or emacs, but then you need to add them as native inputs
<lilyp>I think at this point it's probably wiser to use patch files
<lilyp>they get the point across easier too
<vldn>mhh my guix system doesn't use ~/.guix-profile for guix pull but instead .config/guix/current
<unmatched-paren>vldn: this is expected behaviour
<vldn>alright :)
<unmatched-paren>vldn: ~/.config/guix/current is populated when you `guix pull`, ~/.guix-profile is populated when you do pretty much anything else :) the seperation is intended, and why you shouldn't install the `guix` package
<vldn>thanks for the clarification! :)
<vagrantc>well, vtk-7 has demonstrated my complete lack of understanding of guile.
<vagrantc>i just want to change one line in the source, but i'm lost
<jackhill>vagrantc: what change would you like to make?
<vagrantc>jackhill: i'm lost between ' ` #~(modify-phases ...
<vagrantc>jackhill: i've done this sort of thing on many packages, but i don't get how to do this when it is inherited from another package
<vagrantc>jackhill: it's obviously wrong ... trying to figure out how to not use %standard-phases ... ((#:phases phases) (modify-phases ,phases ... seems to be a common enough pattern
<jackhill>vagrantc: oh, quoting, what fun! This might be beyond my expertese as well, but I recently played with it for nginx-rtmp-module full package:
<vagrantc>jackhill: apparenlty the inherited from package uses (arguments '(#:a #:b #:c ... which affects how it needs to be modified in the inherited package
<jackhill>I think my current advice is to try to stick to just using gexps for now, and everything will be a little clearer (at least to me)
<vagrantc>i don't know what gexps are :)
<vagrantc>or what they're replacing
<davidl>lilyp: thx for the tip reg sed & emacs. I believe patch files won't be suitable, because the code base is like 10k+ lines of bash.
<vagrantc>jackhill: well, i'm not sure what exactly, but cargo-culting your nginx-* package seemed to help
<jackhill>ah, um, well, hopefully lightning from heaven won't strike me down, but it's a way of saying some code should run in the build environment, as opposed to when the package definition is being evaluated. Scheme already has two "levels" for running code: 1) expansion/compilation time 2) regular run time. I think gexps are an extention of that. I probably don't understand it quite well enough to teach,
<jackhill>glad it helped, sort of
<jackhill>there was a lot of staring at the computer to get that one to work.
<jackhill>anyway, the `((#:phases phases` part is just binding the name phases to the value of the original keyword-argument list. It could be foo, and then line would be `modify-phases foo` (modulo quoting)
<vagrantc>that part i got ... although calling it #$phases was elusive to me till just copying your example
<vagrantc>many examples use ,phases
<jackhill>ah, that's because it I was using the gexp-syle of quoting. I didn't need it there, but for something else deeper in the phases, so I needed to use the gexp unquote there.
<vagrantc>it's all greek, er, guile to me
<vagrantc>i can get by modifying many package definitions, but then hit something like this and realize... well... i don't know what i'm doing :)
<vagrantc>so are #~ the magic runes to make something a gexp ... rather than ... a ... something else?
<vagrantc>gotta say, i'd prefer a gexp be called something like, say, "gexp" :)
<jackhill>vagrantc: yes. #~(whatever is equivilent to (gexp whatever, just like '(something-else is equivalent to (quote something-else
<jackhill>there's also ungexp
<jackhill>for #$
<jackhill>I always get confused by the difference between '(foo and (list foo
<vagrantc>magic symbols are a bit rough for me to grasp ... i guess the code is moving away from `( and '( to ... (list ?
<jackhill>I think all those are subtly different, maybe. Like '( won't do any evaluation in the whole thing, but (list (foo a b) c) will try to apply the foo procedure to a and be (except if it's in some sort of macro in an operating system definition or whatever that precludes the application. No wonder it's confusing!
<vagrantc>subtleties are so next-level.
<jackhill>anyways, I have to run. Good luck! Maybe someone with more guile will come along
<vagrantc>thanks for your help!
<vagrantc>i think i need the right level of guile, i think there were some very guile advice floating around earlier, but i was still underwater trying to peer through the murky, turbulent, distorted waters see what was so plainly obvious floating at the surface
<vagrantc>"oh, i get it!" ... only to find ./pre-inst-env guix build ... still explodes just as badly as ever :)
<vagrantc>/gnu/store/i6yya67fr5rz8njpsbh1sqwhga55bacx-vtk-7.1.1 ... yay... now to see if the fix works!
<vagrantc>and the answer is ... no!
<civodul>jackhill, vagrantc: speaking of which, i've been thinking of having a variant of to the manual
<nckx>avp_: Thanks for the patch! Does that mean you figured out the proxy problem?
<nckx>civodul: The Guix or Guile manual?
<vagrantc>civodul: anonymous functions are those things that make you type lambda all the time?
<nckx>(Was that a serious question?)
<vagrantc>civodul: i think i read that back in that day, and it got me through apparently enough to trick y'all :)
<nckx>They aren't a different kind of function/procedure, just procedures that you never bothered to bind to a variable. All procedures are ‘lambdas’. (define (foo) …) is syntactic sugar for (define foo (lambda …)). But the name foo is optional, sometimes you don't bother to give a procedure a name, like you wouldn't write (define a 5) (define b 2) (+ a b) either.
<nckx>Sorry if that's too basic. I was shocked to hear you were just bluffing so far :)
<nckx>You're pretty good at it.
<vagrantc>that's actually helpful, sure!
<vagrantc>yay, success!