IRC channel logs


back to list of logs

<zimoun>civodul: ‘nixguix’ is currently replaced
<zimoun>and FYI, maybe some NAR checkum will be considered somewhere… discussion here
<civodul>zimoun: hi! the 1st issue above doesn't mention the format though, or did i miss it?
<civodul>if would be great if they would add nar as a serialization format :-)
<zimoun>about NAR, it is already almost the case. ;-) Antoine use some external ’nix-nar’ tools and would like a Python replacement.
<zimoun>Well, SWH seems okish to store NAR somewhere. And it would help for looking up (instead of complex SVN tricks)
<zimoun>civodul: another question I have is: why Guix is plain serializer for tarball and nar serializer else?
<zimoun>Why not nar for all?
<civodul>s/NAR/nar/ :-)
<civodul>that'll make things considerably easier if SWH supports nar hashes
<civodul>"plain" serializer is enough for a regular file like a tarball
<civodul>and it's universal, too
<civodul>(as in: not limited to Nix and Guix)
<zimoun>hum, your argument is not convinced me. ;-) Since then the hash is nix-base32 which not universal.
<civodul>converting from nix-base32 to hex is trivial
<civodul>whereas one cannot "convert" from a nar hash to a git hash or plain hash
<civodul>it's important because we resort to content-addressed mirrors besides SWH
<zimoun>which ones?
<civodul>it's in (guix download)
<civodul>alright, in practice these are mirrors provided by Guix, NixOS, and SWH
<civodul>but still
<civodul>why were you asking?
<zimoun>because I try to explain how it works and it appears to me inconsistent.
<zimoun>Well, maybe it could be something to add to Disarchive: a bridge (map) between different serializers.
<zimoun>Today, we use plain (which is more or less tar), nar and git (which is also swh, at least now). On the top of that, different hash algorithms.
<zimoun>One simple piece is missing for whatever reason and paf many things fall down, IMHO.
<civodul>sure, but nothing's new
<civodul>we only use the nar and "plain" serializers in practice
<civodul>we use the Git serializer indirectly, because we refer to commit IDs, but that's it
<zimoun>if we encode Git commit hash in package definition (instead of label tags), we could directly swh:rev identifier to lookup. And it will fix some SWH snappshot issues.
<civodul>right; git-fetch origins often refer to commit IDs, but sometimes refer to tags
<civodul>in the latter case, we do have a fallback mechanism that works well with SWH
<civodul>the "only issue" is if the tag was modified
<civodul>and that's why we should consider not referring to tags (this has been discussed a few times)
<civodul>funny: the nar vs. git serialization issue was one of the first i raised when SWH went public :-)
<civodul>so it's really great news that you have here
<zimoun>yeah, url+tag works well with SWH but we discussed several corner cases – speaking about SWH snapshots and so on. It appears to me an hard path, especially for maintenance, when we could encode (at package time), the information necessary for the lookup.
<civodul>one thing i like on this whole serialization/hash algorithm issue is
<zimoun>Well, seing the flame, it would be hard to have an inclusion in package definition
<civodul>the flame?
<civodul>also, which corner cases do you have in mind?
*civodul missed a few things it seems :-)
<zimoun>I do not have the list at hand but some packages are not reachable even if they already are in SWH.
<zimoun>Some others are bugs on SWH side, I guess. ;-)
<civodul>ah ok
<civodul>i guess we need to look at specific examples to understand what's wrong
<civodul>as for the long thread above, it probably includes valid arguments somewhere in the middle :-)
<civodul>anyway, the day we can look up SWH "content" or "directory" objects by nar hash, all our problems vanish
<efraim>interesting story about SWH backups, I have an unmaintained channel with IETF RFCs in text form and one of them disapeared from the official website. SWH has a backup of it
<civodul>neat; it's good to know that it works in practice :-)
***Server sets mode: +nt