IRC channel logs

<zimoun>civodul: unexpected behaviours are still around when substitutes are unreachable. Yesterday evenening, when ci.guix.gnu.org was down, any action requiring substitutes was just unusable.

<civodul>zimoun: like this: https://issues.guix.gnu.org/63634 ?

<zimoun>this one is another one, and I am currently hitting it. :-)

<zimoun>Yesterday evening, “guix shell ledger” was frozen and after 18 minutes of nothing, I just killed it, reported on guix-devel https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00240.html (and I went for apéro and dinner ;-))

<zimoun>civodul: I appeared to me worse than an error. :-)

<civodul>we'll need more info, there's little that can be done here

<zimoun>It rings this bell: https://issues.guix.gnu.org/issue/62334#7 but it should be fixed on Guile side, no?

<civodul>i don't think this is related

<civodul>(as far 63634 is concerned)

<zimoun>well, I do not know neither, but since some time, I have very hard times with Guix (substitutes, importer, etc.) and all seems related to network link.

<civodul>sorry to hear that

<civodul>speaking of importers, y'all may be interested in https://issues.guix.gnu.org/63571

<rekado>civodul: I saw that; it’s good work

<rekado>I’m just worried about all the bad recommendations that I usually ignore when upgrading the CRAN+bioc packages

<rekado>I do use refresh -u, but I would want to specify (with the package or on the command line?) which recommendations to ignore

<civodul>rekado: good point

<civodul>previously you'd have to edit by hand (to make those changes) and now you'd have to edit by hand (to undo some of those changes)

<civodul>would it be feasible to hard-code in the importer "wrong" recommendations?

<civodul>the cran one already has mappings for "system" packages for instance

<rekado>one of the wrong recommendations is introducing a cycle in r-knitr

<rekado>I like seeing the recommendations up front like some sort of task sheet, so I’m sure I won’t miss any

<rekado>if it still prints the recommendations it applied that would allow me to undo some of them

<rekado>I could live with that

<rekado>some recommendations are about libraries that I know are not supposed to be inputs

<rekado>(because they are only used when building on Windows)

<rekado>these two common sources of misinformed recommendations are not something we could catch globally

<civodul>the Windows libraries is something we could catch globally, no?

<rekado>I don’t know

<civodul>then we could also have package properties like 'cran-ignored-dependencies', for per-package tweaks

<rekado>it’s not a Windows library

<rekado>it’s openssl

<rekado>for example

<civodul>oh, i see

<rekado>but it’s only necessary on Windows

<civodul>we can still have it though, right? :-)

<rekado>R packages do have separate makefiles for Windows, so the temptation is there to just not look at them, but they are *also* used for Linux, sometimes

<rekado>it’s a little messy

<rekado>yes, a package property would be welcome

<rekado>better than just recording this in comments

<civodul>adding support for package properties is easy

<civodul>with that done, would the result be an improvement for you?

<rekado>absolutely, yes!

<civodul>good :-)

<civodul>i wouldn't want it to be a step backwards for those who actually use it

IRC channel logs

2023-05-22.log