[PATCH] Use GBP_EXPORT_ORIG_OPTIONS for dpg-gbp export command

[PATCH] Use GBP_EXPORT_ORIG_OPTIONS for dpg-gbp export command

[Uladzimir Bely]

Since we now use `gbp export-orig <options>` and they need different
options than `gbp buildpackage`, we should store these options in
different variable.

This patch intruduces `GBP_EXPORT_ORIG_OPTINS` variable and
describes it in RECIPE-API-CHANGELOG.

Signed-off-by: Uladzimir Bely <ubely@ilbers.de>
---
 RECIPE-API-CHANGELOG.md       | 16 ++++++++++++++++
 meta/classes/dpkg-gbp.bbclass |  4 ++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
index 0bb83389..8013e585 100644
--- a/RECIPE-API-CHANGELOG.md
+++ b/RECIPE-API-CHANGELOG.md
@@ -441,3 +441,19 @@ exist, empty variables are forwarded.
 
 **Note about reproducibility**: the forwarded variables must not have any influence on the generated package.
 This mechanism must also not be used to inject build configurations. For these cases, templates should be used.
+
+### Switch to `gbp export-orig` and `GBP_EXPORT_ORIG_OPTIONS`
+
+Since Debian Stretch support is removed, we can now use short `gbp export-orig`
+instead of long `gbp buildpackage --git-ignore-new --git-builder=/bin/true`
+to prepare gbp-based sources for building.
+
+Options for `export-orig` should be specified with `GBP_EXPORT_ORIG_OPTIONS`
+variable in favor of previously used `GBP_EXTRA_OPTIONS` one. For example:
+
+```
+GBP_EXTRA_OPTIONS = "--git-no-pristine-tar --git-upstream-branch=master"
+GBP_EXPORT_ORIG_OPTIONS = "--no-pristine-tar --upstream-branch=master"
+```
+
+To support both old and new Isar, custom recipe should have both variables.
diff --git a/meta/classes/dpkg-gbp.bbclass b/meta/classes/dpkg-gbp.bbclass
index f765eb9a..4e29f62d 100644
--- a/meta/classes/dpkg-gbp.bbclass
+++ b/meta/classes/dpkg-gbp.bbclass
@@ -9,13 +9,13 @@ S = "${WORKDIR}/git"
 
 PATCHTOOL ?= "git"
 
-GBP_EXTRA_OPTIONS ?= "--pristine-tar"
+GBP_EXPORT_ORIG_OPTIONS ?= "--pristine-tar"
 
 SCHROOT_MOUNTS = "${WORKDIR}:${PP} ${GITDIR}:/home/.git-downloads"
 
 dpkg_runbuild_prepend() {
     sh -c "
         cd ${WORKDIR}/${PPS}
-        gbp export-orig ${GBP_EXTRA_OPTIONS}
+        gbp export-orig ${GBP_EXPORT_ORIG_OPTIONS}
     "
 }
-- 
2.20.1

Re: [PATCH] Use GBP_EXPORT_ORIG_OPTIONS for dpg-gbp export command

[Jan Kiszka]

On 04.01.23 07:51, Uladzimir Bely wrote:
> Since we now use `gbp export-orig <options>` and they need different
> options than `gbp buildpackage`, we should store these options in
> different variable.
> 
> This patch intruduces `GBP_EXPORT_ORIG_OPTINS` variable and
> describes it in RECIPE-API-CHANGELOG.
> 
> Signed-off-by: Uladzimir Bely <ubely@ilbers.de>
> ---
>  RECIPE-API-CHANGELOG.md       | 16 ++++++++++++++++
>  meta/classes/dpkg-gbp.bbclass |  4 ++--
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
> index 0bb83389..8013e585 100644
> --- a/RECIPE-API-CHANGELOG.md
> +++ b/RECIPE-API-CHANGELOG.md
> @@ -441,3 +441,19 @@ exist, empty variables are forwarded.
>  
>  **Note about reproducibility**: the forwarded variables must not have any influence on the generated package.
>  This mechanism must also not be used to inject build configurations. For these cases, templates should be used.
> +
> +### Switch to `gbp export-orig` and `GBP_EXPORT_ORIG_OPTIONS`
> +
> +Since Debian Stretch support is removed, we can now use short `gbp export-orig`
> +instead of long `gbp buildpackage --git-ignore-new --git-builder=/bin/true`
> +to prepare gbp-based sources for building.
> +
> +Options for `export-orig` should be specified with `GBP_EXPORT_ORIG_OPTIONS`
> +variable in favor of previously used `GBP_EXTRA_OPTIONS` one. For example:
> +
> +```
> +GBP_EXTRA_OPTIONS = "--git-no-pristine-tar --git-upstream-branch=master"
> +GBP_EXPORT_ORIG_OPTIONS = "--no-pristine-tar --upstream-branch=master"
> +```
> +
> +To support both old and new Isar, custom recipe should have both variables.
> diff --git a/meta/classes/dpkg-gbp.bbclass b/meta/classes/dpkg-gbp.bbclass
> index f765eb9a..4e29f62d 100644
> --- a/meta/classes/dpkg-gbp.bbclass
> +++ b/meta/classes/dpkg-gbp.bbclass
> @@ -9,13 +9,13 @@ S = "${WORKDIR}/git"
>  
>  PATCHTOOL ?= "git"
>  
> -GBP_EXTRA_OPTIONS ?= "--pristine-tar"
> +GBP_EXPORT_ORIG_OPTIONS ?= "--pristine-tar"
>  
>  SCHROOT_MOUNTS = "${WORKDIR}:${PP} ${GITDIR}:/home/.git-downloads"
>  
>  dpkg_runbuild_prepend() {
>      sh -c "
>          cd ${WORKDIR}/${PPS}
> -        gbp export-orig ${GBP_EXTRA_OPTIONS}
> +        gbp export-orig ${GBP_EXPORT_ORIG_OPTIONS}
>      "
>  }

Should we issue an error when we detect the usage of the old var?

Otherwise, this looks good to me.

Thanks,
Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH] Use GBP_EXPORT_ORIG_OPTIONS for dpg-gbp export command

[Henning Schild]

Am Wed,  4 Jan 2023 07:51:41 +0100
schrieb Uladzimir Bely <ubely@ilbers.de>:

> Since we now use `gbp export-orig <options>` and they need different
> options than `gbp buildpackage`, we should store these options in
> different variable.
>
> This patch intruduces `GBP_EXPORT_ORIG_OPTINS` 

GBP_EXPORT_ORIG_OPTIONS

> variable and
> describes it in RECIPE-API-CHANGELOG.
> 
> Signed-off-by: Uladzimir Bely <ubely@ilbers.de>
> ---
>  RECIPE-API-CHANGELOG.md       | 16 ++++++++++++++++
>  meta/classes/dpkg-gbp.bbclass |  4 ++--
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
> index 0bb83389..8013e585 100644
> --- a/RECIPE-API-CHANGELOG.md
> +++ b/RECIPE-API-CHANGELOG.md
> @@ -441,3 +441,19 @@ exist, empty variables are forwarded.
>  
>  **Note about reproducibility**: the forwarded variables must not
> have any influence on the generated package. This mechanism must also
> not be used to inject build configurations. For these cases,
> templates should be used. + +### Switch to `gbp export-orig` and
> `GBP_EXPORT_ORIG_OPTIONS` +
> +Since Debian Stretch support is removed, we can now use short `gbp
> export-orig` +instead of long `gbp buildpackage --git-ignore-new
> --git-builder=/bin/true` +to prepare gbp-based sources for building.
> +
> +Options for `export-orig` should be specified with
> `GBP_EXPORT_ORIG_OPTIONS` +variable in favor of previously used
> `GBP_EXTRA_OPTIONS` one. For example: +
> +```
> +GBP_EXTRA_OPTIONS = "--git-no-pristine-tar
> --git-upstream-branch=master" +GBP_EXPORT_ORIG_OPTIONS =
> "--no-pristine-tar --upstream-branch=master" +```
> +
> +To support both old and new Isar, custom recipe should have both
> variables. diff --git a/meta/classes/dpkg-gbp.bbclass
> b/meta/classes/dpkg-gbp.bbclass index f765eb9a..4e29f62d 100644
> --- a/meta/classes/dpkg-gbp.bbclass
> +++ b/meta/classes/dpkg-gbp.bbclass
> @@ -9,13 +9,13 @@ S = "${WORKDIR}/git"
>  
>  PATCHTOOL ?= "git"
>  
> -GBP_EXTRA_OPTIONS ?= "--pristine-tar"
> +GBP_EXPORT_ORIG_OPTIONS ?= "--pristine-tar"
>  
>  SCHROOT_MOUNTS = "${WORKDIR}:${PP} ${GITDIR}:/home/.git-downloads"
>  
>  dpkg_runbuild_prepend() {
>      sh -c "
>          cd ${WORKDIR}/${PPS}
> -        gbp export-orig ${GBP_EXTRA_OPTIONS}
> +        gbp export-orig ${GBP_EXPORT_ORIG_OPTIONS}
>      "
>  }

Re: [PATCH] Use GBP_EXPORT_ORIG_OPTIONS for dpg-gbp export command

[Henning Schild]

Am Wed, 4 Jan 2023 09:20:41 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 04.01.23 07:51, Uladzimir Bely wrote:
> > Since we now use `gbp export-orig <options>` and they need different
> > options than `gbp buildpackage`, we should store these options in
> > different variable.
> > 
> > This patch intruduces `GBP_EXPORT_ORIG_OPTINS` variable and
> > describes it in RECIPE-API-CHANGELOG.
> > 
> > Signed-off-by: Uladzimir Bely <ubely@ilbers.de>
> > ---
> >  RECIPE-API-CHANGELOG.md       | 16 ++++++++++++++++
> >  meta/classes/dpkg-gbp.bbclass |  4 ++--
> >  2 files changed, 18 insertions(+), 2 deletions(-)
> > 
> > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
> > index 0bb83389..8013e585 100644
> > --- a/RECIPE-API-CHANGELOG.md
> > +++ b/RECIPE-API-CHANGELOG.md
> > @@ -441,3 +441,19 @@ exist, empty variables are forwarded.
> >  
> >  **Note about reproducibility**: the forwarded variables must not
> > have any influence on the generated package. This mechanism must
> > also not be used to inject build configurations. For these cases,
> > templates should be used. + +### Switch to `gbp export-orig` and
> > `GBP_EXPORT_ORIG_OPTIONS` +
> > +Since Debian Stretch support is removed, we can now use short `gbp
> > export-orig` +instead of long `gbp buildpackage --git-ignore-new
> > --git-builder=/bin/true` +to prepare gbp-based sources for building.
> > +
> > +Options for `export-orig` should be specified with
> > `GBP_EXPORT_ORIG_OPTIONS` +variable in favor of previously used
> > `GBP_EXTRA_OPTIONS` one. For example: +
> > +```
> > +GBP_EXTRA_OPTIONS = "--git-no-pristine-tar
> > --git-upstream-branch=master" +GBP_EXPORT_ORIG_OPTIONS =
> > "--no-pristine-tar --upstream-branch=master" +```
> > +
> > +To support both old and new Isar, custom recipe should have both
> > variables. diff --git a/meta/classes/dpkg-gbp.bbclass
> > b/meta/classes/dpkg-gbp.bbclass index f765eb9a..4e29f62d 100644
> > --- a/meta/classes/dpkg-gbp.bbclass
> > +++ b/meta/classes/dpkg-gbp.bbclass
> > @@ -9,13 +9,13 @@ S = "${WORKDIR}/git"
> >  
> >  PATCHTOOL ?= "git"
> >  
> > -GBP_EXTRA_OPTIONS ?= "--pristine-tar"
> > +GBP_EXPORT_ORIG_OPTIONS ?= "--pristine-tar"
> >  
> >  SCHROOT_MOUNTS = "${WORKDIR}:${PP} ${GITDIR}:/home/.git-downloads"
> >  
> >  dpkg_runbuild_prepend() {
> >      sh -c "
> >          cd ${WORKDIR}/${PPS}
> > -        gbp export-orig ${GBP_EXTRA_OPTIONS}
> > +        gbp export-orig ${GBP_EXPORT_ORIG_OPTIONS}
> >      "
> >  }  
> 
> Should we issue an error when we detect the usage of the old var?

I would be for bringing back the old code if the old var is
set. Which will again allow us to gbp any random upstream repo from
github and not only the ones that are prepared for gpb ... like the
ones on salsa.
Maybe we need an example for that in meta-isar ...

If GBP_EXTRA_OPTION is set we go that road, if GBP_EXTRA ... the new
road ... if both bbfatal invalid recipe, and not like the changelog
which suggests recipes in layers should carry both.

I do not fully understand why we break all that in the first place, can
we not just go back to where things have been. What is the benefit if
the change that slipped in with stretch removal?

Henning

> 
> Otherwise, this looks good to me.
> 
> Thanks,
> Jan
>