Re: [Buildroot] [PATCH 3/7] package/freescale-imx/kernel-module-imx-gpu-viv: bump to version 6.4.3.p4.2

From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Gary Bisson <gary.bisson@boundarydevices.com>
Cc: Gary Bisson <bisson.gary@gmail.com>,
	Chris Dimich <chris.dimich@boundarydevices.com>,
	Refik Tuzakli <tuzakli.refik@gmail.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	buildroot@buildroot.org, Romain Naour <romain.naour@gmail.com>,
	Giulio Benetti <giulio.benetti@benettiengineering.com>,
	Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Subject: Re: [Buildroot] [PATCH 3/7] package/freescale-imx/kernel-module-imx-gpu-viv: bump to version 6.4.3.p4.2
Date: Fri, 2 Sep 2022 20:43:44 +0200	[thread overview]
Message-ID: <20220902184344.GO68979@scaer> (raw)
In-Reply-To: <Ywy2Ro7fQtQ/lKUM@p1g2>

Gary, All,

On 2022-08-29 14:51 +0200, Gary Bisson spake thusly:
> On Sun, Aug 28, 2022 at 05:44:32PM +0200, Yann E. MORIN wrote:
> > On 2022-08-24 12:26 -0700, Chris Dimich spake thusly:
> > > To match NXP 5.15.32-2.0.0 release.
[--SNIP--]
> > I also have some relatively minor concerns with this package (not
> > specifically due to your change, but prompted by it):
[--SNIP--]
> > So, basically, we are using the commits on the master branch, but all
> > that differs from the corresponding tag is (by running:  git diff -p
> > c897a6c..82c6cb6):
> >   - there is an added 'fscl' (or variation thereof, like '+fscl') in 4
> >     locations, all appended to the version string;
> 'fslc' means that it is maintained by the community (fsl community) so
> the purpose of that tag is to show we're building from the external
> module source code from github/freescale (which is entirely maintained
> by the community).

Arf, and of course, I could not copy a 4-word acronym without making yet
another typo... :-/

> >   - there are two macros that are removed (specifically by ae0f3be).
> Yes this is for Yocto builds in order not to break reproducibiliy of the
> build/module.

Ah, but they are also nice for Buildroot, for the same reason! We also
want to be able to do reproducible builds, which is the reason I
suggested backporting that patch.

> > So, can't we use the tag instead of a sha1, and carry the patch from
> > ae0f3be localy?
> 
> We could but this approach considers there's only that patch that
> matters.
> In the past, the community-maintained module had more features than the
> driver from NXP, for instance it was supporting PREEMPT_RT when NXP
> didn't [1]. But I agree both branches are now very close.
> I don't have any strong feelings to be honest, whatever you think is
> better for BR will do.

OK, so using the master branch is the best solution overall, then.

> > Otherwise, Chris and Gary: could you add tags on the master branch,
> > maybe?
> We could add a tag on master if needed. Would need to run it by the
> project maintainer (Otavio). Just let me know if you want to go that
> route.

Given that there is a tag for the upstream import, it would be nice to
also have a tag for the community-merged result, but I can't impose that
burden, now that the reason for the master branch is better explained.
Thanks!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot