IRC channel logs
2023-09-18.log
back to list of logs
<euouae>sorry these are late-night questions and I'm a bit tired <ulfvonbelow>or, if you know that the only libfoo you need to replace is the one that is a direct input to libxyz, you can just use modify-inputs with the 'replace' clause <somenickname>basically grafting in the cli it would be --with-graft=old=new <RavenJoad>You have lots of options depending on exactly you want to do, I guess, euouae. <ulfvonbelow>if what you want to do is define a variant and try using it somewhere, you don't need to edit any existing package definition to do that <euouae>There's lots of options. I'm recording them because I definitely want to try these features out <somenickname>I think it is better to describe exactly what you want or else you get to many options <euouae>Right now it's a bit vague because I am not actively trying to do something <euouae>but there's a daemon I want to try to hack. <euouae>so being able to test it live would be nice <RavenJoad>Then a system vm is probably the way to go. I've been doing that for apcupsd. <RavenJoad>Guix has the simple-operating-system macro to make a tiny OS with just enough to boot. Just add your daemon's service to that and you get a minimal testing environment. <RavenJoad>If I want the user to choose apcupsd's mail program, would it be more Guix-y to have multiple packages (using a procedure) which use a different mail program, or provide it in the service-type's configuration? <ulfvonbelow>if it's configurable at runtime, put it in the service configuration <danderson>I'm trying out guix, and I was a bit surprised to see that when updating, hundreds of grafts were being applied to dozens of packages. I thought the main purpose of grafts was quick security patching, why are there so many of them in "steady state"? <RavenJoad>ulfvonbelow: Configurable at runtime only if I change the autoconf script to use "sendmail" instead, because it defaults to "mail". The package route would set the autoconf mail value to the <mail>/bin/<mail-or-sendmail> as the procedure's argument. <rdrg109>nckx: > I just noticed a typo before closing the tab < fixed, thanks! <rdrg109>nckx: > I think SDDM uses .desktop files (that's how I start Sway, anyway). So do you have a ... < No, I didn't have a window manager or compositor installed. I'll install one and try it again. <oriansj>combine with greetd and seatd for very minimal wayland dependencies <euouae>danderson: isn't it to make your build faster? can't you use --no-graft? <RavenJoad>danderson: From what I understand of grafts (without reading the source code), they just replace the rpath-s in the resulting binaries, making the loader get fixed packages. Depending on the particular package that was "replaced" with a graft, it might just be nothing. <RavenJoad>I also don't know if your version of guix affects the number of grafts you get. <danderson>RavenJoad: hmm, maybe I'm thinking too much like nix but I'd expect those rpath adjustments to happen at derivation build time when it's not an after the fact security patch. But I have no idea, that's why I'm asking :) <RavenJoad>I am not sure when or what adjustments are made, but I _think_ that is the end result. We would have to look over the graft code to figur eout when it happens. <RavenJoad>danderson: Reading Guix blog posts, Guix implemented/inherited a form of grafting from nixpkgs, so they may in fact be the same thing. <danderson>hm, nix doesn't have grafts, at least not in the form that guix uses. It was proposed in the original thesis that turned into nix, but never implemented there. <danderson>... unless I'm confused, which is very possible :) <RavenJoad>I guess I also need to re-read the original thesis. I missed that section I think. <rdrg109>oriansj: One question: Where should I put "exec sway"? When I was using X, I put it ~/.xsession, but wayland doesn't seem to read that file <rdrg109>Currently, running "sway" in a shell does open it, so that's not a big problem, but I still want to know how to launch it automatically <rdrg109>[Questionn] How to get rid of the service home-redshift-service-type? Despite having deleted home-redshift-service-type from my configuration and having reconfigured my sytem, it is still being shown in "herd status" under the section "Stopped". <mirai>I'm assuming you most likely did since you've been working on the AVR package lately <mirai>I've been silently following the discussion #65860 though I'm not acquainted with the cross-compilation details in guix <mirai>though I've built the AVR toolchain in the past with the instructions in that website <mirai>and I don't quite understand what's making it “hard” to replicate on guix <mirai>at its heart its just a linear sequence of builds/executed commands <mirai>in theory this would mean that you should be able to write a sequence of packages that accomplishes the same thing <mirai>and idk if it makes sense but I think there's at least 2 kinds of “cross-compilation” <mirai>the usual scenario, building from x86_64 linux to aarch64 linux <apteryx>mirai: we have the avr toolchain, it works well <apteryx>the only issues have to do with circular module dependencies <apteryx>which is unrelated to the avr toolchain really (it's a Guile thing) <mirai>and this one here, where you get a toolchain that isn't “executed or executable” on AVR (its just an 8-bit microcontroller) <apteryx>but is a common gotcha with cross-toolchains <apteryx>because we want to define top level packages that inherit from cross-gcc, a procedure from (gnu packgages cross-base) <apteryx>and that's prohibited in our current scheme, as it's very likely to cause circular module dependency problems <apteryx>so all cross toolchains must be lazily evaluated, which means we can't offer them as top level packages <apteryx>mlambda doesn't support keyword arguments, does it? <apteryx>I guess I can use mlambda as the internal implementation of my define* keyword proc <rdrg109>mirai: I rebooted my sytem, but redshift is still being shown in "herd status" under the section "Stopped" <rdrg109>mirai: My bad. For some reason, I thought that home-redshift-service-type was defined in my system configuration when actually it was defined in my home configuration, so I only ran "guix system reconfigure". I have now run "guix home reconfigure" and it is now listed in "Stopped" now. Thanks for the help. <coax256>Hi. Haven't been on one of these since the late 90's. I have a question. I'm trying to try out Guix on a VM but the intaller keeps running out of space. I started off with 8 GB then bumped it up to 12 GB. Is there a certain storage requirement? The ISO is only 814 MiB <yewscion_alt>coax256: Welcome back, then! ^_^ Do You have networking and substitutes enabled? Or are You attempting to compile everything from source inside of the VM? It depends what You've chosen to install, as well. <lilyp>you could use the preinstalled VM image <lechner>coax256 / Hi, I'm not sure why that happens. Running Guix takes more space than other distributions because software can be installed in multiple versions, but I had a Nano Linode with 25 GB <lechner>Hi, what is the email address for the Rust team, please? <lilyp>bug-guix/guix-patches as always <lilyp>tag your bugs as [rust-team] and your patches as [PATCH rust-team] <lechner>okay, thanks! i'll just email the folks directly <lechner>sneek / later tell jpoiret / thanks for your message from a few days ago. my number is not secret. i'm a minor city official in a community of 230,000 and many people have it. also, an online search should produce it right away <hobophile>why would guix resolve the same not-fully-specified package name to different versions between "guix package --install" vs "(operating-system ...)"? <janneke>hobophile: possibly because `guix install foo' chooses the latest version of foo <hobophile>and why wouldn't the os declaration prefer the latest foo? <janneke>if the operating-system definition has something like (packages (list guile)), then it would not install guile-next <janneke>ACTION should prolly have asked if the version of the packages was the same or not <wonko-the-sane>that may be a bad example because (not (eqv? "foo" "foo-next")), and I think (at least by convention of what "...-next" tends to signify) guix install foo wouldnt resolve to foo-next <wonko-the-sane>I'm guessing maybe the explicitly specified package, if not specified would have been implicitly pulled in as dependency (but strictly a different version required) for something else in the os definition, and maybe guix prefers to satisfy the explicit (though not fully qualified) with that one instead of installing two different versions? <rekado>nckx: oh, wow! This “Mac Subsystem for Guix” looks fun! <nckx>Glad it was news to others! <nckx>It landed in my inbox and I was all 'wait' and also 'wut'. <efraim>I got a test failure on the guix package <rekado>I did not expect to see a Guix-related article on hn today. <bilke>Hi civodul, it is again me with the "TLS error in procedure 'write_to_session_record_port': Error in the push function." <zamfofex>Hello, Guix! Is there any interest in making sure Clang’s ‘--sysroot’ option works well? There are two patches/threads, but they seem to be abandoned. <bilke>The last time you suggested me to update my guix version and guix-daemon which I did but the error still persists. <mothacehe>civodul: everything OK :) nice work actorizing Cuirass btw! <adanska>Hi! Does anyone know if `guix.scm' in the git source tree is meant to work? I know that `guix shell' is meant to use guix.scm files as a instructions on how to set up the shell in that directory, but i dont think thats what `guix.scm` is doing... what's its purpose? <bilke>So I am at 0c1aa354048f82023e6d2043bfecc4fd58bc9b58 on a foreign distro and always get these errrors when running guix pack <civodul>bilke: hi! what does “pgrep -fa guix-daemon” report? <janneke>it's been four weeks, possibly /me should just push <civodul>mothacehe: thanks! i’ll try to merge it today and run it at work <civodul>bilke: what about “cat /proc/659/cmdline | xargs -0”? <civodul>(this is to check the exact version that’s running) <bilke>lrwxrwxrwx 1 root root 0 Sep 13 09:05 /proc/659/exe -> /gnu/store/4p7klk2lba1ycbal6n51ajy17hzqv169-guix-daemon-1.4.0-10.4dfdd82/bin/guix-daemon <adanska>janneke: thanks for the link. I still dont quite understand what its doing, though. the patch submitted here doesnt have any resemblance to what it looks like right now. <janneke>ACTION will push at the end of the day, like they just threatened to do ... :) <janneke>adanska: manifest.scm if present, is preferred to guix.scm, and guix git's toplevel guix.scm is the guix library module (guix) <bilke>civodul: This is still the old daemon right? <zamfofex>Small piece of rambling: It would be neat if Guix could cross‐compile to Wasm. <janneke>jonsger: pretty nice hack, ne? courtesy mbakke! <PotentialUser-86>there's a software that's not in the guix repository, but it is in the nix repository. is there a simple way to build a guix package definition from nix ? thanks <civodul>bilke: it looks like a recent daemon, which means that’s likely a real bug on our hands (bad news!) <zamfofex>PotentialUser-86: You have to do it by hand, but depending on the package, it’s not difficult to. <civodul>bilke: is there anything special about the firewall or networking setup? <bilke>civodul: Yes I am also suspecting a firewall issue but I also do not know where to look for. Maybe I can ask our IT guys if they see something in the logs. <bilke>civodul: Also I am wondering why guix pack makes outbound network requests? <bilke>Similar errors also pop up from time to time when running guix pull. <civodul>you could try those ‘wget’ commands to see what you get <civodul>bilke: ‘guix pack’ and pretty much any ‘guix’ command might check whether servers provide “substitutes” for build products they need <civodul>that’s why they connect there, basically to check if the thing you need is already available on the servers <bilke>would --no-substitutes disable these network requests? <nckx>If you don't need to download anything. <janneke>honey-apple: how about mentioning the patch's title in this case? <nckx>adanska: It just re-exports many things, so you can (use-modules (guix)) and get on with your life. It's not special. <rekado>civodul: can you confirm that the DoS message you get is only encountered when using Tor? <civodul>rekado: just my ISP, no Tor involved here <bilke>civodul: First guix pack run with --no-substitutes went fine... <jpoiret>janneke: tests are failing on the guix package for me <sneek>jpoiret, you have 1 message! <sneek>jpoiret, lechner says: / thanks for your message from a few days ago. my number is not secret. i'm a minor city official in a community of 230,000 and many people have it. also, an online search should produce it right away <jpoiret>i can look at it later this evening but not right now <jpoiret>lechner oh alright, that seemed quite weird to me but i guess it's fine then :) <janneke>jpoiret: is this because i ran make update-guix-package? <efraim>I'll say it exposed it, the 'rewrite-url, without to-version' test started failing <janneke>ah, that failed for me on the hurd and it worked for me on linux <jpoiret>usually you should consider that updating the guix package also requires fixing the tests (because we also have failing ones) <jpoiret>but if they're just transient tests that's worse, although building the guix package first locally should make it more reproducible <janneke>ACTION told apteryx: i found the newly added "rewrite-url, to-version specified" test to fail on the Hurd unless i do `guix shell -D guix nss-certs openssl'; does that mean guix is lacking those as dependencies/inputs? <janneke>ACTION goes to revert the guix package update <efraim>it was the first time the package was updated after the test was added <janneke>yeah, i only made sure it worked doing `make check TESTS=..' <janneke>after i found it to fail on the Hurd <janneke>oh wait, for me only "rewrite-url, without to-version" failed? <janneke>in better news, my first `guix pull' of the day on the hurd passes without OOM messages, so far: 1/1 <janneke>efraim, jpoiret: for me those tests seem to pass; would one of you care to file a bug? <jpoiret>Do they pass when building the guix package? <janneke>i tested guix pull, as well as `make as-derivation' on linux and on the hurd this time <janneke>ah, you mean ./pre-inst-env guix build guix? <janneke>efraim: yeah, that's why i asked apterix the question above <janneke>it works for me if i do: guix shell -N -C -D guix nss-certs openssl <janneke>but no idea what the correct solution would be here <efraim>that (getaddrinfo-error -8) makes me think it actually tries to connect, or gives up pre-emptively without networking <janneke>yes, on hurd i got `certificate not found' or somesuch <janneke>i believe apteryx intended for networking functions to be stubbed <rekado>janneke: “rewrite-url, without to-version” fails for me on x86_64 <rekado>that’s in the attempt to build /gnu/store/p54nnhwng2nj6l8sq8aq3zl8blihi0nd-guix-1.4.0-11.658de25.drv <janneke>rekado: yes, i just reverted the -11 guix update :-( <jpoiret>I haven't looked at the test's code but if it uses network it'll need to be either patched in the package to SKIP or mocked somehow <ulfvonbelow>is it normal for guix gc --derivers to give more than one derivation for a given output? <rekado>ulfvonbelow: different derivations can have the same output <rekado>somenickname: yes, I’m aware. It’s on my TODO list for mumi. <ulfvonbelow>how does that come to be? What is allowed to differ within a derivation while still producing the same output path? <tmathieu>Hello, I am new to guix and I would like to use the containers in order to have reproducible development environments for python. A lot of the packages that I use are not on guix yet and hence I want to use both guix shell -C for container and a python virtual environment inside the container. However if I do that, I need to set the LD_LIBRARY_PATH to /lib and use guix shell -F otherwise the python libraries do not find the share <tmathieu>libraries. I saw here: https://issues.guix.gnu.org/25072 that my solution was not good (they say it is a hacking) and I was wondering what is good practice to use python virtual environments in guix. Thanks. <civodul>tmathieu: hi! the ideal situation is when you can handle all the software with Guix <civodul>because then it’s managed uniformly, there are no bad surprises <civodul>but of course, that requires packaging work, although ‘guix import pypi’ can help <civodul>as for an interim solution mixing pip and Guix, i don’t know <civodul>i’d say it’s okay if what you install with pip is pure Python code <civodul>less so if it’s precompiled binaries of C/C++ code <civodul>maybe someone else here has experience with it? <msavoritias>does the development option on guix shell download the source code also? it seems it doesnt <janneke>second `guix pull' of the day on the hurd passes without OOM messages, so far: 2/2 \o/ (one guix pull takes 2h5') <bjc>is that with rumpdisk? <janneke>no, inside a regular vm without using "noide" that would disable rumpdisk <janneke>but yesterday, only the 4th attempt succeeded <nckx>There's no meaningful way to make source code ‘available’ through guix shell, IMO, so it's better left to ‘guix build --source’. <nckx>Damn it. tar: icecat-102.15.1-guix0-preview1/xpfe: Cannot mkdir: No space left on device <lechner>Hi, is there a smart way to manage g/p/crates-io.scm. I have been making manual edits. It seems like it will never end <janneke>*without using "noide" that would disable the mach IDE driver and thus actually use rumpdisk <efraim>janneke: how much ram? That looks much much faster than I was getting with 'make' on ppc32 <jonsger>nckx: should I built it on my machine? <efraim>lechner: I find the target package I want to upgrade (or add) and bump that. I try to build that. If a package is missing I'll package it, if a package needs bumping I'll bump that, and I'll retry building now with the 2 packages. Repeat until all the new and bumped packages build correctly. Create as many commits as necessary and continue on to the next package <janneke>efraim: i'm giving the VMs just 4GiB, currently there's no reason to give it more <msavoritias>nckx: ah didnt know about --source in build. thank you <avalenn>why do "guix home" try to compile some version of Guix I did not ask <janneke>i guess "guix home" is not a very empathic and wise listener <avalenn>it wants to build a guix 1.4.0-11.658de25, but this matches no channel I want to use <janneke>you must have ran `guix pull' sometime this morning <avalenn>my channels.scm points to c46fe3ed743dde2fb4b15e578e6985d888ce87e4 <avalenn>janneke: thanks. I suppose 273709932fa47f6ae56c96564a9415fdbff4a169 fixes it <janneke>which will not build btw, which is why the very next commit reverts that; run guix pull again <janneke>avalenn: yeah fixes/avoids, whatever you'd like to call it <janneke>from time to time you may get a `new guix', alas this time it wasn't to be <janneke>just a new version of the guix package manager package <lnnk>Hay I want to contribute to fsf but at the same time within one year I may became the sole breadwinner of my family. It may be a bit offtop <lnnk>*Off topic do anyone known of any company that contributes to libre software as I am not willing to develop property software. <avalenn>janneke: I understand that this version of Guix is the one packaged and available via "guix install guix" <avalenn>but why does some "guix home" execution triggers the build of this Guix packages ? <janneke>avalenn: never do `guix install guix' ;) <janneke>it's not so much `guix home' as the fact that you ran `guix pull', and thus "requested' (without knowing) a new version of the guix package <janneke>"guix home" uses the guix package, so it needs to build it first <avalenn>Ok. The thing is that "guix home" uses the guix package from gnu/packages, and only the guix "binary" from the ~/.config/guix/current. <avalenn>is it only "guix home" ? or is this dependency more generalized ? <apteryx>neat, we'll have 2 guix buildable firmware options for the ergodox keyboard <janneke>third `guix pull' on the hurd passes without OOM messages: 3/3 -- i'll leave it at that for now <janneke>apteryx: i take it you saw the troubles about "rewrite-url, without to-version" we had this morning and the backtrace i sent? <lagash>Is git-fetch generally preferable to url-fetch when it comes to Git(Hub) repositories? Why do certain packages download from the releases tarball URL instead of cloning? <geri>hey, i remember at least a few people saying they dont use guix home, here's a question - why not and what do you use instead? :D <dthompson>geri: as someone who only started using it about a month ago: pure laziness. it was just "a new thing to learn" <lagash>I figure git-fetch would be preferable because, among other reasons, it would make it easier to track updates. <janneke>geri: also, guix home is a pretty recent feature <janneke>ACTION switched to guix home only half a year ago <geri>ive used it for a bit now and realized i dont like having to run reconfigure when im hacking on my configs <geri>that leaves only packages in my case which can be set in system.scm <geri>it's amazing on foreign distros though <janneke>geri: i often replace the symlink to the store with a copy from git <janneke>hack on that until it works, copy back, commit, reconfigure <janneke>but yeah, there's an extra indirection as opposed to having home in git directly <janneke>yeah, there's been not so many configs to really hack in for me <geri>for emacs i usually store my configs @ $XDG_CONFIG_HOME, but when im playing around i put it into ~/.emacs.d, which takes precidence <geri>probably not taking your approach cause ill get 10k backup folders otherwise <geri>it is, though way more annoying than just editing your configs <janneke>hehe, true; i've started to blindly remove them <janneke>yes, i kinda miss the home-in-git feature of using magit directly on edited configs <janneke>but i very much like my list of packages being consistent with their configs <geri>plus my configs are back to being as portable as they get <janneke>i imagine it's still early days for guix home, dunno <geri>i like it too but my solutions so far were kinda very-very overcomplicated <geri>like modifying PATH with home-environment service to add sway scripts to it <geri>rn i just dumped all my scripts in one directory and nothing else required <janneke>we (i!) need more brilliant and simple template/examples from people that figured out how to do stuff <geri>i absolutely love hacking on guix home tho <geri>janneke: i don't think ive seen your setup before :D <geri>(says the man who shares his configs as a tarball) <geri>are all the configs symlinked into /etc because the path is hardcoded? <janneke>geri: yeah, i haven't found a decent way to deal with secrets <geri>like i know what secrets are, i just dont understand what secrets could be on a personal setup ig <geri>except maybe keepassxc database or smth <janneke>oh, they're passwords in config files for stupid tools or encrypted files that hold passwords <somenickname>You mean retrieving passwords in a Bash script? Stuff like this? <somenickname>Ah nvm, you probably already heard about pass. I moved everything to pass and like my current setup <bumble>geri: http://0x0.st/HO_u.scm can be used this way, after importing... (service home-xdg-configuration-files-service-type (home-alists-create-from-dirs '("config/emacs" "config/fcitx5"))) <bumble>if you don't agree with the way paths are handled, it doesn't modify paths that start with "/" eg root paths <bumble>root paths could be specified directly in the list in whatever way is best <geri>have you tested it out already? <geri>honestly it feels like guix is "everything configuration/package management" tool just the same way emacs is an "everything text" tool <geri>wonder why... *cough* GNU *cough* <apteryx>bjc: I found out that using dvorak as the system layout doesn't really play well with a querty layout on the keyboard either <apteryx>something like '=' gets turned into ']' ^^' <apteryx>so it seems I'll have to use e.g. dvorak as the keyboard layout and set the system layout to querty to have it work correctly <bjc>yeah, there are a number of keys in dvorak that move around between various layouts <bjc>ime, you get used to it fairly quickly, but it is annoying <apteryx>yeah, I don't really want to learn some frankenstein layout, eh <bjc>it's things like brackets, and slashes, iirc. the letters and punctuation should always be in the same place <apteryx>I'll just detect if an ergodox is plugged in the machine and default to qwerty in my xsession script if found, dvorak otherwise <chucho>Hello everybody. I'm a GNU Guix noob, I'm trying to build a package but I'm having dependencies issues, I need this package to do all the process in Spain. it's built on Java (https://github.com/ctt-gob-es/clienteafirma/). Is there a maven example how to build a package? <bjc>if you can stay fluent in qwerty as well, it's worth doing <bjc>i don't hop around between computers that much. so it's nbd for me to have to type qwerty the 5% or less of the time i'm on a system without my preferred layout <bjc>if that ratio were higher, i might have different ideas =) <bjc>ah, yeah. that definitely changes things. i think i was a little lucky in being able to hold on to qwerty <geri>chucho: found that `java-jmh' in /gnu/packages/java.scm is using maven-build-system, might be useful <geri>if someone can drop a link would be great <mirai>does the guix emacs package come with gnutls support? <bjc>i wonder if you could set up a udev rule to change the system layout when the external keyboard is plugged in <geri>it's at least in inputs for emacs mirai <mirai>> If your Emacs has GnuTLS support built-in, the function gnutls-available-p is defined and returns non-nil. <chucho>@geri (I don't know how to mention someone on IRC yet) thanks a lot :) <geri>you just write their name, so all good :D <mirai>outdated documentation? Anyone using TLS for emacs smtp? <geri>mirai: it's not an interactive function and i have it <mirai>hmmm… how can I confirm these kinds of things <mirai>is it a simple describe-variable? (or -function as I just found out) <geri>C-h f gnutls-available-p <geri>i have like 1k lines in total in my emacs configs and i still feel like a newbie <geri>80 gigs of /gnu/store, pog <apteryx>bjc: re keyboards, this leaves me wondering though, how do 'normal' keyboards do it? My '=' key shows up at the right place (per a dvorak layout) when using a system dvorak layout? <apteryx>hm, I think I was just confused there, looking at qwerty-kinesis-mod.c and typing with dvorak system layout, eh. <mirai>geri: I'm still wondering how to operate this piece of software <mirai>are people really expected to magically memorize these key permutations <mirai>perhaps I've missed some `brain-surgery install emacs' step? <mirai>Do the C-h C-u C-x C-????? have some kind of meaning behind or is it arbitrary <apteryx>C-u is to modify the default behavior usually (universal argument) <geri>i used to be a vim + tmux user and i honestly hated emacs the first 2 tries, thought it wasnt for me for next 3 and then i fell in love with hacking on its configs and had it installed "as a toy" and now its my main interface <bjc>so, in usb, every key has a code (the key corresponding to 'a' is 0x04, for example). that code is then interpeted by the os according to its layout. so 0x25 can mean '$' (when coupled with the shift modifier) or '£' in the uk <geri>C-c is for mode-specific stuff <geri>C-x is for like everything lol <bjc>w/o the shift, 0x25 is almost always going to mean '4', though, unless you have a really wacky layout (programmer dvorak or something) <bjc>the keyboard ensures that when you press 'a' it sends out 0x04. the os ensures that when it sees 0x04, it maps to whatever it thinks that key should be in your current layout, always assuming you're physical keyboard is in qwerty <geri>i still have like 43 gigs of stuff in /gnu/store after running `guix gc`, do i need to give it some argument to "clean better"? <bjc>so, 'w' on a standard qwerty layout will send code 0x1a, the os gets 0x1a, assumes you're physical board is qwerty, but you want dvorak, so instead of 'w' it interprets it as ',' <geri>somenickname: i was thinking that too, how do i clean em? <bjc>things get weirder if you have a qwertz or azerty, though, because the codes corresponding to locations change, and so simple remapping on the os end can break down <somenickname>and home is basically the same command if I remember it correctly <unwox>geri: or better yet "guix gc -d1w" - deletes generations older than 1 week <somenickname>ah it was under guix gc, searched for that time argument <unwox>if you run "sudo guix gc -d1w" then it should gc system generations as well iirc <geri>also guix package apparently had 90 generations <apteryx>bjc: I think I get it now, thank you <somenickname>I personally think guix gc is really satisfying to watch. Don't know why but seeing all those lines and having all that disk space back is nice <geri>if my last generation is older than 1 week, would it get deleted? <geri>way more satisfying than compile logs on gentoo <geri>oh actually i ran unwox's command, im just bind <geri>janneke: maybe i should define packages for everything that create a custom shell wrappers to launch apps with my configs... <geri>no .config == ultimate cleaniness B) <geri>plus everything gets encapsulated in a package <lagash>So, a package requires a URW Type 1 font for building the documentation - should I put `font-liberation` in native-inputs or inputs? <lagash>Another twist: the meson.build file explicitly lists fontconfig as a run-time dependency. <f1refly>hello, I'm using the syncthing herd service with my user, but it frequently seems to be disabled without reason (i think it does so after waking from suspend but i'm not sure). is there anything to be mindful about when setting up a syncthing for a user? <efraim>janneke, geri: Here's what I have in mind for storing secrets in guix-home: https://paste.debian.net/1292388/ I used gpg to encrypt them and then encoded them base64 so they can go in the store, then used 'pipeline' to read it back <efraim>haven't actually pulled the trigger on it yet <efraim>cbaines thinks I'm crazy for considering it and has given me several crazy looks for bringing it up <geri>efraim: why do you encode them to base64? <geri>is it like you encode cyphertext into base64? <efraim>%email-password-base64 is the base64 encoded copy of the password gpg encrypted. the gpg encrypted password contains characters which can't go into the store <mirai>lagash: congrats, you've just hit a big headache <mirai>short term solution: font-ghostscript <mirai>long term: a rename and figuring out why fontconfig doesn't work with updated URW font <lagash>mirai: I'm trying to update vips. It seems to work. <lagash>If only because it's using the font only during building documentation, via Graphviz.. <zamfofex>Hello, Guix! I decided to stop just lamenting it, and started to try to add a Wasm target to Guix. I haven’t gotten very far yet, but I spent the whole day working on it. (Mostly just waiting for things to build.) I feel like if I didn’t need to set up a Clang variant package that has a working ‘--sysroot’, it would go much more smoothly. I set up a simple ‘wasi-libc’ package that (almost) works, so all I need is Clang <zamfofex>with working ‘--sysroot’ (without needing to build the thing myself, because it takes literally four whole hours.) Maybe I’m further than what I imagine, but it didn’t seem particularly difficult, just a bit fiddly. <zimoun>nckx: another issue with Debbugs. ;-) Why “git send-email --to=62202@debbugs.gnu.org v2-000[1-9]-*.patch v2-001[0-9]-*.patch v2-002[0-3]-*.patch” open many new issue instead of just associate to issue 62202? <zimoun>Well, why from #66075 to #66092? When using the git-send-email above? <zimoun>Note that #62202 also have the 23 patches. <zimoun>Well, I am closing #66075 to #66092 since they seem duplicate with the ones in #62202 which is what I wanted. <mirai>zimoun: I think the problem is given away by this line <mirai>From: Nicolas Graves via Guix-patches via <guix-patches@gnu.org> <mirai>try cat'ing one of the patches that ended up opening a new issue <mirai>it probably CC'd to guix-patches when it meant to CC Nicolas <nckx>mirai's hypothesis is probably correct, but I've seen Debbugs *not* opening new bugs merely because guix-patches@ was in CC. It's just great that this basic functionality is apparently not reliable. <nckx>(Aside, zimoun, what shell do you use that you have to manually group file names by 10s? Is ‘v2-*.patch’ really not sorted in your shell?) <nckx>(Or is the ‘v2-000[1-9]-*.patch v2-001[0-9]-*.patch’ just unoptimised…)