[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020
From: |
zimoun |
Subject: |
bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020 |
Date: |
Mon, 11 Oct 2021 10:41:50 +0200 |
Hi,
On Thu, 7 Oct 2021 at 18:07, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:
> I guess, in our mind, the problem was fixed long ago. :-)
Yes, to me the 2 remaining packages was from
<http://issues.guix.gnu.org/43442#0> but moved already to Gitlab.
Whatever, :-)
> > As I am asking in this thread [3], the Guix project has the ressource,
> > storage speaking, to archive these tarballs -- waiting a robust
> > long-term automatic system. But we (the Guix projet) cannot because we
> > duplicate the effort on keeping twice all the build outputs. Somehow,
> > between Berlin and Bordeaux, coherent policies for conservancy are
> > missing. IMHO.
>
> So I think we’re lucky that we can try different solutions at once.
Well, it is not what I am observing. Anyway. :-)
> The best solution is the one that won’t rely solely on the Guix project:
> SWH + Disarchive. We’re getting there!
Yes. Although, it is hard to define "the Guix project". :-)
Well, the remaining question is where to set the Disarchive
database... but hardware could be floating around once it is ready.
;-)
> The second-best solution is to improve our tooling so we can actually
> keep source code in a more controlled way. That’s what I had in mind
> with <https://ci.guix.gnu.org/jobset/source>. We have storage space for
> that on berlin, but it’s not infinite.
If Berlin has space, why so much derivations are missing when running
time-machine?
Well, aside the implementation that ci.guix.gnu.org fetches from repo
every X minutes, i.e., drops all the commits (and the associated
derivations) pushed in the meantime. And that bordeaux.guix.gnu.org
fetches from guix-commits the commit batch, i.e., builds only one
commit of this batch.
> Another approach is to use ‘git-fetch’ more, at least for non-Autotools
> packages (that’s the case for Scotch, for instance.)
This is what I suggested when opening this thread [1] more than one
year ago. Reading the discussion and keeping in mind the inertia, I
do not think it is a viable path. For instance, you know all the
pitfalls and you updated Scotch without switching to git-fetch -- no
criticism :-) just a realistic matter of facts to have good coverage.
<https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00224.html>
> So we can do all these things, and we’ll have to push hard to get the
> Disarchive option past the finish line because it’s the most promising
> long-term.
Agree. Even, I think it is the only long-term option. :-)
All the best,
simon