Hello,
> Is that because the changes you describe were done after the staging
> data was loaded or is it a bug?
Our staging instance inherits its append-only property from our main
archive. In the staging case (for "prototypes", soon-to-be-deployed new
feature or so), that makes it hard to see th
Hello,
This is very exciting work, thanks everyone!
"Antoine R. Dumont (@ardumont)" writes:
> FWIW, in the "new" lister [1] implementation, there are a bunch of extra
> computations done [1] to try and resolve those situations. It's trying
> to fetch more information from upstream server (e.g.
Hey Antoine,
"Antoine R. Dumont (@ardumont)" skribis:
>>> My understanding is that so far these URLs were ignored by the
>>> lister/loader because they didn’t end in *.tar.*.⁰
>
> FWIW, in the "new" lister [1] implementation, there are a bunch of extra
> computations done [1] to try and resolve
>> My understanding is that so far these URLs were ignored by the
>> lister/loader because they didn’t end in *.tar.*.⁰
FWIW, in the "new" lister [1] implementation, there are a bunch of extra
computations done [1] to try and resolve those situations. It's trying
to fetch more information from up
Hi,
> The initial NixGuix loader (currently in production) lists and loads
> origins from a manifest, ignoring the specific origins mentioned above. The
> new stack will be able to ingest those origins. It will also optionally
> associate, if present, a NAR hash (specific intrinsic identifier to N
Hi Benoit and all!
(Cc: guix-devel rather than gnu-system-discuss.)
Benoit Chauvet skribis:
> Regarding the Nix/GNU Guix stack, Software Heritage will soon be ready to
> support the
> ingestion of specific versioned files, tarballs, git, hg, svn source code
> listed in their respective manifest
