[Buildroot] Interaction between SITE_METHOD=LOCAL and .patch files

[Buildroot] Interaction between SITE_METHOD=LOCAL and .patch files

[Grant Edwards]

I've been chasing a bug in a package for a couple days, and have been
baffled because the executable failed with segfault when it was built
from a local package.tar.gz file located in thepackage directory
(where the package.mk file is).  However, if I unpack package.tar.gz
and then set the SITE_METHOD to LOCAL, the executable works fine.

After comparing build trees that worked with build trees that failed,
I finallythat setting SITE_METHOD = LOCAL prevents the application of
the .patch files present in the package directory. 

I don't find this behavior documented anywhere.  The description of
SITE_METHOD only says it affects how the sources are fetched.  It
doesn't say anything about it controlling whether or not patches are
applied.  Is it interaction intentional, or is it a bug?

[FWIW, the package in question is the most recent version of the ipkg
package, and the 0001-fix-musl-build.patch is what breaks it.  Since
that package has already been removed, I won't bother to file a bug
report.]

-- 
Grant Edwards               grant.b.edwards        Yow! Are we wet yet?
                                  at               
                              gmail.com            

[Buildroot] Interaction between SITE_METHOD=LOCAL and .patch files

[Arnout Vandecappelle]

On 06-02-17 22:54, Grant Edwards wrote:
> I've been chasing a bug in a package for a couple days, and have been
> baffled because the executable failed with segfault when it was built
> from a local package.tar.gz file located in thepackage directory
> (where the package.mk file is).  However, if I unpack package.tar.gz
> and then set the SITE_METHOD to LOCAL, the executable works fine.
> 
> After comparing build trees that worked with build trees that failed,
> I finallythat setting SITE_METHOD = LOCAL prevents the application of
> the .patch files present in the package directory. 

 It does. The technical reason for that is that SITE_METHOD = local is
implemented using _OVERRIDE_SRCDIR, and for that we don't want to apply patches
because the typical use case is to build some different version to which the
patches wouldn't apply anyway.

 Also, when you set SITE_METHOD = local, there should be no reason to apply
patches because you can just as well apply them in your custom tarball.

> I don't find this behavior documented anywhere.  The description of
> SITE_METHOD only says it affects how the sources are fetched.  It
> doesn't say anything about it controlling whether or not patches are
> applied.  Is it interaction intentional, or is it a bug?

 Indeed, it should be documented. Care to send a patch?

 Regards,
 Arnout

> 
> [FWIW, the package in question is the most recent version of the ipkg
> package, and the 0001-fix-musl-build.patch is what breaks it.  Since
> that package has already been removed, I won't bother to file a bug
> report.]
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Interaction between SITE_METHOD=LOCAL and .patch files

[Grant Edwards]

On 2017-02-07, Arnout Vandecappelle <arnout@mind.be> wrote:

>> After comparing build trees that worked with build trees that failed,
>> I finallythat setting SITE_METHOD = LOCAL prevents the application of
>> the .patch files present in the package directory. 
>
> It does. The technical reason for that is that SITE_METHOD = local
> is implemented using _OVERRIDE_SRCDIR, and for that we don't want to
> apply patches because the typical use case is to build some
> different version to which the patches wouldn't apply anyway.
>
> Also, when you set SITE_METHOD = local, there should be no reason to
> apply patches because you can just as well apply them in your custom
> tarball.

Can SITE_METHOD = local be used with a custom tarball?  My
understanding from the docs is that it requires an unpacked source
directory tree [in which, as you said, one can easily apply whatever
patches are required].

I agree that for the unpacked source directory tree use case, not
appying patches makes the most sense.

>  Indeed, it should be documented. Care to send a patch?

Will do.

-- 
Grant Edwards               grant.b.edwards        Yow! Somewhere in Tenafly,
                                  at               New Jersey, a chiropractor
                              gmail.com            is viewing "Leave it to
                                                   Beaver"!

[Buildroot] Interaction between SITE_METHOD=LOCAL and .patch files

[Grant Edwards]

On 2017-02-07, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2017-02-07, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>>> After comparing build trees that worked with build trees that failed,
>>> I finallythat setting SITE_METHOD = LOCAL prevents the application of
>>> the .patch files present in the package directory. 
>>
>> It does.
>
>>  Indeed, it should be documented. Care to send a patch?
>
> Will do.

Is it just the .patch files found in the package directory that are
skipped in the [FOO_SITE_METHOD = local] case?  Or are all patches
skipped (also skipping those specified by FOO_PATCH and
BR2_GLOBAL_PATCH_DIR)?

-- 
Grant Edwards               grant.b.edwards        Yow! Alright, you!!
                                  at               Imitate a WOUNDED SEAL
                              gmail.com            pleading for a PARKING
                                                   SPACE!!

[Buildroot] Interaction between SITE_METHOD=LOCAL and .patch files

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

Hi,

 >>> Indeed, it should be documented. Care to send a patch?
 >> 
 >> Will do.

 > Is it just the .patch files found in the package directory that are
 > skipped in the [FOO_SITE_METHOD = local] case?  Or are all patches
 > skipped (also skipping those specified by FOO_PATCH and
 > BR2_GLOBAL_PATCH_DIR)?

All patches, it skips directly to to the configure step.

-- 
Bye, Peter Korsgaard

[Buildroot] Interaction between SITE_METHOD=LOCAL and .patch files

[Thomas Petazzoni]

Hello,

On Tue, 07 Feb 2017 20:47:42 +0100, Peter Korsgaard wrote:

>  > Is it just the .patch files found in the package directory that are
>  > skipped in the [FOO_SITE_METHOD = local] case?  Or are all patches
>  > skipped (also skipping those specified by FOO_PATCH and
>  > BR2_GLOBAL_PATCH_DIR)?  
> 
> All patches, it skips directly to to the configure step.

Just to clarify things:

 * For all site methods (except local/OVERRIDE_SRCDIR), the steps
   through which a package go are:

   source -> extract -> patch -> configure -> build -> install

 * For the local site method and OVERRIDE_SRCDIR, the steps through
   which a package go are:

   rsync -> configure -> build -> install

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Interaction between SITE_METHOD=LOCAL and .patch files

[Thomas Petazzoni]

Hello,

On Tue, 7 Feb 2017 17:18:04 +0000 (UTC), Grant Edwards wrote:

> Can SITE_METHOD = local be used with a custom tarball?

No. Arnout got it wrong here. You've got the following choices:

 <pkg>_SITE_METHOD = local
 <pkg>_SITE = /path/to/directory

*OR*

 <pkg>_SITE_METHOD = file
 <pkg>_SITE = /path/to/local/tarball.tar.gz

So the "local" site method points to a directory, and patches are *NOT*
applied. The "file" site method points to a local tarball, and patches
*ARE* applied.

> My understanding from the docs is that it requires an unpacked source
> directory tree [in which, as you said, one can easily apply whatever
> patches are required].

Your understanding is correct.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com