IRC channel logs

<meaty>could someone with privileges add a 'help-wanted' label to my PR #964?

<futurile-afk>morning civodul, user_oreloznog - and all!

<user_oreloznog>good morning futurile, guix...

<apteryx>how do I comment on the commit *message* in a Codeberg review? Do I need to do it manually copying parts and commenting in the overall discussion of the PR?

<civodul>apteryx: i don’t know! i think you need to mention it “manually”

<apteryx>OK! Ah, I can already see the strict GNU ChangeLog culture eroding before my eyes ;-). Maybe not a bad thing?

<efraim>I've found in other projects where there isn't a strict rule about the commit messages it tends to get sloppy quickly

<efraim>(including in my own)

<apteryx>The danger is that *any* commit message practice becomes harder to review, this the effect probably means worst commit messages in the long run.

<apteryx>efraim: yeah, I can see how that could happen. I think mailing lists managed projects are often strict on commit messages, but I haven't had such experience with most forge-based projects (anything reasonable goes).

<apteryx>it's sloppyfficient

<z572>i think we need codeberg action.

<z572>The initial review should be conducted by a machine

<efraim>only platforms which guix actually supports goes in supported-systems, right?

<efraim>i'm working on some more grub plackages, the tests for grub-uboot want the qemu-system-i386 binary ...

<apteryx>z572: I agree! I think it's a goal.

<efraim>ok, looks like it's the fallback position so I can try just dropping using substitute*

<apteryx>(to have more integration between QA/Codeberg and/or a runner that runs at least 'guix lint' on each commit)

<civodul>z572: QA does a great job at that (it just needed to be hooked up to Codeberg), and now there’s also a Forgejo Runner service (well, very soon)

<civodul>yes exactly

<allana>Hi guix! I'm curious, is anyone working towards upgrading libssh2 and changing its backend from libgcrypt to openssl as described in the mailing list? https://lists.gnu.org/archive/html/guix-devel/2025-03/msg00165.html

<allana>Or is it perhaps a big thing that requires a lot of architectural decision making and testing before being considered?

<z572>civodul: What is blocking QA from connecting to codeberg now?

<identity>what package provides the OpenGL::EGL cmake target?

<civodul>z572: https://codeberg.org/guix/data-service/pulls/2 allows the Data Service to process revisions from pull requests, but i don’t think it’s deployed

<z572>i think maybe is mesa

<allana>Sorry if my question is a bit much, for me it is crucial for accessing secured repos in various forges.

<identity>z572: does not look like that

<civodul>allana: hi! i think there’s nothing against applying such a change, other than testing, as you wrote

<civodul>feel free to submit it as a pull request once you’ve confirmed that it works for you

<z572>identity: please show the code. It might be that other dependencies are not satisfied

<gnubootuser>hello

<identity>z572: what do you mean "show the code"? i am trying to update a package and get multiple CMake Errors saying "Target $name links to: OpenGL::EGL but the target was not found", nothing else of interest (i think)

<futurile-afk>hello gnubootuser

<andreas-e>civodul: Your link to the Forgejo/QA integration does not show the actual content of the pull request, saying that the branch was deleted. Is this normal? If yes it would mean that unlike in debbugs, we lose the contents of the commits that are discussed. Which in turn makes the discussion rather incomprehensible, and would mean we lose history.

<z572>identity: show the package's code. This is better for debugging.

<z572>andreas-e: i think because is pushed on trunk, and not merge pr.

<z572>for example: https://codeberg.org/guix/guix/pulls/742

<z572>pushed and manual merge. then delete branch, the commits is still available.

<identity>z572: the arcan package but with the version bumped to 0.7.0.1

<avalenn>apteryx: for commit message review there is a feature request https://codeberg.org/forgejo/forgejo/issues/7353

<avalenn>some projects I follow uses bot to force some formalism on commit messages

<avalenn>with e.g. https://commitlint.js.org/ which is obviously not at all adapted to GNU Changelog rules

<gnubootuser>hello futurile

<andreas-e>z572: What do you mean with "pushed on trunk"? But good to see that in other cases the commits are still there.

<z572>see https://codeberg.org/guix/data-service/commits/branch/trunk

<z572>"Add support for Forgejo web hooks." ... commits is already in the repo

<z572>so, when forgejo detects, it will consider that there is no commit in the pr

<z572>identity: you can open a WIP PR on codeberg.

<allana>civodul: Thanks:-) In response to submitting a PR for upgrading libssh2 and replacing the backend with openssl, I think someone has already submitted such a patch. It's not particulalry stale having been submitted in March of this year, but if there are any problems with it I would be glad to try to help!

<allana>it is labeled bug#77154

<peanuts>"[PATCH 0/1] Update libssh2 and change crypto backend" https://issues.guix.gnu.org/77154

<allana>I see that there is some activity there and an unanswered question. I will do some tests and see what's up and try to respond in the right place.

<civodul>allana: oh excellent, thanks; and yeah, if you can respond with feedback from your own testing, that may help push it forward

<andreas-e>allana: As debbugs does not cc people who have commented on an issue, I would suggest to cc them manually if you comment on the issue.

<allana>andreas-e: thanks

<apteryx>andreas-e: Gnus has some smart wide reply that collect everyone in thread, but I've only discovered that recently ^^

<csantosb>Hi ! could someone please build #1001 (comedilib 0.13.0) ?

<csantosb>I see something weird with `tree /gnu/store/hjxfsbnvs169sh1cmha1zr54vimxm86m-comedilib-0.13.0`

<csantosb>Same thing as with `tree /gnu/store/rwcm25ap2yyd0070anckar7rn6dnn26k-libserialport-0.1.2`

<dlowe>I've gotten my guix system into a crazy state where guix pull gives an SSL error and saying --no-check-certificates segfaults :(

<dlowe>This is what I get for not pulling in a few months

<csantosb>Tried with `guix pull --url=https://codeberg.org/guix/guix.git` ?

<andreas-e>csantosb: To me it looks as if the origin is wrong:

<andreas-e>fatal: couldn't find remote ref r_0_13_0

<andreas-e> * [new tag] r0_13_0 -> r0_13_0

<dlowe>csantosb: it seems to follow the redirect but I'll try

<andreas-e>One underscore too many!

<dlowe>Yeah, same thing. SSL cert error and without checking it segfaults after "Receiving objects"

<andreas-e>Then it fetches something from SWH, which hopefully is the correct source, and ends up with a package.

<dlowe>I downloaded a recent cacerts.pem and pointed the environment variables at it, and it still fails

<dlowe>actually wouldn't the guix-daemon need the new cacerts

<csantosb>dlowe: `sudo -i guix pull` ?

<dlowe>SSL cert error, but there's no ignoring the check on the system version of guix

<csantosb>andreas-e: thanks, that was it; it was literally using the sources from next package in the list

<dlowe>I may have to just reinstall the system from scratch.

<dlowe>At least I can feed it my config.scm

<noe>Hello my dear committers could someone merge https://codeberg.org/guix/guix/pulls/871 please

<noe>It has one approval

<postroutine>Hello. When I use Guix Home to manage my settings and store everything in a git repository, do you have any suggestions to manage sensitive settings ? Like SSH private key or application settings that store auth informations.

<identity>postroutine: do not manage plain text private info with guix, because they will get put into the world-readable store; i hear there are ways to put the private info encrypted into the store, but not putting your secrets there is definitely an easier solution

<meaty>when should we use `#:parallel-build? #t`? it only shows up four times so I'm guessing there's some standard to be met for its use?

<vhns>Is there an example of how to use Codeberg's guix git repo instead of savannah's/git.guix.gnu.org?

<ekaitz>vhns: yes but for what? pulling?

<vhns>pulling, yes

<ekaitz>vhns: if you guix pulled and reconfigured recently that's happening automatically

<vhns>`guix pull`

<ekaitz>if not, you can...

<vhns>doesn't seem to be the case

<vhns>I'm on guix 26a8b63

<ekaitz>ACTION needs to check the options and needs a second

<vhns>and it still pulls from git.guix.gnu.org

<ekaitz> --url=URL download "guix" channel from the Git repository at URL

<ekaitz>i think

<ekaitz>i did it not that long ago and I forgot

<vhns>I meant what is the way to replace it in your system/home config

<vhns>since that would require me to always point it there manually

<ekaitz>vhns: if you update, that will happen alone

<vhns>(not being pedantic, just stating my question)

<vhns>ok, I'll try it

<ekaitz> https://guix.gnu.org/manual/devel/en/guix.html#Using-a-Custom-Guix-Channel

<ekaitz>vhns: that would let you select, but I don't think you need to configure anything extra as we made the migration

<vhns>I asked because https://git.guix.gnu.org/guix.git is timing out for me currently

<vhns>using --url=https://codeberg.org/guix/guix.git is working

<ekaitz>:)

<ekaitz>vhns: "https://git.guix.gnu.org/guix.git" redirects to the codeberg

<vhns>well, yes, but it only redirects as long as the webserver doing the redirects isnt borked somewhat

<ekaitz>in the default channel it uses that git.guix.gnu.org address, so no, what I told you that it will use the codeberg automatically is not right 100%

<ekaitz>exactly, if the redirect is broken, it won't

<ekaitz>(it shouldn't be)

<ekaitz>so you might need to read #Using-a-Custom-Guix-Channel in case this fails again

IRC channel logs

2025-07-04.log