IRC channel logs
2025-08-21.log
back to list of logs
<jlicht>IWBC if inferiors (and I guess time-machines?) could refer to commits or pull requests opened via the AGit workflow <jlicht>as they currently can't seem to be used directly if a particular commit is not (also) part of a 'normal' branch yet <jlicht>Not sure if this is a forgejo, guile-git, libgit or guix thing ;) <vntsuyo>what's the world-rebuild branch on upstream? <untrusem>I am getting ssh-askpass error for a few days, if I try to use ssh-add from emacs, does something changed in openssh? error - https://bpa.st/DTIQ <untrusem>ok it seems its related to display server <untrusem>I found out that x11-ssh-askpass for responsible for this, so I installed the wayland equivalent for this <Deltafire>untrusem: there's also pinentry-gnome3, if you're running a gnome desktop <hugohugo>How can I get a /etc/ssl/certs/ca-certificates.crt in a 'guix shell -C'? The file is provided by ca-certificate-bundle, but that does not seem to be a package itself <hugohugo>I'd like this command to work: guix shell -C python python-requests -- python3 -c "import requests" <hugohugo>That now errors out because it tries to read /etc/ssl/certs/ca-certificates.crt <Rutherther>hugohugo: yes, it is not a package, it is made by a shell hook. Adding nss-hooks to the shell will add it. You might also want to add curl for the search paths SSL_CERT_DIR and SSL_CERT_FILE, or you can set them manually of course <hugohugo>Thanks Rutherther, this indeed works: guix shell nss-certs curl -C python python-requests -- python3 -c "import requests" <hugohugo>Shouldn't nss-certs and curl then be propagated-inputs to python-requests? Since it is only possible to import the package if these packages are also available <hugohugo>Although adding curl as a dependency sounds like the wrong way to solve this problem <Rutherther>hugohugo: I think not not, as adding curl is just a hack, if anything, requests could get a search path to ssl dirs same way curl does. Adding nss-certs is one way to create ca certs, but not the only way, there can be other packages providing info for building the ca-certificates.crt file. So adding that also doesn't make sense to me <hugohugo>OK that makes sense. Part of the charm of Guix is that no-one is 'forced' to use a specific set of certificates. <hugohugo>And in package definitions we should just put nss-certs-for-test in native-inputs everywhere <hako>I'm going to merge rust-team soon :) <untrusem>yay! I know the pain of trying to use inferior 🥲 <noe>They can be reopened by changing the destination branch I think, but maybe we should avoid deleting branches before making sure all related PRs are closed? <andreas-e>noe: Policy says branches should be closed upon merge. But one could maybe pay attention - how does one get the pull requests for a branch? <andreas-e>Maybe the real question is why they were for the branch in the first place; should pull requests not be against master in any case? <noe>What if one wants to contribute to a team’s work? For example rust 88 by efraim (#989) <andreas-e>Your link is useful, because it shows which pull requests were closed by my closing the branch; but how do I reopen them now? Can I do it. <noe>I would change the target branch first by clicking edit <andreas-e>Good question. Personally I have always marked my pull requests as for the master branch, and then they get tagged for a team. <Rutherther>andreas-e: there is work that is not applicable to master branch, but only to team's branch, like if it depends on newer dependencies available only on the given team branch. Or work that fits on the branch for example causing world rebuilds... <Rutherther>andreas-e: but if you start from the team branch, marking them for master is going to make a mess <andreas-e>Rutherther: Yes, but then it is normally also on the branch before the merge; well, this is not a law of nature. <andreas-e>Ah, I had not seen that it also allowed me to change the branch and not only the title. <Rutherther>andreas-e: but the branch exists for some time, someone had to create it and get it to mergeable state... so there is naturally a window where you can submit PRs so that it can get on the branch before the merge <noe>same error… Probably a Forgejo bug <andreas-e>Maybe it does not apply anymore? But it should, because the latest rust-team is almost the same as master. <Rutherther>since rust-team has been rebased prior to merge none of the PRs can apply cleanly because the commit histories diverge by a lot. I do not know if this is the cause of the issue though. <andreas-e>To record the numbers from your useful link: 1224, 803, 503, 989, 1653 <noe>It gives the 409 error, maybe forgejo checks the previous branch before changing, but since it doesn’t exist treats the request as invalid? <andreas-e>Rutherther: Maybe, if people have not rebased close to the merge. <civodul>uh, another day, another set of channels broken due to (gnu packages crates-io) having disappeared :-/ <andreas-e>The authors get a message and can resubmit, right? But this is not a good process. <noe>the message being “andreas-e closed your pull request” <andreas-e>I think we need to change the policy. But that means more work for the teams. Or we decide to just keep the team branches open indefinitely. <civodul>hako: congrats on the rust-team merge, quite a milestone! <andreas-e>noe: Yes, because I deleted the branch; at least the culprit is identified :) <noe>andreas-e, maybe you can try recreating the branch to move the PRs? <andreas-e>There is a bit of tension between managing the git repo and codeberg. <Rutherther>andreas-e: as you can see in the number of commits none of the authors have rebased close to merge <noe>I mean it was rebased yesterday, right? <Rutherther>I would expect it to be rebased prior to the merge on the latest master commit, so today, as team branches are not merged with merge commits <andreas-e>noe: I could rebase on rust-team, which equals master; now it show 585 commits. <andreas-e>Strangely, I still cannot rebase on master, although the branch is exactly the same. <noe>I can try with my pr <civodul>the good news with rust-team is that we went from 35k to 29k packages! <andreas-e>Well, they actually rebase themselves automatically. One just needs to reopen them. <andreas-e>civodul: Well, the bad news is that we went from 4% broken packages to 5% :) <andreas-e>noe, Rutherther: All branches are reopened. Now you probably have to see how to get rid of the 584 spurious commits. <andreas-e>civodul: Somehow we should invite channel maintainers to follow more closely the Guix project. And we should provide the information. <noe>andreas-e, great, I’ll just rebase on master and force push <noe>all good now, after applying my patch on master and force pushing I was able to change the target branch <andreas-e>noe: Interesting! But this needs to be done by the submitter, right? <andreas-e>As I understand it, also one thing we lost with debbugs is that someone else can propose a new version of the patch. <andreas-e>I sometimes did that: Someone proposed a patch, a proposed a (hopefully) improved version at the same issue number, and then asked whether the original author agreed with the changes. <noe>It depends if the “allow edits from maintainers” checkbox is checked by the author <noe>In which case a comitter to the target branch gets permission to push to the author’s branch on their fork <andreas-e>Ah, okay! But this is maybe a bit violent to force push to another person's branch... <andreas-e>But one could just add a commit on top that could later be squashed. <noe>andreas-e, (re new versions) that’s true, although its possible to make a new pull request with v2 in the title and link it in the previous one <andreas-e>Yes, but then there are two, which is also a bit confusing. Well, new tools, adapted workflows. <andreas-e>Because the old non-deleted branches in origin are also a burden. <noe>I think it would be a good idea to migrate or close PRs that target a branch before deleting it. But like you I have no idea how to list them <dariqq>thank you for making rust easier to intergrate with other build systems. Having to switch to cargo-build-system just to use #:cargo-inputs and setting up the vendor dir only to replace the other phases again was not a great experience <dariqq>that should make packaging some of the gnome adjacent meson+rust apps a lot easier to package <noe>andreas-e, an okay workaround could be to add [X-team] in subjects manually <noe>dariqq, I hope so too! I think gnome-authenticator has an example of that. <andreas-e>noe: Yes, this is more or less what I meant: Give "master" as the reference branch, and add a tag (I find tags more elegant than text in the subject; also one can click on tags). <noe>the team tags right! <noe>though they are used for something else at time <andreas-e>Speaking of tags etc., do you know how to get the issues and pull requests opened by a person? Just clicking on their name does not work. <andreas-e>person -> repository -> branches gives some good indication for pull requests <Rutherther>andreas-e: on the PR / issues pages there are filters right below the searchbox on the right side, one of them is Author <morenonatural>hey, y'all ... I got this code that runs ok in my-debian-without-guix, but it's missing a thing when trying `guix shell`... guile complains it cannot dlopen libcue.so.2 <morenonatural>current command: guix shell guile-next guile-lib nyacc guile-bytestructures libcue -- <vntsuyo>rust branch merged! i can work on more packages now :) <dariqq>noe: Would love to package fractal in guix but it is a bit of a monster. It depends on random git commits of the rust-matrix-sdk and when building it rustc uses 24+GB ram <xiews>hi, I have problem loading pages using nyxt in guix. The message is <xiews>Warning: Error on GTK thread: The value NIL is not of type STRING when <xiews>Had anyone the same problem? <noe>dariqq, its also on my todo list but I wasn’t aware of the monstrosities :P <noe>xiews, yup old problem with nyxt and the version of webkit guix is using <andreas-e>xiews: This has already been reported, on codeberg and on debbugs. The program seems to be broken (which is not really a consolation...) <xiews>ok, Thanks. Is it hard to fix? <andreas-e>jacobk: In theory, you could try to "--do-not-upgrade PACKAGE" to exclude the package that does not build. Here it is gtk+, which makes this solution unpractical. <andreas-e>Are you on x86_64? Which commit? This should normally not happen. <dariqq>i guess there is no way I can reuse some of the crate definitions from guix? (they are all not exported) <Rutherther>dariqq: why would you do that? the importer is going to import the proper dependencies for you, and if they happened to match the guix ones, the same source folder is going to be used as the derivation will be basically the same <andreas-e>Does anyone know how to read a file into the Guile REPL, which would be interpreted as if it were copy-pasted text? <identity>andreas-e: the ‘include’ macro should work <identity>like (include "file1.scm" "file2.scm" …) <hugohugo>I'm guessing I got rate limited, because I ran "guix lint" quite often the last week <andreas-e>identity: It does, thanks - strangely only with an absolute file name. <andreas-e>I would have expected a special repl command such as ,read file.scm. <hugohugo>maybe for relative filenames it is necessary to set a certain path environment first? <dariqq>Rutherther: This will lock the dependencies to the best match for today for the few rust packages in my channel. But if there is a newer (semver compatible) version avaialble i would need to to update these manually i guess <hugohugo>Thanks identity, then I won't worry about it <identity>andreas-e: there is also ‘include-from-path’ that searches ‘%load-path’ <andreas-e>Okay. Here "include" was what I needed; I wanted to run the code and end up in the REPL in case it contained an error. But it works :) <jacobk>andreas-e: I realized right after I sent my first message that I forgot to run `guix pull` today (I did run it yesterday though). `guix pull` said "Authenticating channel 'guix', commits 9edb3f6 to fa4fe70 (615 new commits)...", so I guess that means I was on the commit before 9edb3f6. Sorry, it looks like maybe it was just a temporary issue. I've rrun `guix pull` again now and `guix package -u` seems to be working fine, but it's pretty sl <jacobk>ow usually so it may be a while before I know for sure. I am on a foreign distro, Trisquel, on x86_64. Yesterday, running `guix build gtk+` showed no errors, but `guix package -u` was still failing. <andreas-e>We just merged the rust-team branch, so if there are new failures, it might be worth a report. <attila_lendvai_>is this only me? "guix home: error: profile contains conflicting entries for libxml2" <attila_lendvai>probably only me, because i have libxml2 explicitly in my profile. i'll just remove it and resolve that in another way... <corvvs>Hello, I'm having trouble installing GUIX on my Acer Nitro 5 AN515-44 laptop. I flashed the .iso file into my flash drive with dd and tried to boot from the flash drive. The GRUB menu appears fine but then I got stuck at this boot up process: https://ibb.co.com/XrQN3zb7 <corvvs>Can someone help? Is this a case of unsupported hardware for which no solution exists? <attila_lendvai>there are no substitutes for ungoogled-chromium. how can i find a commit for guix pull --commit=? so that i'll get a substitute? <attila_lendvai>corvvs, you'll need the nonguix channel/iso for your wifi... but it shouldn't stop it from booting. it may be worth a try if you want wifi later anyways. <corvvs>Okay, thanks for the pointer attila_lendvai <attila_lendvai>corvvs, also, it's waiting for entropy. i think keyboard is used, so typinnng randomly may speed it up. <corvvs>I waited for like around 5 minutes on that boot phase though. It's abnormal right? <andreas-e>It is not normal. But I am not sure if it continues when it does not find an Internet connection; then it is anyway impossible to install Guix. <Rutherther>corvvs: have you tried blacklisting iwlwifi and bluetooth? (adding them to modprobe.blacklist in kernel command line) <identity>attila_lendvai: the ungoogled-chromium package is horribly outdated and riddled with vulnerabilities, switch to a different browser or step up to update our ungoogled-chromium package <attila_lendvai>identity, i know. thanks for the head's up, though! i'm procrastinating on that... <corvvs>The one I should download is systemcrafters' 202412150202 nonguix iso right? (From GitHub) <jacobk>I was about to try to install ungoogled-chromium from guix, but after reading recent messages I'm considering using the version Flathub instead, but I don't know if the version there is really free software. <jacobk>s/version Flathub/version on Flathub/ <ieure>jacobk, I'm not sure ungoogled-chromium is even building in Guix, but even if it does, it's multiple years old and riddled with CVEs. <corvvs>The systemcrafters' iso worked lol <corvvs>Very fortunate I didn't have to buy another laptop lol <morenonatural>hey, y'all ... I got this code that runs ok in my-debian-without-guix, but it's missing a thing when trying `guix shell`... guile complains it cannot dlopen libcue.so.2 <morenonatural>current command: guix shell guile-next guile-lib nyacc guile-bytestructures libcue -- <morenonatural>(oh, I didn't... this other IRC client presents my username different from my other client) <andreas-e>ungoogled-chromium stopped building a month ago. And without help on getting it to build, it is scheduled to be removed in a few days. <Rutherther>morenonatural: you will probably have to either reference fully to the library under $GUIX_ENVIRONMENT/lib, or use something like DYLD_LIBRARY_PATH <Guest52>how can I set gtk theme using guix home config? <ieure>Guest52, I'm not sure where those are configured, but probably home-xdg-configuration-files-service-type is what you want. <ieure>Guest52, There's one in the manual. <Rutherther>though if you want to be even more lazy, you could just put the name of the theme to GTK_THEME environment variable using the home environment service type and call it a day <Rutherther>(and then of course also install the theme to your home profile) <Tadhgmister>is there a similar thing to 'local-file' that you specify the file hash and if the interned file is already in the store it doesn't bother trying to recompute the hash of the local file? <Tadhgmister>I'm trying to gather a bunch of files to update via guix deploy and using local-file for all of them has terrible performance but I don't expect them to update often so something more cumbersome but fast would be ideal <ieure>Tadhgmister, Put them in a package? <Tadhgmister>would that help? if the package still lists them as local-files I think I'll have the same issue, I feel like I need a way to use an origin record but the url is a local file path and it makes use of the same reuse mechanics as other origins <Tadhgmister>whether it is also wrapped in a package I don't think will make much difference <lilyp>Tadhgmister: how would you determine that the file is "already there"? <lilyp>that being said, you can use url-fetch with file URIs <Tadhgmister>if I specify a filename and a file hash and there exists a file in the guix store that matches the declaration it reuses that one without necessarily needing to compute the hash of the file every time <Tadhgmister>oh like I can specify (origin (uri "file:///...") (method url-fetch)), ok that might be what I am looking for tyvm <PapagaiNiko>I'm having a problem reconfiguring my system on a fresh install: switching or reconfiguring always fail with a `guix system: error: build of `/gnu/store/…-install-bootloader.scm.drv' failed`. Even though the reconfiguration fails, it does create a new generation but it's unbootable (`boot program '/gnu/store/…system/boot' terminated, rebooting` <ieure>PapagaiNiko, Haven't seen that before. What arch/bootloader? Is there a log of the build failure? <ieure>PapagaiNiko, Uh, huh. That's definitely weird. <ieure>PapagaiNiko, Can you paste your system config? <PapagaiNiko>I have to say that, following another problem, I erased yesterday everything that was in `/` and ran a `guix system init` <Rutherther>that \x0;\x0;\x0;\x0;\x0;\x0;\x0;\x0; seems like some sort of corruption. Have you verified there are no corruptions? <PapagaiNiko>Rutherther No I haven't! Is there a command that could check that? <Rutherther>you probably won't be able to gc root the problematic file though, that is gc rooted <PapagaiNiko>`sudo guix gc --verify=contents,repair` did repair 32 files out of the 50 I had. I'll try to see if a reconfiguration works now <ieure>PapagaiNiko, That really shouldn't happen, you might be dealing with a failed disk. <PapagaiNiko>Huum. That could also explain the weird problem I had yesterday that led to scratch `/` <PapagaiNiko>Still the same error. I'll keep digging a bit. Thank you anyways!