unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxime Devos <maxime.devos@student.kuleuven.be>
To: zimoun <zimon.toutoune@gmail.com>, 44199@debbugs.gnu.org
Cc: Timothy Sample <samplet@ngyro.com>, gnunet-developers@gnu.org
Subject: [bug#44199] [PATCH 0/1] An origin method for GNUnet FS URI's
Date: Sun, 01 Nov 2020 01:05:53 +0100	[thread overview]
Message-ID: <05677842bc60336461f8fe77ebd3526b2b23efb9.camel@student.kuleuven.be> (raw)
In-Reply-To: <86blgn4wk5.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

[CC'd to Timothy Sample because of discussion of defining a new format
for disarchive, and to gnunet-developers because of obvious reasons]

A small status update!

zimoun schreef op di 27-10-2020 om 14:39 [+0100]:
> [...]
> 
> The story about archives as tarball is a bit more complicated.  The
> main
> issue –as I understand it– can be summarized as: Guix knows the URL,
> the
> integrity checksum and only at package time the content of the
> tarball.
> Later in time, it is difficult to lookup because of this very
> address;
> and some are around: nar, swh-id, ipfs, gnunet, etc.
> 
> Bridges to reassemble the content are currently discussed, e.g.,
> 
>    <https://git.ngyro.com/disarchive-db/>
>    <https://git.ngyro.com/disarchive>
> 
> Well, today the fallback of tarball archive to SWH is not reliable.
> 
> 
> What is your question? ;-)

I looked a bit into the GNUnet FS code and disarchive discussions. The
part about tarballs seemed particularily relevant, as well as some
older discussion on preserving the executable bit when using IPFS.

Some issues with using GNUnet's directory format in GNUnet for Guix
substitutes to address:

* directory entries are not placed in any particular order.
  Solution: sort by file-name

* there is no executable bit.
  Solution: define a new metadata property (*).
  This should only take a small patch to libextractor.

  (*) Not sure about the correct terminology

* GNUnet sometimes inlines small files in directories,
  but strictly speaking when to do so is left up to the implementation.
  Solution: pick a fixed reference implementation.

* By default, when publishing, gnunet-publish uses libextractor
  to figure out some meta-data (e.g. title, mime-type, album name),
  which may return different meta-data depending on the implementation.

  Solution: disable the use of libextractor, at least when GNUnet is
  used by Guix.

I'm currently porting the directory creation code of GNUnet to Scheme
(but not any other GNUnet code), to be used by Guix (for publishing
substitutes) and disarchive (for reconstructing GNUnet directories).

After addressing these issues, I believe I will end up with a fairly
well-defined archive format.

<friendly-footer/>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

  parent reply	other threads:[~2020-11-01  0:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-24 19:47 [bug#44199] [PATCH 0/1] An origin method for GNUnet FS URI's Maxime Devos
2020-10-24 19:54 ` [bug#44199] [PATCH 1/1] guix: Add (guix gnunet-download) Maxime Devos
2020-10-27 13:39 ` [bug#44199] [PATCH 0/1] An origin method for GNUnet FS URI's zimoun
2020-10-27 18:50   ` Maxime Devos
2020-11-16  0:35     ` zimoun
2020-11-18 20:28       ` Maxime Devos
2020-11-18 22:40         ` zimoun
2020-11-01  0:05   ` Maxime Devos [this message]
2020-11-15 21:13 ` Ludovic Courtès
2020-11-18 19:14   ` Maxime Devos
2020-11-18 22:42     ` zimoun
2021-01-27 13:07 ` [bug#44199] Info: Rehash Project Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=05677842bc60336461f8fe77ebd3526b2b23efb9.camel@student.kuleuven.be \
    --to=maxime.devos@student.kuleuven.be \
    --cc=44199@debbugs.gnu.org \
    --cc=gnunet-developers@gnu.org \
    --cc=samplet@ngyro.com \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).