IRC channel logs

2022-12-07.log

back to list of logs

<zimoun>hi!
<zimoun>Ouch! This https://github.com/JuliaPy/Conda.jl killed my day!
<zimoun>Why, oh, why!
<zimoun>the Julia package manager is decent for reproducibility, why this addition?
<drakonis>it exists for the sole purpose of enabling conda to serve julia
<zimoun>rekado: emacs-ess is not available from Cuirass https://ci.guix.gnu.org/build/169323/details It fails about a dependency.
<zimoun>It builds fine on my laptop. But the build emacs-ess fails on a VM.
<zimoun>FAILED ess-r-eval-visibility-eval-standard-filter-test
<zimoun>civodul: having one local Git checkout per user is really inefficient when you have to create several users. Cloning the Guix repo is not cheap at all… when this very same repo is already there.
<zimoun>Somehow, Guix should first try to clone from the root Guix repo, then update.
<civodul>zimoun: sounds like you're about to propose a patch? :-)
<zimoun>maybe, who knows :-)
<civodul>everyone agrees with the diagnostic anyway
<civodul>re Conda.jl, looks fun :-)
<civodul>i guess they want to be able to deal with non-Julia packages
<zimoun>on Guix System, is /root/.cache/guix/checkouts also an expected location?
<civodul>that's used by "guix pull" when it runs as root
<zimoun>civodul: however, I do not know how to improve the Authenticating part. It can be slow. For instace, with 29,262 new commits.
<efraim>zimoun: I tried to package Conda.jl before https://gitlab.com/genenetwork/guix-bioinformatics/-/blob/master/gn/packages/julia.scm#L205
<civodul>zimoun: authentication duration proportional to the number of commits, that's unavoidable
<civodul>i think a solution would be a "git checkout cache daemon"
<civodul>starting off /root/.cache is not an option; is it what you had in mind?
<zimoun>civodul: why is it not an option? Instead of fetching from the network, just fetch from the local filesystem. I do not see what could be an issue since it is authentificated after the clone part..
<rekado>zimoun: because that’s just the root user’s cache.
<rekado>there could be a daemon-managed cache of the repo instead
<zimoun>yeah but this daemon-managed cache adds a layer of complexity when what we want is just to avoid a plain clone from Savanah and just reuse an already local clone. Keeping the per user clone under $HOME/.cache/guix/checkouts
<zimoun>I mean, I agree that a kind of daemon managing all the checkouts would be nice. It would allow to avoid the duplication of all the checkouts. But it is not implemented. When just try to clone from file:///root first instead of https://savanah is easy to implement and will save many ressources.
<civodul>zimoun: we're not gonna solve this in an IRC discussion :-)
<civodul>it's pretty tricky
<civodul>we can't just share data across user accounts
<civodul>make /root/.cache world-readable and things like that
<zimoun>why? What is the rationale behind this «we can't just share data across user accounts »
<rekado>not from home directories
<rekado>reusing something in /var/cache/guix/ would probably be okay
<civodul>*if* it's read-only
<zimoun>yes, it could be read-only. Only cloned at install time.
<zimoun>Just, “guix pull” takes 10min vs 3min (if I manage the clone by hand). 3min include authentication. It is ~7min for fetching Git data.
<zimoun>I mean, the first time an user install Guix, they clone once because they run “guix pull” as root for updating the guix-daemon and then another as user. I miss why the first clone (as root) could not be cached under /var/guix/checkouts (yeah that’s better than reuse /root/.cache :-))
<civodul>it could, it could
<civodul>but for that you need a third-party trusted by both root and the user
<civodul>and that's... the git checkout caching daemon!
<civodul>re authentication, i measured its throughput for the <Programming> paper
<civodul>in "normal conditions", you shouldn't find yourself authenticating 29K commits at once
<zimoun>at first install, yes you have :-)
<civodul>that's not "normal conditions", that's a project unable to publish a single release in 18 months :-)
<rekado>that’s because the release has been so terribly delayed
<zimoun>well, that’s real life condition :-)
<rekado>it’s better solved at the root
<rekado>there are no good reasons why it should be like this, only many, many bad ones