Re: [yocto] incohenrence between defconf, .config and /proc/config.gz

[María del Mar Velasco AERTEC Solutions – Aerospace & Aviation]

Hello all,

I have found that if I write the image using the created *.wic file, kernel 
config is correctly updated (/proc/config.gz and .config are coherent). However 
if I use the created *.ext4 file to write a rootfs partition of target, 
previous kernel config still remains (kernel config used when target was 
written for first time using *.wic file still remains).

Any idea about how to keep kernel config updates in *.ext4 file?

Thanks in advance

De: María del Mar Velasco AERTEC Solutions – Aerospace & Aviation
Enviado el: viernes, 6 de septiembre de 2019 10:50
Para: 'yocto@yoctoproject.org' 
Asunto: incohenrence between defconf, .config and /proc/config.gz

Dear all,

I have built an image after doing changes in kernel config by adding a layer 
that adds lines in .config file. This changes lead me to an undesired 
configuration, so I decided to undo the last kernel config. When I remove the 
layer that adds lines in .config file, I ensure that kernel is clean by doing 
bitbake -c cleanall linux-xxx. Then I build again the image. I can see .config 
file is exactly equal than defconf kernel file. However, when I write image 
into the target, /proc/config.gz file is inconsistent with .config file and it 
preserves some lines that are missing in .config file.

Could somebody give me an advice about this issue? Why /proc/config.gz is not 
equal than .config file?

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

[yocto] package_qa fails on copy openssl

[William Durocher]

Currently updating a sumo build to warrior. One of our recipe called config
server uses nodejs which was updated from 8.9 in sumo to 10.5 in warrior.
As an interim solution we decided to keep the version of nodejs to 8.90.
However I am getting the following exception in the package_qa step:

"File:
'/home/wdurocher/work/gammaip/warrior/sources/meta/meta/classes/staging.bbclass',
lineno: 151, function: staging_copyfile
 0147:os.symlink(linkto, dest)
 0148:#bb.warn(c)
 0149:else:
 0150:try:
 *** 0151:os.link(c, dest)
 0152:except OSError as err:
 0153:if err.errno == errno.EXDEV:
 0154:bb.utils.copyfile(c, dest)
 0155:else:
Exception: FileExistsError: [Errno 17] File exists:
'/home/wdurocher/work/gammaip/warrior/build/tmp/sysroots-components/x86_64/openssl-native/usr/bin/openssl.real'
->
'/home/wdurocher/work/gammaip/warrior/build/tmp/work/cortexa8hf-neon-schneider-linux-gnueabi/config-server/0.0.2-r0/recipe-sysroot-native/usr/bin/openssl.real'"

Which apparently is related to nodejs(sumo) using openssl 1.0.2p while a
few packages use openssl 1.1.0. Hacking staging.bbclass to remove the file
did allow package_qa to complete but that is not really a satisfactory
solution as 1) I would rather not hack the meta repo directly and 2) there
has to be a better way to have both openssl 1.0 and openssl 1.1 coexist
with the recipes using the correct version.

How do I either

- Fix the error mentionned above
- Make yocto be aware that there are 2 versions of openssl !

Any help would be appreciated.

-- 



William Durocher

Linker / Developpeur

1800-500 Place d’Armes, Montréal, QC, H2Y 2W2

+1 (438) 259-3227 / +1 (514) 613-6887

www.it-link.ca

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

Re: [yocto] package_qa fails on copy openssl

[Martin Jansa]

On Tue, Sep 10, 2019 at 08:49:35AM -0400, William Durocher wrote:
> Currently updating a sumo build to warrior. One of our recipe called config
> server uses nodejs which was updated from 8.9 in sumo to 10.5 in warrior.
> As an interim solution we decided to keep the version of nodejs to 8.90.
> However I am getting the following exception in the package_qa step:
> 
> "File:
> '/home/wdurocher/work/gammaip/warrior/sources/meta/meta/classes/staging.bbclass',
> lineno: 151, function: staging_copyfile
>  0147:os.symlink(linkto, dest)
>  0148:#bb.warn(c)
>  0149:else:
>  0150:try:
>  *** 0151:os.link(c, dest)
>  0152:except OSError as err:
>  0153:if err.errno == errno.EXDEV:
>  0154:bb.utils.copyfile(c, dest)
>  0155:else:
> Exception: FileExistsError: [Errno 17] File exists:
> '/home/wdurocher/work/gammaip/warrior/build/tmp/sysroots-components/x86_64/openssl-native/usr/bin/openssl.real'
> ->
> '/home/wdurocher/work/gammaip/warrior/build/tmp/work/cortexa8hf-neon-schneider-linux-gnueabi/config-server/0.0.2-r0/recipe-sysroot-native/usr/bin/openssl.real'"
> 
> Which apparently is related to nodejs(sumo) using openssl 1.0.2p while a
> few packages use openssl 1.1.0. Hacking staging.bbclass to remove the file
> did allow package_qa to complete but that is not really a satisfactory
> solution as 1) I would rather not hack the meta repo directly and

> 2) there
> has to be a better way to have both openssl 1.0 and openssl 1.1 coexist
> with the recipes using the correct version.

Unfortunately there isn't, pick one version (preferably 1.1) and use it
for everything.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] incohenrence between defconf, .config and /proc/config.gz

[Khem Raj]

On Tue, Sep 10, 2019 at 2:45 AM María del Mar Velasco AERTEC Solutions –
Aerospace & Aviation  wrote:

> Hello all,
>
>
>
> I have found that if I write the image using the created *.wic file,
> kernel config is correctly updated (/proc/config.gz and .config are
> coherent). However if I use the created *.ext4 file to write a rootfs
> partition of target, previous kernel config still remains (kernel config
> used when target was written for first time using *.wic file still remains).
>
>
>
> Any idea about how to keep kernel config updates in *.ext4 file?
>
>
>

Ext4 is just rootfs without new kernel I think that’s why you see old
.config since it’s bundled into kernel  binary

With wic you write full disk along with new kernel

> Thanks in advance
>
>
>
> *De:* María del Mar Velasco AERTEC Solutions – Aerospace & Aviation
> *Enviado el:* viernes, 6 de septiembre de 2019 10:50
> *Para:* 'yocto@yoctoproject.org' 
> *Asunto:* incohenrence between defconf, .config and /proc/config.gz
>
>
>
> Dear all,
>
>
>
> I have built an image after doing changes in kernel config by adding a
> layer that adds lines in .config file. This changes lead me to an undesired
> configuration, so I decided to undo the last kernel config. When I remove
> the layer that adds lines in .config file, I ensure that kernel is clean by
> doing bitbake -c cleanall linux-xxx. Then I build again the image. I can
> see .config file is exactly equal than defconf kernel file. However, when I
> write image into the target, /proc/config.gz file is inconsistent with
> .config file and it preserves some lines that are missing in .config file.
>
>
>
> Could somebody give me an advice about this issue? Why /proc/config.gz is
> not equal than .config file?
>
>
>
> Thanks in advance
> --
> ___
> 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] Yocto Project Status WW37'19

[sjolley.yp.pm]

Current Dev Position: YP 2.8 M4 Feature Freeze

Next Deadline: YP 3.0 Final Release 25th Oct

 

SWAT Team Rotation:

*   SWAT lead is currently: Paul
*   SWAT team rotation: Paul -> Ross on Sept. 13, 2019
*   SWAT team rotation: Ross -> Amanda on Sept. 20, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*   Bug Triage meeting Thursday Sept 12th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Oct. 1st at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday Sept. 10th at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch - Next event is Tuesday Sept. 10th at 8am PDT (
 https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*   We're now in feature freeze for 3.0 and working on bug fixing for
final release
*   We have not built M3 yet as some work still remains for us to be
feature complete and ready for QA. This puts us behind schedule but the plan
is to complete the key features we've planned rather than adhere strictly to
dates. We hope to make up time during M4 by having M3 at high quality and
take advantage of our automation.
*   RP is away for the rest of the week which means M3 progress will be
limited this week, Ross will queue patches.
*   Key 3.0 changes have now merged:

*   5.2 linux-libc-kernel-headers
*   5.2 kernel recipes by default for all reference BSPs
*   Removal of LSB and poky-lsb and replacement with alt config testing
*   systemd by default for poky-altcfg
*   Patches have significantly reduced the dependency on python2
*   Reproducible builds are now being tested for core-image-minimal
*   Automated toolchain testsuite tests (binutils, gcc, glibc)

*   Key blocking issues for M3 that have been fixed:

*   Systemtap issues with 5.2 were debugged and patches sent/merged
upstream
*   5.2 dmesg on qemuarm64 fixed
*   qemumips hang when using highmem root caused and worked around (for
now)
*   mdadm ptest timeout worked around
*   quilt and libevent ptest regressions from M2 resolved

*   Remaining issues blocking M3:

*   systemd boot failure on qemumips
*   strace ptest timeout
*   Hash equivalence performance problems (RP has a simple idea to
~double speed)
*   Hash equivalence bugs
*   Toolchain testsuite relocation bugs (Nathan working on it)

*   Hash Equivalency status:

*   Ideas about removing some dependency information from the hashes to
allow faster bulk queries aren't viable so the current codebase approach is
correct
*   we need to rework the client/server communication to scale to the
autobuilder
*   there are some bugs in the code the autobuilder continues to expose
*   we have cases where its not 100% clear what the correct behaviour
should be
*   test cases are proving to be problematic to write in a maintainable
way

*   Documentation - Due to illness Scott is unavailable for the next
month or two so doc patches will be handled by Richard or Ross in the short
term. We'll likely limit them to correctness issues and defer any
substantial new text. If anyone has availability and skills to work on the
manuals please talk to us. We're aware there is a patch backlog.
*   If anyone has any status items for the project they'd like to add to
the weekly reports, please email Richard+Stephen.

 

Planned Releases for YP 3.0 {2.8}:

*   M3 Release 6th Sept
*   M4 Cutoff 30th Sept - this will be YP 3.0.
*   YP 3.0 {2.8 (M4)} Final Release 25th Oct

 

Planned upcoming dot releases:

*   YP 2.7.2 (Warrior) is planned for after YP 3.0 release.
*   YP 2.6.4 (Thud) is planned for after YP 2.7.2  release.

 

Tracking Metrics:

*   WDD 2424 (last week 2413) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1417 (last week 1470)
*   Patches in the Pending State: 582 (41%) [last week 611 (42%)]

 

Key Status Links for YP:

 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status

 
https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule

 
https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org

Re: [yocto] [meta-selinux][PATCH] conf/layer.conf: use BBFILES_DYNAMIC for dynamic layers

[Yi Zhao]

On 9/10/19 1:11 AM, Joe MacDonald wrote:

Hi Yi,

[[meta-selinux][PATCH] conf/layer.conf: use BBFILES_DYNAMIC for dynamic layers] 
On 19.09.09 (Mon 14:01) Yi Zhao wrote:


From: Robert Yang 

The previous code add all BBFILE_COLLECTIONS/recipes*/*/*.bbappend to BBFILES,
which causes the parsing very slow when there are many layers, e.g., I have 87
layers:

* Before:
$ rm -fr tmp-glibc/ cache; time bitbake -p
real0m45.173s
user0m0.560s
sys 0m0.060s

* After:
$ rm -fr tmp-glibc/ cache; time bitbake -p
real0m25.542s
user0m0.572s
sys 0m0.040s

It wasted 20s which wasn't worth (The host has 128 threads, it should cost more
time on less power host), use BBFILES_DYNAMIC can fix the problem.


This seems like a big claim, I certainly haven't seen that on my setup:

* Before:
$ rm -fr tmp cache
real0m14.751s
user0m0.323s
sys 0m0.048s

* After:
$ rm -fr tmp cache ; time bitbake -p
real0m14.725s
user0m0.326s
sys 0m0.046s

but it's still a sensible change.  When I ran a test before/after
configuration for augeas the configuration seemed off, though.  Can you
confirm that with this change as is you're getting the correct
--with/--without and --enable/--disable and patches applied for your
layers?  I just want to confirm since the ~20s difference in parsing
seems kind of out of scale for moving essentially three bbappends around
and I'm wondering if there's something else siginficant in your tree we
want to consider.



This patch is from Robert Yang. CC to him. Maybe he can give us more 
explanation.


For the augeas, the current augeas_%.bbapend doesn't work because the 
augeas recipe is in meta-oe layer but not meta-python layer. This patch 
moves the bbappend to the correct layer to fix this issue.


It works on my local:

$ cat log.do_configure

[snip]
checking for library containing setfilecon... -lselinux
[snip]
checking for selinux/selinux.h... (cached) yes
checking selinux/context.h usability... yes
checking selinux/context.h presence... yes
checking for selinux/context.h... yes
[snip]


//Yi




-J.


Signed-off-by: Robert Yang 
Signed-off-by: Yi Zhao 
---
  conf/layer.conf   | 11 +++
  .../recipes-daemons/iscsi-initiator-utils/files/initd.debian  |  0
  .../iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend|  0
  .../iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc   |  0
  .../recipes-support}/augeas/augeas_%.bbappend |  0
  .../recipes-containers/lxc/lxc_%.bbappend |  0
  6 files changed, 7 insertions(+), 4 deletions(-)
  rename {networking-layer => 
dynamic-layers/networking-layer}/recipes-daemons/iscsi-initiator-utils/files/initd.debian
 (100%)
  rename {networking-layer => 
dynamic-layers/networking-layer}/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend
 (100%)
  rename {networking-layer => 
dynamic-layers/networking-layer}/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc
 (100%)
  rename {meta-python/recipes-extended/augeas => 
dynamic-layers/openembedded-layer/recipes-support}/augeas/augeas_%.bbappend (100%)
  rename {virtualization-layer => 
dynamic-layers/virtualization-layer}/recipes-containers/lxc/lxc_%.bbappend (100%)

diff --git a/conf/layer.conf b/conf/layer.conf
index 9dd34b1..89b9468 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -5,10 +5,13 @@ BBPATH .= ":${LAYERDIR}"
  BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
  ${LAYERDIR}/recipes-*/*/*.bbappend"
  
-# Let us add layer-specific bbappends which are only applied when that

-# layer is included in our configuration
-BBFILES += "${@' '.join('${LAYERDIR}/%s/recipes*/*/*.bbappend' % layer \
-   for layer in BBFILE_COLLECTIONS.split())}"
+BBFILES_DYNAMIC += 
"openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/*/*/*.bb \
+
openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/*/*/*.bbappend 
\
+
networking-layer:${LAYERDIR}/dynamic-layers/networking-layer/*/*/*.bb \
+
networking-layer:${LAYERDIR}/dynamic-layers/networking-layer/*/*/*.bbappend \
+
virtualization-layer:${LAYERDIR}/dynamic-layers/virtualization-layer/recipes*/*/*.bb
 \
+
virtualization-layer:${LAYERDIR}/dynamic-layers/virtualization-layer/recipes*/*/*.bbappend
 \
+   "
  
  BBFILE_COLLECTIONS += "selinux"

  BBFILE_PATTERN_selinux = "^${LAYERDIR}/"
diff --git 
a/networking-layer/recipes-daemons/iscsi-initiator-utils/files/initd.debian 
b/dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/files/initd.debian
similarity index 100%
rename from 
networking-layer/recipes-daemons/iscsi-initiator-utils/files/initd.debian
rename to 
dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/files/initd.debian
diff --git 
a/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils

[yocto] One second timestamp resolution?

[Paul D. DeRocco]

I just noticed that I'm getting one-second resolution on all my
timestamps. This is for both ext4 and vfat partitions, and shows up in ls
--full-time and the stat command. What could account for this? My uname -a
output is "Linux CHROMA1 4.10.17-yocto-preempt-rt #1 SMP PREEMPT Wed Oct
11 12:33:54 PDT 2017 i686 i686 i386 GNU/Linux" if that's any help. Also,
my ext4 mount options are "rw,noatime,nodiratime,data=ordered".

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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