transitioning GNU Linux-libre to git-based releases

[Jason Self]

On Thu, 07 May 2020 09:59:08 -0300
Alexandre Oliva <lxoliva at fsfla.org> wrote:

> I'm not sure whether it makes sense to create all of .bz2, .xz
> and .lz, though.

One is probably sufficient. xz is probably more popular but I think
lzip is a better choice. It provides similar compression to xz when
invoked with similar settings but lzip is instead licensed as
GPL-2.0-or-later while xz are ostensibly public domain. Treat this as a
vote for strong copyleft.

If there is a desire to discontinue any particular compression method
that should probably be announced in advance and give people time to
adapt.

> This transition would offer a good opportunity to fix this unusual
> behavior, and make upcoming tarballs explodes to linux-libre-x.y.gnu/.
> However, for backward compatibility, it seems to me that it would be
> less disruptive to keep the current unusual behavior.

The current unusual behavior created some difficulty working on
LibreWRT which expected the tarballs to explode to the same name as the
tarball. That was eventuall worked around though.

I like the idea of changing to the new linux-libre prefix but keeping
with the current one would be less disruptive to automated workflows
but I also don't expect it to be a thing for people to make the needed
changes in their workflow.

On the topic of tarballs did you notice that there are also GPG
signatures for tarballs in the git repo I created? They are saved as
git notes. Assuming that you have done:

git fetch origin refs/notes/*:refs/notes/*

The signatures can then be seen with, for example:

git notes --ref refs/notes/signatures/tar show v4.18.5-gnu

This is possible because "git archive" generates bit-identical tarballs
each time. Each of the signatures includes a comment showing the
command used to make it, letting anyone else (re-)generate a tarball
and use that same signature. A benefit of having this is that
is obliviates any concern about future problems with relying on SHA-1 to
verify integrity before making a tarball.

The signature can also be exported and saved in a file to work as a
detached GPG signature for tarball releases.

The changelog is also included and can be seen with a similar command:

git notes --ref refs/notes/changelog show v4.18.5-gnu

I liked keeping the changelog with the git repo to ensure that the
description of the changes made goes along with the repo. Just like
the GPG signatures it can also be saved into a file to go along with
tarball releases.

Would you plan to do something like this?

> Though it might be possible to try to duplicate the metadata that goes
> in upstream tarballs, I don't see reason to try to emulate this
> artifact of our previous release procedure, that served mainly to
> reduce xdeltas (see below).  Please let me know if you find otherwise.

I agree that there is not such a need to do this.

> I'm therefore inclined to simply discontinue the creation of xdeltas.

I agree.

> Would that re-signing and repackaging be of any use for anyone?

Using the primary Linux-libre key would probably make sense to avoid
trust issues with multiple keys in use.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20200507/3459ef23/attachment.sig>