All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 11/16 v3] core/legal-info: also save patches
Date: Sun, 31 Jan 2016 11:18:03 +0100	[thread overview]
Message-ID: <56ADDF5B.9040300@lucaceresoli.net> (raw)
In-Reply-To: <415acb524afa715f0b51d6f1b3344a63e90301ee.1454004518.git.yann.morin.1998@free.fr>

Hi Yann,

Yann E. MORIN wrote:
> Currently, the legal-info infra only saves the source archive of a
> package. However, that's not enough as we may apply some patches on
> packages sources.
>
> We do suggest users to also redistribute the Buildroot sources as part
> of their compliance distribution, so the patches bundled in Buildroot
> would indeed be included in the compliance distribution.
>
> However, that's still not enough, since we may download some patches, or
> the user may use a global patch directory. Patches in there might not
> end up in the compliance distribution, and there are risks of
> non-conformity.
>
> So, always include patches alongside the source archive.
>
> To ensure reproducibility, we also generate a series file, so patches
> can be re-applied in the correct order.
>
> We get the list of patches to include from the list of patches that were
> applied by the package infrastructure (via the apply-patches support
> script). So, we need to get packages properly extracted and patched
> before we can save their legal-info, not just in the case they define
> _LICENSE_FILES.
>
> Update the legal-info header accordingly.
>
> Note: this means that, when a package is not patched and defines no
> LICENSE_FILES, we will extract and patch it for nothing. There is no
> easy way to know whether we have to patch a package or not. We can only
> either duplicate the logic to detect patches (bad) or rely on the infra
> actually patching the package. Also, a vast majority of packages are
> either patched, or define _LICENSE_FILES, so it is best and easiest to
> always extract and patch them prior to legal-info.
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Luca Ceresoli <luca@lucaceresoli.net>
> Tested-by: Luca Ceresoli <luca@lucaceresoli.net>
>
> ---
> Changes v2 -> v3:
>    - also mention that patches have been saved  (Luca)
>
> Changes v1 -> v2:
>    - don't recompute rawname-version needlessly  (Luca)
> ---
>   package/pkg-generic.mk           | 13 ++++++++-----
>   support/legal-info/README.header |  9 +++++----
>   2 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
> index 7ad3bc3..c5b66db 100644
> --- a/package/pkg-generic.mk
> +++ b/package/pkg-generic.mk
> @@ -759,12 +759,10 @@ $(2)_MANIFEST_LICENSE_FILES = $$($(2)_LICENSE_FILES)
>   endif
>   $(2)_MANIFEST_LICENSE_FILES ?= not saved
>
> -# If the package declares _LICENSE_FILES, we need to extract it,
> -# for overriden, local or normal remote packages alike, whether
> -# we want to redistribute it or not.
> -ifneq ($$($(2)_LICENSE_FILES),)
> +# We need to extract and patch a package to be able to retrieve its
> +# license files (if any) and the list of patches applied to it (if
> +# any).
>   $(1)-legal-info: $(1)-patch
> -endif
>
>   # We only save the sources of packages we want to redistribute, that are
>   # non-local, and non-overriden. So only store, in the manifest, the tarball
> @@ -826,6 +824,11 @@ ifeq ($$($(2)_REDISTRIBUTE),YES)
>   	$$(Q)$$(call hardlink-copy,\
>   		     $$(DL_DIR)/$$($(2)_ACTUAL_SOURCE_TARBALL),\
>   		     $$($(2)_REDIST_SOURCES_DIR))
> +# Copy patches and generate the series file
> +	$$(Q)while read f; do \
> +		$$(call hardlink-copy,$$$${f},$$($(2)_REDIST_SOURCES_DIR)) || exit 1; \
> +		printf "%s\n" "$$$${f##*/}" >>$$($(2)_REDIST_SOURCES_DIR)/series || exit 1; \
> +	done <$$($(2)_DIR)/.applied_patches_list
>   endif # redistribute
>
>   endif # other packages
> diff --git a/support/legal-info/README.header b/support/legal-info/README.header
> index d07c45d..0b5aa66 100644
> --- a/support/legal-info/README.header
> +++ b/support/legal-info/README.header
> @@ -14,10 +14,11 @@ This material is composed of the following items.
>      compiled programs.
>      Note: this may have not been saved due to technical limitations, you may
>      need to collect it manually.
> - * The source code for all packages; this has been saved in the sources/
> -   subdirectory (except for the non-redistributable packages, which have not
> -   been saved); patches applied to some packages by Buildroot are included in
> -   the Buildroot sources and were not duplicated in the sources/ subdirectory.
> + * The original source code for all packages; this has been saved in theo

theo -> the

With that fixed:
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>

You already carried my Tested-by tag, I re-tested this and it works
fine.

-- 
Luca

  reply	other threads:[~2016-01-31 10:18 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 18:15 [Buildroot] [PATCH 0/16 v3] legal-info improvements and completeness (branch yem/legal-2) Yann E. MORIN
2016-01-28 18:14 ` [Buildroot] [PATCH 01/16 v3] core/legal-info: update the legal-info report header Yann E. MORIN
2016-02-01 22:42   ` Thomas Petazzoni
2016-01-28 18:15 ` [Buildroot] [PATCH 02/16 v3] toolchain/external: add hashes for actual sources Yann E. MORIN
2016-01-31 22:30   ` Arnout Vandecappelle
2016-02-01 13:54     ` Yann E. MORIN
2016-02-01 14:08       ` Arnout Vandecappelle
2016-01-28 18:15 ` [Buildroot] [PATCH 03/16 v3] core/pkg-utils: add macro to hardlink-or-copy Yann E. MORIN
2016-01-30 11:29   ` Luca Ceresoli
2016-01-30 11:55     ` Yann E. MORIN
2016-01-31 22:43   ` Arnout Vandecappelle
2016-02-01 10:13     ` Luca Ceresoli
2016-02-01 11:22       ` Arnout Vandecappelle
2016-01-28 18:15 ` [Buildroot] [PATCH 04/16 v3] core/legal-info: use the macro to install source archives Yann E. MORIN
2016-01-28 18:15 ` [Buildroot] [PATCH 05/16 v3] core/pkg-generic: reorder variables definitions for legal-info Yann E. MORIN
2016-01-30 15:02   ` Luca Ceresoli
2016-01-30 15:46     ` Yann E. MORIN
2016-01-31 22:47   ` Arnout Vandecappelle
2016-01-28 18:15 ` [Buildroot] [PATCH 06/16 v3] core/legal-info: ensure legal-info works in off-line mode Yann E. MORIN
2016-01-30 14:56   ` Luca Ceresoli
2016-01-30 15:24     ` Yann E. MORIN
2016-01-30 15:31       ` Luca Ceresoli
2016-01-30 15:43         ` Yann E. MORIN
2016-01-28 18:15 ` [Buildroot] [PATCH 07/16 v3] core/pkg-generic: add variable to store the package rawname-version Yann E. MORIN
2016-01-28 18:15 ` [Buildroot] [PATCH 08/16 v3] core/legal-info: install source archives in their own sub-dir Yann E. MORIN
2016-01-28 18:15 ` [Buildroot] [PATCH 09/16 v3] core/legal-info: add package version to license directory Yann E. MORIN
2016-01-28 18:15 ` [Buildroot] [PATCH 10/16 v3] core/apply-patches: store full path of applied patches Yann E. MORIN
2016-01-28 18:15 ` [Buildroot] [PATCH 11/16 v3] core/legal-info: also save patches Yann E. MORIN
2016-01-31 10:18   ` Luca Ceresoli [this message]
2016-01-28 18:15 ` [Buildroot] [PATCH 12/16 v3] core/legal-info: renumber saved patches Yann E. MORIN
2016-01-31 19:42   ` Luca Ceresoli
2016-01-31 20:02     ` Yann E. MORIN
2016-01-28 18:15 ` [Buildroot] [PATCH 13/16 v3] core/legal-info: also save extra downloads Yann E. MORIN
2016-01-31 14:38   ` Luca Ceresoli
2016-01-28 18:15 ` [Buildroot] [PATCH 14/16 v3] core/legal-info: generate a hash of all saved files Yann E. MORIN
2016-01-31 14:40   ` Luca Ceresoli
2016-01-28 18:15 ` [Buildroot] [PATCH 15/16 v3] core/legal-info: allow ignoring packages from the legal-info Yann E. MORIN
2016-01-31 20:11   ` Luca Ceresoli
2016-01-31 21:44     ` Yann E. MORIN
2016-01-28 18:15 ` [Buildroot] [PATCH 16/16 v3] core/pkg-virtual: ignore from legal-info output Yann E. MORIN
2016-02-01  9:07   ` Luca Ceresoli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56ADDF5B.9040300@lucaceresoli.net \
    --to=luca@lucaceresoli.net \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.