IRC channel logs
2025-09-01.log
back to list of logs
<RavenJoad>Is it known that ci.guix.gnu.org is getting HSTS errors? Firefox is claiming the domain's certificate expired today. <RavenJoad>Ok. problem seems to be disappearing on my end. I guess certificates just needed to propagate or something. <euouae>Hello, the 1.4 installer doesn't come with the codeberg channel, I tried to switch to it, but what should the introduction be? <euouae>What would make sense is that it's the same as the savannah one, but I wasn't sure how to view that information <euouae>The initial commit for the guix repo is 207cba8114d354737b231e510d6110ea2a42e07b but it's unsigned <untrusem>euouae: isn't just you need to change url to codeberg, I think introduction is same <euouae>untrusem: it complains that introduction is missing <euouae>I created a ~/.config/channels.scm with the details <euouae>I used the bare-bones.scm configuration <euouae>Nice, thank you. I wonder if `guix describe` can net me that information <euouae>Does anyone know when a version after 1.40 will be released for .iso? <Tadhgmister>euouae I mean you can build your own installer iso pretty easily or just update your system after installing with the 1.40 iso <Tadhgmister>see 3.9 Building the Installation Image in the manual <euouae>but there's an issue that %base-packages has been modified between 1.40 and later <euouae>so it's a bit confusing now -- you have to add nss-certs to packages to update and then you can remove it since it's default <Tadhgmister>oh and the latest installer image doesn't account for that does it? ok you are asking about the installer os being updated to reflect that not about a new iso being published to the website <euouae>I'm wondering if there's some other reason that 1.40 is kept? Also, since the codeberg migration, another .iso version with codeberg as default would be good to have, no? <euouae>Right now it's still savannah on 1.40 <Tadhgmister>no the templates in the current version do drop nss-certs. so it is just a matter of pushing to the website <euouae>Yup, I'm just suggesting that it'd be a good idea to push now <Tadhgmister>is the website being updated with a newer iso relevant to you or just pointing it out as probably important? I have to assume it is on someones radar but have no direct contact with anyone relevant <euouae>both because of the new %base-packages but also because of codeberg -- unless there's reason for the opposite <euouae>fair enough, I'll ping about this some time later again, or maybe create an issue on codeberg <euouae>ACTION goes back to watching podcast and eating <Tadhgmister>if there is no such issue on codeberg making one is probably the right approach, give it a state that can be assigned to someone to deal with. <cancername>How and why is /var/guix/profiles/system-108-link/boot trying to link /run/current-system to a nonexistant /var/guix/profiles/system-107-link ? I "fixed" it with (symlink (canonicalize-path "/var/guix/profiles/system-108-link") "/var/guix/profiles/system-107-link") , but how did it get to this state in the first place? <vntsuyo>so I was trying to package a C++ library and use it to package something else <vntsuyo>the library was able to build fine but when I added it as an input for a different package, pkg-config wasn't able to find it <vntsuyo>i had the same issue when I was trying to bump wlroots to 0.19 <simendsjo>Any https://toys.whereis.social/ developers here? I notice the search doesn't match some packages from my channel anymore. E.g. a search for jetbrains-rider, jetbrains or rider doesn't show the jetbrains-rider package. <unwox>simendsjo: when did you add this package? <simendsjo>unwox: Around 12 months ago ;) It has been showing at an earlier date, but I have no idea when it disappeared. Other packages from my channel lists, but not these jetbrains-X packages. Might be more too, but I have enough packages that going through them is very tedious. <cbaines>I'm getting this as the hash in the signature of a narinfo from the data service, and I have no idea why (hash sha256 "VïµÐåÏû:oïGPùFQòÑâSQã+IòÿÊúkþMäâ") <cbaines>it's even missing the # # that surround the hash normally, so I have no idea how it could be this broken <mozul>Hello everyone, I am new here and am not very knowledgable either of IRC nor guix, please be patient with me ^_^. I am currently trying to use guix in an HPC environment. I manage to create a guix profile with wich I can run 'guix shell --pure' and build/run my program on the fronal node. But when I try to submit a slurm script, I got the error : <mozul>"guix shell: error: terminal-window-size: Unknown error 524". Is it something I can solve on my side or should I ask something to the administrator of the cluster ? <identity>something is probably interpreting binary data as text… <PotentialUser-7>I have finally installed guix! Also configured hyprland and waybar, albeit very basically <identity>mozul: it seems the TIOCGWINSZ ioctl is returning an error, you probably should ask the sysadmin about that <civodul>cbaines: sounds like a déjà vu, an encoding issue <mozul>Ok thanks. I will do that. And thanks for the tool... I hope I will get better at using it over time since it really gives a lot of possibility. Have a nice day everyone. <unwox>simendsjo: possibly because of channel dependencies. toys does not always handle those correctly <identity>PotentialUser-7: you should try configuring vanilla Emacs the way you like it, it will teach you a lot about Emacs and may leave you with a configuration that you like more; if you, for some reason, do not wish to do that, then i would expect following instructions in the doom emacs repository to work without any major problems <cbaines>civodul, encoding, like some glibc locales issue, or something else? <PotentialUser-7>identity doom emacs does it's own package management which I think is a big no no in the guix world right? <Rutherther>I mean the only difference between Guix System and other systems in regards to stuff like Doom Emacs is that you might not have the development dependencies installed, ie. for the vterm library or for tree sitter grammars. So you can either install those through guix or somehow give emacs gcc-toolchain <PotentialUser-7>Frankly anything, I am not yet educated enough to judge what is the best way <Rutherther>PotentialUser-7: philosophically some might treat is as 'big no no', but it is not technically infeasible. Guix doesn't stop you from using other package managers. The only thing that you have to take into account is that you don't have FHS on Guix System. So if you use a package manager that isn't capable of providing all dependencies, it might cause issues. One issue you can face is downloading random binaries, ie. if you use lsp-mode and leave it... <identity>PotentialUser-7: i myself configure Emacs by installing the Emacs packages into my home profile and symlinking my init.el into place with ‘home-xdg-configuration-files-service-type’ <untrusem>I also just install emacs packages using guix home and configure them using use-package <untrusem>I know someone has made emacs into a package <Rutherther>PotentialUser-7: this is where the two approaches can clash, doom emacs expects to be able to modify the files, so you might have hard time modifying doom emacs to work with guix. It's usually not worth it either I would say. Though there are people who do it at least for Nix and if it works with Nix, it has to with Guix I would say. See https://github.com/marienz/nix-doom-emacs-unstraightened for example. But it would be a lot of work <identity>oh, right, putting your emacs configuration into a package <Rutherther>PotentialUser-7: but what doesn't work exactly? Send the errors <simendsjo>PotentialUser-7: I'm using Dooms package manager without any issues. It downloads all dependencies. If it use binary dependencies that will cause issues, but otherwise it's no problem. I need some hacks to load things from the guix profile rather than the supplied binaries, e.g. epdfinfo and vterm-module.so. <untrusem>I installed doomemacs without guix, manually it works fine <Rutherther>PotentialUser-7: you somehow identified 'it doesn't work', so just send what led to that identification for starters <identity>PotentialUser-7: are you sure you installed it correctly? <PotentialUser-7>the error in the bottom "screen" basically says "error in doom module: ... evil-bindings.el" <PotentialUser-7>identityI installed emacs, cloned doom into .config/emacs and ran doom install <Rutherther>PotentialUser-7: then open the messages / warnings buffer and look at what it says <bdju>Can anyone else running qutebrowser load up https://tetr.io/ and tell me if you get an error in the bottom right about sound effects not being loaded? I only started having it recently. <cbaines>maybe it is encoding related, but the issue seems to only occur for some hash values <fnat>I'm trying to update Pandoc to 3.7.0.2. I've fetched the repository from upstream, checked out that particular tag 3.7.0.2, then run 'guix hash -rx .', as usual? But the hash won't match when I get to build the package. <fnat>Perhaps something to do with the haskell-build-system? <identity>fnat: how would the build-system of a package impact the package source's hash? <sibl>hi all, I am trying to update Rakudo on Guix, using the current definition the build fails, I modified slightly the file: https://termbin.com/htcd, but since I am a beginner at Guix, I really dont know how to make this "clean" or how to help in a better way, so far with that modified version, moarvm|nqp|rakudo are at a much newer version, zef on the other hand I couldnt figure out it yet <identity>sibl: you could submit a PR and mark it as WIP, somebody should help you with doing whatever else is required <sibl>alright I will try that, thanks ! <fnat>identity: Hm... IDK, I guess it can't then? <identity>fnat: the source fetch and package build are different derivations, package build can not have any impact on the output (and thus the hash) of the source fetch <fnat>Can you think of anything that might be getting in the way here - i.e. that I might be forgetting or doing wrong? I usually checkout the tag that I want to compute the hash of and then run 'guix hash -rx .'... <fnat>I triple-checked. The hash I get from the Git checkout is different from the hash of the tarball. xz something something? PEBCAK also a possibility here. <sibl>identity: I tried to fork the Guix repo to do a pr, but codeberg failed to fork and show me an error message ;-; "files already exist, contact an Admin", but on my profile there is no fork/repo <sibl>I guess filling an issue instead is a bad idea ? <Rutherther>sibl: it's not a bad idea, but issue to codeberg, not to guix repo. Also maybe it will just take some time to appear <Rutherther>sibl: anyway having a fork is not a necessity for contributing, see the forgejo agit workflow for another way to contribute <Franciman>hi, i don't understand the new way to package rust things <Rutherther>Franciman: did you go over the cookbook _tutorial_? <sibl>I will give a try to the "agit workflow" thanks ! <sibl>Rutherther: alright I tried this `git push origin HEAD -o topic="trying to update Rakudo to a newer version"` but I get a permission denied from codeberg, I am not used to that kind of workflow xD <Rutherther>sibl: you forgot to specify the ref you're pushing to <sibl>should it be HEAD:HEAD ? <fnat>I checked Pandoc's hash for tag 2.9.12 - the version currently in Guix. The repository hash also doesn't match with what's in Guix. I guess the hash should be taken from the unpacked tarball then. And that there's something in the tarball generation process that alter the repo content somehow. <fnat>At least it's not a problem specific to 3.7.0.2. <podiki>for agit it is git push origin HEAD:refs/for/master -o.... <civodul>so there’s ‘guix gc’ (without arguments) running on bayfront since at least 8h <Rutherther>did it get stuck or are there so many things to remove? <cbaines>civodul, that's somewhat expected I think given the large number of small items in the store <civodul>but it’s still using mcron so i can’t easily get details <cbaines>I don't think there are any ports involved <cbaines>I've got a more minimal reproducer now: <cbaines>(canonical-sexp->sexp (string->canonical-sexp "#56efb5d0e5cffb3a6fef4750f94651f2d1e25351e32b49f2ffcafa6bfe4de4e2#")) <cbaines>or (canonical-sexp->string (string->canonical-sexp "#56efb5d0e5cffb3a6fef4750f94651f2d1e25351e32b49f2ffcafa6bfe4de4e2#")) <civodul>certainly you’re doing something with the resulting string <cbaines>civodul, I'm still very confused, depending on the hash you put in, you get different types back <cbaines>e.g. this returns a bytevector (canonical-sexp->sexp (string->canonical-sexp "#0e0fcd55350dc6f115031292db2e53053f2975e283fcb7232b6f0741688bf4de#")) <cbaines>but this returns a symbol (that guile-gcrypt makes from a string): (canonical-sexp->sexp (string->canonical-sexp "#56efb5d0e5cffb3a6fef4750f94651f2d1e25351e32b49f2ffcafa6bfe4de4e2#")) <cbaines>the string->pointer and pointer->string calls in guile-gcrypt specify the encoding <cbaines>assuming I'm understanding these canonical sexp's, this also doesn't work, so maybe I can follow the bytes with this smaller example (canonical-sexp->string (string->canonical-sexp "#56#")) <cbaines>unfortunately I've run out of time today <civodul>cbaines: let’s continue on the bug tracker, but perhaps give more context as to the higher-level problem that this issue brings <civodul>blog post about to be published (when server is ready…) <timmy>does anyone know if there is a guide for getting xdg-desktop-portal stuff working with sway and guix home? <Rutherther>timmy: I am not aware of such tutorial, but it should be basically just installing the xdg-desktop-portal & an implementation and then not forgetting to relog to source the environment variables pointing to the implementations directory <Rutherther>(and then the rest is same as for other package managers) <timmy>Rutherther: when you say relog, you're talking about running dbus-update-activation-environment? are you running xdg-desktop-portal manually or how is it typically set up if it's installed with through guix home? <Rutherther>timmy: no, I literally mean you log out and log back in, to get the "XDG_DESKTOP_PORTAL_DIR" environment variable. Running dbus-update-activation-environment is definitely a necessity, though that has nothing to do with Guix, it's the same for any package manager <Rutherther>timmy: I do not run it manually, it should not normally be ran manually as it is a dbus service, started by dbus when something requests it <timmy>Rutherther: what sets XDG_DESKTOP_PORTAL_DIR? I don't see it set on my machine <Rutherther>the etc/profile of guix-home profile after you install both xdg-desktop-portal & an implementation as I provided in the required steps <timmy>Rutherther: ok thanks. I think the issue is my guix home-bash/zsh-service-type is not sourcing the guix home etc profile <Rutherther>how are you using guix home then if you don't source the file? You wouldn't even get PATH to the profile to execute executables under it <podiki>nckx: if you are about, can you release my info-guix message about the security update? <Rutherther>the zsh service type should add "source ~/.profile" inside ~/.config/zsh/.zprofile <timmy>Rutherther: thanks again i'm going to reboot to see if that cleans things up <Rutherther>there isn't anything that reboot would clean up in respect to this compared to a relog <timmy>Rutherther: am I supposed to manually set XDG_CURRENT_DESKTOP=sway ? <identity>timmy: i would expect the default sway configuration to do that, do you use ‘home-sway-service’? <Rutherther>timmy: yeah, if you don't use a display manager that would set it. But note that you need to set it in dbus (you do that with the dbus-update-activation-environment), it doesn't matter if you have it set in sway environmenft <Rutherther>identity: no, sway doesn't do that and they are against doing that (they have an issue on that) <timmy>ah great looks like i got it working after setting that manually thanks again! <identity>Rutherther: huh, the arch wiki says their (arch's) package provides a drop in config file for that <Rutherther>identity: sure, but that's Arch package thing, not sway thing <identity>yeah, i was slightly confused by the wording of the wiki <timmy>heh and now audio wasn't working. gemini gave me the sage advice of rm -r ~/.local/state/wireplumber/ && killlall wireplumber. after that the actual hardware devices starting showing up in pavucontrol. surprised that worked <Rutherther>hako: when opening a PR for rust-crates.scm, should the one opening the PR resolve conflicts in case they come up, or should the one merging it do that? <civodul>bayfront is still GC’ing, so no security advisory 🤷 <Rutherther>civodul: hi, may I ask, how are /var/guix/profiles/per-user/$USER folders created on foreign distros for respective users? <Rutherther>like the guix-daemon does that and it does that thanks to having CAP_CHOWN, or what exactly gets this capability? <civodul>guix-daemon is granted CAP_CHOWN, so it can create those directories on behalf of users <civodul>the declarative solution in Guix System is nicer, but obviously not available on other distros <euouae>Hello I was looking into installing Guix from 1.40 bare-bones.scm <euouae>On the other hand using codeberg directly I'm told it might be a stale mirror. What is the way to salvage this? <Rutherther>euouae: it might be a stale mirror according to the logic in guix 1.4.0. But it isn't one. So there's no issue with that <euouae>I know, but how do I switch to git.guix.gnu.org? <euouae>I'm assuming that's the download point; tomorrow codeberg might go offline or guix might move away from it <Rutherther>euouae: I don't think you can, it just seems guix 1.4.0 didn't support redirects for whatever reason. You first have to pull and only then use the redirect url <Rutherther>euouae: for the record I don't think your concern makes sense, bordeaux could go offline as well and yes, guix might move away, but the same ways as with savannah it would definitely be announced and kept as a mirror for some time, like a year <Rutherther>probably the version of guile-git didn't support redirects, but I don't have time to investigate now <euouae>Rutherther: it's a standard method to have a link that points to several mirrors <Rutherther>git.guix.gnu.org doesn't point to several mirrors, at least not at the moment <euouae>But that is not the point – the guix.gnu.org subdomain is controlled by the project <euouae>It is a subtle point, it's not very important, but there's breakage in 1.40 is what I guess my biggest concern is. <Rutherther>there have already been several breakages in 1.4.0, you cannot really pull without substitutes for example, as some sources have dissapeared. The solution to that is to make a new release and one will be made later this year <euouae>Great, I'm just documenting some of the issues in a codeberg Issue <FuncProgLinux>Speaking of that, the guile-bash package source seems to be gone. Both the sr.ht and the notabug one :( <civodul>the workaround is easy (pass the codeberg.org URL), but still <FuncProgLinux>I know I've nagged a lot with this and I have barely contributed to the system. <FuncProgLinux>But is there a geek in charge of the mate desktop? There are a few missing bits <FuncProgLinux>and pieces and I would like to help with that. Apologies if this is spam for <FuncProgLinux>I'm kind of jealous that XFCE gets so much more attention - ‸ - <kratacoa>FuncProgLinux: There doesn't seem to be a team in guix/etc/teams.scm <kratacoa>judging by the commits the main person that signs off the commits there is the same one who is responsible for xfce <kratacoa>and the main contributors over the past 4 years was a certain Andy Tai <FuncProgLinux>These people are still active? I might wait until they come-up online, I saw a merge request last week regarding polkit in this desktop. <Deltafire>oh wow, this is a lot of packages being downloaded <podiki>the world-rebuild branch was just merged <podiki>subs should be available (on x86-64 especially) already, but might want to wait a bit if you are seeing local builds needed and don't want to <podiki>it is like that (the web front end) often, unfortunately