Date   

Re: grubenv not being generated

Khem Raj
 

On 10/27/20 3:33 PM, Howard wrote:
Hi:
I am using grub as my bootloader, and enabling it via
EFI_PROVIDER = "grub-efi"
That all seems to work fine, except that grubenv is not being created anywhere.  I can run grub-editenv to create one on the target, but I need it built in.
Most of what I'm reading implies that it should be getting built.  I will say this, however, and that is that grub.cfg does not seem to reference the grubenv file which kind of makes sense since grubenv is not present.
I did find this thread, but it didn't really have any answers.
https://lists.yoctoproject.org/g/yocto/message/40612?p=,,,20,0,0,0::Created,,grubenv,20,2,0,61333830 <https://lists.yoctoproject.org/g/yocto/message/40612?p=,,,20,0,0,0::Created,,grubenv,20,2,0,61333830>
Wondering what I am missing.
perhaps a post edit function and add grub-native to DEPENDS so you can find needed binaries during cross build.

Many Thanks
Howard


grubenv not being generated

Howard
 

Hi:

I am using grub as my bootloader, and enabling it via 

EFI_PROVIDER = "grub-efi"

That all seems to work fine, except that grubenv is not being created anywhere.  I can run grub-editenv to create one on the target, but I need it built in.

Most of what I'm reading implies that it should be getting built.  I will say this, however, and that is that grub.cfg does not seem to reference the grubenv file which kind of makes sense since grubenv is not present.

I did find this thread, but it didn't really have any answers.
https://lists.yoctoproject.org/g/yocto/message/40612?p=,,,20,0,0,0::Created,,grubenv,20,2,0,61333830

Wondering what I am missing.

Many Thanks
Howard


Re: Cross compilation error finding libraries

Khem Raj
 

On Tue, Oct 27, 2020 at 9:41 AM Bel Hadj Salem Talel <bhstalel@gmail.com> wrote:

Hi,

Thanks for the reply.
Setting LD to $CC didn't work as well.
Pass LDFLAGS as CLFAGS as well, you need to use --syroot option during
link as well



Re: How to use WORKDIR of recipe A in recipe B ?

Khem Raj
 

Hello Talel

On Tue, Oct 27, 2020 at 11:23 AM Bel Hadj Salem Talel
<bhstalel@gmail.com> wrote:

Hi All,

I have a macchina.io recipe that fetches the source from Github and compiles it correctly.

In the WORKDIR , there is a samples directory with many examples, and each example has a Makefile, here is an example :

include $(POCO_BASE)/build/rules/global
include $(POCO_BASE)/OSP/BundleCreator/BundleCreator.make
objects = BundleActivator
target = io.macchina.samples.sensor1
target_includes = $(PROJECT_BASE)/devices/Devices/include
target_libs = IoTDevices PocoOSP PocoUtil PocoJSON PocoXML PocoFoundation
postbuild = $(SET_LD_LIBRARY_PATH) $(BUNDLE_TOOL) -n$(OSNAME) -a$(OSARCH) -o../bundles HelloSensor1.bndlspec
include $(POCO_BASE)/build/rules/dylib

There is a global variable that are used when building macchina, like (POCO_BASE, BUNDLE_TOOL, ...)

Now, I don't want to make a patch for my custom sample, because that will force macchina to recompile again and that will take more than 45minutes.
I need to use the macchina WORKDIR
many options to handle such situations.
usually, workdirs is strictly specific to one recipe, no other recipe
gets to peak into it. however if you have multiple recipes needing to
access same sources again
its perhaps ok to turn it into recipe-source recipe which sets up
common sources dir and every recipe refers to it. This however only
works if you purely need to access source
and source alone. If you are depending on intermediate buils artifacts
e.g. object file libraries etc. then better approach is to add it to
your -dev package from the source recipe
during its build and then when you DEPEND = "recipeA" in your recipeB
it will automatically stage them in the recipe specific sysroot.

However in many case you need fully configured and built trees of a
package into another. then look at how kernel is sharing its build
artifacts for kernel module builds from other
recipes.



Re: Recent issues with BB_DONT_CACHE?

Khem Raj
 

On Tue, Oct 27, 2020 at 11:05 AM Andrew Geissler <geissonator@gmail.com> wrote:

Over in the OpenBMC project, we rebased on yocto master (https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/37488). After this we started seeing intermittent issues with our os-release.bb recipe. We have a .bbappend in our meta-phosphor layer (https://github.com/openbmc/openbmc/blob/583147ea45f94ee363e9ae30ccb65b9ed1561b54/meta-phosphor/recipes-core/os-release/os-release.bbappend) that issues git commands to use the git hash to fill in our os-release.

After updating to the latest poky, sometimes the build works fine, other times we run into https://github.com/openbmc/openbmc/issues/3720

ERROR�[0m: �[31mWhen reparsing /var/lib/jenkins-slave/workspace/ci-meta/distro/ubuntu/label/docker-builder/target/witherspoon/openbmc/meta/recipes-core/os-release/os-release.bb:do_compile, the basehash value changed from 5da39bb75d4e4256ff7e589f6204c0ee79f16031e54aa78a23d630633becceac to c266b6051c26e27a7f5585d632b703511a7a9657fa2960515b570d3ef54a8ef2. The metadata is not deterministic and this needs to be fixed.�[0m

After some debug, it appears as if occasionally, bitbake is using the sstate cached os-release initially, and then during the build process it moves to using the correct hash id. This then causes the above error. We had issues with this way back in the day when we first introduced this bbappend and the solution was to add this to that recipe:

BB_DONT_CACHE = "1"

I don't see anything in that commit list from poky that looks suspicious but it definitely started happening when we brought that in. I tried modifying our os-release.bbappend to only run once during the compile phase but that caused issues where sometimes the os-release field in our flash image was incorrect (https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/37705 is the revert of that try)
You can add a function and use nostamp on it so it gets executed every
time, something like
https://github.com/YoeDistro/yoe-distro/blob/dunfell/sources/meta-yoe/recipes-core/images/updater.inc#L27-L47
for ideas

secondly, https://github.com/openbmc/openbmc/blob/583147ea45f94ee363e9ae30ccb65b9ed1561b54/meta-phosphor/recipes-core/os-release/os-release.bbappend#L38
seems to be
interesting what is the intention here ?

I think it would be better to have this data extraction added to
bitbake so it can be run at the beginning when layers are parsed, it
already is dumping build configuration so latch on
to it would get you what you want.





dlib recipe linking issue

Marek Belisko
 

Hi,

I'm creating a recipe for the dlib library. Source also contains
python bindings so my recipe looks like:

SUMMARY = "A toolkit for making real world machine learning and data
analysis applications"
HOMEPAGE = "https://github.com/davisking/dlib"

LICENSE = "Boost-Software"
LIC_FILES_CHKSUM =
"file://dlib/LICENSE.txt;md5=2c7a3fa82e66676005cd4ee2608fd7d2 \

file://dlib/external/pybind11/LICENSE;md5=beb87117af69fd10fbf9fb14c22a2e62
\

file://dlib/external/libpng/LICENSE;md5=243135ddedf702158f9170807cbcfb66
\

file://docs/docs/license.xml;md5=2e6ff4080dcb217d4d300b90e9aabb5b \

file://examples/LICENSE_FOR_EXAMPLE_PROGRAMS.txt;md5=57eee82829ed297e23d84de5f905afee
\

file://examples/video_frames/license.txt;md5=127ee508b60a6be9dea8af3b441993dc
\

file://python_examples/LICENSE_FOR_EXAMPLE_PROGRAMS.txt;md5=064f53ab40ea2b6a4bba1324149e4fde"

SRC_URI = "git://github.com/davisking/dlib.git;protocol=https"

PV = "1.0+git${SRCPV}"
SRCREV = "3b794540baeabbcd033b544230401967106d5483"

S = "${WORKDIR}/git"

inherit setuptools3

DEPENDS += "python3 cmake-native"

FILES_${PN}-dev += "${libdir}/cmake/dlib"

EXTRA_OECMAKE += "-DDLIB_NO_GUI_SUPPORT=ON -DBUILD_SHARED_LIBS=ON
-DDLIB_USE_CUDA=OFF"

Problem is to build python bindings because it builds the first c++
code using cmake and pybind11. I hit the first issue described here:
https://github.com/davisking/dlib/issues/2220 and resolved it simply
by commenting out code which compares python binary and toolchain
binary.

Then compilation seems to progress but there is again an issue with
linkin because it tries to link with x86-64 python libraries instead
of arm python3 libs. Any ideas how to solve this issue or anyone can
share a working recipe.

Thanks and BR,

marek





--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


Re: How to use WORKDIR of recipe A in recipe B ?

Bel Hadj Salem Talel
 

Sorry this is rest of the mail:

I need to use the macchina WORKDIR in a different recipe , so that I can compile only my sample.
For example, in my recipe I export those global variable used in the Makefile like :

export POCO_BASE = ${WORKDIR_MACCHINA}
...

Any idea ?
Thanks ,Talel


How to use WORKDIR of recipe A in recipe B ?

Bel Hadj Salem Talel
 

Hi All,

I have a macchina.io recipe that fetches the source from Github and compiles it correctly.

In the WORKDIR , there is a samples directory with many examples, and each example has a Makefile, here is an example :

include $(POCO_BASE)/build/rules/global
include $(POCO_BASE)/OSP/BundleCreator/BundleCreator.make
objects = BundleActivator
target          = io.macchina.samples.sensor1
target_includes = $(PROJECT_BASE)/devices/Devices/include
target_libs     = IoTDevices PocoOSP PocoUtil PocoJSON PocoXML PocoFoundation
postbuild = $(SET_LD_LIBRARY_PATH) $(BUNDLE_TOOL) -n$(OSNAME) -a$(OSARCH) -o../bundles HelloSensor1.bndlspec
include $(POCO_BASE)/build/rules/dylib

There is a global variable that are used when building macchina, like (POCO_BASE, BUNDLE_TOOL, ...)

Now, I don't want to make a patch for my custom sample, because that will force macchina to recompile again and that will take more than 45minutes.
I need to use the macchina WORKDIR


Recent issues with BB_DONT_CACHE?

Andrew Geissler
 

Over in the OpenBMC project, we rebased on yocto master (https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/37488). After this we started seeing intermittent issues with our os-release.bb recipe. We have a .bbappend in our meta-phosphor layer (https://github.com/openbmc/openbmc/blob/583147ea45f94ee363e9ae30ccb65b9ed1561b54/meta-phosphor/recipes-core/os-release/os-release.bbappend) that issues git commands to use the git hash to fill in our os-release.

After updating to the latest poky, sometimes the build works fine, other times we run into https://github.com/openbmc/openbmc/issues/3720

ERROR�[0m: �[31mWhen reparsing /var/lib/jenkins-slave/workspace/ci-meta/distro/ubuntu/label/docker-builder/target/witherspoon/openbmc/meta/recipes-core/os-release/os-release.bb:do_compile, the basehash value changed from 5da39bb75d4e4256ff7e589f6204c0ee79f16031e54aa78a23d630633becceac to c266b6051c26e27a7f5585d632b703511a7a9657fa2960515b570d3ef54a8ef2. The metadata is not deterministic and this needs to be fixed.�[0m

After some debug, it appears as if occasionally, bitbake is using the sstate cached os-release initially, and then during the build process it moves to using the correct hash id. This then causes the above error. We had issues with this way back in the day when we first introduced this bbappend and the solution was to add this to that recipe:

BB_DONT_CACHE = "1"

I don't see anything in that commit list from poky that looks suspicious but it definitely started happening when we brought that in. I tried modifying our os-release.bbappend to only run once during the compile phase but that caused issues where sometimes the os-release field in our flash image was incorrect (https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/37705 is the revert of that try)


Re: Cross compilation error finding libraries

Bel Hadj Salem Talel
 

Hi,

Thanks for the reply.
Setting LD to $CC didn't work as well.


Re: [meta-selinux][PATCH] layer.conf: add gatesgarth compatibility

Vincent Prince
 

Thanks, no problem :)

Le mar. 27 oct. 2020 à 16:09, Joe MacDonald <joe@...> a écrit :
[Re: [yocto] [meta-selinux][PATCH] layer.conf: add gatesgarth compatibility] On 20.10.27 (Tue 16:00) nefethael wrote:

> Hi Jon,
>
> There is already a pending patch submitted some time ago by Aníbal Limó here
> https://patchwork.openembedded.org/patch/177350/

Yeah, I've had that older patch in my work-tree for a while now and
haven't pushed it upstream yet.  I'll get on that today.  Sorry for the
delay.

-Joe.

>
> Best regards,
> Vincent
>
>
>
> Le lun. 26 oct. 2020 à 21:56, Jon Mason <jdmason@...> a écrit :
>
>     Signed-off-by: Jon Mason <jdmason@...>
>     ---
>      conf/layer.conf | 2 +-
>      1 file changed, 1 insertion(+), 1 deletion(-)
>
>     diff --git a/conf/layer.conf b/conf/layer.conf
>     index da24359b7484..178ce1b734d3 100644
>     --- a/conf/layer.conf
>     +++ b/conf/layer.conf
>     @@ -23,7 +23,7 @@ BBFILE_PRIORITY_selinux = "5"
>      # cause compatibility issues with other layers
>      LAYERVERSION_selinux = "1"
>
>     -LAYERSERIES_COMPAT_selinux = "dunfell"
>     +LAYERSERIES_COMPAT_selinux = "dunfell gatesgarth"
>
>      LAYERDEPENDS_selinux = " \
>          core \
>     --
>     2.20.1
>
>
>
>
>

>
>
>


--
-Joe MacDonald.
:wq


Re: Systemd, overlayfs, and machine-id problem

Vincent Prince
 

Hi,

In my project, I ended up by overlaying not the entire /etc but only subparts I needed to modify.
(/etc/machine-id is maybe already a bind mount from /run/machine-id)
Hope it helps,

Best regards,
Vincent


Le mar. 27 oct. 2020 à 16:24, Khem Raj <raj.khem@...> a écrit :


On 10/27/20 2:23 AM, Morten Bruun wrote:
> Hi,
>
> In our current Yocto project we are using an overlayfs on top of /etc
>
> This seems to trigger the systemd-machine-id-setup service which fails
> with the error below:
>
> systemd-machine-id-setup[204]: Failed to unmount transient
> /etc/machine-id file: Invalid argument.
>
> The failed service then triggers an error in the test_systemd_failed
> test in the systemd testimage suite.
>
> As far as I understand the machine-id setup is triggered because
> path_is_mount_point() can report false positives when using overlayfs.
>
> Is there a way to fix this?

maybe pregeenerate machine ID sometimes you can seed it from CPU Id or
soc ID from eeprom.

>
> Kind regards,
> Morten
>
>
>
>
>




Re: Cross compilation error finding libraries

Khem Raj
 

On 10/27/20 2:52 AM, Bel Hadj Salem Talel wrote:
Hi All,
I have an SDK populated from an image.
After sourcing the SDK env file, I try to run make on a project with this command :
make CC="$CC" LD="$LD" CFLAGS="${CFLAGS}
--sysroot=/media/talel/data/sdk-multigate/sysroots/aarch64-poky-linux"
CXXFLAGS="${CXXFLAGS}
--sysroot=/media/talel/data/sdk-multigate/sysroots/aarch64-poky-linux"
I specified the CFLAGS and CXXFLAGS as mentionned in Yocto document (part 5.2 Makefile-Based projects) : https://www.yoctoproject.org/docs/1.1.2/adt-manual/adt-manual.html
Now I have this error:
** Building dynamic library (debug, shared) /home/talel/Documents/macchina.io/samples/LinuxThermalSimple/bin/Linux/x86_64/io.macchina.linux-thermal-simpled.so
aarch64-poky-linux-g++ -shared -Wl,-soname,io.macchina.linux-thermal-simpled.so -o /home/talel/Documents/macchina.io/samples/LinuxThermalSimple/bin/Linux/x86_64/io.macchina.linux-thermal-simpled.so /home/talel/Documents/macchina.io/samples/LinuxThermalSimple/obj/Linux/x86_64/debug_shared/LinuxThermalSensor.o /home/talel/Documents/macchina.io/samples/LinuxThermalSimple/obj/Linux/x86_64/debug_shared/BundleActivator.o -L/home/talel/Documents/macchina.io/lib/Linux/x86_64 -L/home/talel/Documents/macchina.io/platform/lib/Linux/x86_64 -lIoTDevicesd -lPocoRemotingNGd -lPocoOSPd -lPocoUtild -lPocoXMLd -lPocoFoundationd  -lpthread -ldl -lrt
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find crti.o: No such file or directory
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find crtbeginS.o: No such file or directory
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lIoTDevicesd
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lPocoRemotingNGd
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lPocoOSPd
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lPocoUtild
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lPocoXMLd
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lPocoFoundationd
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lpthread
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -ldl
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lrt
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lstdc++
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lm
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lgcc_s
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lc
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lgcc_s
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find crtendS.o: No such file or directory
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
/home/talel/Documents/macchina.io/platform/build/rules/dylib:54: recipe for target '/home/talel/Documents/macchina.io/samples/LinuxThermalSimple/bin/Linux/x86_64/io.macchina.linux-thermal-simpled.so' failed
make: *** [/home/talel/Documents/macchina.io/samples/LinuxThermalSimple/bin/Linux/x86_64/io.macchina.linux-thermal-simpled.so] Error 1
I need help.
I see that your linker is not using proper sysroot perhaps using LD=${CC} might help.

Thanks, Talel


Re: Systemd, overlayfs, and machine-id problem

Khem Raj
 

On 10/27/20 2:23 AM, Morten Bruun wrote:
Hi,
In our current Yocto project we are using an overlayfs on top of /etc
This seems to trigger the systemd-machine-id-setup service which fails with the error below:
systemd-machine-id-setup[204]: Failed to unmount transient /etc/machine-id file: Invalid argument.
The failed service then triggers an error in the test_systemd_failed test in the systemd testimage suite.
As far as I understand the machine-id setup is triggered because path_is_mount_point() can report false positives when using overlayfs.
Is there a way to fix this?
maybe pregeenerate machine ID sometimes you can seed it from CPU Id or soc ID from eeprom.

Kind regards,
Morten


Yocto Project Status WW43'20

Stephen Jolley
 

Current Dev Position: YP 3.2 Final Build

Next Deadline: YP 3.2 Final Release

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.2 rc1 came out of QA but two reported ptest regressions along with a separate issue identified with buildhistory meant we have built an rc2 which is now in QA.
  • It's Yocto Project’s birthday. Happy 10th anniversary everyone and thanks to everyone who has contributed over the last 10 years. It’s the people that make the project what it is!
  • This week is the Embedded Linux Conference Europe which is followed by the Yocto Project Developer Summit. There is still time to register for that: https://events.linuxfoundation.org/yocto-project-summit-europe/
  • Unfortunately, intermittent autobuilder issues continue to occur. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated, unfortunately it is proving hard to find anyone interested in helping figure these out and they significantly hamper our testing.

  • We have a steadily riding WDD and Medium+ bug count which is a concern.
  • A YP 3.3 planning document has been created for ideas about what may happen in the YP 3.3 release (assuming there are people to work on the items):

https://docs.google.com/document/d/1IHiE0NU0XspDocgxZeLQ_W7o-yr0nVeBjbqImQUtH5A/edit Request edit access if you want to add to it.

  • YP 3.3 dates for builds, milestones and release have been added below.

 

Ways to contribute:

 

YP 3.2 Milestone Dates:

  • YP 3.2 M4 in QA now.

 

YP 3.3 Milestone Dates:

  • YP 3.3 M1 build date 2020/12/07
  • YP 3.3 M1 Release date 2020/12/18
  • YP 3.3 M2 build date 2021/01/18
  • YP 3.3 M2 Release date 2021/01/29
  • YP 3.3 M3 build date 2021/03/01
  • YP 3.3 M3 Release date 2021/03/12
  • YP 3.3 M4 build date 2021/04/05
  • YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

  • YP 3.1.4 build date 2020/11/2
  • YP 3.1.4 release date 2020/11/13
  • YP 3.2.1 build date 2020/11/16
  • YP 3.2.1 release date 2020/12/4
  • YP 3.1.5 build date 2021/01/11
  • YP 3.1.5 release date 2021/01/22
  • YP 3.2.2 build date 2021/02/08
  • YP 3.2.2 release date 2021/02/19
  • YP 3.1.6 build date 2021/02/22
  • YP 3.1.6 release date 2021/03/05
  • YP 3.1.7 build date 2021/03/22
  • YP 3.1.7 release date 2021/04/02

 

Tracking Metrics:

 

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/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [meta-selinux][PATCH] layer.conf: add gatesgarth compatibility

Joe MacDonald
 

[Re: [yocto] [meta-selinux][PATCH] layer.conf: add gatesgarth compatibility] On 20.10.27 (Tue 16:00) nefethael wrote:

Hi Jon,

There is already a pending patch submitted some time ago by Aníbal Limó here
https://patchwork.openembedded.org/patch/177350/
Yeah, I've had that older patch in my work-tree for a while now and
haven't pushed it upstream yet. I'll get on that today. Sorry for the
delay.

-Joe.


Best regards,
Vincent



Le lun. 26 oct. 2020 à 21:56, Jon Mason <jdmason@kudzu.us> a écrit :

Signed-off-by: Jon Mason <jdmason@kudzu.us>
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index da24359b7484..178ce1b734d3 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -23,7 +23,7 @@ BBFILE_PRIORITY_selinux = "5"
 # cause compatibility issues with other layers
 LAYERVERSION_selinux = "1"

-LAYERSERIES_COMPAT_selinux = "dunfell"
+LAYERSERIES_COMPAT_selinux = "dunfell gatesgarth"

 LAYERDEPENDS_selinux = " \
     core \
--
2.20.1







--
-Joe MacDonald.
:wq


Re: [meta-selinux][PATCH] layer.conf: add gatesgarth compatibility

Vincent Prince
 

Hi Jon,

There is already a pending patch submitted some time ago by Aníbal Limó here

Best regards,
Vincent



Le lun. 26 oct. 2020 à 21:56, Jon Mason <jdmason@...> a écrit :
Signed-off-by: Jon Mason <jdmason@...>
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index da24359b7484..178ce1b734d3 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -23,7 +23,7 @@ BBFILE_PRIORITY_selinux = "5"
 # cause compatibility issues with other layers
 LAYERVERSION_selinux = "1"

-LAYERSERIES_COMPAT_selinux = "dunfell"
+LAYERSERIES_COMPAT_selinux = "dunfell gatesgarth"

 LAYERDEPENDS_selinux = " \
     core \
--
2.20.1





Re: devtool modify issues with ubuntu 20 and fedora core 32

Ernst Sjöstrand
 

Running into this also.

Here's another report of the same issue: https://lists.yoctoproject.org/g/yocto/message/50856

Regards
//Ernst


Cross compilation error finding libraries

Bel Hadj Salem Talel
 

Hi All,

I have an SDK populated from an image.
After sourcing the SDK env file, I try to run make on a project with this command :
make CC="$CC" LD="$LD" CFLAGS="${CFLAGS} --sysroot=/media/talel/data/sdk-multigate/sysroots/aarch64-poky-linux" CXXFLAGS="${CXXFLAGS} --sysroot=/media/talel/data/sdk-multigate/sysroots/aarch64-poky-linux"
I specified the CFLAGS and CXXFLAGS as mentionned in Yocto document (part 5.2 Makefile-Based projects) : https://www.yoctoproject.org/docs/1.1.2/adt-manual/adt-manual.html
Now I have this error:


** Building dynamic library (debug, shared) /home/talel/Documents/macchina.io/samples/LinuxThermalSimple/bin/Linux/x86_64/io.macchina.linux-thermal-simpled.so
aarch64-poky-linux-g++ -shared -Wl,-soname,io.macchina.linux-thermal-simpled.so -o /home/talel/Documents/macchina.io/samples/LinuxThermalSimple/bin/Linux/x86_64/io.macchina.linux-thermal-simpled.so  /home/talel/Documents/macchina.io/samples/LinuxThermalSimple/obj/Linux/x86_64/debug_shared/LinuxThermalSensor.o /home/talel/Documents/macchina.io/samples/LinuxThermalSimple/obj/Linux/x86_64/debug_shared/BundleActivator.o -L/home/talel/Documents/macchina.io/lib/Linux/x86_64 -L/home/talel/Documents/macchina.io/platform/lib/Linux/x86_64  -lIoTDevicesd -lPocoRemotingNGd -lPocoOSPd -lPocoUtild -lPocoXMLd -lPocoFoundationd  -lpthread -ldl -lrt
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find crti.o: No such file or directory
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find crtbeginS.o: No such file or directory
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lIoTDevicesd
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lPocoRemotingNGd
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lPocoOSPd
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lPocoUtild
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lPocoXMLd
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lPocoFoundationd
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lpthread
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -ldl
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lrt
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lstdc++
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lm
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lgcc_s
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lc
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find -lgcc_s
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find crtendS.o: No such file or directory
/media/talel/data/sdk-multigate/sysroots/x86_64-pokysdk-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.2.0/real-ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
/home/talel/Documents/macchina.io/platform/build/rules/dylib:54: recipe for target '/home/talel/Documents/macchina.io/samples/LinuxThermalSimple/bin/Linux/x86_64/io.macchina.linux-thermal-simpled.so' failed
make: *** [/home/talel/Documents/macchina.io/samples/LinuxThermalSimple/bin/Linux/x86_64/io.macchina.linux-thermal-simpled.so] Error 1

I need help.
Thanks, Talel


Systemd, overlayfs, and machine-id problem

Morten Bruun
 

Hi,

In our current Yocto project we are using an overlayfs on top of /etc

This seems to trigger the systemd-machine-id-setup service which fails with the error below: 

systemd-machine-id-setup[204]: Failed to unmount transient /etc/machine-id file: Invalid argument.

The failed service then triggers an error in the test_systemd_failed test in the systemd testimage suite.

As far as I understand the machine-id setup is triggered because path_is_mount_point() can report false positives when using overlayfs.

Is there a way to fix this?

Kind regards,
Morten

3881 - 3900 of 55062