IRC channel logs


back to list of logs

<zimoun>civodul: unexpected behaviours are still around when substitutes are unreachable. Yesterday evenening, when was down, any action requiring substitutes was just unusable.
<civodul>zimoun: like this: ?
<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 (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: 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
<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