[yocto] using git am to apply git patch in the workdir of any package+

[Pandey, Kamal]

Hello,
I am trying to modify the src code of a package named say x,
For this I type the command $bitbake x -c devshell.
This leads me to the git repo of the x package(if it is a git repo).
Now I do my changes, commit the changes, and create a patch out of it using git 
format-patch.
Now I want this git patch to be applied via git am  whenever I run bitbake x.
In some packages the patch is applied via git am for example linux-yocto-%.bb, 
but in some cases the patch is not being applied via git am for example 
u-boot%.bb
Is there any setting in bitbake to apply git patches via git am so that it is 
easy to modify the older patches via rebase commands, or we have to create new 
patch every time for a small change and the later patches will have dependency 
on older patches.


Best Regards
Kamal Pandey
Junior Software Engineer
[ifm_logo_sqrs]ifm engineering pvt. ltd.
Survey No. 1/10/16, 3rd floor, Above SBI, Bavdhan Branch, N.D.A. Road, Bavdhan, 
Pune, India - 411021 | Web: www.ifm.com | Phone: 
+91-20-22951910 Extn:215 | CIN: U29213PN2010FTC13676

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [thud]: Issues with git sub modules

[philippe gislard]

Hello everyone,

Our use case is the following:
- We are building firmwares using yocto on machines that have no internet access
- We have a mirror that we are feeding with tarballs generated by a
machine connected to internet
- We want to port our BSP to yocto thud

Until now (we used krogoth) our mirror was operating properly.

Since we switched to thud, the build systems is generating tarballs of
git repositories (i.e.: gstreamer1.0-plugins-good_1.14.imx.bb, from
freescale) containing symbolic links to git submodules (gstreamer
common).
The issue is that these symbolic links contain an absolute path which
is not portable on other machines.

We fixed it by patching the yocto framework so it generates a relative
symbolic link instead.

_We want to be sure is that is the proper way to fix the issue we are
facing for our use case_

You will find the patch we used at the end of this mail.

Thank you.

>From 456bc347c38039006619c0e95831cb4faf4d8c49 Mon Sep 17 00:00:00 2001
From: Philippe GISLARD 
Date: Wed, 6 Mar 2019 10:03:43 +0100
Subject: [PATCH] Change the git submodule symbolic link from absolute to
 relative in order to allow sharing the downloaded packages between different
 build machines

Signed-off-by: Philippe GISLARD 
Signed-off-by: Fabien MICAELLI 
---
 bitbake/lib/bb/fetch2/gitsm.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bitbake/lib/bb/fetch2/gitsm.py b/bitbake/lib/bb/fetch2/gitsm.py
index 35729db..009b2af 100644
--- a/bitbake/lib/bb/fetch2/gitsm.py
+++ b/bitbake/lib/bb/fetch2/gitsm.py
@@ -119,7 +119,7 @@ class GitSM(Git):
 os.makedirs(os.path.dirname(symlink_path), exist_ok=True)
 except OSError:
 pass
-os.symlink(local_paths[module], symlink_path)
+os.symlink(os.path.relpath(local_paths[module],
os.path.dirname(symlink_path)), symlink_path)

 return True

-- 
2.7.4

-- 
Philippe GISLARD
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] using git am to apply git patch in the workdir of any package+

[Alexander Kanavin]

The supported recommended workflow for this things is with devtool.

Please try especially 'devtool modify' and 'devtool upgrade'. The latter
will rebase patches for you, regardless of how they were made.

Alex

On Wed, 6 Mar 2019 at 15:18, Pandey, Kamal  wrote:

> Hello,
>
> I am trying to modify the src code of a package named say x,
>
> For this I type the command $bitbake x –c devshell.
>
> This leads me to the git repo of the x package(if it is a git repo).
>
> Now I do my changes, commit the changes, and create a patch out of it
> using git format-patch.
>
> Now I want this git patch to be applied via git am  whenever I run bitbake
> x.
>
> In some packages the patch is applied via git am for example
> linux-yocto-%.bb, but in some cases the patch is not being applied via git
> am for example u-boot%.bb
>
> Is there any setting in bitbake to apply git patches via git am so that it
> is easy to modify the older patches via rebase commands, or we have to
> create new patch every time for a small change and the later patches will
> have dependency on older patches.
>
>
>
>
>
> Best Regards
>
> Kamal Pandey
>
> Junior Software Engineer
>
> [image: ifm_logo_sqrs]ifm engineering pvt. ltd.
>
> Survey No. 1/10/16, 3rd floor, Above SBI, Bavdhan Branch, N.D.A. Road,
> Bavdhan, Pune, India - 411021 | Web: www.ifm.com | Phone: +91-20-22951910
> Extn:215 | CIN: U29213PN2010FTC13676
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [thud]: Issues with git sub modules

[Alexander Kanavin]

Yocto master has got a lot of fixing around gitsm fetcher
(particularly creation of symlinks seems to be gone), so if you could
try that and report, that would be appreciated.

Alex

On Wed, 6 Mar 2019 at 15:20, philippe gislard
 wrote:
>
> Hello everyone,
>
> Our use case is the following:
> - We are building firmwares using yocto on machines that have no internet 
> access
> - We have a mirror that we are feeding with tarballs generated by a
> machine connected to internet
> - We want to port our BSP to yocto thud
>
> Until now (we used krogoth) our mirror was operating properly.
>
> Since we switched to thud, the build systems is generating tarballs of
> git repositories (i.e.: gstreamer1.0-plugins-good_1.14.imx.bb, from
> freescale) containing symbolic links to git submodules (gstreamer
> common).
> The issue is that these symbolic links contain an absolute path which
> is not portable on other machines.
>
> We fixed it by patching the yocto framework so it generates a relative
> symbolic link instead.
>
> _We want to be sure is that is the proper way to fix the issue we are
> facing for our use case_
>
> You will find the patch we used at the end of this mail.
>
> Thank you.
>
> From 456bc347c38039006619c0e95831cb4faf4d8c49 Mon Sep 17 00:00:00 2001
> From: Philippe GISLARD 
> Date: Wed, 6 Mar 2019 10:03:43 +0100
> Subject: [PATCH] Change the git submodule symbolic link from absolute to
>  relative in order to allow sharing the downloaded packages between different
>  build machines
>
> Signed-off-by: Philippe GISLARD 
> Signed-off-by: Fabien MICAELLI 
> ---
>  bitbake/lib/bb/fetch2/gitsm.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bitbake/lib/bb/fetch2/gitsm.py b/bitbake/lib/bb/fetch2/gitsm.py
> index 35729db..009b2af 100644
> --- a/bitbake/lib/bb/fetch2/gitsm.py
> +++ b/bitbake/lib/bb/fetch2/gitsm.py
> @@ -119,7 +119,7 @@ class GitSM(Git):
>  os.makedirs(os.path.dirname(symlink_path), exist_ok=True)
>  except OSError:
>  pass
> -os.symlink(local_paths[module], symlink_path)
> +os.symlink(os.path.relpath(local_paths[module],
> os.path.dirname(symlink_path)), symlink_path)
>
>  return True
>
> --
> 2.7.4
>
> --
> Philippe GISLARD
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] INHIBIT_SYSROOT_STRIP

[Dimitris Tassopoulos]

Hi all,

this is not a request for help.

Today, I've found a very nice option which is not documented
which is the INHIBIT_SYSROOT_STRIP and is used in the sysroot_strip()
inside the poky/meta/classes/staging.bbclass.

I had an issue with a recipe that had a few binaries that I wanted to add
to the
recipe-sysroot-native in order to build another package and I was getting
errors
because the do_populate_sysroot couldn't strip those binaries. I've
searched in
the source and found that the author of that code was handling this case,
but it's
not documented (at least in the latest mega-manual).

Therefore, I'm dropping this message as a reference to other that might
need it.

Regards,
Dimitris
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] INHIBIT_SYSROOT_STRIP

[Scott Rifenbark]

Dimitris,

Good find... I will see about documenting this.

Scott

On Wed, Mar 6, 2019 at 8:12 AM Dimitris Tassopoulos 
wrote:

> Hi all,
>
> this is not a request for help.
>
> Today, I've found a very nice option which is not documented
> which is the INHIBIT_SYSROOT_STRIP and is used in the sysroot_strip()
> inside the poky/meta/classes/staging.bbclass.
>
> I had an issue with a recipe that had a few binaries that I wanted to add
> to the
> recipe-sysroot-native in order to build another package and I was getting
> errors
> because the do_populate_sysroot couldn't strip those binaries. I've
> searched in
> the source and found that the author of that code was handling this case,
> but it's
> not documented (at least in the latest mega-manual).
>
> Therefore, I'm dropping this message as a reference to other that might
> need it.
>
> Regards,
> Dimitris
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/4] meta-yocto-bsp/poky: update kernel to 5.0

[bruce . ashfield]

From: Bruce Ashfield 

This is a follow on to my oe-core series that introduces the 5.0
kernel. Once that is merged (and all outstanding issues resolved),
these can be applied to make the default 5.0 for poky and the
reference BSPs.

The removal of 4.18 from master will follow once everything is updated.

Cheers,

Bruce

The following changes since commit bbcc844c89493841d002cddb00a537a069b278e2:

  machine: bump preferred version to 5.0 (2019-03-06 11:37:45 -0500)

are available in the Git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel-yocto
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto

Bruce Ashfield (2):
  meta-yocto-bsp: introduce 5.0 bbappend
  poky/kernel: make default 5.0

Kevin Hao (2):
  meta-yocto-bsp: Add the v5.0 kernel support for all the BSPs
  meta-yocto-bsp: Update the default kernel to v5.0 for the non-x86 BSPs

 meta-poky/conf/distro/poky.conf   |  2 +-
 .../conf/machine/beaglebone-yocto.conf|  2 +-
 meta-yocto-bsp/conf/machine/edgerouter.conf   |  2 +-
 meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf |  2 +-
 .../linux/linux-yocto_5.0.bbappend| 27 +++
 5 files changed, 31 insertions(+), 4 deletions(-)
 create mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend

-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/4] meta-yocto-bsp: introduce 5.0 bbappend

[bruce . ashfield]

From: Bruce Ashfield 

Although the hardware reference boards are not using the 5.x
kernel yet, we generate a baseline bbappend for future work.

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.0.bbappend| 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
new file mode 100644
index 00..de5d84db11
--- /dev/null
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
@@ -0,0 +1,27 @@
+KBRANCH_genericx86  = "v4.19/standard/base"
+KBRANCH_genericx86-64  = "v4.19/standard/base"
+KBRANCH_edgerouter = "v4.19/standard/edgerouter"
+KBRANCH_beaglebone-yocto = "v4.19/standard/beaglebone"
+KBRANCH_mpc8315e-rdb = "v4.19/standard/fsl-mpc8315e-rdb"
+
+KMACHINE_genericx86 ?= "common-pc"
+KMACHINE_genericx86-64 ?= "common-pc-64"
+KMACHINE_beaglebone-yocto ?= "beaglebone"
+
+SRCREV_machine_genericx86?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
+SRCREV_machine_genericx86-64 ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
+SRCREV_machine_edgerouter ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
+SRCREV_machine_beaglebone-yocto ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
+SRCREV_machine_mpc8315e-rdb ?= "21aae3b4437eb6eec18804f1bad692030352430c"
+
+COMPATIBLE_MACHINE_genericx86 = "genericx86"
+COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
+COMPATIBLE_MACHINE_edgerouter = "edgerouter"
+COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
+COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
+
+LINUX_VERSION_genericx86 = "4.19.14"
+LINUX_VERSION_genericx86-64 = "4.19.14"
+LINUX_VERSION_edgerouter = "4.19.14"
+LINUX_VERSION_beaglebone-yocto = "4.19.14"
+LINUX_VERSION_mpc8315e-rdb = "4.19.14"
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 2/4] meta-yocto-bsp: Add the v5.0 kernel support for all the BSPs

[bruce . ashfield]

From: Kevin Hao 

Boot test for all the boards.

Signed-off-by: Kevin Hao 
Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto_5.0.bbappend| 24 +--
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
index de5d84db11..fe52a06550 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.0.bbappend
@@ -1,17 +1,17 @@
-KBRANCH_genericx86  = "v4.19/standard/base"
-KBRANCH_genericx86-64  = "v4.19/standard/base"
-KBRANCH_edgerouter = "v4.19/standard/edgerouter"
-KBRANCH_beaglebone-yocto = "v4.19/standard/beaglebone"
-KBRANCH_mpc8315e-rdb = "v4.19/standard/fsl-mpc8315e-rdb"
+KBRANCH_genericx86  = "v5.0/standard/base"
+KBRANCH_genericx86-64  = "v5.0/standard/base"
+KBRANCH_edgerouter = "v5.0/standard/edgerouter"
+KBRANCH_beaglebone-yocto = "v5.0/standard/beaglebone"
+KBRANCH_mpc8315e-rdb = "v5.0/standard/fsl-mpc8315e-rdb"
 
 KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 KMACHINE_beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine_genericx86?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
+SRCREV_machine_genericx86?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
 SRCREV_machine_genericx86-64 ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
 SRCREV_machine_edgerouter ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
-SRCREV_machine_beaglebone-yocto ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
+SRCREV_machine_beaglebone-yocto ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
 SRCREV_machine_mpc8315e-rdb ?= "21aae3b4437eb6eec18804f1bad692030352430c"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
@@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "4.19.14"
-LINUX_VERSION_genericx86-64 = "4.19.14"
-LINUX_VERSION_edgerouter = "4.19.14"
-LINUX_VERSION_beaglebone-yocto = "4.19.14"
-LINUX_VERSION_mpc8315e-rdb = "4.19.14"
+LINUX_VERSION_genericx86 = "5.0"
+LINUX_VERSION_genericx86-64 = "5.0"
+LINUX_VERSION_edgerouter = "5.0"
+LINUX_VERSION_beaglebone-yocto = "5.0"
+LINUX_VERSION_mpc8315e-rdb = "5.0"
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 3/4] meta-yocto-bsp: Update the default kernel to v5.0 for the non-x86 BSPs

[bruce . ashfield]

From: Kevin Hao 

Signed-off-by: Kevin Hao 
Signed-off-by: Bruce Ashfield 
---
 meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 2 +-
 meta-yocto-bsp/conf/machine/edgerouter.conf   | 2 +-
 meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf 
b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
index 69e11eca59..70d3cfea3d 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
@@ -24,7 +24,7 @@ SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0"
 SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "4.18%"
+PREFERRED_VERSION_linux-yocto ?= "5.0%"
 
 KERNEL_IMAGETYPE = "zImage"
 KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
diff --git a/meta-yocto-bsp/conf/machine/edgerouter.conf 
b/meta-yocto-bsp/conf/machine/edgerouter.conf
index b7a94e9cbb..78c87f2f87 100644
--- a/meta-yocto-bsp/conf/machine/edgerouter.conf
+++ b/meta-yocto-bsp/conf/machine/edgerouter.conf
@@ -11,7 +11,7 @@ KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
 KERNEL_IMAGE_STRIP_EXTRA_SECTIONS  = ".comment"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "4.18%"
+PREFERRED_VERSION_linux-yocto ?= "5.0%"
 
 SERIAL_CONSOLES = "115200;ttyS0"
 USE_VT ?= "0"
diff --git a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf 
b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
index 6f5b9859d7..54a34be3aa 100644
--- a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
+++ b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
@@ -14,7 +14,7 @@ SERIAL_CONSOLES = "115200;ttyS0"
 
 MACHINE_FEATURES = "keyboard pci ext2 ext3 serial"
 
-PREFERRED_VERSION_linux-yocto ?= "4.18%"
+PREFERRED_VERSION_linux-yocto ?= "5.0%"
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 
 PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 4/4] poky/kernel: make default 5.0

[bruce . ashfield]

From: Bruce Ashfield 

The 5.0 kernel is available and 4.18 will soon be dropped,
so we updated the preferred version to 5.0.

Signed-off-by: Bruce Ashfield 
---
 meta-poky/conf/distro/poky.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index adb2af9c9d..6544c03396 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -21,7 +21,7 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} 
${POKY_DEFAULT_DISTRO_FEATURES}"
 
-PREFERRED_VERSION_linux-yocto ?= "4.18%"
+PREFERRED_VERSION_linux-yocto ?= "5.0%"
 
 SDK_NAME = 
"${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
 SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] INHIBIT_SYSROOT_STRIP

[Khem Raj]

On Wed, Mar 6, 2019 at 8:15 AM Scott Rifenbark  wrote:
>
> Dimitris,
>
> Good find... I will see about documenting this.
>

Although its not encouranged to use it, its to be used as a last resort
we use it sparingly.

> Scott
>
> On Wed, Mar 6, 2019 at 8:12 AM Dimitris Tassopoulos  wrote:
>>
>> Hi all,
>>
>> this is not a request for help.
>>
>> Today, I've found a very nice option which is not documented
>> which is the INHIBIT_SYSROOT_STRIP and is used in the sysroot_strip()
>> inside the poky/meta/classes/staging.bbclass.
>>
>> I had an issue with a recipe that had a few binaries that I wanted to add to 
>> the
>> recipe-sysroot-native in order to build another package and I was getting 
>> errors
>> because the do_populate_sysroot couldn't strip those binaries. I've searched 
>> in
>> the source and found that the author of that code was handling this case, 
>> but it's
>> not documented (at least in the latest mega-manual).
>>
>> Therefore, I'm dropping this message as a reference to other that might need 
>> it.
>>
>> Regards,
>> Dimitris
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] INHIBIT_SYSROOT_STRIP

[Scott Rifenbark]

I think we should probably at least document the variable in the YP
Reference Manual's glossary.  Correct?

Scott

On Wed, Mar 6, 2019 at 9:24 AM Khem Raj  wrote:

> On Wed, Mar 6, 2019 at 8:15 AM Scott Rifenbark 
> wrote:
> >
> > Dimitris,
> >
> > Good find... I will see about documenting this.
> >
>
> Although its not encouranged to use it, its to be used as a last resort
> we use it sparingly.
>
> > Scott
> >
> > On Wed, Mar 6, 2019 at 8:12 AM Dimitris Tassopoulos 
> wrote:
> >>
> >> Hi all,
> >>
> >> this is not a request for help.
> >>
> >> Today, I've found a very nice option which is not documented
> >> which is the INHIBIT_SYSROOT_STRIP and is used in the sysroot_strip()
> >> inside the poky/meta/classes/staging.bbclass.
> >>
> >> I had an issue with a recipe that had a few binaries that I wanted to
> add to the
> >> recipe-sysroot-native in order to build another package and I was
> getting errors
> >> because the do_populate_sysroot couldn't strip those binaries. I've
> searched in
> >> the source and found that the author of that code was handling this
> case, but it's
> >> not documented (at least in the latest mega-manual).
> >>
> >> Therefore, I'm dropping this message as a reference to other that might
> need it.
> >>
> >> Regards,
> >> Dimitris
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] INHIBIT_SYSROOT_STRIP

[Khem Raj]

On Wed, Mar 6, 2019 at 9:48 AM Scott Rifenbark  wrote:
>
> I think we should probably at least document the variable in the YP Reference 
> Manual's glossary.  Correct?
>

yes and also mention that we only expect it to be used in rare special
curcumstances, e,g, prebuilt binaries etc.

> Scott
>
> On Wed, Mar 6, 2019 at 9:24 AM Khem Raj  wrote:
>>
>> On Wed, Mar 6, 2019 at 8:15 AM Scott Rifenbark  wrote:
>> >
>> > Dimitris,
>> >
>> > Good find... I will see about documenting this.
>> >
>>
>> Although its not encouranged to use it, its to be used as a last resort
>> we use it sparingly.
>>
>> > Scott
>> >
>> > On Wed, Mar 6, 2019 at 8:12 AM Dimitris Tassopoulos  
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> this is not a request for help.
>> >>
>> >> Today, I've found a very nice option which is not documented
>> >> which is the INHIBIT_SYSROOT_STRIP and is used in the sysroot_strip()
>> >> inside the poky/meta/classes/staging.bbclass.
>> >>
>> >> I had an issue with a recipe that had a few binaries that I wanted to add 
>> >> to the
>> >> recipe-sysroot-native in order to build another package and I was getting 
>> >> errors
>> >> because the do_populate_sysroot couldn't strip those binaries. I've 
>> >> searched in
>> >> the source and found that the author of that code was handling this case, 
>> >> but it's
>> >> not documented (at least in the latest mega-manual).
>> >>
>> >> Therefore, I'm dropping this message as a reference to other that might 
>> >> need it.
>> >>
>> >> Regards,
>> >> Dimitris
>> >> --
>> >> ___
>> >> yocto mailing list
>> >> yocto@yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/yocto
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Incremental rebuild doesn't pick up FILES changes.

[Richard Purdie]

On Tue, 2019-03-05 at 18:28 -0800, Kaz Kylheku (poky) wrote:
> Hi,
> 
> I'm working in a Yocto 2.5 environment.
> 
> In my own layer, I added a bbappend targeting python which does this:
> 
>FILES_${PN}_remove = "${libdir}/python2.7/encodings"
> 
> Now this didn't take effect as I expected. I had to do a "bitbake -c 
> cleanall python" to rebuild the package.
> 
> In any case, all I have in the image now, as I expected, is these
> four 
> files, vastly reduced from dozens:
> 
>/usr/lib/python2.7/encodings/{aliases,utf-8}.{py,pyc}
> 
> Now, if I comment out this FILES_${PN}_remove variable assignment, I 
> cannot get the previously removed encoding modules to re-appear in
> my 
> image! I tried "bitbake -c cleanall" on python, and blowing away its 
> build directory. It didn't work; still there are just those four
> files.
> 
> How do we get Yocto to react to FILES changes, short of blowing away
> the entire build tree?

Maybe related to this change:

http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/data_smart.py?id=f7f5e30667e1ad8e1ca76ee331be2843f2976bfa

?

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] INHIBIT_SYSROOT_STRIP

[Scott Rifenbark]

Got it. Thanks Khem.

On Wed, Mar 6, 2019 at 10:22 AM Khem Raj  wrote:

> On Wed, Mar 6, 2019 at 9:48 AM Scott Rifenbark 
> wrote:
> >
> > I think we should probably at least document the variable in the YP
> Reference Manual's glossary.  Correct?
> >
>
> yes and also mention that we only expect it to be used in rare special
> curcumstances, e,g, prebuilt binaries etc.
>
> > Scott
> >
> > On Wed, Mar 6, 2019 at 9:24 AM Khem Raj  wrote:
> >>
> >> On Wed, Mar 6, 2019 at 8:15 AM Scott Rifenbark 
> wrote:
> >> >
> >> > Dimitris,
> >> >
> >> > Good find... I will see about documenting this.
> >> >
> >>
> >> Although its not encouranged to use it, its to be used as a last resort
> >> we use it sparingly.
> >>
> >> > Scott
> >> >
> >> > On Wed, Mar 6, 2019 at 8:12 AM Dimitris Tassopoulos <
> dimt...@gmail.com> wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> this is not a request for help.
> >> >>
> >> >> Today, I've found a very nice option which is not documented
> >> >> which is the INHIBIT_SYSROOT_STRIP and is used in the sysroot_strip()
> >> >> inside the poky/meta/classes/staging.bbclass.
> >> >>
> >> >> I had an issue with a recipe that had a few binaries that I wanted
> to add to the
> >> >> recipe-sysroot-native in order to build another package and I was
> getting errors
> >> >> because the do_populate_sysroot couldn't strip those binaries. I've
> searched in
> >> >> the source and found that the author of that code was handling this
> case, but it's
> >> >> not documented (at least in the latest mega-manual).
> >> >>
> >> >> Therefore, I'm dropping this message as a reference to other that
> might need it.
> >> >>
> >> >> Regards,
> >> >> Dimitris
> >> >> --
> >> >> ___
> >> >> yocto mailing list
> >> >> yocto@yoctoproject.org
> >> >> https://lists.yoctoproject.org/listinfo/yocto
> >> >
> >> > --
> >> > ___
> >> > yocto mailing list
> >> > yocto@yoctoproject.org
> >> > https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] INHIBIT_SYSROOT_STRIP

[Dimitris Tassopoulos]

My use case, as I've told to Scott, was building a bare metal firmware for
a cortex m0 with an external GCC toolchain. Although, the toolchain's
binaries are strippable, there are some other blob files that are needed
for the build, which are not.

Cheers,
Dimitris

Scott Rifenbark  schrieb am Mi., 6. März 2019, 19:55:

> Got it. Thanks Khem.
>
> On Wed, Mar 6, 2019 at 10:22 AM Khem Raj  wrote:
>
>> On Wed, Mar 6, 2019 at 9:48 AM Scott Rifenbark 
>> wrote:
>> >
>> > I think we should probably at least document the variable in the YP
>> Reference Manual's glossary.  Correct?
>> >
>>
>> yes and also mention that we only expect it to be used in rare special
>> curcumstances, e,g, prebuilt binaries etc.
>>
>> > Scott
>> >
>> > On Wed, Mar 6, 2019 at 9:24 AM Khem Raj  wrote:
>> >>
>> >> On Wed, Mar 6, 2019 at 8:15 AM Scott Rifenbark 
>> wrote:
>> >> >
>> >> > Dimitris,
>> >> >
>> >> > Good find... I will see about documenting this.
>> >> >
>> >>
>> >> Although its not encouranged to use it, its to be used as a last resort
>> >> we use it sparingly.
>> >>
>> >> > Scott
>> >> >
>> >> > On Wed, Mar 6, 2019 at 8:12 AM Dimitris Tassopoulos <
>> dimt...@gmail.com> wrote:
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> this is not a request for help.
>> >> >>
>> >> >> Today, I've found a very nice option which is not documented
>> >> >> which is the INHIBIT_SYSROOT_STRIP and is used in the
>> sysroot_strip()
>> >> >> inside the poky/meta/classes/staging.bbclass.
>> >> >>
>> >> >> I had an issue with a recipe that had a few binaries that I wanted
>> to add to the
>> >> >> recipe-sysroot-native in order to build another package and I was
>> getting errors
>> >> >> because the do_populate_sysroot couldn't strip those binaries. I've
>> searched in
>> >> >> the source and found that the author of that code was handling this
>> case, but it's
>> >> >> not documented (at least in the latest mega-manual).
>> >> >>
>> >> >> Therefore, I'm dropping this message as a reference to other that
>> might need it.
>> >> >>
>> >> >> Regards,
>> >> >> Dimitris
>> >> >> --
>> >> >> ___
>> >> >> yocto mailing list
>> >> >> yocto@yoctoproject.org
>> >> >> https://lists.yoctoproject.org/listinfo/yocto
>> >> >
>> >> > --
>> >> > ___
>> >> > yocto mailing list
>> >> > yocto@yoctoproject.org
>> >> > https://lists.yoctoproject.org/listinfo/yocto
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Incremental rebuild doesn't pick up FILES changes.

[Kaz Kylheku (poky)]

On 2019-03-06 10:23, Richard Purdie wrote:

On Tue, 2019-03-05 at 18:28 -0800, Kaz Kylheku (poky) wrote:

How do we get Yocto to react to FILES changes, short of blowing away
the entire build tree?


Maybe related to this change:

http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/data_smart.py?id=f7f5e30667e1ad8e1ca76ee331be2843f2976bfa


Actually, the problem was that I had an accidental local change applied
to the .json manifest file; that's where the 
"${libdir}/python2.7/encodings" was

being deleted.

So, the issues are now is that

FILES_${PN}_remove = "${libdir}/python2.7/encodings"

in fact does not work, as I believed.  It doesn't register at all. If I 
run "bitbake -e", to find the places that influence the value of $FILES, 
this _remove assignment doesn't appear anywhere. In fact, the name of my 
.bbpappend file doesn't even appear anywhere in that listing.


If I change it to just FILES_remove = ...  then it does show up in 
"bitbake -e" (early, before all the base recipe manipulations of 
$FILES). It doesn't work; the encodings do not disappear:



 $FILES [527 operations]
#   set /mnt/sdb4/kaz/proj/poky/meta/conf/bitbake.conf:288
# ""
#   set /mnt/sdb4/kaz/proj/poky/meta/conf/documentation.conf:169
# [doc] "The list of directories or files that are placed in 
packages."
#   _remove 
/mnt/sdb4/kaz/proj/meta-custom/common/recipes-devtools/python/python_%.bbappend:15

# "${libdir}/python2.7/encodings"

[ big snip ]

#   override[python-core]:append python_2.7.15.bb:220 
[__anon_238__mnt_sdb4_kaz_y25_wp76_poky_meta_recipes_devtools_python_python_2_7_15_bb]

# " ${libdir}/python2.7/encodings"

I think this override might be winning over the _remove or something. 
The output never shows the final, settled value of FILES. At the bottom 
of this section about the $FILES variable we just have:


# pre-expansion value:
#   ""
FILES=""

which is uninformative; obviously there is a populated FILES because the 
package has files in it.


Should I just add some install append steps to "rm -f" the unwanted 
material and be done with it?


I feel there should be a sane way to customize the FILES variable (and 
any other) emanating from a base recipe, though.




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Incremental rebuild doesn't pick up FILES changes.

[Burton, Ross]

On Wed, 6 Mar 2019 at 20:14, Kaz Kylheku (poky)
<442-103-8...@kylheku.com> wrote:
> So, the issues are now is that
>
> FILES_${PN}_remove = "${libdir}/python2.7/encodings"
>
> in fact does not work, as I believed.

Have a look at python.bb.  Specifically:

PACKAGES_remove = "${PN}"

There is no PN being packaged.

What are you actually trying to do?

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Incremental rebuild doesn't pick up FILES changes.

[Kaz Kylheku (poky)]

On 2019-03-06 12:29, Burton, Ross wrote:

On Wed, 6 Mar 2019 at 20:14, Kaz Kylheku (poky)
<442-103-8...@kylheku.com> wrote:

So, the issues are now is that

FILES_${PN}_remove = "${libdir}/python2.7/encodings"

in fact does not work, as I believed.


Have a look at python.bb.  Specifically:

PACKAGES_remove = "${PN}"

There is no PN being packaged.


Ah, okay; this is because it's been split into various sub-packages. So 
we have to operate on "-core".

The .json manifest brings these into the "core" package:

"${libdir}/python2.7/encodings",
"${libdir}/python2.7/encodings/aliases.py",
"${libdir}/python2.7/encodings/utf_8.py",

I don't want all of encoders, just the utf_8.py and the aliases 
dictionary.


So I'm guessing this should be

  FILES_${PN}-core_remove =


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Incremental rebuild doesn't pick up FILES changes.

[Burton, Ross]

On Wed, 6 Mar 2019 at 22:27, Kaz Kylheku (poky)
<442-103-8...@kylheku.com> wrote:
> Ah, okay; this is because it's been split into various sub-packages. So
> we have to operate on "-core".
> The .json manifest brings these into the "core" package:
>
>  "${libdir}/python2.7/encodings",
>  "${libdir}/python2.7/encodings/aliases.py",
>  "${libdir}/python2.7/encodings/utf_8.py",
>
> I don't want all of encoders, just the utf_8.py and the aliases
> dictionary.
>
> So I'm guessing this should be
>
>FILES_${PN}-core_remove =

Yes.  It's too late to think about parse ordering because of the
complexity of Python's packaging but that *should* work.

Worst case: provide your own manifest if the packaging isn't what you want.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Incremental rebuild doesn't pick up FILES changes.

[Kaz Kylheku (poky)]

On 2019-03-06 14:26, Kaz Kylheku (poky) wrote:

So I'm guessing this should be

  FILES_${PN}-core_remove =


No dice. FILES_${PN}-core_remove = "${libdir}/python-2.7/encodings" does 
not register anywhere. In the "bitbake -e" output, no _remove event 
appears for FILES_python-core, and the image still contains that 
encodings directory.


I'm afraid I'm outsmarted here by the Smart Dictionary.

This ugly fallback is doing what I want though:

  do_install_append() {
encodings=${D}/usr/lib/python2.7/encodings

if [ -e "$encodings" ] ; then
  find "$encodings" -type f | grep -v -E 
'/(utf_8|aliases)\.(py|pyc)$' | xargs rm -f

fi
  }


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?

[Mark Hatle]

On 3/5/19 10:44 PM, Alex Kiernan wrote:
> On Tue, Mar 5, 2019 at 10:50 PM Richard Purdie
>  wrote:
>>
>> On Tue, 2019-03-05 at 16:05 +, Alejandro Del Castillo wrote:
>>>
>>> On 3/5/19 12:11 AM, ChenQi wrote:
 Hi All,

 Recently I'm dealing with issue from which some discussion raises.
 I'd like to ask why update-alternatives from opkg-utils chooses
 /usr/lib
 to hold its alternatives database?
 I looked into debian, its update-alternatives chooses /var/lib by
 default.
 Is there some design consideration? Or some historical reason?
>>>
>>> Update-alternatives used to be on the opkg repo. I did a search
>>> there
>>> all the way to the first commit on 2008-12-15 [1], but even then
>>> /usr/lib was used. I can't think of a design consideration that
>>> would
>>> make /usr/lib more palatable than the Debian default.
>>>
>>> Maybe someone with more knowledge of the previous history can chime
>>> in?
>>>
>>> [1]
>>> http://git.yoctoproject.org/clean/cgit.cgi/opkg/commit/?id=8bf49d16a637cca0cd116450dfcabc4c941baf6c
>>
>> I think the history is that the whole of /var was considered volatile
>> and we wanted the alternatives data to stick around so it was put under
>> /usr.
>>
>> That decision doesn't really make sense now since only parts of /var
>> are volatile..
>>
> 
> I don't use opkg (or in fact any package manager on a target), but I
> do use OSTree, where my /var isn't part of what gets deployed to a
> device 
> (https://ostree.readthedocs.io/en/latest/manual/adapting-existing/#adapting-existing-package-managers)
> so having the option to keep it in /usr would be important to anyone
> who has mechanisms like that.
> 

Do you allow a device that has been sent an update via OSTree to then run
update-alternatives to change what has been set by the update mechanism?

In my own uses of both OSTree and update-alternatives, I set this on a global
basis and use it that way.  So no individual user (device) would be different
then what was globally sent out.

If this is desired, then continuing to have a mechanism to allow it to be
overridden for legacy or your purposes seems reasonable... but I think moving
the default still makes a lot of sense.

--Mark
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?

[Alex Kiernan]

On Wed, Mar 6, 2019 at 11:37 PM Mark Hatle  wrote:
>
> On 3/5/19 10:44 PM, Alex Kiernan wrote:
> > On Tue, Mar 5, 2019 at 10:50 PM Richard Purdie
> >  wrote:
> >>
> >> On Tue, 2019-03-05 at 16:05 +, Alejandro Del Castillo wrote:
> >>>
> >>> On 3/5/19 12:11 AM, ChenQi wrote:
>  Hi All,
> 
>  Recently I'm dealing with issue from which some discussion raises.
>  I'd like to ask why update-alternatives from opkg-utils chooses
>  /usr/lib
>  to hold its alternatives database?
>  I looked into debian, its update-alternatives chooses /var/lib by
>  default.
>  Is there some design consideration? Or some historical reason?
> >>>
> >>> Update-alternatives used to be on the opkg repo. I did a search
> >>> there
> >>> all the way to the first commit on 2008-12-15 [1], but even then
> >>> /usr/lib was used. I can't think of a design consideration that
> >>> would
> >>> make /usr/lib more palatable than the Debian default.
> >>>
> >>> Maybe someone with more knowledge of the previous history can chime
> >>> in?
> >>>
> >>> [1]
> >>> http://git.yoctoproject.org/clean/cgit.cgi/opkg/commit/?id=8bf49d16a637cca0cd116450dfcabc4c941baf6c
> >>
> >> I think the history is that the whole of /var was considered volatile
> >> and we wanted the alternatives data to stick around so it was put under
> >> /usr.
> >>
> >> That decision doesn't really make sense now since only parts of /var
> >> are volatile..
> >>
> >
> > I don't use opkg (or in fact any package manager on a target), but I
> > do use OSTree, where my /var isn't part of what gets deployed to a
> > device 
> > (https://ostree.readthedocs.io/en/latest/manual/adapting-existing/#adapting-existing-package-managers)
> > so having the option to keep it in /usr would be important to anyone
> > who has mechanisms like that.
> >
>
> Do you allow a device that has been sent an update via OSTree to then run
> update-alternatives to change what has been set by the update mechanism?
>

No.

> In my own uses of both OSTree and update-alternatives, I set this on a global
> basis and use it that way.  So no individual user (device) would be different
> then what was globally sent out.
>

Sounds like our use case is similar... variation is exactly what we're
trying to avoid, so we don't allow changes like that.

> If this is desired, then continuing to have a mechanism to allow it to be
> overridden for legacy or your purposes seems reasonable... but I think moving
> the default still makes a lot of sense.
>

I'd agree, it's clearly valuable for some, it's just how you accommodate both.

I guess so long as it's still changeable, it's not a problem.

-- 
Alex Kiernan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH] scap-security-guide: use makefile generator instead of ninja for cmake

[Yi Zhao]

Fixes build error:
  | make: *** No rule to make target 'openembedded'.  Stop.

Signed-off-by: Yi Zhao 
---
 .../recipes-openscap/scap-security-guide/scap-security-guide_0.1.33.bb  | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_0.1.33.bb
 
b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_0.1.33.bb
index 7fa417d..27d3d86 100644
--- 
a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_0.1.33.bb
+++ 
b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_0.1.33.bb
@@ -19,6 +19,8 @@ S = "${WORKDIR}/git"
 
 STAGING_OSCAP_BUILDDIR = "${TMPDIR}/work-shared/openscap/oscap-build-artifacts"
 
+OECMAKE_GENERATOR = "Unix Makefiles"
+
 EXTRA_OECMAKE += "-DSSG_PRODUCT_CHROMIUM:BOOL=OFF"
 EXTRA_OECMAKE += "-DSSG_PRODUCT_DEBIAN8:BOOL=OFF"
 EXTRA_OECMAKE += "-DSSG_PRODUCT_FEDORA:BOOL=OFF"
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto