IRC channel logs
2025-05-22.log
back to list of logs
<Tadhgmister>I thought the introduction fingerprint was based on the root git commit, if the mirror uses the same git tree it should be the same no? <identity>Lord_Devi: you could also start the repl (`guix repl`), import the module (`,use (guix channels)`), and evaluate the variable (`%default-channels`) <Lord_Devi>Oh. Yeah I read that the make-channel-introduction is a git commit. But I wasn't sure about the gpg fingerprint. I only have one channels.scm file active on my machine atm, in my ~/.config/guix. Which contains the codeberg url. This seems to be url used when I do a 'guix pull'. But it complains about an introduction being missing when I do so. However, I see a channels.scm in in guix-mirror/guix, <Lord_Devi>which does seem to have some introduction information as identity told me to look for. <vagrantc>suspect these sorts of issues will be coming up while the transition to codeberg is underway... <Lord_Devi>Thank you identity. The introduction I found in the mirror's 'guix/channels.scm' file seems to be working. Also going to play with your repl suggestion now to see what I can learn. <Tadhgmister>oh %guix-channel-introduction isn't exported? that is kind of annoying, you can use `(@@ (guix channels) %guix-channel-introduction)` as the introduction or `(channel-introduction %default-guix-channel)` if you `(use modules (guix channels))` <Lord_Devi>Oh nice. Going to save that suggestion and try that approach. Seems cleaner than what I did. <Tadhgmister>`(channel (inherit %default-guix-channel) (url "..."))` might also work and be easier to deal with <Tadhgmister>but I have no idea where the `inherit` syntax gets defined for the record types that part is magic to me so I am never sure if it is valid <Lord_Devi>Wow. Tadhgmister, that inherit %default-guix-channel, and then just changing the URL worked like a charm. So much simpler than what I did. <identity>Tadhgmister: inherit seems to be a feature of define-record-type* from (guix records) <Tadhgmister>yes but have you looked at guix/records.scm? As I said that part is magic to me <Tadhgmister>like the word 'inherit' doesn't appear anywhere in the definition of `define-record-type*` , only in `make-syntactic-constructor` which is used by it <Tadhgmister>sorry, * I have no idea _how_ the inherit notation gets defined, I do suppose I know _where_ it happens <icy-thought>I hope no one takes this the wrong way. Is there any reason why some of the famous packages are not in guix besides no interest in packaging them? Example, I just noticed that nerd fonts are not present in neither nonguix nor gnu guix repo <identity>icy-thought: most of the time, the answer is "nobody packaged it yet" (so go do that?) <icy-thought>And no, it personally does not matter if I don't have the package available. But I think that some people might not want to migrate because of missing famous packages <identity>1. somebody who needs/wants $software does not switch to $distro because $software is not packaged; 2. nobody packages $software for $distro; 3. goto 1 <afm-victoria>Someone suggested it was a Savannah infra issue yesterday... <Tadhgmister>ooooh now I want to have all my guix channels as git submodules of my dotfiles so I have a history of which commits I have been using <Tadhgmister>transmission depends on gtkmm for the gui output, is there an easy option to just not build the gui stuff or do I have to edit the build process figuring out how to tell Cmake to skip the gtk stuff and not try to test it etc <efraim>do we have a way to have the ld.so.cache not retain a reference to an input? <efraim>sneek: later tell apteryx I see now there's a 4.x cmake on core-packages-team. I don't know if there are breaking changes between 3.x and 4.x, but moving cmake-bootstrap to a newer 3.x I assume would help with the curl vs cmake-bootstrap build problem <cqst>what is the benefit of using home-bash-extension versus just setting things in home-bash-configuration? <cqst>the manual pushes you toward using home-bash-extension to set a PS1 prompt but examples online just set it in home-bash-configuration <efraim>it's useful if you add a service that wants to modify the home-bash-extension <ruther>cqst: there is jus one service instantiation with the config, whereas you can have many extensions. So you can split your config like that <identity>efraim: i think anubis only blocks you if you have 'Mozilla' in the user-agent string, so you could use a different browser or fiddle with your user-agent <civodul>efraim: Anubis works for me in IceCat (without LibreJS though) <civodul>speaking of which, i wonder if we should set it up for some of our services <civodul>it’s not great because it requires JS <efraim>interesting, so it might just be me <efraim>anyway, it works in qutebrowser and the firefox flatpak <civodul>anyone has experience setting it up on Guix System? <civodul>i think it would make sense for things like Cuirass, QA, etc. <efraim>although I do need to buy a new GPU, my nvidia gt 710 crashes too often <identity>i mean, it does not /really/ require JS, if you use some obscure, no-'mozilla'-in-user-agent-string browser, it lets you through, i think <civodul>ci.guix is being hammered, with like 10 requests per second for random builds (nginx rate limiting helps a bit) <civodul>identity: oh a user agent string without “Mozilla” goes through? <civodul>indeed; is this one using Anubis though? i get “Access denied” instead of the anime and progress bar <civodul>i don’t get this far, but that’s prolly because this browser goes through Tor <civodul>so i get blocked before i even reach the web site <cbaines>civodul, yay, I'm glad you've managed to reboot bayfront <cbaines>I've stopped the bffe and qa-frontpage, just in case that speeds up pulling and reconfiguring <civodul>the load is always very high on this machine <civodul>cbaines: i plan to release the bug-fix shepherd in a few days <civodul>in the meantime, i’ve stopped the ‘update-*’ services (timers) to be on the safe side <civodul>we’ll have to keep them off until we’ve booted into the new shepherd <notcqst>im trying to follow the example in the documentation to change the PS1 prompt with home config <ruther>notcqst: simple-service already returns a service, it goes directly to the services list, you do not instantiate (service ...) with it <bacs>packages.guix.gnu.org down again - 504 <bacs>oh dear - anubis spreading like a plague across the net. Even it's own website says it is a heavy handed approach. <bacs>the anubis website takes several seconds to load while displaying anime and progress bars <bacs>please avoid unless you *really* have a problem that can't be solved another way <identity>bacs: another way to solve this problem is to take down the websites that are being hammered, which is, uh. not the best solution either. you could also aim for a class action lawsuit, i would like to see you try (and possibly succeed?). or you could just use a browser that does not get blocked <identity>there is mostly no other way to deal with being DoS'ed by Amazon and friends, especially for a project of such scale (that is to say, not very big) <bacs>depends a lot on the content being served and your infra setup <bacs>is there an issue open for this with stats and such? <futurile>I don't think anyone is excited by this sort of thing - but I don't think the handful of volunteers who actually try and keep the infrastructure up have to demonstrate why they might implement this - we've all seen how difficult it is right now <civodul>a static web site can live with the AI scrapers (as long as bandwidth is gratis) <civodul>something backed by a database etc. (like QA and ci.guix) cannot <bacs>futurile: I'm just trying to understand the problem in some more detail so I can think about it. How many requests? How many unique IPs? Which AS numbers are involved etc. <identity>git blame is also a very expensive operation (if only we used a Real VCS) <identity>bacs: a Lot of requests, a Lot of (residential) IPs, and 0 of them look at /robots.txt <bacs>it's a problem a lot of FOSS sites are seeing and I'm wondering if we can find a better solution generally than "slap anubis in front of it" <bacs>residental? ok - that's different to the DDOSed by amazon thing <bacs>is the infrastructure documented anywhere publicly I can see? <bacs>civodul: I know about the general issue - trying to understand one specific case here <bacs>civodul: yes, I read drew's post <civodul>bacs: ah well, it’s no different, though of course a smaller scale than sr.ht <bacs>sr.ht and codeberg have been having a helluva time <bacs>mostly developers running the infra too - not too many infra people involved <bacs>if anyone gathers any stats for the guix side of things, or there's doco for the infra let me know <bacs>civodul: thanks - will have a read over coffee later <bacs>I'll ask drew if he has any stats I can poke at <civodul>cbaines: what’s the right certbot incantation to add a certificate for a sub-domain to an existing one? <civodul>adding that of git.guix.gnu.org to that of guix.gnu.org <cbaines>civodul, I usually use the certbot-configuration, just keep the first domain in the list the same and add the new domain <civodul>i did use --expand but it didn’t have the desired effect <civodul>of course that’s likely to 502 right now but that will change on Sunday :-) <noe>The move to codeberg is this sunday? Exciting! <csantosb>And I assume that there is no final user intervention; guix pulling is enough, %default-channels takes care of the rest <civodul>why would it be more reliable though? <efraim>its a read-only proxy for the git repos that has better uptime <efraim>that's the only announcement I've seen of it to date <identity>the emacs-minimal package uses substitute* to replace (among other things) the string "\"find\"" with a reference to /bin/find in the findutils package. the lisp/mpc.el file does not use "find" as an invocation of /bin/find, but as a literal string as a command to send to MPD; the substitution breaks mpc.el; the fix is to remove "lisp/mpc.el" from the list on line 209 (on the master branch) <efraim>I assume git.guix.gnu.org is live? <noe>civodul: guix describe from 2018 couldn’t have had that URL! I can’t believe the guix manual authors would make such an inconsistency! Unreadable! /j <noe>I will have to make a PR to fix it :P <icy-thought>just got back online. identity, well you are not wrong! I will try to package the missing packages that I want but cannot find and hopefully in the end I can reduce the needs of some (even though it might be 0.0001%) <icy-thought>I need a bouncer... because I am most likely missing some cool conversations <efraim>I've been using quassel for years <identity>icy-thought: there are ZNC and pounce shepherd service available <cdegroot>Quassel as well. Simple setup and the client is good enough for what I do with IRC <nikolar>i get guix pull: error: Git error: could not find appropriate mechanism for credentials <identity>/guix.git is not up yet (check back sunday) <nikolar>i was getting a 502 for that i think <ruther>identity: that goes to savannah and that is usually down, so the mirror is better <nikolar>but efraim also said it failed for him <noe>when you get 502, just try again and sometimes it works <ruther>when you get 502, just use the mirror :) why do it multiple times if you can just use the mirror and not care about it <icy-thought>question, what is the guix command for building the setup from the current project dir? Trying to figure out how to structure my setup <noe>ruther: because changing url does a full clone <icy-thought>In my nix config, I simply do nixos-rebuild switch --use-remote-sudo --flake .#(hostname) --impure <identity>noe: until it is cached, after that it keeps both in the cache <civodul>maybe i should send another message to info-guix + guix-devel about the May 25th change; what do people think? <icy-thought>Ruther, if I have a modular setup with files in a given dir. How do I build that setup ? <ruther>icy-thought: you give guix system command path to the system config <noe>“guix system reconfigure <path-to-config.scm>” <noe>same thing with guix home by the way <icy-thought>I wonder if guix accepts an environment var for a dir to automate the path-to-config <icy-thought>Oh ok! I guess I'll just make a function somewhere that does both in one go (so that I do not forget) <noe>“cd $CONFIG_DIR && guix system reconfigure config.scm”? <ruther>icy-thought: no, because guix system reconfigure needs a path as required argument, there is no default path <identity>if you are going to be writing modules that you import in the config.scm, then add -L . to add cwd to Guile's module load path <icy-thought>Hmmm I wonder how I should approach this now that there are no flakes <identity>noe: or guix system reconfigure "$CONFIG_DIR/config.scm" <identity>icy-thought: you can still pin channels fyi, read (info "(guix) Replicating Guix") <icy-thought>I was thinking more of, having a seperate hosts/hostname/config.scm and then having guix system recognize that <icy-thought>Also, TIL!! That is even better!! Now I truely don't need flakes anymore xD <futurile>civodul: yeah, another email sounds good - you know people might miss it <civodul>futurile: yeah; ah news on ‘guix pull’, sure, why not? <icy-thought>Question, does `(service service-name-service-type)` mean enable service? I am thinking of utilizing services like I have with options in my nix config and I am somewhat lost on how to enable the services <ruther>icy-thought: that means to add a service to used services, so it will start having effect on your system. So yes, it is sort of like enable option in nixos services <identity>icy-thought: 'service' is a procedure that accepts a TYPE argument and returns a new service of TYPE, that you then put in your services list; it also optionally accepts a configuration for the service as a second argument <icy-thought>I noticed that! It does remind me of nixos options that I am currently using <icy-thought>I will document all of this after I am done and publish it somewhere <GNUtoo>hi, is there a way to use locales in a guix shell container? <civodul>GNUtoo: you can “export LC_ALL=C.UTF-8”; if you need other locales, you can bring in the ‘glibc-locales’ package <cbaines>civodul, I've just reconfigured bayfront and I think the update- timers are back running <cbaines>does something need doing to disable them? <civodul>cbaines: i’ve stopped them now, with ~ludo/stop-web-timers.sh <identity>snikta: the (unofficial) policy seems to leave them as-is until somebody who cares comes around and fixes them <identity>the real reason to learn sed is so you can correct your messages on IRC <futurile>snikta: if it build previously, there should be a substitute for it that you can use? (presumably you're trying to build something else where it's an input) <QUL>Hi, I am new to GNU Guix and installed it in a VM and wondered why is it this slow? What are the technical reasons for it or is there some fix I am not aware of? <ieure>QUL, What specific thing is slow? <snikta>Thanks! The development version of the reference manual just gave me an 404 earlier. My plan was to use hatch in guix shell. What I actually want is to use uv, but that might be too much work. I think I'll just expose the uv/hatch on the host system. <QUL>@ieure When I am trying to "update the channels". I am not sure I used the right words. <identity>QUL: it is because it has to fetch a pretty large git repo, it is cached afterwards <ruther>QUL: the initial pull is significanty slower than subsequent ones as the whole repo has to be fetched and authenticated. Later cached version of the repo will be used <QUL>Thanks! Good to know that it will not be a constant thing. But wouldn't it be more convinient to guix pull during the instalation or for example installing a repo that was up to date during the building of the ISO so the end user would not need to pull everything at once but only new things since the build of the iso? <ruther>QUL: certainly it would. But there is no mechanism to copy over the checkout in the cache of the target system, at least not yet. <ruther>if there isn't such mechanism, even if you pull in the iso, the first pull and reconfigure will be slow <QUL>ruther: Thank you for clarifying! Hopefully there would be a mechanism some day. <snikta>My experience is that guix pull doesn't work with the default repository. It's too slow or gives an 502. I believe the GNU Savannah repos are seriously overloaded. cgit is also unusable. <QUL>Oh and another thing. Would'nt GNU Guix System when running on Hurd just be basicly the GNU System? Since it uses even gnu packages for the kernel and the init system? I am asking not because I wan't to erase the effort that the GUIX Team has done but simply beacause in many GNU Materials it reffers to it's goal the create the GNU System. <GNUtoo>civodul: thanks, but locale -a doesn't show them <identity>QUL: it is a GNU system either way, be it GNU/Linux or GNU/Hurd <GNUtoo>civodul: I see only C and POSIX, and even if I try something like that 'GUIX_LOCPATH=/gnu/store/mnb6575q98c13xkfwfn4i5x9r9fka6z8-profile/lib/locale/' and 'export GUIX_LOCPATH', locale -a still shows only C and POSIX <QUL>identity: Ah so there would not be such a thing as THE GNU System, ok got it. But what are the requirements than to be a GNU System I didn <ruther>GNUtoo: you will need to build glibc with locale you want using make-glibc-utf8-locales <QUL>'t found it in the docs is it just to use the GNU userland? <identity>QUL: yes, the userland is the important part <QUL>identity: Thank you for explaining! <GNUtoo>QUL: your question was discussed a lot in the GNU mailing list, and at the end if I remember well it was decided not to make a distribution more official than others <GNUtoo>*in one of the GNU mailing lists <GNUtoo>(There are also other distributions that are fine too like Trisquel, etc) <civodul>GNUtoo: ‘locale -a’ doesn’t know it, but C.UTF-8 is built-in :-) <QUL>GNUtoo: Thanks! Yeah it makes sense. As long as a distro is following the FSDG it is fine. no need to promote one over the other officially. <GNUtoo>oh ok, the problem I have is that a haunt website I'm working on doesn't work in guix shell and I very strongly suspect UTF-8 related issues because it fails with that: "ERROR: In procedure substring:", "Value out of range 65 to< 115: 117" <identity>can you try setting the locale to a non-UTF8 one outside the container? <identity>and testing if it fails with that same error outside of the container <GNUtoo>there are no errors outside of the container <GNUtoo>And I also used guix shell -C at the root of the git directory, so it should find files and so on <identity>GNUtoo: then it is highly unlikely that it is a locale error! no idea what it actually is though <GNUtoo>ACTION will try to write a smaller test case <GNUtoo>thanks a lot for the help so far <GNUtoo>There are 3 markdown files that cause an issue, I removed 2 of them and in the last one I manage to nail it down to the ™ (Trademark character) character. If I remove that it works fine. <ieure>Definitely points to some kind of character encoding issue. <GNUtoo>Another issue is the '…' (3 dots) characters in the markdown version of the GFDL. <ieure>Yes, any non-ASCII character will be a problem. <GNUtoo>I have '(fluid-set! %default-port-encoding "UTF-8") <GNUtoo>I've made a test case and without (fluid-set! %default-port-encoding "UTF-8") it works, strange... <GNUtoo>(though the character is converted to ???) <GNUtoo>(fluid-set! %default-port-encoding #f) makes it work... <GNUtoo>I'm unsure what that does under the hood but if (fluid-set! %default-port-encoding #f) auto-detects the encoding and that for some reasons (fluid-set! %default-port-encoding "UTF-8") isn't able to use the builtin locales, it could explain the issue <Tadhgmister>when using `--target=` does it not set the `TARGET` environement variable to the triplet? <Tadhgmister>I can't cross compile `libunwind` and I think I've narrowed it down to it is expecting a TARGET environment variable which is missing <ruther>Tadhgmister: no, it does not set env var TARGET <Tadhgmister>ok.... does '$ENV{TARGET}' in a `CMakeLists.txt` refer to something other than environment variable? <Tadhgmister>ok weird, I guess I now get to go figure out why it isn't using that CMakeLists.txt cause if `TARGET` isn't set it should be crashing there <GNUtoo>'(setlocale LC_ALL "en_US.utf8")' fails in 'guix shell -C guile -- guile' but doesn't fail in 'guile' <civodul>GNUtoo: yes; as i wrote, C.UTF-8 is builtin, but for everything else, you need the ‘glibc-locales’ package <GNUtoo>ok, I'll use that then as even with glibc-locales for some reasons it didn't work <Tadhgmister>libunwind has a few things in cmake files that deal with cross compiling and the guix package currently just uses gnu-build-system so it ignores the cmake stuff, if I wanted to update it upstream would it be preferable to switch it to cmake build system or reimplement some of the logic from it with the simpler gnu build? <Tadhgmister>like would a patch that changes a package from gnu-build-system to cmake-build-system be frowned upon if it allows the package to be cross compiled? <g_bor>civodul: you also happen to know why it might not work even with glibc-locales? <g_bor>Tadhgmister: I think switching to an upstream well maintained build system is ok. The only question is if we need the package somehow to bootstrap the cmake build system, in that case we might need to retain a version that allows us to do this. (But I think this would still fly in that case.) <Tadhgmister>ok ty, when I test it in the guix repo I will see if it affects any bootstrap stuff. It might just be a version thing and the newer version that I was checking uses cmake and the one in our repo didn't <dariqq>hello, i am trying to build a custom gcc but get errors with libstdc++ . I think this might be a version mismatch with my gcc and libstdc++ (which is always 11) <GNUtoo>With Guix 1.4.0 I managed to make guile swith to en_US.UTF-8 by doing that inside bash inside the guix shell container GUIX_LOCPATH=/gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33/lib/locale, so I might be able to use something else than C.UTF-8 (which doesn't work on Guix 1.4.0 anyway) <GNUtoo>Thanks a lot for the help, at the end I think I'll manage to do what I need <g_bor>GNUtoo: you might be able to do --preserve if you have the variable in the env where you ar launching from, like --preserve="^GUIX_LOCPATH$", but this did not work for me for some reason <ruther>it did not work because the path is not present in the container <dariqq>hmm even after replacing the libstdc++ headers the old ones are still available and included from somewhere <g_bor>ruther: actually it almost works, the preserve injects a path to glibc-utf8-locales, but installing glibc-locales does not provide this path <g_bor>when you do this: guix shell --preserve="^GUIX_LOCPATH$" -C glibc-locales guile coreutils -- env <g_bor>GUIX_LOCPATH=/home/gabriel/.guix-profile/lib/locale:/gnu/store/pxnrbpc30m5qsr8jqx86a9m42mzn25ni-glibc-utf8-locales-2.39/lib/locale <ruther>yes, and those paths are not going to be in the container as I said earlier <ruther>it is pointless preserving GUIX_LOCPATH unless you decided to expose those paths <ruther>and even then I see no point, why don't you use the proper mechanism - search paths in the profile? <ruther>GUIX_LOCPATH is search path provided by glibc <g_bor>ruther: Fine for me, I was jsut wondering where this comes from at all, the original environment variable does not contain this, and should the appended vaule contain the glibc-locales version it would work. <g_bor>Maybe you can enlighten me how it ends up there <g_bor>also, as far as I can see the working solution for GNUtoo requires manual tweaking the container after it is created to make it work, but I might be missing something <ruther>the working solution is to put glibc in the shell for the search path and use make-glibc-utf8-locales if they want other locales than C.UTF8 <ruther>as for why the preserve adds a path to the locpath, that is because the `guix` executable contains setenv GUIX_LOCPATH, then this env var leaks to the profile system, and preserve keeps it in the environment <ruther>I would say it's sort of a bug, but hard one to solve <GNUtoo>g_bor: yes I did that and it worked on Guix 1.4.0 <g_bor>ruther: thanks for the explanation, much appreciated <g_bor>ok, now this is very clear, how I could make this work by adding the glibc-locales is this: <g_bor>guix shell -C glibc-locales guile glibc -- guile <g_bor>I was missing the glibc for the search path as you mentioned ruther <g_bor>Do you happen to have any tips on discovering things like this? <g_bor>(Finding out that the locales are missing was simple, but finding where is the search path is provided somehow elided me) <ruther>g_bor: I grep the guix source for looking for search paths <Tadhgmister>when I do `guix build libunwind --check` it just applies grafts from a `libunwind-1.6.2` that was substituted and calls it a day, how do I also rebuild that one without removing it from my store and saying --no-substitutes? <dariqq>nvm i had a mistake (replaced in inputs vs native-inputs) and I did not actully replace the headers. Lets hope this was the issue <Tadhgmister>nvm `--no-grafts` is doing it, it listed a long string of things that would need to be rebuilt so I got confused <identity>are there any style guidelines on using #:export in define-module vs define-public? <gabber>the "Couldn't find proper `ls' command" emacs-tramp error seems like a Guix specific issue many stumble upon. should there be a hint in the docs on how to resolve it or should we fix the package? <dariqq>gabber: checkout tramp-remote-path and specifically the tramp-own-remote-path option <gabber>i've found some references in the issue tracker and the help-guix mailing list, but i guess there could be a more "official" way to document how to tackle the issue <ieure>Haven't had that issue, but have experienced similar ones with opening shells on remote systems with my emacs-nssh package. <ieure>It breaks because it wants to use the value of shell-file-name to run the shell, which points to the store item for the local host. <ieure>But is the same with ex. using bash from Homebrew and trying to log into a Debian box. <dariqq>gabber: info '(tramp) Remote programs' <dariqq>yay, i got a different error than before now, i feel like i am making progress <gabber>> TRAMP queries the remote host with ‘getconf PATH’ <gabber>which on my Guix system returns "/bin:/usr/bin" <civodul>g_bor, GNUtoo: you need to set GUIX_LOCPATH=$GUIX_ENVIRONMENT/lib/locale <GNUtoo>civodul: thanks that works too. Doing it right also enabled me to find a bug in a script.