[yocto] [meta-selinux][PATCH] policycoreutils: fix usrmerge install path
From: Mingli Yu
Set SBINDIR to ${base_sbindir} to fix below
issue when usrmerge enabled in DISTRO_FEATURES
| ERROR: QA Issue: policycoreutils-dbg package is not obeying usrmerge distro
feature. /sbin should be relocated to /usr. [usrmerge]
| WARNING: policycoreutils-2.7-r0 do_package: QA Issue: policycoreutils:
Files/directories were installed but not shipped in any package:
/sbin/restorecon
/sbin/setfiles
/sbin/load_policy
/sbin/restorecon_xattr
/sbin/fixfiles
Signed-off-by: Mingli Yu
---
recipes-security/selinux/policycoreutils.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/recipes-security/selinux/policycoreutils.inc
b/recipes-security/selinux/policycoreutils.inc
index b7cb510..e2d44f4 100644
--- a/recipes-security/selinux/policycoreutils.inc
+++ b/recipes-security/selinux/policycoreutils.inc
@@ -158,6 +158,7 @@ do_compile_prepend() {
do_install_prepend() {
export PYTHON=python
export SEMODULE_PATH=${sbindir} SYSTEMDDIR=${D}/${systemd_unitdir}
+ export SBINDIR="${D}/${base_sbindir}"
}
do_install_class-native() {
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-cgl][PATCH] ocfs2-tools: fix usrmerge install path
From: Mingli Yu
Set prefix to fix below issue when usrmerge
enabled in DISTRO_FEATURES
| WARNING: ocfs2-tools-1.8.5-r0 do_package: QA Issue: ocfs2-tools:
Files/directories were installed but not shipped in any package:
/sbin/mount.ocfs2
/sbin/o2cb
/sbin/o2cluster
/sbin/mkfs.ocfs2
/sbin/tunefs.ocfs2
/sbin/fsck.ocfs2
/sbin/debugfs.ocfs2
/sbin/o2cb_ctl
/sbin/ocfs2_hb_ctl
/sbin/mounted.ocfs2
/sbin/o2image
| ERROR: QA Issue: ocfs2-tools-dbg package is not obeying usrmerge distro
feature. /sbin should be relocated to /usr. [usrmerge]
Signed-off-by: Mingli Yu
---
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.5.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.5.bb
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.5.bb
index 8cf82a8..a0376ec 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.5.bb
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.5.bb
@@ -48,6 +48,7 @@ EXTRA_OECONF = " \
--enable-ocfs2console=no \
--enable-dynamic-fsck=yes \
--enable-dynamic-ctl=yes \
+--with-root-prefix=${root_prefix} \
"
do_configure_prepend () {
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Tracking changes in image
Hi Bryan, In addition to what Jon mentioned, “os-release” package in oe-core could help in tracking the operating system identification data in deployed images. Since you are using u-boot, a customized logic involving environment variable in u-boot and accessing it from user-space with tools like “fw_printenv” available from u-boot-fwutils should help there. Best Regards, Maxin From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Jon Szymaniak Sent: Tuesday, August 28, 2018 6:18 AM To: bryan.fish...@gmail.com Cc: yocto@yoctoproject.org Subject: Re: [yocto] Tracking changes in image On Mon, Aug 27, 2018 at 10:13 Bryan Fishell mailto:bryan.fish...@gmail.com>> wrote: Hi, I want to be able to track different parts of my image, accessible from within userspace so I can programmatically (via an environment variable or something) what version of my patches have been applied. Ultimately, I want to be able to answer questions from the field to know 'what changed' in a deployed image. Is there already a method to do this? For example, our project has u-boot, a zImage and rootfs. Is there a way to tell the patched version (from my layer) for each of those so I can connect what is in the field to what is in my layer in version control? Thanks in advance -- Take a look at the documentation for the Build History feature. I think that may be a good starting point for you. https://www.yoctoproject.org/docs/2.5.1/dev-manual/dev-manual.html#maintaining-build-output-quality Ultimately, the Build History provides you with the "what changed" in terms of build artifacts, which you can then trace back to individual packages and recipes. On the other hand, version control of your own Yocto/OE layers (which has nothing to do with build history) should capture the "why was X changed". Of course, this requires that your organization uses version control in a disciplined manner for any layer metadata they maintain. Between these two, you should be able to develop a pretty clear picture of the "what and why" with respect to changes in an image. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Porting rtc-pcf85363.c file
Hi I need to port rtc-pcf85363 driver to older version of linux . Can anyone suggest the patch that can directly work or steps need to be followed. Sent from my Samsung Galaxy smartphone.-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PyBuild based OpenEmbedded/BitBake recipe
On 20 August 2018 at 01:33, bernardo araujo rodrigues wrote: > Looking at PhantomJS' github repo (https://github.com/ariya/phantomjs), I > realized it's a PyBuild based project. However, I couldn't find any BitBake > class like the setuptools or pypi that would support the build.py script. That build.py is entirely hand-coded and doesn't use *any* standard systems, you'll need to call it yourself. This is trivial: python3 build.py. Then you get to discover all the corner cases that people don't think about when they hand-code build scripts... Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Porting rtc-pcf85363.c file
>> I need to port rtc-pcf85363 driver to older version of linux. What version exactly? --- Kosta Z -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gRPC: grpc_cpp_plugin is not included in host sysroot for standard sdk
I think it is a very sensible approach to first check in the latest branch. If it is supported in the latest branch - then port it. So - is this thing supported in the latest poky branch? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Does yocto support android build tools?
Hello Everyone, I'm trying to introduce an android package to my image. As I know, android uses its own build development kit, and uses Android.mk and Android.bp rather than traditional makefiles. I'm curious about if yocto supports such mechanism. Do I have to replace Android.mk and Android.bp with Makefiles? The following link says that yocto may be compatible with android packages. I've googled a lot but I didn't get any tip. https://stackoverflow.com/questions/40759597/what-is-android-compat-build-artifacts-of-poky-in-yocto So, before rewriting all the makefiles, I would rather ask: is there any better way to solve the problem?-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PyBuild based OpenEmbedded/BitBake recipe
Please remember to CC the list.
On 28 August 2018 at 14:40, bernardo araujo rodrigues
wrote:
> Indeed I thought about calling "python3 build.py" inside the do_compile
> task.
>
> However my doubt is whether this will actually cross compile and integrate
> properly with the sysroot, or Python will build natively (which would be
> kinda useless).
Exactly. Good luck, you might need it. If you're lucky it will just
work, if it respects ${CC} and so on.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] do_rootfs fails at master with something about glibc-binary-localedata-...
Hi, I need a bit of help on Yocto. I have a perfect working project at the latest state of Sumo. However, building the image when having all meta layers at the latest state at master fails. The step 'do_rootfs' gives: -- The following packages have unmet dependencies: locale-base-en-gb : Depends: glibc-binary-localedata-en-gb but it is not going to be installed locale-base-en-us : Depends: glibc-binary-localedata-en-us but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). -- Could somebody point me in the correct direction? Thanks -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_rootfs fails at master with something about glibc-binary-localedata-...
2018-08-28 16:34 GMT+02:00 jan vermaete : > I have a perfect working project at the latest state of Sumo. > However, building the image when having all meta layers at the latest > state at master fails. > > The step 'do_rootfs' gives: > -- > The following packages have unmet dependencies: > locale-base-en-gb : Depends: glibc-binary-localedata-en-gb but it is > not going to be installed > locale-base-en-us : Depends: glibc-binary-localedata-en-us but it is > not going to be installed > E: Unmet dependencies. Try 'apt-get -f install' with no packages (or > specify a solution). We don't really test deb packaging, and especially making images from debs is not tested on the autobuilder at all I believe. Your options are to debug the dependencies in .deb, or switch to rpm or ipk formats. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW35’18
Current Dev Position: YP 2.6 M3. - This is feature freeze for YP 2.6! Next Deadline: YP 2.6 M3 Build Target is Aug. 27, 2018 SWAT Team Rotation: · SWAT lead is currently: Paul · SWAT team rotation: Paul -> Ross on Aug. 31, 2018 · SWAT team rotation: Ross -> Amanda on Sept. 7, 2018 · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: · We’re now into M3 feature freeze so new feature patches, particularly for unplanned changes will be much less likely to be merged until 2.7 now. · Fixes merged for hardlinked files and their debug symbol links including new test cases to ensure this does not regress · Pending kernel upgrades (to 4.18) and other kernel changes for 2.6 merged · There was a change to the cpan class code which broke various external perl recipes. A secondary fix has been merged but needs testing, if it fails we may need to revert the original change. · Some key changes in toaster merged · Some oeqa race/logging output issues were identified and fixed · The sstate equivalency server work from Joshua/Garmin has review still pending and identifying/fixing persist_data fork issues (it's partly tracked down but not completely). · 2.4 (rocko) series stabilization continues for the next point release 2.4.4 · Autobuilder2 now includes instructions on setting up and rebuilding the Yocto Console UI plugin · We have a build speed performance regression where the llvm build time and python pgo optimisation time added by new recent features mean builds are now taking around 45 minutes longer on our standard benchmarking system (1:26 -> 2:11). · This llvm dependency addition to mesa by default means image size for core-image-sato also increased substantially (230MB -> 309MB). Planned Releases for YP 2.6: · YP 2.6 M3 Build Target is Aug. 27, 2018 · YP 2.6 M3 Release Target is Sept. 7, 2018 · YP 2.6 M4 Build Target is Oct. 1, 2018 · YP 2.6 M4 Release Target is Oct. 26, 2018 Planned upcoming dot releases: · YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done. · YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done. Tracking Metrics: · WDD 2610 (last week 2578) (https://wiki.yoctoproject.org/charts/combo.html) · Poky Patch Metrics oTotal patches found: 1636 (last week 1623) oPercentage of patches in the Pending State: 737 (45%) [last week 737 (45%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features 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 INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 •Cell:(208) 244-4460 • Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] net-snmp_5.8.bb failed to compile
Hi,
Just download net-snmp_5.8.bb but it failed to compile:
$ bitbake net-snmp
Loading cache: 100%
||
Time: 0:00:01
Loaded 3093 entries from dependency cache.
*ERROR:* ExpansionError during parsing
/opt/PHYTEC_BSPs/yocto_imx7/sources/meta-openembedded/meta-networking/recipes-protocols/net-snmp/
net-snmp_5.8.bb | ETA:
--:--:--
Traceback (most recent call last):
File
"/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/classes/base.bbclass", line
375, in
__anon_656__opt_PHYTEC_BSPs_yocto_imx7_sources_poky_meta_classes_base_bbclass(d=):
pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
>pn = d.getVar("PN", True)
File
"/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
line 569, in DataSmart.getVar(var='PACKAGECONFIG', expand=True,
noweakdefault=False, parsing=False):
def getVar(self, var, expand, noweakdefault=False, parsing=False):
>return self.getVarFlag(var, "_content", expand, noweakdefault,
parsing)
File
"/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
line 737, in DataSmart.getVarFlag(var='PACKAGECONFIG', flag='_content',
expand=True, noweakdefault=False, parsing=False):
cachename = var + "[" + flag + "]"
>value = self.expand(value, cachename)
File
"/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
line 410, in DataSmart.expand(s="${@bb.utils.filter('DISTRO_FEATURES',
'ipv6', d)}", varname='PACKAGECONFIG'):
def expand(self, s, varname = None):
>return self.expandWithRefs(s, varname).value
File
"/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
line 400, in
DataSmart.expandWithRefs(s="${@bb.utils.filter('DISTRO_FEATURES', 'ipv6',
d)}", varname='PACKAGECONFIG'):
except Exception as exc:
>raise ExpansionError(varname, s, exc) from exc
bb.data_smart.ExpansionError: Failure expanding variable PACKAGECONFIG,
expression was ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} which
triggered exception AttributeError: module 'bb.utils' has no attribute
'filter'
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
$
Any hints would be greatly appreciated.
S
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Production vs Debug Images
Hi, Given a target machine, is there a traditional way to produce either a debug image vs a production image? If so, can you give some advice on generally how to do this? I have read about conditionally including a package (or bitbake variable) based on another variable, but that seems error prone. It seems like this is a problem that already has a solution, I just don't know what it is. TIA -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] net-snmp_5.8.bb failed to compile
Follow the READMEs and don't mix layers from different branches.
You need to checkout all repositories with layers from the same branch to
be compatible. Now you're mixing newer meta-oe branch with older oe-core
branch which doesn't have bb.utils.filter function yet.
On Tue, Aug 28, 2018 at 5:17 PM Simon Chamlian
wrote:
>
> Hi,
>
> Just download net-snmp_5.8.bb but it failed to compile:
>
>
> $ bitbake net-snmp
> Loading cache: 100%
> ||
> Time: 0:00:01
> Loaded 3093 entries from dependency cache.
> *ERROR:* ExpansionError during parsing
> /opt/PHYTEC_BSPs/yocto_imx7/sources/meta-openembedded/meta-networking/recipes-protocols/net-snmp/
> net-snmp_5.8.bb | ETA:
> --:--:--
> Traceback (most recent call last):
> File
> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/classes/base.bbclass", line
> 375, in
> __anon_656__opt_PHYTEC_BSPs_yocto_imx7_sources_poky_meta_classes_base_bbclass(d= object at 0x7fe0ee311be0>):
> pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
> >pn = d.getVar("PN", True)
>
> File
> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
> line 569, in DataSmart.getVar(var='PACKAGECONFIG', expand=True,
> noweakdefault=False, parsing=False):
> def getVar(self, var, expand, noweakdefault=False, parsing=False):
> >return self.getVarFlag(var, "_content", expand,
> noweakdefault, parsing)
>
> File
> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
> line 737, in DataSmart.getVarFlag(var='PACKAGECONFIG', flag='_content',
> expand=True, noweakdefault=False, parsing=False):
> cachename = var + "[" + flag + "]"
> >value = self.expand(value, cachename)
>
> File
> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
> line 410, in DataSmart.expand(s="${@bb.utils.filter('DISTRO_FEATURES',
> 'ipv6', d)}", varname='PACKAGECONFIG'):
> def expand(self, s, varname = None):
> >return self.expandWithRefs(s, varname).value
>
> File
> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
> line 400, in
> DataSmart.expandWithRefs(s="${@bb.utils.filter('DISTRO_FEATURES', 'ipv6',
> d)}", varname='PACKAGECONFIG'):
> except Exception as exc:
> >raise ExpansionError(varname, s, exc) from exc
>
> bb.data_smart.ExpansionError: Failure expanding variable PACKAGECONFIG,
> expression was ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} which
> triggered exception AttributeError: module 'bb.utils' has no attribute
> 'filter'
>
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> $
>
> Any hints would be greatly appreciated.
>
> S
>
>
>
> --
> ___
> 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] Production vs Debug Images
On Tue, Aug 28, 2018 at 4:31 PM Bryan Fishell wrote: > > Hi, > > Given a target machine, is there a traditional way to produce either a debug > image vs a production image? If so, can you give some advice on generally how > to do this? > > I have read about conditionally including a package (or bitbake variable) > based on another variable, but that seems error prone. It seems like this is > a problem that already has a solution, I just don't know what it is. > This is what we're using: https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/classes/image-mode-variants.bbclass -- Alex Kiernan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Sequential generation of eSDK from with the same workspace fails for similar machines
Hi, I am subsequently trying to render eSDKs for two different machines from within the same workspace. The first (succeeding) is built according to 'MACHINE="zcu102-zynqmp" bitbake core-image-minimal -c populate_sdk_ext' whereas the second (MACHINE="zcu104-zynqmp" bitbake core-image-minimal -c populate_sdk_ext) fails providing: ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: The recipe core-image-minimal is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /home/martin/work/z7000-distro/build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-aarch64-toolchain-ext-2.5.1.testdata.json (matched in manifest-zcu102_zynqmp-core-image-minimal.populate_sdk_ext) /home/martin/work/z7000-distro/build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-aarch64-toolchain-ext-2.5.1.sh (matched in manifest-zcu102_zynqmp-core-image-minimal.populate_sdk_ext) Please verify which recipe should provide the above files. The build has stopped, as continuing in this scenario WILL break things - if not now, possibly in the future (we've seen builds fail several months later). If the system knew how to recover from this automatically it would, however there are several different scenarios which can result in this and we don't know which one this is. It may be you have switched providers of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you need to execute the clean task for both recipes and it will resolve this error. It may be you changed DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those recipes should again resolve this error, however switching DISTRO_FEATURES on an existing build directory is not supported - you should really clean out tmp and rebuild (reusing sstate should be safe). It could be the overlapping files detected are harmless in which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It could also be your build is including two different conflicting versions of things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to resolve the conflict. If in doubt, please ask on the mailing list, sharing the error and filelist above. ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: If the above message is too much, the simpler version is you're advised to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix things in most (but not all) cases. ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Function failed: sstate_task_postfunc ERROR: Logfile of failure stored in: /home/martin/work/z7000-distro/build/tmp/work/zcu104_zynqmp-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk_ext.14111 ERROR: Task (/home/martin/work/z7000-distro/poky/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext) failed with exit code '1' Since the machines are of the same CPU architecture and and the image being the same, the previously built artifacts are about to be overwritten. AFAICS images are neatly populated in subdirectories according to the machine name, however since the SDKs are not populated according to the machine the above issue is encountered. Is this not a supported use case, or am I missing a configuration? Thanks, Martin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Does yocto support android build tools?
On Tue, Aug 28, 2018 at 5:59 AM benxi wrote: > > Hello Everyone, > I'm trying to introduce an android package to my image. As I know, > android uses its own build development kit, and uses Android.mk and > Android.bp rather than traditional makefiles. > I'm curious about if yocto supports such mechanism. Do I have to replace > Android.mk and Android.bp with Makefiles? > > The following link says that yocto may be compatible with android > packages. I've googled a lot but I didn't get any tip. > > https://stackoverflow.com/questions/40759597/what-is-android-compat-build-artifacts-of-poky-in-yocto > > So, before rewriting all the makefiles, I would rather ask: is there any > better way to solve the problem? Yocto build system delegates the build work to component's own build system therefore it should be inline to build android packages, may be a bbclass to abstract common android build functions and then writing recipes would become easier. It might be one time work but worth if there are many packages that need to be ported. you have to also keep in mind the runtime differences between android and general Linux systems. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] net-snmp_5.8.bb failed to compile
How can I avoid mixing branches.
I already have a meta-openembedded layer, which supports net-snmp_5.7.3
(which compiles but I want to update).
Now I cloned a new meta-openembedded layer, which as net-snmp_5.8.
How can I merge the layers (meta-openembedded that I have and the new
cloned one)?
On Tue, Aug 28, 2018 at 11:43 AM, Martin Jansa
wrote:
> Follow the READMEs and don't mix layers from different branches.
>
> You need to checkout all repositories with layers from the same branch to
> be compatible. Now you're mixing newer meta-oe branch with older oe-core
> branch which doesn't have bb.utils.filter function yet.
>
> On Tue, Aug 28, 2018 at 5:17 PM Simon Chamlian
> wrote:
>
>>
>> Hi,
>>
>> Just download net-snmp_5.8.bb but it failed to compile:
>>
>>
>> $ bitbake net-snmp
>> Loading cache: 100% |#
>>
>> ###|
>> Time: 0:00:01
>> Loaded 3093 entries from dependency cache.
>> *ERROR:* ExpansionError during parsing /opt/PHYTEC_BSPs/yocto_imx7/
>> sources/meta-openembedded/meta-networking/recipes-protocols/net-snmp/
>> net-snmp_5.8.bb | ETA:
>> --:--:--
>> Traceback (most recent call last):
>> File "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/classes/base.bbclass",
>> line 375, in __anon_656__opt_PHYTEC_BSPs_yocto_imx7_sources_poky_meta_
>> classes_base_bbclass(d=> 0x7fe0ee311be0>):
>> pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
>> >pn = d.getVar("PN", True)
>>
>> File
>> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
>> line 569, in DataSmart.getVar(var='PACKAGECONFIG', expand=True,
>> noweakdefault=False, parsing=False):
>> def getVar(self, var, expand, noweakdefault=False,
>> parsing=False):
>> >return self.getVarFlag(var, "_content", expand,
>> noweakdefault, parsing)
>>
>> File
>> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
>> line 737, in DataSmart.getVarFlag(var='PACKAGECONFIG', flag='_content',
>> expand=True, noweakdefault=False, parsing=False):
>> cachename = var + "[" + flag + "]"
>> >value = self.expand(value, cachename)
>>
>> File
>> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
>> line 410, in DataSmart.expand(s="${@bb.utils.filter('DISTRO_FEATURES',
>> 'ipv6', d)}", varname='PACKAGECONFIG'):
>> def expand(self, s, varname = None):
>> >return self.expandWithRefs(s, varname).value
>>
>> File
>> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
>> line 400, in
>> DataSmart.expandWithRefs(s="${@bb.utils.filter('DISTRO_FEATURES',
>> 'ipv6', d)}", varname='PACKAGECONFIG'):
>> except Exception as exc:
>> >raise ExpansionError(varname, s, exc) from exc
>>
>> bb.data_smart.ExpansionError: Failure expanding variable PACKAGECONFIG,
>> expression was ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} which
>> triggered exception AttributeError: module 'bb.utils' has no attribute
>> 'filter'
>>
>>
>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>> $
>>
>> Any hints would be greatly appreciated.
>>
>> S
>>
>>
>>
>> --
>> ___
>> 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] do_rootfs fails at master with something about glibc-binary-localedata-...
It's working. Thanks! I hope deb package will be again fully supported in the next release. Op 28 aug. 2018 4:48 p.m. schreef "Alexander Kanavin" < alex.kana...@gmail.com>: 2018-08-28 16:34 GMT+02:00 jan vermaete : > I have a perfect working project at the latest state of Sumo. > However, building the image when having all meta layers at the latest > state at master fails. > > The step 'do_rootfs' gives: > -- > The following packages have unmet dependencies: > locale-base-en-gb : Depends: glibc-binary-localedata-en-gb but it is > not going to be installed > locale-base-en-us : Depends: glibc-binary-localedata-en-us but it is > not going to be installed > E: Unmet dependencies. Try 'apt-get -f install' with no packages (or > specify a solution). We don't really test deb packaging, and especially making images from debs is not tested on the autobuilder at all I believe. Your options are to debug the dependencies in .deb, or switch to rpm or ipk formats. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_rootfs fails at master with something about glibc-binary-localedata-...
2018-08-28 21:39 GMT+02:00 jan vermaete : > It's working. Thanks! > > I hope deb package will be again fully supported in the next release. Someone has to do the work though. If you truly want it fixed, you know what to do :) Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] net-snmp_5.8.bb failed to compile
Will the following method work?
yocto-layer create openembedded*2*
and add the path in conf/bblayers.conf
By doing this, I will have
openembedded where net-snmp version 5.7.3 resides
openembedded*2* where net-snmp version 5.8 resides
Then issuing bitbake net-snmp it will take the 5.8?
On Tue, Aug 28, 2018 at 2:32 PM, Simon Chamlian
wrote:
> How can I avoid mixing branches.
>
> I already have a meta-openembedded layer, which supports net-snmp_5.7.3
> (which compiles but I want to update).
>
> Now I cloned a new meta-openembedded layer, which as net-snmp_5.8.
>
> How can I merge the layers (meta-openembedded that I have and the new
> cloned one)?
>
>
>
>
>
>
> On Tue, Aug 28, 2018 at 11:43 AM, Martin Jansa
> wrote:
>
>> Follow the READMEs and don't mix layers from different branches.
>>
>> You need to checkout all repositories with layers from the same branch to
>> be compatible. Now you're mixing newer meta-oe branch with older oe-core
>> branch which doesn't have bb.utils.filter function yet.
>>
>> On Tue, Aug 28, 2018 at 5:17 PM Simon Chamlian
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> Just download net-snmp_5.8.bb but it failed to compile:
>>>
>>>
>>> $ bitbake net-snmp
>>> Loading cache: 100% |#
>>>
>>> ###|
>>> Time: 0:00:01
>>> Loaded 3093 entries from dependency cache.
>>> *ERROR:* ExpansionError during parsing /opt/PHYTEC_BSPs/yocto_imx7/so
>>> urces/meta-openembedded/meta-networking/recipes-protocols/net-snmp/
>>> net-snmp_5.8.bb | ETA:
>>> --:--:--
>>> Traceback (most recent call last):
>>> File "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/classes/base.bbclass",
>>> line 375, in __anon_656__opt_PHYTEC_BSPs_yo
>>> cto_imx7_sources_poky_meta_classes_base_bbclass(d=>> object at 0x7fe0ee311be0>):
>>> pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
>>> >pn = d.getVar("PN", True)
>>>
>>> File
>>> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
>>> line 569, in DataSmart.getVar(var='PACKAGECONFIG', expand=True,
>>> noweakdefault=False, parsing=False):
>>> def getVar(self, var, expand, noweakdefault=False,
>>> parsing=False):
>>> >return self.getVarFlag(var, "_content", expand,
>>> noweakdefault, parsing)
>>>
>>> File
>>> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
>>> line 737, in DataSmart.getVarFlag(var='PACKAGECONFIG', flag='_content',
>>> expand=True, noweakdefault=False, parsing=False):
>>> cachename = var + "[" + flag + "]"
>>> >value = self.expand(value, cachename)
>>>
>>> File
>>> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
>>> line 410, in DataSmart.expand(s="${@bb.utils.filter('DISTRO_FEATURES',
>>> 'ipv6', d)}", varname='PACKAGECONFIG'):
>>> def expand(self, s, varname = None):
>>> >return self.expandWithRefs(s, varname).value
>>>
>>> File
>>> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
>>> line 400, in DataSmart.expandWithRefs(s="${
>>> @bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}",
>>> varname='PACKAGECONFIG'):
>>> except Exception as exc:
>>> >raise ExpansionError(varname, s, exc) from exc
>>>
>>> bb.data_smart.ExpansionError: Failure expanding variable PACKAGECONFIG,
>>> expression was ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} which
>>> triggered exception AttributeError: module 'bb.utils' has no attribute
>>> 'filter'
>>>
>>>
>>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>>> $
>>>
>>> Any hints would be greatly appreciated.
>>>
>>> S
>>>
>>>
>>>
>>> --
>>> ___
>>> 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] Disable cert validation
All I have a situation where our device (yocto - Jethro) is failing to validate a certificate. 12520 EAP-TLS failed SSL/TLS handshake because the client rejected the ISE local-certificate. I would like to disable the cert validation. Is there an nmcli command (or some other way) that I could disable? Thanks, srini CONFIDENTIALITY NOTICE: This email message and any attachments are confidential and may be privileged and are meant to be read by the intended recipient only. If you are not the intended recipient, please notify sender immediately and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Morty (2.2.1) Build Verification
Hi, I've read that some of the ongoing initiatives of the Yocto project is to strive towards binary reproducible builds. I am using a test project with Morty (2.2.1). My custom BSP layer are currently local files.Ultimately I would like to: 1. Know a method of how I can verify my build on two different hosts 2. Is there a way I can append this verification method (hashes of SRCREV or something) into the os-release recipe so with whatever build verification (correlating build-metadata into the image so I can correspond it to version control to see what changed?) Thanks in advance -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Sequential generation of eSDK from with the same workspace fails for similar machines
The problem is about two machines having the same TUNE_PKGARCH, and could be solved by setting TOOLCHAIN_OUTPUTNAME in your distro conf file to include MACHINE information. But I'm not sure if this is a bug and should be fixed. Let's wait for more opinions. Best Regards, Chen Qi On 08/28/2018 04:44 PM, Martin Siegumfeldt wrote: Hi, I am subsequently trying to render eSDKs for two different machines from within the same workspace. The first (succeeding) is built according to 'MACHINE="zcu102-zynqmp" bitbake core-image-minimal -c populate_sdk_ext' whereas the second (MACHINE="zcu104-zynqmp" bitbake core-image-minimal -c populate_sdk_ext) fails providing: ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: The recipe core-image-minimal is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /home/martin/work/z7000-distro/build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-aarch64-toolchain-ext-2.5.1.testdata.json (matched in manifest-zcu102_zynqmp-core-image-minimal.populate_sdk_ext) /home/martin/work/z7000-distro/build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-aarch64-toolchain-ext-2.5.1.sh (matched in manifest-zcu102_zynqmp-core-image-minimal.populate_sdk_ext) Please verify which recipe should provide the above files. The build has stopped, as continuing in this scenario WILL break things - if not now, possibly in the future (we've seen builds fail several months later). If the system knew how to recover from this automatically it would, however there are several different scenarios which can result in this and we don't know which one this is. It may be you have switched providers of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you need to execute the clean task for both recipes and it will resolve this error. It may be you changed DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those recipes should again resolve this error, however switching DISTRO_FEATURES on an existing build directory is not supported - you should really clean out tmp and rebuild (reusing sstate should be safe). It could be the overlapping files detected are harmless in which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It could also be yo ur build is including two different conflicting versions of things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to resolve the conflict. If in doubt, please ask on the mailing list, sharing the error and filelist above. ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: If the above message is too much, the simpler version is you're advised to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix things in most (but not all) cases. ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Function failed: sstate_task_postfunc ERROR: Logfile of failure stored in: /home/martin/work/z7000-distro/build/tmp/work/zcu104_zynqmp-poky-linux/core-image-minimal/1.0-r0/temp/log.do_populate_sdk_ext.14111 ERROR: Task (/home/martin/work/z7000-distro/poky/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext) failed with exit code '1' Since the machines are of the same CPU architecture and and the image being the same, the previously built artifacts are about to be overwritten. AFAICS images are neatly populated in subdirectories according to the machine name, however since the SDKs are not populated according to the machine the above issue is encountered. Is this not a supported use case, or am I missing a configuration? Thanks, Martin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux][PATCH] libselinux: fix usrmerge do_install
From: Mingli Yu
When usrmerge enabled in DISTRO_FEATURES,
the binary actually installed under ${base_sbindir},
so cannot remove ${D}${base_sbindir} when
usrmerge enabled.
Signed-off-by: Mingli Yu
---
recipes-security/selinux/libselinux.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/recipes-security/selinux/libselinux.inc
b/recipes-security/selinux/libselinux.inc
index 51d0875..ae47b5a 100644
--- a/recipes-security/selinux/libselinux.inc
+++ b/recipes-security/selinux/libselinux.inc
@@ -34,7 +34,9 @@ do_compile_append() {
do_install_append() {
oe_runmake install-pywrap swigify \
PYSITEDIR=${D}${libdir}/python${PYTHON_BASEVERSION}/site-packages
-rm -rf ${D}${base_sbindir}
+if ! ${@bb.utils.contains('DISTRO_FEATURES','usrmerge','true','false',d)};
then
+rm -rf ${D}${base_sbindir}
+fi
}
BBCLASSEXTEND = "native"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
