Re: Linux-libre 5.8 and beyond

[Mark H Weaver <mhw@netris.org>]

Hi Alexandre,

Alexandre Oliva <lxoliva@fsfla.org> wrote:
> On Aug 15, 2020, Mark H Weaver <mhw@netris.org> wrote:
>
>> If I were to implement this, what would you suggest I do if the patches
>> fail to apply
>
> Look at the conflict presented by the rebase, and resolve the likely
> freedom issue introduced at that point.
>
>> if the result fails to match the next Linux-libre release?
>
> Identify the intervening commit where code that got cleaned up
> differently was introduced or removed and make the change to the
> deblobbing at that point; rinse and repeat.

In other words, your proposed approach cannot be done automatically in
the general case.  Do you see how this is a problem?

If a Guix user reports that one of their devices stopped working in
Linux-libre-5.4.34, I'd like to enable them to easily build deblobbed
kernels at intermediate commits on the upstream stable/linux-5.4.y
branch.  With the present approach, I can provide a simple Guix recipe
to do this automatically.  With your proposed approach, the user may
need to manually resolve merge conflicts and so on.  Not all Guix users
will have the skills or motivation to do this.

Even _I_ would not want to do this, because it would mean doing
unnecessary labor.  I would much rather have my computer do this job
while I do something else, even if it takes longer.

       Mark