[PATCH 0/3] Implement hello <-> libhello pattern

[PATCH 0/3] Implement hello <-> libhello pattern

[Alexander Smirnov]

This series intended to add Isar build dependencies between recipes.

Overall concept:
 - A new recipe is added to Isar - libhello.
 - 'hello' application was modified, not it has 'libhello-dev' as build
   dependency.

Issues:
 - At the moment there is no support for Isar-apt in buildchroot, so no
   clear way to install 'libhello-dev' during building 'hello'
   application. To satisfy it for now, I've added line to install newly
   built packages right after compilation (see patch 2).

I'm going to improve Isar-apt support to avoid the issue mentioned
above. Isar-apt looks for me as a bit complicated change, so I'd
suggest to commit this series as intermediate small step.

NOTE: please don't pay attention to SRC_URI. I'm sharing my current
tested state. Before merging this to Isar I'll update hello/libhello
repositories and point SRC_URIs to master branches.

Alex

Alexander Smirnov (3):
  dpkg-base: Add dependecies between Isar recipes
  build.sh: Install newly built packages
  libhello: Add libhello

 meta-isar/recipes-app/example-hello/example-hello.bb |  7 +++++--
 meta-isar/recipes-app/libhello/libhello.bb           | 18 ++++++++++++++++++
 meta/classes/dpkg-base.bbclass                       |  4 ++++
 meta/recipes-devtools/buildchroot/files/build.sh     |  3 +++
 4 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 meta-isar/recipes-app/libhello/libhello.bb

-- 
2.1.4

[PATCH 1/3] dpkg-base: Add dependecies between Isar recipes

[Alexander Smirnov]

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta/classes/dpkg-base.bbclass | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/dpkg-base.bbclass b/meta/classes/dpkg-base.bbclass
index 4941f9b..568d847 100644
--- a/meta/classes/dpkg-base.bbclass
+++ b/meta/classes/dpkg-base.bbclass
@@ -4,6 +4,10 @@
 # Add dependency from buildchroot creation
 do_build[depends] = "buildchroot:do_build"
 
+# Add dependency between Isar recipes
+DEPENDS ?= ""
+do_build[deptask] = "do_deploy_deb"
+
 # Each package should have its own unique build folder, so use
 # recipe name as identifier
 PP = "/home/builder/${PN}"
-- 
2.1.4

Re: [PATCH 1/3] dpkg-base: Add dependecies between Isar recipes

[Jan Kiszka]

On 2018-01-25 09:38, Alexander Smirnov wrote:
> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> ---
>  meta/classes/dpkg-base.bbclass | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/meta/classes/dpkg-base.bbclass b/meta/classes/dpkg-base.bbclass
> index 4941f9b..568d847 100644
> --- a/meta/classes/dpkg-base.bbclass
> +++ b/meta/classes/dpkg-base.bbclass
> @@ -4,6 +4,10 @@
>  # Add dependency from buildchroot creation
>  do_build[depends] = "buildchroot:do_build"
>  
> +# Add dependency between Isar recipes
> +DEPENDS ?= ""
> +do_build[deptask] = "do_deploy_deb"
> +
>  # Each package should have its own unique build folder, so use
>  # recipe name as identifier
>  PP = "/home/builder/${PN}"
> 

Please don't forget to merge this useful patch soon so that DEPENDS
works properly.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 1/3] dpkg-base: Add dependecies between Isar recipes

[chombourger]

[-- Attachment #1.1: Type: text/plain, Size: 1174 bytes --]

+1 - this would allow us to remove one more local patch from our isar-based 
project :)

On Monday, February 5, 2018 at 8:40:08 PM UTC+1, Jan Kiszka wrote:
>
> On 2018-01-25 09:38, Alexander Smirnov wrote: 
> > Signed-off-by: Alexander Smirnov <asmi...@ilbers.de <javascript:>> 
> > --- 
> >  meta/classes/dpkg-base.bbclass | 4 ++++ 
> >  1 file changed, 4 insertions(+) 
> > 
> > diff --git a/meta/classes/dpkg-base.bbclass 
> b/meta/classes/dpkg-base.bbclass 
> > index 4941f9b..568d847 100644 
> > --- a/meta/classes/dpkg-base.bbclass 
> > +++ b/meta/classes/dpkg-base.bbclass 
> > @@ -4,6 +4,10 @@ 
> >  # Add dependency from buildchroot creation 
> >  do_build[depends] = "buildchroot:do_build" 
> >   
> > +# Add dependency between Isar recipes 
> > +DEPENDS ?= "" 
> > +do_build[deptask] = "do_deploy_deb" 
> > + 
> >  # Each package should have its own unique build folder, so use 
> >  # recipe name as identifier 
> >  PP = "/home/builder/${PN}" 
> > 
>
> Please don't forget to merge this useful patch soon so that DEPENDS 
> works properly. 
>
> Jan 
>
> -- 
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE 
> Corporate Competence Center Embedded Linux 
>

[-- Attachment #1.2: Type: text/html, Size: 1732 bytes --]

Re: [PATCH 1/3] dpkg-base: Add dependecies between Isar recipes

[Alexander Smirnov]

On 02/06/2018 01:10 PM, chombourger@gmail.com wrote:
> +1 - this would allow us to remove one more local patch from our 
> isar-based project :)
Applied to next (only this patch).

Alex

[PATCH 2/3] build.sh: Install newly built packages

[Alexander Smirnov]

Install the debs to buildchroot immediately. This should go when Isar
apt will be integrated to buildchroot, so the next packages will be
able to populate build dependencies via 'apt-get install'.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta/recipes-devtools/buildchroot/files/build.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/buildchroot/files/build.sh b/meta/recipes-devtools/buildchroot/files/build.sh
index 975252e..a04f3b6 100644
--- a/meta/recipes-devtools/buildchroot/files/build.sh
+++ b/meta/recipes-devtools/buildchroot/files/build.sh
@@ -19,3 +19,6 @@ done
 
 # Build the package
 LC_ALL=C LANG=C dpkg-buildpackage
+
+# Install newly built packages
+dpkg -i ../*.deb
-- 
2.1.4

Re: [PATCH 2/3] build.sh: Install newly built packages

[Jan Kiszka]

On 2018-01-25 09:38, Alexander Smirnov wrote:
> Install the debs to buildchroot immediately. This should go when Isar
> apt will be integrated to buildchroot, so the next packages will be
> able to populate build dependencies via 'apt-get install'.

What makes adding the local repo to the buildchroot so complex? I would
assume it's just

- creating an empty repo already during buildchroot setup
- adding the additional source to buildchroot's multistrap.conf
- be happy

Unless I'm missing something, I can hack this up tomorrow.

Jan

PS: Patch 1 works nicely.

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 2/3] build.sh: Install newly built packages

[Alexander Smirnov]

On 01/31/2018 10:39 PM, Jan Kiszka wrote:
> On 2018-01-25 09:38, Alexander Smirnov wrote:
>> Install the debs to buildchroot immediately. This should go when Isar
>> apt will be integrated to buildchroot, so the next packages will be
>> able to populate build dependencies via 'apt-get install'.
> 
> What makes adding the local repo to the buildchroot so complex? I would
> assume it's just
> 
> - creating an empty repo already during buildchroot setup

The repo is already created outside the buildchroot.

> - adding the additional source to buildchroot's multistrap.conf
> - be happy
> 

The isar-apt should be visible in buildchroot, so:
  - We need to 'mount --bind' apt folder to buildchroot before packages 
build started.
  - Unmount this folder when all the packages are built.
  - Cleanup the mount point if build fails.

I have working concept now, I'll send the series tomorrow.

Apart from changes above I've also fixed reprepro races protection and 
isar-apt population.

Alex

Re: [PATCH 2/3] build.sh: Install newly built packages

[Jan Kiszka]

On 2018-01-31 20:55, Alexander Smirnov wrote:
> On 01/31/2018 10:39 PM, Jan Kiszka wrote:
>> On 2018-01-25 09:38, Alexander Smirnov wrote:
>>> Install the debs to buildchroot immediately. This should go when Isar
>>> apt will be integrated to buildchroot, so the next packages will be
>>> able to populate build dependencies via 'apt-get install'.
>>
>> What makes adding the local repo to the buildchroot so complex? I would
>> assume it's just
>>
>> - creating an empty repo already during buildchroot setup
> 
> The repo is already created outside the buildchroot.
> 
>> - adding the additional source to buildchroot's multistrap.conf
>> - be happy
>>
> 
> The isar-apt should be visible in buildchroot, so:
>  - We need to 'mount --bind' apt folder to buildchroot before packages
> build started.
>  - Unmount this folder when all the packages are built.
>  - Cleanup the mount point if build fails.
> 
> I have working concept now, I'll send the series tomorrow.
> 
> Apart from changes above I've also fixed reprepro races protection and
> isar-apt population.

Great, looking forward!

I've just switched my Jailhouse demo-image build over to the custom
kernel recipe helper I'm preparing, and proper Build-Depends support
would make the recipes even nicer.

Jan

Re: [PATCH 2/3] build.sh: Install newly built packages

[Benedikt Niedermayr]

Am 31.01.2018 um 21:01 schrieb Jan Kiszka:
> On 2018-01-31 20:55, Alexander Smirnov wrote:
>> On 01/31/2018 10:39 PM, Jan Kiszka wrote:
>>> On 2018-01-25 09:38, Alexander Smirnov wrote:
>>>> Install the debs to buildchroot immediately. This should go when Isar
>>>> apt will be integrated to buildchroot, so the next packages will be
>>>> able to populate build dependencies via 'apt-get install'.
>>> What makes adding the local repo to the buildchroot so complex? I would
>>> assume it's just
>>>
>>> - creating an empty repo already during buildchroot setup
>> The repo is already created outside the buildchroot.
>>
>>> - adding the additional source to buildchroot's multistrap.conf
>>> - be happy
>>>
>> The isar-apt should be visible in buildchroot, so:
>>   - We need to 'mount --bind' apt folder to buildchroot before packages
>> build started.
>>   - Unmount this folder when all the packages are built.
>>   - Cleanup the mount point if build fails.
>>
>> I have working concept now, I'll send the series tomorrow.
>>
>> Apart from changes above I've also fixed reprepro races protection and
>> isar-apt population.
> Great, looking forward!
>
> I've just switched my Jailhouse demo-image build over to the custom
> kernel recipe helper I'm preparing, and proper Build-Depends support
> would make the recipes even nicer.
>
> Jan
>
Am I right, that building own packages from own repositories is not 
supported yet by Isar?

When I take a look into dpkg-raw class, I can see that dpkg_runbuild() 
only creates a debian package, but does not build the package out from 
it sources?

Do I miss something here?


Benni

Re: [PATCH 2/3] build.sh: Install newly built packages

[Alexander Smirnov]

On 02/01/2018 10:49 AM, Benedikt Niedermayr wrote:
> Am 31.01.2018 um 21:01 schrieb Jan Kiszka:
>> On 2018-01-31 20:55, Alexander Smirnov wrote:
>>> On 01/31/2018 10:39 PM, Jan Kiszka wrote:
>>>> On 2018-01-25 09:38, Alexander Smirnov wrote:
>>>>> Install the debs to buildchroot immediately. This should go when Isar
>>>>> apt will be integrated to buildchroot, so the next packages will be
>>>>> able to populate build dependencies via 'apt-get install'.
>>>> What makes adding the local repo to the buildchroot so complex? I would
>>>> assume it's just
>>>>
>>>> - creating an empty repo already during buildchroot setup
>>> The repo is already created outside the buildchroot.
>>>
>>>> - adding the additional source to buildchroot's multistrap.conf
>>>> - be happy
>>>>
>>> The isar-apt should be visible in buildchroot, so:
>>>   - We need to 'mount --bind' apt folder to buildchroot before packages
>>> build started.
>>>   - Unmount this folder when all the packages are built.
>>>   - Cleanup the mount point if build fails.
>>>
>>> I have working concept now, I'll send the series tomorrow.
>>>
>>> Apart from changes above I've also fixed reprepro races protection and
>>> isar-apt population.
>> Great, looking forward!
>>
>> I've just switched my Jailhouse demo-image build over to the custom
>> kernel recipe helper I'm preparing, and proper Build-Depends support
>> would make the recipes even nicer.
>>
>> Jan
>>
> Am I right, that building own packages from own repositories is not 
> supported yet by Isar?

Doch! :-)

> 
> When I take a look into dpkg-raw class, I can see that dpkg_runbuild() 
> only creates a debian package, but does not build the package out from 
> it sources?

Please take a look to dpkg class and to example-hello application.

Alex

Re: [PATCH 2/3] build.sh: Install newly built packages

[Benedikt Niedermayr]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

Am 01.02.2018 um 09:07 schrieb Alexander Smirnov:
> Please take a look to dpkg class and to example-hello application. 

Ok,

but when I look into example-hello then I'm able to comprehend that, but

when I take look at example-raw which only inlcudes dpkg-raw then I 
can't see any possibility to build

the package out from its sources.


So when including dpkg.bbclass then I'm able to build out from sources.

But when I also need to "debianize" my sources I have to include 
dpkg-raw, which in turn will overwrite the

dpkg_runbuild task.

I think the dpkg_runbuild of dpkg-raw should also call "sudo chroot 
${BUILDCHROOT_DIR} /build.sh ${PP}/${SRC_DIR}" ?


Bennie







[-- Attachment #2: Type: text/html, Size: 2174 bytes --]

Re: [PATCH 2/3] build.sh: Install newly built packages

[Jan Kiszka]

On 2018-02-01 11:09, 'Benedikt Niedermayr' via isar-users wrote:
> Am 01.02.2018 um 09:07 schrieb Alexander Smirnov:
>> Please take a look to dpkg class and to example-hello application. 
> 
> Ok,
> 
> but when I look into example-hello then I'm able to comprehend that, but
> 
> when I take look at example-raw which only inlcudes dpkg-raw then I
> can't see any possibility to build
> 
> the package out from its sources.
> 
> 
> So when including dpkg.bbclass then I'm able to build out from sources.
> 
> But when I also need to "debianize" my sources I have to include
> dpkg-raw, which in turn will overwrite the
> 
> dpkg_runbuild task.
> 
> I think the dpkg_runbuild of dpkg-raw should also call "sudo chroot
> ${BUILDCHROOT_DIR} /build.sh ${PP}/${SRC_DIR}" ?

There are currently three ways to build a package:

- the sources comes with debian/ control files
   -> inherit dpkg
- the sources are not debianized and you don't want to do that
   -> inherit dpkg-raw, build manually (if needed at all), define
      artifacts and let the raw class do that ad-hoc binary packaging
- the sources are not debianized, but your recipe can fill that gap
   -> inherit dpkg-base, provide a debian/ folder, overload
      dpkg_runbuild to trigger a debianized build

I'm going the last path with the upcoming custom kernel recipe.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[PATCH 3/3] libhello: Add libhello

[Alexander Smirnov]

'libhello' package intended to demonstrate Isar build dependencies between
recipes.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta-isar/recipes-app/example-hello/example-hello.bb |  7 +++++--
 meta-isar/recipes-app/libhello/libhello.bb           | 18 ++++++++++++++++++
 2 files changed, 23 insertions(+), 2 deletions(-)
 create mode 100644 meta-isar/recipes-app/libhello/libhello.bb

diff --git a/meta-isar/recipes-app/example-hello/example-hello.bb b/meta-isar/recipes-app/example-hello/example-hello.bb
index 114ee85..19f9d69 100644
--- a/meta-isar/recipes-app/example-hello/example-hello.bb
+++ b/meta-isar/recipes-app/example-hello/example-hello.bb
@@ -8,10 +8,13 @@ DESCRIPTION = "Sample application for ISAR"
 LICENSE = "gpl-2.0"
 LIC_FILES_CHKSUM = "file://${LAYERDIR_isar}/licenses/COPYING.GPLv2;md5=751419260aa954499f7abaabaa882bbe"
 
-PV = "0.1+g7f35942-1"
+PV = "0.2"
+
+DEPENDS += "libhello"
 
 SRC_URI = "git://github.com/ilbers/hello.git;branch=devel;protocol=https"
-SRCREV = "5c0ae73fdc97d80b6726e602a1fa0ef00c2c012a"
+SRCREV = "ffca497b3f8157efe3eb6fab97a88045142591ae"
+
 
 SRC_DIR = "git"
 
diff --git a/meta-isar/recipes-app/libhello/libhello.bb b/meta-isar/recipes-app/libhello/libhello.bb
new file mode 100644
index 0000000..4caaf2d
--- /dev/null
+++ b/meta-isar/recipes-app/libhello/libhello.bb
@@ -0,0 +1,18 @@
+# Sample shared library
+#
+# This software is a part of ISAR.
+# Copyright (C) 2017-2018 ilbers GmbH
+
+DESCRIPTION = "Sample shared library for ISAR"
+
+LICENSE = "gpl-2.0"
+LIC_FILES_CHKSUM = "file://${LAYERDIR_isar}/licenses/COPYING.GPLv2;md5=751419260aa954499f7abaabaa882bbe"
+
+PV = "0.1"
+
+SRC_URI = "git://github.com/alexbluesman/libhello.git;protocol=https"
+SRCREV = "1671f0287fe0bca8937f687f53a3bd05c9e2d9c2"
+
+SRC_DIR = "git"
+
+inherit dpkg
-- 
2.1.4

Re: [PATCH 3/3] libhello: Add libhello

[Jan Kiszka]

On 2018-01-25 09:38, Alexander Smirnov wrote:
> 'libhello' package intended to demonstrate Isar build dependencies between
> recipes.
> 
> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> ---
>  meta-isar/recipes-app/example-hello/example-hello.bb |  7 +++++--
>  meta-isar/recipes-app/libhello/libhello.bb           | 18 ++++++++++++++++++
>  2 files changed, 23 insertions(+), 2 deletions(-)
>  create mode 100644 meta-isar/recipes-app/libhello/libhello.bb
> 
> diff --git a/meta-isar/recipes-app/example-hello/example-hello.bb b/meta-isar/recipes-app/example-hello/example-hello.bb
> index 114ee85..19f9d69 100644
> --- a/meta-isar/recipes-app/example-hello/example-hello.bb
> +++ b/meta-isar/recipes-app/example-hello/example-hello.bb
> @@ -8,10 +8,13 @@ DESCRIPTION = "Sample application for ISAR"
>  LICENSE = "gpl-2.0"
>  LIC_FILES_CHKSUM = "file://${LAYERDIR_isar}/licenses/COPYING.GPLv2;md5=751419260aa954499f7abaabaa882bbe"
>  
> -PV = "0.1+g7f35942-1"
> +PV = "0.2"
> +
> +DEPENDS += "libhello"

Should be marked as workaround. How hard would it be do extend
dpkg[-base?].class with some "DEPENDS += "${@
get_deps_from_debian_control()}"? We probably also need some translation
from the debian package name / aliases into bitbake PROVIDES variables.

Jan

>  
>  SRC_URI = "git://github.com/ilbers/hello.git;branch=devel;protocol=https"
> -SRCREV = "5c0ae73fdc97d80b6726e602a1fa0ef00c2c012a"
> +SRCREV = "ffca497b3f8157efe3eb6fab97a88045142591ae"
> +
>  
>  SRC_DIR = "git"
>  
> diff --git a/meta-isar/recipes-app/libhello/libhello.bb b/meta-isar/recipes-app/libhello/libhello.bb
> new file mode 100644
> index 0000000..4caaf2d
> --- /dev/null
> +++ b/meta-isar/recipes-app/libhello/libhello.bb
> @@ -0,0 +1,18 @@
> +# Sample shared library
> +#
> +# This software is a part of ISAR.
> +# Copyright (C) 2017-2018 ilbers GmbH
> +
> +DESCRIPTION = "Sample shared library for ISAR"
> +
> +LICENSE = "gpl-2.0"
> +LIC_FILES_CHKSUM = "file://${LAYERDIR_isar}/licenses/COPYING.GPLv2;md5=751419260aa954499f7abaabaa882bbe"
> +
> +PV = "0.1"
> +
> +SRC_URI = "git://github.com/alexbluesman/libhello.git;protocol=https"
> +SRCREV = "1671f0287fe0bca8937f687f53a3bd05c9e2d9c2"
> +
> +SRC_DIR = "git"
> +
> +inherit dpkg
> 

Re: [PATCH 3/3] libhello: Add libhello

[Alexander Smirnov]

On 01/25/2018 12:01 PM, Jan Kiszka wrote:
> On 2018-01-25 09:38, Alexander Smirnov wrote:
>> 'libhello' package intended to demonstrate Isar build dependencies between
>> recipes.
>>
>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
>> ---
>>   meta-isar/recipes-app/example-hello/example-hello.bb |  7 +++++--
>>   meta-isar/recipes-app/libhello/libhello.bb           | 18 ++++++++++++++++++
>>   2 files changed, 23 insertions(+), 2 deletions(-)
>>   create mode 100644 meta-isar/recipes-app/libhello/libhello.bb
>>
>> diff --git a/meta-isar/recipes-app/example-hello/example-hello.bb b/meta-isar/recipes-app/example-hello/example-hello.bb
>> index 114ee85..19f9d69 100644
>> --- a/meta-isar/recipes-app/example-hello/example-hello.bb
>> +++ b/meta-isar/recipes-app/example-hello/example-hello.bb
>> @@ -8,10 +8,13 @@ DESCRIPTION = "Sample application for ISAR"
>>   LICENSE = "gpl-2.0"
>>   LIC_FILES_CHKSUM = "file://${LAYERDIR_isar}/licenses/COPYING.GPLv2;md5=751419260aa954499f7abaabaa882bbe"
>>   
>> -PV = "0.1+g7f35942-1"
>> +PV = "0.2"
>> +
>> +DEPENDS += "libhello"
> 
> Should be marked as workaround. How hard would it be do extend
> dpkg[-base?].class with some "DEPENDS += "${@
> get_deps_from_debian_control()}"?

I've covered this issue in RFC for reproducibility. Bitbake is 
statically configured tool, so it prepares pipeline *before* start of 
execution. Parsing 'debian/control' assumes that you have already done 
do_fetch() and do_unpack() for specific recipe.

But in theory I see only the following for now:

  - Double bitbake re-run: first step fetch/unpack, second stage parse 
and prepare pipeline.
  - Modify bitbake.

I consider this as hack and not as proposal.

I'll continue this investigation.

Alex

  We probably also need some translation
> from the debian package name / aliases into bitbake PROVIDES variables.
> 
> Jan
> 
>>   
>>   SRC_URI = "git://github.com/ilbers/hello.git;branch=devel;protocol=https"
>> -SRCREV = "5c0ae73fdc97d80b6726e602a1fa0ef00c2c012a"
>> +SRCREV = "ffca497b3f8157efe3eb6fab97a88045142591ae"
>> +
>>   
>>   SRC_DIR = "git"
>>   
>> diff --git a/meta-isar/recipes-app/libhello/libhello.bb b/meta-isar/recipes-app/libhello/libhello.bb
>> new file mode 100644
>> index 0000000..4caaf2d
>> --- /dev/null
>> +++ b/meta-isar/recipes-app/libhello/libhello.bb
>> @@ -0,0 +1,18 @@
>> +# Sample shared library
>> +#
>> +# This software is a part of ISAR.
>> +# Copyright (C) 2017-2018 ilbers GmbH
>> +
>> +DESCRIPTION = "Sample shared library for ISAR"
>> +
>> +LICENSE = "gpl-2.0"
>> +LIC_FILES_CHKSUM = "file://${LAYERDIR_isar}/licenses/COPYING.GPLv2;md5=751419260aa954499f7abaabaa882bbe"
>> +
>> +PV = "0.1"
>> +
>> +SRC_URI = "git://github.com/alexbluesman/libhello.git;protocol=https"
>> +SRCREV = "1671f0287fe0bca8937f687f53a3bd05c9e2d9c2"
>> +
>> +SRC_DIR = "git"
>> +
>> +inherit dpkg
>>
>

Re: [PATCH 3/3] libhello: Add libhello

[Jan Kiszka]

On 2018-01-25 11:11, Alexander Smirnov wrote:
> On 01/25/2018 12:01 PM, Jan Kiszka wrote:
>> On 2018-01-25 09:38, Alexander Smirnov wrote:
>>> 'libhello' package intended to demonstrate Isar build dependencies
>>> between
>>> recipes.
>>>
>>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
>>> ---
>>>   meta-isar/recipes-app/example-hello/example-hello.bb |  7 +++++--
>>>   meta-isar/recipes-app/libhello/libhello.bb           | 18
>>> ++++++++++++++++++
>>>   2 files changed, 23 insertions(+), 2 deletions(-)
>>>   create mode 100644 meta-isar/recipes-app/libhello/libhello.bb
>>>
>>> diff --git a/meta-isar/recipes-app/example-hello/example-hello.bb
>>> b/meta-isar/recipes-app/example-hello/example-hello.bb
>>> index 114ee85..19f9d69 100644
>>> --- a/meta-isar/recipes-app/example-hello/example-hello.bb
>>> +++ b/meta-isar/recipes-app/example-hello/example-hello.bb
>>> @@ -8,10 +8,13 @@ DESCRIPTION = "Sample application for ISAR"
>>>   LICENSE = "gpl-2.0"
>>>   LIC_FILES_CHKSUM =
>>> "file://${LAYERDIR_isar}/licenses/COPYING.GPLv2;md5=751419260aa954499f7abaabaa882bbe"
>>>
>>>   -PV = "0.1+g7f35942-1"
>>> +PV = "0.2"
>>> +
>>> +DEPENDS += "libhello"
>>
>> Should be marked as workaround. How hard would it be do extend
>> dpkg[-base?].class with some "DEPENDS += "${@
>> get_deps_from_debian_control()}"?
> 
> I've covered this issue in RFC for reproducibility. Bitbake is
> statically configured tool, so it prepares pipeline *before* start of
> execution. Parsing 'debian/control' assumes that you have already done
> do_fetch() and do_unpack() for specific recipe.
> 

Ah, ok. Too bad.

> But in theory I see only the following for now:
> 
>  - Double bitbake re-run: first step fetch/unpack, second stage parse
> and prepare pipeline.
>  - Modify bitbake.
> 
> I consider this as hack and not as proposal.
> 
> I'll continue this investigation.

Well, if these duplicate dep statements remain limited to self-built
packages, which /should/ remain few as well, we may live with that for
now. Maybe bitbake will eventually learn to update dependencies during
the run so that the two-stage processing wouldn't be needed...

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/3] Implement hello <-> libhello pattern

[Henning Schild]

Am Thu, 25 Jan 2018 11:38:48 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> This series intended to add Isar build dependencies between recipes.

Nice, this is truly needed!

> Overall concept:
>  - A new recipe is added to Isar - libhello.
>  - 'hello' application was modified, not it has 'libhello-dev' as
> build dependency.
> 
> Issues:
>  - At the moment there is no support for Isar-apt in buildchroot, so
> no clear way to install 'libhello-dev' during building 'hello'
>    application. To satisfy it for now, I've added line to install
> newly built packages right after compilation (see patch 2).
> 
> I'm going to improve Isar-apt support to avoid the issue mentioned
> above. Isar-apt looks for me as a bit complicated change, so I'd
> suggest to commit this series as intermediate small step.

I would not like to see patch2 being merged, this is just running
deeper into dept. People that have an urgent need for that can always
"dpkg -i" in their recipes, that is already happening. So when we come
up with a solution, it should be the right one and not centralizing a
known-to-work hack.

Henning

> NOTE: please don't pay attention to SRC_URI. I'm sharing my current
> tested state. Before merging this to Isar I'll update hello/libhello
> repositories and point SRC_URIs to master branches.
> 
> Alex
> 
> Alexander Smirnov (3):
>   dpkg-base: Add dependecies between Isar recipes
>   build.sh: Install newly built packages
>   libhello: Add libhello
> 
>  meta-isar/recipes-app/example-hello/example-hello.bb |  7 +++++--
>  meta-isar/recipes-app/libhello/libhello.bb           | 18
> ++++++++++++++++++
> meta/classes/dpkg-base.bbclass                       |  4 ++++
> meta/recipes-devtools/buildchroot/files/build.sh     |  3 +++ 4 files
> changed, 30 insertions(+), 2 deletions(-) create mode 100644
> meta-isar/recipes-app/libhello/libhello.bb
> 

Re: [PATCH 0/3] Implement hello <-> libhello pattern

[Baurzhan Ismagulov]

On Thu, Jan 25, 2018 at 11:38:48AM +0300, Alexander Smirnov wrote:
> This series intended to add Isar build dependencies between recipes.

Some comments on the hello / libhello themselves.


> [PATCH 1/2] Rename binary package to avoid correlations with Debian hello.
> [PATCH 2/2] Add dependency from 'libhello'.

Please remove the trailing dot from the subjects.


> diff --git a/debian/changelog b/debian/changelog
...
> +hello (0.2) unstable; urgency=low

I'd suggest to tag:

v0.1 7f35942 Add autotools
v0.2 ffca497 Add dependency from 'libhello'

Otherwise, Acked-by: Baurzhan Ismagulov <ibr@ilbers.de>.


> [PATCH] libhello: First implementation

> diff --git a/Makefile.am b/Makefile.am
...
> +DB2MAN = docbook-to-man

I think that should be in Build-Depends: (the same applies to hello).


> +man1_MANS = hello.1

I suggest say_hello.3.


> +clean-local:
> +	-$(RM) -f $(man1_MANS)

I suggest removing the leading "-" (the same applies to hello; not sure why I
used that at the time).


> diff --git a/debian/.control.swp b/debian/.control.swp

Please remove.


> diff --git a/debian/changelog b/debian/changelog
...
> +libhello (0.1) unstable; urgency=low

Suggest to tag v0.1 1671f02 libhello: First implementation.


> diff --git a/debian/control b/debian/control
...
> +Build-Depends: debhelper (>= 9), autotools-dev

Strictly speaking, autotools-dev is not needed. However, in that case the build
may fail due to timestamp mess after a git checkout (if configure.ac happens to
be newer than configure, the latter would try to rebuild itself).

Depending on autotools-dev workarounds that for the same build suite, but not
for a different one (configure generated on jessie would rebuild fine on
jessie, but possibly not on other version, since exactly the same autotools
versions are required).

That led to the following hack:

https://github.com/ilbers/isar/blob/2d56fc1242ef3e3041eb248942324eb67e9b1319/meta/recipes-devtools/buildchroot/files/build.sh#L17

I suggest:

* Dropping the autotools-dev build-dependency.

* Adding AM_MAINTAINER_MODE([disable]) to configure.ac to avoid rebuilding
  configure, Makefile.in, etc. For development, one may enable it with
  ./configure --enable-maintainer-mode.

* Dropping the mentioned touch hack.

That would apply also to hello.

That is documented in:

https://www.gnu.org/software/automake/manual/html_node/CVS.html#CVS
https://www.gnu.org/software/automake/manual/html_node/maintainer_002dmode.html#maintainer_002dmode


> diff --git a/debian/copyright b/debian/copyright
...
> +Copyright: 2016 ilbers GmbH

2018?


> diff --git a/debian/menu b/debian/menu

I don't think we need a GUI menu entry for libhello. Suggest dropping the file.


> diff --git a/hello.h b/hello.h
...
> +#ifndef __HELLO_H__

According to C99, identifiers that begin with an underscore are reserved
(typically for compiler or OS use). Suggest HELLO_H.


> diff --git a/hello.sgml b/hello.sgml
...
> +    <refentrytitle>HELLO</refentrytitle>
> +    <manvolnum>1</manvolnum>
...
> +    <refname>hello</refname>
...
> +    <title>EXIT STATUS</title>
> +
> +    <para><application>libhello</application> always returns zero.</para>

Suggest providing info applicable for say_hello(3).


As we have a backlog of patches and the issues are minor, feel free to create
github bugs for issues that would take longer and mention them as # TODO:
https://github.com/ilbers/isar/issues/NN in the code.


With kind regards,
Baurzhan.