IRC channel logs
2024-09-07.log
back to list of logs
<galois`>Well even if I would use the old mono package it would still be heavily outdated, right? <galois`>Maybe I should dual-boot another distro. <meaty>what I'm writing a package that inherits from another, how can I refer to the description of the parent package? <aswjrisp>ekaitz: It is just good to hear that qmk on guix works. I am planning on using qmk for programming a keyboard. <ekaitz>yeah, it worked long time ago when I used it <ekaitz>right now i don't know if it does, but with Rutherther 's changes in the toolchains should <aswjrisp>ekaitz: You mentioned pico sdk. So you are programming your mice, trackballs and keyboards using pico sdk, with pico being the microcontroller. <ekaitz>that's the plan, but the old ones I made had an arduino <ekaitz>well, not an arduino, sorry an ATMega32U4 <ekaitz>that is very well supported in guix with the avr toolchain <aswjrisp>ekaitz: What toolchain do you use with pico? <ekaitz>arm-none-eabi that's what i've been discussing earlier that was broken and is in the way to be fixed <aswjrisp>ekaitz: What type of phisical keyboard do you like using and what alphabetic character layout? (qwerty, workman, dvorak, halmak, workman...) <ekaitz>it's hard for me to get used to something new <ekaitz>in fact, i was raised in spanish, so I got stuck to the spanish layout <ekaitz>and now I'm using the US layout because it's better for coding <ekaitz>and i'm forgetting the other one <ekaitz>and i'm having trouble with it because I have to write in spanish pretty often <ekaitz>so... if i learn dvorak i'd probaby be unable to use any other computer, and nobody wants that <aswjrisp>ekaitz: kmonad with a layer for spanish characters? <aswjrisp>Thanks for sharing the toolchain information. <ekaitz>i switch layouts, it just works :) <xelxebar>I wonder if profiles should set FONTCONFIG_FILE in bashrc etc... <apteryx>hello! I'm deploying a wireguard service on a remote machine, and I don't see where the generated config is stored; any clues? <apteryx>OK, 'guix gc -R /run/current-system | grep wg' on the target yields it <apteryx>ah, there is also: herd configuration wireguard-wg0 <apteryx>herd restart wireguard-wg0 doesn't cause the new config to be reloaded... <apteryx>hm, it should. I think my config is not correct or something :-) it complains: Warning: AllowedIP has nonzero host part: 10.0.0.3/24 <apteryx>ah, the last part (3) should be 0 for providing a subnet to AllowedIPs <the_tubular>What if you want to give it 10.0.0.52 to 10.0.0.55 ? <jaft_r>Is there a way to list the last generation for "guix pull"? I was able to figure out the current iteration and list it with "guix pull --list-generations=###" but that'll be cumbersome, in the future (as the generation changes). <apteryx>the warning is gone; I guess wireguard supports only a few network 'patterns' <eikcaz>cuirass seems to assume machines are on the same local network. Are there downsides to distributing a cuirass swarm across networks? I see a benefit that each package is only built once, instead of once per node, but are the network requirements prohibitive? <apteryx>I don't think the avahi discovery mechanism is able to cross networks, IIRC <meaty>does anyone here use the 'kitty' terminal? were you able to get the 'kitten' commands to work? <meaty>they seem to be missing/not installed in the guix package <eikcaz>apteryx: The cuirass-remote-worker-configuration allows me to specify a server IP, so I think I should be fine (with appropriate port forwards) <podiki>meaty: haven't used kitty in a while, but just a note our package is a bit old (looked difficult to update when i last looked due to adding lots of go stuff if i remember?) <apteryx>eikcaz: ah yes, I think by default it listens on localhost only, but you can change that to 0.0.0.0 to listen to any interface <eikcaz>meaty, podiki: I get some promising output from "kitty +kitten" <eikcaz>apteryx: cool. I think I will proceed under the assumption that ethernet connections should be strong enough for cuirass even if it's across the country. <meaty>yeah, it seems our version just predates the one the docs are written for <meaty>ah, the wonders of online documentation :) <aswjrisp>meaty: are you aware that the kitty developer likes telemetry in the kitty terminal? <aswjrisp>You can search the projects github issues for telemetry for more information. <meaty>aswjrisp: thank you for informing me <meaty>any good alternatives? i like it for the font ligature support and theming ability, images are nice too <meaty>i'd do alacritty if it could to ligatures <aswjrisp>meaty: I can't help with suggesting alternatives as I have not looked into images or ligatures in the terminal. <meaty>PuercoPop: i look it up and all I see are rust packages to extend it <podiki>kitty telementary should be disabled in our package config already <robin>meaty, kitten doesn't work, it's an optional go problem that's not built (not easy to package its dependencies either) <robin>in particular the go importer is package- rather than module-oriented, or something along those lines, which is by now an outdated way to approach go compilation...i believe there's a patch floating around to try to fix that <robin>(ofc you could just install the necessary tools yourself and build kitten manually) <meaty>robin: I may just do that. i mean that's one of the reasons we have profiles no? I can make a spare build/dev environment just for building kitty+accessories from source <robin>yeah, that should work, it's just that "go get" doesn't cut it when building packages :) <robin>(i played with it for a day or two before deciding that alacritty would work just as well for my nethack sessions :p) <meaty>which guix package contains the 'magick' executable? <meaty>I'm trying to package a maintained version of pywal and it need it at runtime <meaty>you'd think imagemagick but not so <weary-traveler>hm after installing guix from installer script, running guix pull is resulting in a build failure: build of isrg-roots-x2.pem.drv failed <robin>meaty, maybe graphicsmagick? <robin>oh nm, i see that it's supposed to be part of imagemagick <weary-traveler>seems it's unable to download isrg-root-x2.pem from letsencrypt? any thoughts on how to proceed? <robin>meaty, looks like the imagemagick package isn't up-to-date with upstream, 6.9.12-4 vs. 7.x <weary-traveler>ah /etc/services is missing (since it's now under /usr/etc on foreign distro) <apteryx>did we get both a GNOME refresh as well as a core-updates merge? <apteryx>hm, no keepassxc autotype when using wayland <apteryx>from GNOME settings, clicking on "Shares", I'm prompted for the 'default' wallet passphrase, which I don't know (not my user password) any idea? <apteryx>ah, they meant the SSH passphrase... that wasn't too clear. <futurile>what's happening with CI and the master branch at the moment? There's a message that armhf-linux has a low level of substitutes so patch processing is suspended. So according to this https://ci.guix.gnu.org/workers the whole build farm is now idle <nckx>futurile: Unless somebody quietly frobbed something, that's not what I'm seeing. There are a few builds running and the ARM builders are building, but only aarch64, nothing armhf indeed. <futurile>nckx: but yeah, I probably don't understand what's happening :-) <futurile>nckx: looks like 5/30 are doing something <nckx>The workers are physical machines. The hydra-* ones are x86_64 rack nodes. It's plausible that they are caught up. Only grunewald and overdrive1 are ARM, and they both seem to be building. <nckx>...although on pankow all 4 builds have been running for a sus high number of seconds. ('Duration' if you click through.) <nckx>s/pankow/grunewald/; pankow is another ARM machine that's off-line for some reason. <simendsjo>I'm trying to package using the binary-build system using patchelf where one library depends on another in the same folder. How can I specify this? E.g. I want "bar" to depend on "foo" (("foo" ("gcc:lib")) ("bar" ("./foo"))) <PotentialUser-37>Hey I am trying to add an user to the group "wireshark" but I need to create the group first. How do I do? Thanks a lot <PotentialUser-37>futurile: it explains how to an user to the group but not how to create the group <nckx>simendsjo: You don't specify 'dependencies' in Guix, they are computed by scanning for store items (strings) in the resulting binary. But then I'm not sure what you mean by a 'binary' build system. <nckx>Oh, is this some not-Guix thing? <simendsjo>nckx: It's a package which has a.so and b.so. b.so relies on a.so, which is not in the store. <Rutherther>please discuss this in a channel for the project it comes from, there is no binary-build-system in guix <nckx>Probably better—for practical reasons if not ideological–to ask them, yes. <nckx>Once you're manually specifying dependencies of binaries you're not following the Guix reference scanning way, so I have no ieda. <Rutherther>since they still don't seem to be coming to the channel and I've already written a reply: simendjso: I've skimmed through the code of the binary-build-phase, and if I am looking correctly, it should try to match outputs as well as inputs. So just put name of the output instead of name of input, ie. "out". If you do not want to use the default "/lib", put the path there as second element, something like this: "#:patchelf-plan '("foo ("gcc:lib" ("out"... <simendsjo>Solved it by using patchelf directly, adding (dirname file) as the first rpath. Changed from binary-build-system to copy-build-system too. <simendsjo>I'm using the copy-build-system, but I'd like to change #:elf-directories which is used by validate-runpath. This function is not exported, so I cannot easily replace the step and call the function (or can I?). What's the proper way to set this argument? <Rutherther>when a function is not exported you can still access it with "(@@ (the module) the-symbol)" thoough in this case you should just add argument to your package. The arguments are just passed to the phases, that's how you change their argument, not by calling it yourself instead <simendsjo>copy-build has #:allow-other-keys and #:rest, but when I pass #:elf-directories, I get "Unrecognized keyword: #:elf-directories". <simendsjo>I see gnu-build doesn't allow the key, which is why I cannot configure it <ngz>simendsjo: If you add (#:imported-modules `(,@%copy-build-system-modules (guix build gnu-build-system))) and (#:modules '((guix build copy-build-system) (guix build gnu-build-system) #:prefix gnu:)), you call change validate-runpath in your phases with (replace 'validate-runpath (lambda args (apply (assoc-ref gnu:%standard-phases 'validate-runpath) args))). <nckx>Being restricted to a single build phase's keywords is annoying though. And I'm not just saying that because it recently bit me, but it doesn't help. <Rutherther>simendsjo it seems to be all -build inside of the guix build-system accepting just some expected arguments, so in this case copy-build. Probably a safety mechanism against typos I suppose. It's quite funny with Nix actually, where you can type in anything, and it will just get set as env var, even case mismatch can lead to confusion there. <nckx>Oh god I'd repressed my memories of Nix doing everything through environment variables. <Rutherther>ngz why is that imported-modules and modules necessary, why cannot it be taken out of %standard-phases directly, without getting it specifically out of the gnu-build-system ones? <nckx>I might be missing your point, but %standard-phases isn't a global thing. It's defined differently for each build system. <Rutherther>yes, but copy-build-system still has it, it's even visible from the suggested solution, as it's just a replace 'validate-runpath, and not add-after or something liET hat <nckx>If your top-level build system is the copy-b-s, %standard-phases won't have all the GNU phases, and vice versa. <nckx>Uh, OK, then I indeed don't get your point. <Rutherther>%standard-phases of copy-build-system has 'validate-runtime, no? So "(assoc-ref %standard-phases 'validate-runpath)" should work as well, no? Since the daemon already has loaded %standard-phases out of copy-build-system in this case <Rutherther>the source and install-phase were just first thing that came to mind (almost, first was gcc, but that has quite a big source), nothing that should be showing much. <nckx>No, I get it, I just misinterpreted which part of the convo you were sceptical of. <Rutherther>ah, okay, good. I thought you meant you still don't get it when you said "don't" instead of "didn't". At least simendsjo has an example now, it also didn't occur to me in the beginning one can just get a phase like this until ngz mentioned it <nckx>rodrigo-morales: '-r' isn't and won't be deprecated. Its long form is now '-S nar', not '--recursive'. <nckx>Although I do see that the manual doesn't phrase it like that, which I agree is confusing. <nckx>It should not imply that -r is short for --recursive, even though that's obviously its origin. <nckx>Hmm, issues. was down again (502). I fixed™ it using 'herd restart' technology. <nckx>How do I ask herd to reload its configuration? <rodrigo-morales>[Question] What would be the equivalent of the Emacs function guix-packages-by-name-regexp (it lists all guix packages whose name matches a regular expression) for the command line? I have used "guix search <regex> | grep '^name:.*<regex>" in the past but I wonder if there's a shorter way to do it. <thorondir>Does anyone have a working example of a home-dotfiles service? I can't get mine to work as I think it should. <nckx>rodrigo-morales: ‘guix package -A’? <nckx>Some post-processing required if you want only the name. <nckx>You can specify an optional regexp after '-A' and '-I', no grep needed. <apteryx>just ran a quick disk benchmark using kdiskmark on a SSD, with ext4 vs btrfs + zstd comp; it's similar, but btrfs is either as fast or faster <apteryx>I guess we should work toward making it our default file system for GNU+Linux <apteryx>especially since it can pack more of /gnu/store and doesn't suffer from inode exhaustions <aswjrisp>apteryx: I have not tried btrfs. It is a newer file system for Linux. Has it matured and stabalized? <Rutherther>are you running the same guix executable as root or a different one? <ngz>Let's default to bcachefs <koorosh>the user one points to /gnu/store/va037anzxcbd2asnr92j1q3m48qk2spk-guix-command and the root one is pointing to /gnu/store/3idscgjackx6si753iqj3a5gn2xb5nxw-guix-1.4.0-24.9a2ddcc/bin/guix <Rutherther>okay, and it's all guix commands, or only some? There was an issue like a week or two ago where guix got broken for like a day. If you are on any of the commits that is there currently, you would experience this. And the solution to that is to update. To update you can just run different guix, like the root's one, and do "guix pull". If this does not help, it's something else and will need debugging <koorosh>all of them even without any arguments <Rutherther>okay, then it's probably something else and pull probably won't help <Rutherther>does running the same guix binary you use as user, as root also cause a segfault? <apteryx>aswjrisp: it's quite mature in my own experience, if you steer clear from RAID 5 or 6 <koorosh>no I can run the user guix as root without problems <koorosh>could this be a problem with my LD_LIBRARY_PATH <aswjrisp>apteryx: Does guix already support btrfs, so I could use it if I did a manual install? <apteryx>been using it for at least 7 years; the only time I've had issues with it was when some drive was dying; and it was protecting my data by mounting my array read-only then. <Rutherther>yes, for sure. Do not use LD_LIBRARY_PATH on Guix <apteryx>you do need a couple services to run for example 'btrfs balance' to free btrfs storage blocks though; otherwise the file syste <koorosh>it just points to ~/.guix-profile/lib <apteryx>may fill up even though 'du' says otherwise. <nckx>koorosh: That is guaranteed to break guix pull when glibc updates. <koorosh>I think I set it when trying to use guile ffi for some library <koorosh>so I should never set LD_LIBRARY_PATH unless when using guix shell for some specific use case or at least when I'm using guix <Rutherther>setting it even in a shell can break stuff, ie. if you put different glibc there it can break some programs <nckx>It's fine to set it when you understand what it does and why it breaks things. And don't forget that you set it, years later, when they break 😛 <koorosh>nckx: Rutherther: I think I understand what it does but I'm not sure why it breaks things can you tell me more <nckx>I'm going AFK now but will type it out later if nobody else has. <Rutherther>The programs are built against some specific libraries. The program then loads the library when/after you start it. If different version was loaded instead, the functions expected may not be found at correct places. Setting LD_LIBRARY_PATH means the programs will try to load libraries from paths specified there instead of the ones they were built for, so this breakage can occur. <koorosh>ok so when I try upgrading the at some point there is guix binary linked with some older version of glibc and there is a new glibc in my profile is that correct? <koorosh>also how does the ld cache tie into this? <Rutherther>See "man ld" (can be obtained on guix by "guix shell binutils man-db") for all the details including order. The ld.so.conf is two steps after the LD_LIBRARY_PATH <Rutherther>no, sorry, that's wrong manual. The correct one is man 8 ld.so, but I am not sure which package it comes from <apteryx>man dhclient says: "At startup the client may be started for one or the other via the -4 or -6 options." <apteryx>the service doesn't specify either-4 or -6, so it uses the default <apteryx>so it seems I'd need to run a second dhcp-client-service-type with -6 <apteryx>OK, there's a 'version' field for dhcp-client-configuration, although it is currently undocumented <apteryx>weird, I see this during byte-compilation: "Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (atf (gnu packages check)) #f)'." <apteryx>with above line: "Failed to autoload atf in (gnu packages check):" <apteryx>building guix still takes 8 m 17s to build on a top of the day desktop machine <apteryx>hm, 'git send-email' says: Not using SSL_VERIFY_PEER due to out-of-date IO::Socket::SSL. <nckx>Not the personal experience you requested, but 'Under the hood of UTM is QEMU' means that it's likely to work without problems. Guix won't even know it's a Macintosh. <nckx>If you don't know what QEMU is, it means that you'll be emulating a virtual PC to boot a separate OS (Guix System) in a window. You won't be installing & using Guix packages on your main Mac OS. <simendsjo> Thanks Rutherther and nckx! Worked great calling the previous 'validate-runpath using that technique. <podiki>trying to update godot and get on building: "/gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/include/bits/errno.h:26:11: fatal error: linux/errno.h: No such file or directory" <podiki>i do see linux-libre-headers in the various env variables, but i don't know this whole scons build. no issues on current version of godot we have though, even post core-updates merge <podiki>ah got it, needed to update a substitute* string that sets env for scons <Rutherther>if I send multiple patches with git send-email, will they be picked up as one issue, or one issue per patch? <podiki>each patch will get a new issue number if you send them all at once <podiki>see the manual about sending a patch series if you want multiple patches for one issue <Rutherther>oh, this cover letter feature is very nice. Thanks. Though this will be a little bit trickier for me since I will have to wait multiple hours for answer from Debbugs :D <podiki>that's a shame, hopefully it gets faster for you <podiki>usually it should respond in a minute or a few, i guess some are unlucky for some reason (routing?) <podiki>neat, last commit starts with 123 <podiki>sneek: later tell hako are you still updating your hyprland packages? i think we should be able to move them to guix (possibly first on mesa-updates where newer libdrm and wayland-protocols are right now)