Generate diff with git-diff and use in patches field of packages

Generate diff with git-diff and use in patches field of packages

[Léo Le Bouter]

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

Hello!

While patching packages for security issues, I often am needing to get
some patches from git repos because upstream does not make releases.

Including patch in "patches" directory etc. is a bit troublesome, I
would rather have some Scheme code do this with: upstream git url,
commit selector range or not, with hash checking like origins.

Is that possible?

Thank you

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

Re: Generate diff with git-diff and use in patches field of packages

[zimoun]

Hi,

On Wed, 10 Mar 2021 at 04:11, Léo Le Bouter <lle-bout@zaclys.net> wrote:

> While patching packages for security issues, I often am needing to get
> some patches from git repos because upstream does not make releases.

If the package already uses git-fetch, why not directly uses the commit
fixing the issue as source?

If the package is not already using git-fetch but instead url-fetch,
maybe the replacement to git-fetch makes sense.  Even if there is no
consensus about git-fetch vs url-fetch. :-) Thread here:

<https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00224.html>


Cheers,
simon

Re: Generate diff with git-diff and use in patches field of packages

[Leo Famulari]

On Wed, Mar 10, 2021 at 04:11:34AM +0100, Léo Le Bouter wrote:
> Hello!
> 
> While patching packages for security issues, I often am needing to get
> some patches from git repos because upstream does not make releases.
> 
> Including patch in "patches" directory etc. is a bit troublesome, I
> would rather have some Scheme code do this with: upstream git url,
> commit selector range or not, with hash checking like origins.
> 
> Is that possible?

We do this sometimes. Check out how Bash is patched, and also the
vestigial qemu-patch procedure.

However, I think it's more reliable to include the patches in Guix
itself, and a lot easier for other packagers — including from other
distros — to read them. I often look at what other distros have done
when deciding how to fix things in Guix, and it's helpful when they
don't make things too obscure.

Re: Generate diff with git-diff and use in patches field of packages

[Leo Famulari]

On Wed, Mar 10, 2021 at 02:42:32PM +0100, zimoun wrote:
> If the package already uses git-fetch, why not directly uses the commit
> fixing the issue as source?

It's different to build from a Git commit vs to cherry-pick a single
commit.

Re: Generate diff with git-diff and use in patches field of packages

[zimoun]

Hi Leo,

On Wed, 10 Mar 2021 at 12:09, Leo Famulari <leo@famulari.name> wrote:
> On Wed, Mar 10, 2021 at 02:42:32PM +0100, zimoun wrote:
>> If the package already uses git-fetch, why not directly uses the commit
>> fixing the issue as source?
>
> It's different to build from a Git commit vs to cherry-pick a single
> commit.

I could miss something but I was not suggesting to cherry-pick. :-)
Cherry-picking means use the current packaged version and backport to it
the commit(s) fixing the issue.

I am suggesting to update the packaged version to the upstream version
at commit.  But maybe it is not possible because the new upstream has
changed some API or whatever breaking some dependants.


Cheers,
simon

Re: Generate diff with git-diff and use in patches field of packages

[zimoun]

On Wed, 10 Mar 2021 at 12:09, Leo Famulari <leo@famulari.name> wrote:

> However, I think it's more reliable to include the patches in Guix
> itself, and a lot easier for other packagers — including from other
> distros — to read them. I often look at what other distros have done
> when deciding how to fix things in Guix, and it's helpful when they
> don't make things too obscure.

In addition, I think it makes easier for long term support.  The source
should be archived in Software Heritage–work-in-progress.  If the
patches are not in the Guix repo, where are they if upstream disappears?


Cheers,
simon

Re: Generate diff with git-diff and use in patches field of packages

[Leo Famulari]

On Wed, Mar 10, 2021 at 06:49:37PM +0100, zimoun wrote:
> I could miss something but I was not suggesting to cherry-pick. :-)
> Cherry-picking means use the current packaged version and backport to it
> the commit(s) fixing the issue.

I know you were not suggesting to cherry-pick. But that is what this
thread is about: the best workflow for cherry-picking patches.

> I am suggesting to update the packaged version to the upstream version
> at commit.  But maybe it is not possible because the new upstream has
> changed some API or whatever breaking some dependants.

We can do that, and sometimes we do. I think we should avoid it when
possible, since it's rare that upstream projects intend for us to
distribute their development branches.

Re: Generate diff with git-diff and use in patches field of packages

[zimoun]

Hi Leo,

On Wed, 10 Mar 2021 at 13:06, Leo Famulari <leo@famulari.name> wrote:
> On Wed, Mar 10, 2021 at 06:49:37PM +0100, zimoun wrote:

>> I could miss something but I was not suggesting to cherry-pick. :-)
>> Cherry-picking means use the current packaged version and backport to it
>> the commit(s) fixing the issue.
>
> I know you were not suggesting to cherry-pick. But that is what this
> thread is about: the best workflow for cherry-picking patches.

Ah sorry, I have not read the initial message:

        While patching packages for security issues, I often am needing
        to get some patches from git repos because upstream does not
        make releases.

as it was about cherry-picking but how to have security fixes included…

>> I am suggesting to update the packaged version to the upstream version
>> at commit.  But maybe it is not possible because the new upstream has
>> changed some API or whatever breaking some dependants.
>
> We can do that, and sometimes we do. I think we should avoid it when
> possible, since it's rare that upstream projects intend for us to
> distribute their development branches.

…and all is clear. :-)


Sorry for the noise so.

Cheers,
simon