IRC channel logs
2023-09-22.log
back to list of logs
<nckx>And there's probably some obvious deal-breaker I missed, but it was fun to write horrible regexp code. <somenickname>euouae: No, I just wanted to know if someone can approve that it works or requires additional stuff. Guess I need to enable debug and do some testing for something that should work out of the box but not for me... <somenickname>Also, what should be the intended behavior of booting from NVIDIA GPU but without nouveau on. Probably low resolution but I should see output? <nckx>I expect it to get (not unjustifiably) murdered in review, but maybe someone has a better idea. <euouae>I don't understand though, you seem to be editing version.texi <nckx>Or there's a better way to READ without making any assumptions about future read syntax. <euouae>but are all version strings from that file? because my man pages work fine, it's only the info manual that misses the version strings <nckx>Did you read the whole patch. <euouae>I read it all, I'm just not understanding it very well <euouae>It looks to me like you're regexing the version string from package-management.scm into version.texi <nckx>People still use man pages? Wild. <ulfvonbelow>well they sure beat "visit the online documentation" <euouae>right, but why are they okay? and is your patch syncing the two versions correctly? or will info manual show different version string to man pages? <euouae>err nvermind, I'm asking, why do the man pages work? <nckx>Hmm, I wonder why we're not squeamish about rebuilding those, while explicitly not wanting to rebuild the info manual. Is it that much more expensive? <euouae>Ah because those get rebuilt? got it <nckx>euouae: Because the current code deliberately doesn't want to rebuild the info pages for each commit, indeed. <euouae>nckx, can't the package force the output of info pages to be built locally? <nckx>euouae: <is your patch syncing the two versions> [deliberately dropping âcorrectlyâ] In a way. It replaces 0.0-git with 1.4.0,, but not 1.4.0-10.4dfdd82. <nckx>euouae: I'd say straining people's computers is far worse than straining the build server. <nckx>Anyway, I guess I have to research why we're yeeting out fresh man pages for every single guix pull, and if those are really that much cheaper. (Info *is* expensive, that's not in question.) <euouae>man pages are superior, face the truth <euouae>ACTION is kidding, they likes info better <euouae>Good job on that patch, that is certainly nothing I would be able to dish out <pinoaffe>hi folks, is there a way to actually do `guix package -m "(@ (whatever module) manifest)"`? <nckx>OK, so the man pages are not built by âguix pullâ (guix self) at all. <pinoaffe>aka, to specify a manifest on the command line using a guile expression rather than a path to a file <nckx>The â1.4.0-10.4dfdd82â in my âguix-buildâ man page is pretty, sure, but my pulled Guix is actually newer. <pinoaffe>also, for whatever reason specifications->manifest is *extremely* slow when I add stuff to the load path, does anyone know why? <euouae>pinoaffe: echo "(@ (whatever module) manifest)" | guix package -m - <nckx>pinoaffe: It might fail because you can't seek, but there's always guix package --manifest=<(echo 'hello i am become manifest') <nckx>Ah, basically what euouae wrote in the meantime, with extra shellsanity. <pinoaffe>nckx: ah yes, the sad part is that y shell of choice doesn't do input redirection <nckx>(There is no magic special handling of the â-â token, that's why it won't work.) <nckx>(Not because it can't handle stdin.) <nckx>pinoaffe: Can't you use -m /dev/stdin then? <pinoaffe>also I like that - isn't treated differently, since it is a valid filename <jaeme>Rust packaging is pain. But `guix import crate <name>` helps so much. <jaeme>Is rust packaging supposed to be very tedious? <nckx>From the Guix side, the antioxidant-build-system should reduce the pain a bit. From the Rust side, I dunno how interested they are in improving packaging outside their walled garden. <chipb>jaeme: I'd guess they mean anything existing outside the scope of cargo as The One True Rust Build Tool. <jaeme>I'm trying to package a wallpaper daemon called 'swww' for wayland compositors and it has led me to writing like 30+ crate definitions <bjc>if it's only 30, you're getting away easy <bjc>last time i dabbled in rust, i got over 200 deep before i gave up <jaeme>But a lot of them are just older definitions of upstream crates so far <jaeme>except for stuff like the CUDA rust libraries <drewjose>Packaged github.com/casey/just and I only had to add 10 :) <apteryx>curious; has anyone else changed from dvorak to something else like colemak or even QFMLWY? <apteryx>and if you did, did it improve things (comfort, efficiency or otherwise?) <lilyp>drewjose: just 10 dependencies for a barebones make! <adanska>just seeing if theres anyone working on porting auto-cpufreq to guix? otherwise i'll give it a shot, doesnt look too complex <fnat>Now, not that the email is particularly important to be honest, but who should I reach out to to have a quick look? <janneke>fnat: if it is your first mail to a guix list it, will await human moderation <fnat>I see, thanks janneke. It's not my first email, but it might have been flagged for human moderation anyway (misteriously, it was flagged as spam on my end). I'll wait a few days and see. Thanks! <janneke>ACTION won't be able to look, but others here will <fnat>janneke: [PATCH] home: msmtp's password field to accept strings and G-expressions. <adanska>going to try writing a package and service for auto-cpufreq. `tlp`'s decl. is in linux.scm, would it be a good idea to put `auto-cpufreq` there too? <adanska>also, when it comes to sending my patches, should i have seperate ones for the package and for the service? <jpoiret>if it's entirely linux-specific, then yes <minima>when creating a system image, is there a way to copy files over to a given path within the image? context: i'd like to inject a specific set of SSH server keys into the image, in /etc/ssh <minima>i suppose this should be done "via the store", i.e. having the keys as artefacts in the store <jpoiret>yes, you should extend the etc-service-type <jpoiret>maybe there's already a service specific to ssh though <minima>brilliant, thanks jpoiret i'll look at etc-service-type <jpoiret>note that the keys will end up in your store though, which is world-readable <minima>i wasn't able to find anything very specific to ssh, but i don't know, maybe i missed it - anyway etc-service-type sounds like a good unmatched-paren <minima>sorry, a good match - darn completion :) <minima>jpoiret: ... hm ... that's a good point ... what's the threat model, whoever has access to my system, the one where the image gets created, correct? <minima>i think it's fine in my context but that's a great point <minima>also, just to avoid the xy problem scenario, the broader context and objective would be to create an image that i can SSH into knowing what the SSH fingerprint will be <minima>in other words, i thought of dictating what the SSH key is (or what the keys are) so that when i connect to the image (or machine should i say) i know what SSH fingerprint to expect <minima>the only way that came to mind was to create the keys separately and manually with ssh-keygen and have them added to /etc/ssh <parnikkapore>Hi Guix! I'm running a Cuirass instance to build and serve substitutes for my own channel. I'd like to pin the packages in the latest evaluations so that they won't be deleted by guix gc, even after >30 days. What's the best way to do this? <janneke>sneek: later tell parnikkapore: if it's about 30days, you could postpone deletion to two months by running guix gc -d 2m, for example <parnikkapore_xm>janneke: (had to switch devices) afaik cuirass evaluations aren't affected by -d, unlike profiles and pulls? <janneke>if it's not about a time period, see the --root option to many comands, like guix build <parnikkapore_xm>my current idea is to gather the derivations in those specifications and pass them to `guix build --root`, but I want to ask first, in case there's an easier way <parnikkapore_xm>ACTION needs to check if cuirass registers profiles for the evaluations; if it does, then only changing the cleanup script is needed <adanska>ok, so i've run into the first roadblock. auto-cpufreq depends on the `power` module on pypi which essentially provides a cross-platform method of obtaining power info on your system. my issue is precisely that: it's cross platform, and depends on an objectivec interop library. since guix is really exclusively linux (not including hurd), is it ok if i patch out everything except linux support? how do you guys typically deal with these <adanska>ok, upon a further look, it doesnt seem like there will be any issues if i just dont package the macos stuff. <adanska>just to confirm: it's ok for me to write packages that dont work cross platform? even if they advertise as such? <nckx>sneek: later tell adanska Absolutely. We also remove 'cross-platform' from descriptions more often than not as low-value noise. <nckx>apteryx: No, but after a few years of Colemak I switched to Dvorak for ergonomic reasons. I got sold on Colemak's 'easy transition' from Qwerty and regret it now. <janneke>ACTION does prefer maltron, but that needs a custom keyboard that doesn't really make for great traveling <nckx>I have yet to try that... <bjc>i've never understood the "easy transition" thing. it sounds like something that would only make sense to someone who's never changed layouts before <bjc>ie: none of them are easy unless they're also, simultaneously, basically pointless <efraim>I'm feeling stumped on this error and I'm not really sure what's happened here <efraim>/gnu/store/7vgsy4gmwpmpgvh33g6yr5cjys9jpd0b-vg-1.50.0/bin/vg: error: depends on 'lib/libvg.so', which cannot be found in RUNPATH ("/gnu/store/7vgsy4gmwpmpgvh33g6yr5cjys9jpd0b-vg-1.50.0/lib" <bjc>likewise, the "cut/copy/paste" keys are in the same place is such a weird selling point <efraim>for some reason the library seems to be named 'lib/libvg.so' <janneke>looks to me like a bug in the build system <efraim>it's a hand written makefile, so lots of fun :/ <efraim>I'll try changing the line that creates the binary to use lib/libvg.so instead of $(LIB_DIR)/libvg.$(SHARED_SUFFIX) and see if that gets me anywhere <janneke>surely you mean something like: -L lib -lvg? <janneke>(or possibly $(LIBDIR) -l vg, depending) <efraim>janneke: thanks, I think my brain is fried <janneke>it's the linker's repsonsibility to choose the extension <efraim>sounds good to me. I've already removed the options for building the static library <radio>When using define-configuration to serialize something, no predicate to test if something is a valid configuration is produced? <radio>I'm writting a simple configuration for fish abbreviations, since the current alist structure is limitating about which kind of abbreviations you can declare within guix (actually you can just put the flags in the key string of each association, but it's ugly) <radio>And I used define-configuration to do so <radio>But then now I need to write a predicate to test if something is a list of abbreviations, and I have no predicate to test if something is an abbreviation <radio>I wouldn't like to rewrite it as a record because configurations have types and documentation strings <civodul>to be fair, itâs called Smart Hurdloadingâ˘, but the patches themselves arenât so smart <zimoun>Aside the good marketing, the cover letter is appealing! :-) <civodul>i spent like 10x more time than i expected on this damn patch series <dthompson>I am so behind on hurd stuff that I don't know what this means :) <civodul>thatâs the point of marketing, especially when thereâs âsmartâ in the name: that one cannot guess what this is about! <ulfvonbelow>I wish we had a (catch* thunk cont handler) that was like (call-with-values thunk cont) except that handler is active during thunk <lechner>Hurd is a hard name to market since it sounds so much like "hurt" <ulfvonbelow>it can be implemented manually, but it causes an argument list to be consed <lechner>also, "onboarding" would sound better than offloading, although I realize it makes little sense <lechner>maybe one day someone will rename user-space microservices to "coins", so Hoard can make sense <lechner>but then i am not sure that hollow marketing is compatible with the free software movement <lechner>or maybe that's exactly what we need <ulfvonbelow>man, remember when bunding a browser with an OS was crazy monopolistic behavior/ <lechner>also, instead of childhurd, which sounds a lot like childhood, i would use "baby hurd" <lechner>Hi, by which logic does the Guix daemon prevent kernels and initrds from being garbage collected, please? is it the mention of either in "/parameters" is the system profiles? <mirai>def will have to check it out <mirai>lechner: âweâ may shit on Windows as much as we want but IMO we shouldn't completely dismiss it. There are things that Windows has an advantage and it would be profitable to learn from those parts <mirai>nckx: ackschully, âgratisâ <mirai>Are C-U build failure logs of interest to anyone? <zamfofex>mirai: I feel like regarding proprietary software, although itâs wrong for being proprietary, itâs not like it doesnât have any value or anything that can be taken from it. Ideally it wouldnât be proprietary, but that doesnât mean everything that it does is wrong and should be disregarded. (Though, of course, I wouldnât endorse it as a whole either in any way.) <zamfofex>As in, of course being ethical is more important than most other aspects, but that doesnât mean other aspects (like technical merit, aesthetics, etc.) donât exist, and so certain things can be learned from some proprietary software. <janneke>civodul: reconfiguring to test smart hurdloading! <lechner>Hi, I switched to Guix in April of last year, and just want to say thank you to all contributors. After losing hope in another Linux distro, Guix provided a great technical perspective of what could be. Plus, I like Scheme and no longer use shell scripts or Perl. I think we are the forefront of free software development <nckx>And actually, let me second that. Thank you all. You are disturbingly competent for a bunch of weirdoes on the Internet. <janneke>ACTION has been using guix system for 7y4 or so and is also very grateful for all you lot! <Gooberpatrol66>so is the purpose of that Smart Hurdloading^TM patch to build packages natively in vms to obviate explicit cross-compilation support? <nckx>Sigh. Recent(?) K-9 versions default to 'Reply' over 'Reply all'. Enjoy the duplicate mail, civodul. <janneke>we've been already doing that, but (short summary) it was still pretty hard to setup, there were bugs, there were problems running childhurds on the buildfarm <nckx>civodul: I had my goofy fun, which was the point, but '@set GUIX-RELEASE 1.4.0' is probably the simplest way forward. <ulfvonbelow>civodul: random catch scrolling through the patches, s/offlading/offloading/ <stocastico>hello guixers! does anyone have any exeperience with guix on the pinebook pro? I'm having problems booting the system, not really sure why :( . I rightly get from towboot to uboot but after uboot loads the kernel the screen goes black forever. here is both the configs i tried http://paste.debian.net/1292822/ and here the flashing script http://paste.debian.net/1292811/ i run from an armbian installed on the emmc <elevenkb>Hey there how does one get the dependency graph of a guix home profile? <elevenkb>I mean the package dependency graph, not the service dependency graph. <janneke>guix refresh --list-dependent psautohint makes it seem real harmless, but that can't be true <civodul>elevenkb: hi! you can approximate it with âguix graph -t references $(readlink -f ~/.guix-home) > whatever.dotâ <janneke>font-abattis-cantarell depends on it and isn't listed? <lechner>Hi, what does "lowering" an item mean in the context of the Guix store, please? <ulfvonbelow>for some items it means producing a derivation, for others it means producing a store item <ulfvonbelow>e.g. a <computed-file>, <package>, <bag>, etc will result in a derivation, while a <plain-file> will result in a store item filename string. <ulfvonbelow>at least, that's what my experiments with (guix monad-repl) tell me <lechner>okay, thanks! I am just checking my own understanding. <ulfvonbelow>the lowest-level representation of a "build unit" we have. Usually it refers to a regular file plain text store item of a certain format with a filename ending in ".drv", though it can also refer to the in-memory representation in guile, a <derivation> object <lechner>okay, and how are derivations used in Guix, please? What is their purpose? <ulfvonbelow>a derivation includes the complete list of input derivations and the output names from each of those that are used, a list of its own output names, a builder, sources (non-derivation inputs), environment variables (some of which are treated specially and interpreted by the daemon), the host system name, and other stuff <ulfvonbelow>some derivations (like ones that download source code) are "fixed-output", and are consequently allowed access to the network because all non-reproducibility can be detected due to the included content hash <ulfvonbelow>basically, a derivation is a file that sits in the store, and it's also a node in the directed acyclic graph of derivations that describes how to produce certain outputs <nckx>Their high-level âpurposeâ is to serve as the object you ask the build daemon to build, because it has absolutely no concept of âpackagesâ, âgit checkoutsâ, âfile-like objectsâ, and any of that silly abstract nonsense. <nckx>That's why Guix can use the Nix daemon despite the two projects not having *that* much in common TBH. <zamfofex>nckx: I wonder how sensible it would would be to just have a Guixy approach that doesnât use the Nix daemon (or a fork thereof). Something that just directly build Guix objects like packages and operating system records in an environment without needing to go through derivations. <ulfvonbelow>if you're okay with losing the ability to allow multiple users to share the same store, that would work. <mwette>guix is a functional package manager; the derivations are definitions for the functions that generate outputs (e.g., executable binary software packages) given the inputs (e.g., software source packages, dependencies, env variable) <zamfofex>Well, I imagine still having a daemon, though one with Guixâspecific concerns in mind only. <Rovanion>Anybody knows why I'm getting error: symbol 'grub_file_filters' not found. when trying to boot the LiveCD? <Rovanion>I've tried burning it using two different programs to the USB. <nckx>Rovanion: I'm not sure, but could this be related to UEFI âsecure bootâ? <Rovanion>nckx: The machine is too old for that I'm afraid. Intel i5 2500K inside. <nckx>I'll have to admit I've never burnt the ISO to CD, ever. <nckx>Oh, you said âburning to USBâ. <nckx>A special choice of words, but OK, it does increase the odds that something went wrong when writing. <nckx>Which command(s) did you use, exactly? <Rovanion>I wrote it from the Windows PC I was sitting by, trying both Balana Etcher and Rufus. Rufus had two modes (copy and dd) so I'll try dd next. <nckx>The fact that they offer that choice implies that âcopy is not ddâ, and we definitely want something akin to dd. <nckx>It probably unpacked the *contents* of the ISO into the USB drives' FAT file system, which would cause exactly that error message. <nckx>IM(second-hand)E these kind of GUI tools need careful hand-holding to prevent them from being too clever and breaking things. <nckx>Not just with Guix; in general. <nckx>Oh, right, sorry zamfofex. <nckx>That addresses the âGuileâ part. I don't see any advantages to âraisingâ the daemon protocol to higher-level objects, only disadvantages, so you'll have to explain that part further. <nckx>Having a âparse this Aterm file, with these inputs, and build whatever comes out the other sideâ is a pretty solid base IMO. <zamfofex>nckx: I donât know much to say either way, it just felt it would be a reasonable thing. I donât see these âdisadvantagesâ, though itâs probably because Iâm not as familiar with it in general. <nckx>I think we've broken the package ABI a good number of times in the past, for example. It's an *extremely* high level of abstraction for what we need and currently have, which is a dumb thing-builder that is very, very good at building things. Dumbly. <nckx>I don't have a well-articulated response ready though. I've never answered this question before. <zamfofex>nckx: It is fine. I feel like the daemon being usable across multiple versions of Guix is a very significant advantage! And being able to change the package record definition (and for other things like operating system records too) is also important. <lechner>ACTION has never heard of GRUB being too new <lechner>Rovanion / i believe that error relates to grub-install having a different notion of devices from GRUB during boot (perhaps caused by an older BIOS). i would explore the available devices with 'c' if needed and then correct the boot menu in-memory with 'e'. It's probably obvious <lechner>if you are in the grub rescue shell, you have to find the GRUB files first and then run 'insmod normal' <nckx>I respectfully disagree with your sincerely held belief. <nckx>Where do you get this âtoo newâ concept? <nckx>This GRUB was not installed with grub-install, and doesn't care about device names. <nckx>You won't be able to find the GRUB files because the file system driver is missing, hence the error about âfiltersâ. <nckx>This is not a general-purpose GRUB. <nckx>It can boot the ISO it came with, nothing more. If you unpack that ISO, things break. <lechner>okay, fine. it's a CD, but your theory has holes, too. How can Grub show any messages when the ISO is burned as a FAT filesystem? <nckx>WDYM by âburned as a FAT filesystemâ? <nckx>Y'all a bunch of pyromaniacs >:( <nckx>I cannot say for sure since the nearest Windows machine is several miles away, but I expect this Balufus tool to be doing what it considers copying the boot sector to the start of the drive. I don't know, but I don't think that counts as a hole. I understand GRUB quite well. <mirai>is it feasible to start building core-updates in CI <mirai>can anybody schedule it or is it a âmembers-onlyâ thing <nckx>âSpecification core-updates already exists.â <mirai>building c-u with a single 6c computer here is⌠slow <nckx>ACTION has 2/3rds of that⌠<mirai>nckx: can you get CI to start churning out c-u substitutes or is this a ML-worthy topic <nckx>504 Gateway Time-out ⪠<degauss>Hi all! I'm following Ludo's blog article "From development environments to continuous integration", "guix build -f guix.scm" works fine, but as soon as I move "guix.scm" into ".guix/modules", change the 1st arg of "local-file" to "../.." and symlink back to "guix.scm", the recursive copy done by "local-file" becomes totally empty. Has anyone come across the same issue or have any hints? Thanks a lot! :) <nckx>It's weird, even using the psql CLI directly I can't seem to operate on specifications. It just hangs. <sneek>mothacehe was in #guix one day and 8 hours ago, saying: civodul: what's the duplicated part?. <nckx>sneek: later ask mothacehe Any idea why a query like this would hang? psql -d cuirass â delete from Specifications where name = 'core-updates'; <apteryx>nckx: interesting! so colemak's finger rolls fared worst for you than dvorak's alternating hands in terms of comfort? <Rovanion>nckx: Unfortunately a dd'd image from Linux had the same result. <nckx>Rovanion: At least you can share the exact dd command you used now :) <Rovanion>dd if=Downloads/guix-some.iso of=/dev/sdb bs=8M <nckx>Is this an official ISO? <nckx>ACTION goes to look for a USB drive and some metal. <nckx>Did you happen to verify the GPG signature already? (Unlikely to be corruption, but still.) <Rovanion>Nah, but downloaded it twice and tried with both. <nckx>The sha1sum is 46bcc9c5ea04515b4a3bd37c8efff790512612da, just in case. <apteryx>nckx: great, thanks for giving me a good reason to stick with dvorak <nckx>It's one person's experience but I'm not impressed with heatmaps and seemingly-logical stories about finger movement anymore, and nobody does actual studies of long-term use AFAIK. <ulfvonbelow>I'm using workman right now, so far it's been... whelming. It seems that, like with battery life, race-to-idle tends to overwhelm all efficiency concerns, and it's hard to compete with experience since youth in qwerty for speed. <nckx>Meanwhile, I killed my entire desktop with âpkill -USR1 ddâ because I am very smart. <ulfvonbelow>I get the sense that I should've skipped alternative keyboard layouts and gone straight to stenography systems <ulfvonbelow>but I guess this way I'll be the first to know when our gdm finally has a working layout switcher or on screen keyboard <Rovanion>I started learning stenography and got a fair bit, but then realised that each language has its own system. <ulfvonbelow>yeah, the reliance on phonetic mapping makes it inherently inconsistent in that way <ulfvonbelow>it's probably still worth it if you're all-in on english <nckx>Rovanion: Any other USB drives around? (Or, hell, CDs?) <nckx>lechner: I cannot find a workable hypothesis where the BIOS finds the USB device to load GRUB, only to then lose track of it completely. <nckx>Older machines that can't boot from USB are a dime a dozen, but this⌠<Rovanion>nckx: Just tried to boot a Ubuntu image and got the same issue so yeah, I'll try some other USB stick. <Rovanion>nckx: Funnily enough this computer actually has a DVD drive. <nckx>Oh right, we outgrew CDs again. <degauss>I think I found the bug in the "Level 2: The repository as a channel" section: the "vcs-predicate?" should be updated to have "(git-predicate (dirname (dirname (current-source-directory))))". I think I'll ping Ludo about this, as the post may need fixing. <nckx>Unfortunately inelegant, though. <nckx>Any real-world drawbacks to using (getcwd)? <nckx>This isn't a workflow I personally use. <nckx>degauss: Now I've actually tried it out, and take it back: I don't think there's a bug. <nckx>The blog post suggests using a .guix/modules subdirectory of the Guile git checkout, so why would (GIT-PREDICATE? ".guix/modules") return false? <degauss>nckx, I'm actually practicing on another package to learn, and it failed regardless of whether "guix.scm" and ".guix/modules/my-package.scm" were include in a git commit or not. While "guix.scm" existed as a file (not symlink) in the project's root (with "(local-file "." ...)"), "guix build -f guix.scm" worked even if "guix.scm" didn't yet belong in a commit. Anyway, no reason to worry about the Guile package, I didn't use it for my tests. ;) <nckx>If I read your original message correctly, that's not what you expected. <degauss>nckx, I don't know, maybe "(local-file "../.." ...)" still passes "./README.md" as ".../.guix/modules/README.md" to "vcs-file?" instead of ".../.guix/modules/../../README.md" or ".../README.md"? I'm not familiar enough with Guix to check that myself, however the "(dirname (dirname (current-source-directory)))" seems to work. <nckx>Yeah, maybe. I'll have to try the full example (which is a bit too much right now). <degauss>nckx, think I figured it out: "(git-predicate "X")" creates a predicate which is #t for files *under X*. In your example, "((git-predicate ".") "/home/nckx/guile/README" (lstat "/home/nckx/guile/README"))" should be #f. So my "(dn (dn (c-s-d))" works because it creates a predicate for the root of the source directory. <degauss>(In other words, "X" should be the root of the Git checkout, the dir having the ".git" subdir.) <degauss>(That is, for "." being ".../.git/modules".) <degauss>I'll send a patch to Ludo. Thanks nckx for your help! <nckx>degauss: You're welcome, but that's not what GIT-PREDICATE means (otherwise there would be little use for a dedicated procedure). It should work *anywhere* inside a git repository, and in my example it does. <nckx>So yes, there is a bug, but I think you might be blaming an âincorrectâ usage that is actually a bug elsewhere. <nckx>But regardless what it turns out to be: thanks for spotting & reporting it :) <nckx>The last version of KDE I used was 3, but I assume âKDE + Plasma = the KDE desktopâ now? <zamfofex>As far as I know, it is now said that âKDE Plasmaâ is the *desktop environment* and âKDEâ is the group of people behind it (and other software). <nckx>Right. I'd written âKDE Plasmaâ because that's what Wikipedia told me to do. <zamfofex>âIâd like to interject for a moment. What youâre referring to as KDE is, in fact, KDE Plasma.â đ <nckx>âThe desktop environments in Guix use the Xorg display server by defaultâ â is that still true? <nckx>âŚI guess not, re: Wayland. That's on other distroes. <mirai>what's the right way to describe the following âsnippetâ: (define (foo a) #~(lambda (x) âŚ)) <mirai>I've got "Return a G-Exp containing a procedure that returns a XML Catalog for Docbook-XSL in SXML representation." <ulfvonbelow>that describes what calling the procedure defined by that snippet does, not the snippet itself, which would add a "define a procedure foo of one argument which when called with that argument will..." to the front of the description <mirai>oh right, let me refine the question then: does the above work as a docstring for `foo' ? <ulfvonbelow>aside from the fact that it doesn't mention what foo's sole argument is supposed to be or how it's used <jaeme>Is there a specific reason for why gnome is not upstream in Guix? <jaeme>Does something change between 42.4 and future versions <jaeme>GNOME 45 has released already <jaeme>I'm just wondering if there's something blocking guix specifically for gnome <zamfofex>More seriously: It just takes time to update packages and make sure they work. <ulfvonbelow>has something changed between 42.4 and future versions that's a big improvement? <jaeme>Thank you, I'll check it out. :) <lilyp>nckx: there's quite a number of packages still left to update; gnome-team is currently experimental <nckx>jaeme: â u help yes da. 