Update bitbake broken build
JH
Hi,
I updated the bitbake to run git pull in master branch, now it is broken, what does the following error message mean, how to fix it? $ bitbake-layers show-layers NOTE: Starting bitbake server... ERROR: Variable PROVIDES_prepend contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake. Thank you. Kind regards, - jupiter
|
|
Re: Wayland and X11 on Yocto
Manuel Wagesreither
Hi all, hi Khem,
Am Do, 19. Aug 2021, um 00:22, schrieb Khem Raj: On Wed, Aug 18, 2021 at 3:06 PM Manuel Wagesreither <ManWag@...> wrote:Okay, so if I get things right then IMAGE_FEATURES+="x11" is under the hood nothing more than an IMAGE_INSTALL+="packagegroup-core-x11". Is that right? If so, what's the purpose of adding the concept of IMAGE_FEATURE? I mean, it doesn't make things SO much easier. Setting an IMAGE_FEATURE or an IMAGE_INSTALL variable is the same to me.x11-* features is primarily to control what kind of x11 packages you you should really is looking at DISTRO_FEATURES e.g. wayland distroYepp, I know. I left them out on purpose because I was mainly interested in where the configuration for X11 and wayland differs conceptually. With "conceptually" I mean that one is added through IMAGE_FEATURES while the other is through IMAGE_INSTALL. And if there would be more wayland based compositors or images then you would turn extract this into an IMAGE_FEATURE as well? Why? How does that make things easier? Again, I feel there's something to IMAGE_FEATURES I didn't yet understand.* Theory: Is IMAGE_FEATURE +=x11 manipulating IMAGE_INSTALL under the hood so you don't have to do it manually? And as there is no IMAGE_FEATURE "wayland", you have do it manually. Correct?there are not many wayland based compositors or images we have in core Thanks for the explanation on MACHINE_HWCODEC. I'm curious, so is core-image-x11 require DISTRO_FEATURE hwcodec or not? If yes, than it seems to be missing in the core-image-x11.bb (it's in the core-images-weston.bb, after all), if no, then why is it not required for X11?* Why does core-image-weston.bb need to enable IMAGE_FEATURE hwcodec, while core-image-x11.bb does not? (Dunfell branch.)openGL is needed for wayland/weston to work too but hwcodec feature is I know I'm asking quite detailed questions, but I got the feeling I need to understand this once and for all. Thanks, regards, Manuel
|
|
Extensible SDK - runtime packages installation
d0ku
Hi, I've been playing with extensible SDK lately and got to a point, where I want to create a minimal SDK installer and install all the required packages in runtime via `devtool sdk-install`, so that every developer can get only the stuff that's actually needed. For the target part it works as expected, installing the content to ${OECORE_TARGET_SYSROOT}, however for the host part the content gets installed to ${OECORE_NATIVE_SYSROOT}, but it's not visible in the PATH in some cases. E.g. for perl-native the binaries are installed to `<native sysroot>/bin/perl-native` and are not visible, unless I manually extend the PATH with this directory, then it works fine. So my questions are: * Is the runtime installation of packages meant to run on host actually supported? It surely works for e.g. compiler, so I assume it should be also fine for other packages? * Should I install `nativesdk-` or `-native` packages, if I want to use them this way? Or can I actually do both? In the eSDK talk by Paul Eggerton I saw that `nativesdk-cmake` was added, but the `nativesdk-` doesn't really seem to fit `mini Yocto environment` that eSDK basically is. * Am I possibly missing some configuration steps? In Yocto environment the PATH gets expanded with `bin/perl-native` automatically, but I wasn't able to pinpoint what file/task actually does it. Best Regards and thanks in advance, Jakub
|
|
Re: meta-gnome error
#yocto
On 8/23/21 2:55 AM, yasminebenghozzi6@... wrote:
Hello, please can anyone help with this error ?this class is provided by meta-oe layer. Make sure you have meta-oe layer in your bblayers.conf
|
|
Yocto Technical Team Minutes, Engineering Sync, for August 17, 2021
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for August 17, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == disclaimer == Best efforts are made to ensure the below is accurate and valid. However, errors sometimes happen. If any errors or omissions are found, please feel free to reply to this email with any corrections. == attendees == Trevor Woerner, Stephen Jolley Richard Purdie Peter Kjellerstedt Joshua Watt Randy MacLeod Saul Wold Michael Halstead Richard Elberger Scott Murray Steve Sakoman Tony Toscioglu Trevor Gamblin Bruce Ashfield Ross Burton Alexandre Belloni Daiane Angolini Jon Mason Jan-Simon Möller == project status == - 3.1.10 (dunfell) released - 3.4 (honister) is in feature freeze next week (pending work includes rust and prserv) - glibc 2.34 update merged. the builds are fine, but causes problems with uninative and pseudo, fixes being investigated - kernel: drop 5.4, updates to 5.10 and 5.13 - appears to be issues with buildtools tarball in aarch64 (probably related to gcc 11 update) - plan to migrate tune files into architecture-specific directories; patch likely to merge in the next few days - bitbake fetcher no longer ignores SSL certificates - LTO linker flag handling changes merged to help with reproducibility issues - overlayfs class changes were merged == discussion == Randy: the pending rust work is coming along. fixed ppc issue and fixed reproducibility issues but still having an issue with diffsigs. Alex did a full build and it’s looking good. is diffsig issue a requirement? RP: yes. maybe show it to me and i can take a look. perhaps a status update to the mailing list Scott: re: prserv. i was away. i was able to reproduce the hang issues that RP was seeing on the AB before i left. however, i’m seeing a new issue with debian 10 and python 3.7 we’re seeing a hang, but it’s not like any of the other hangs we’ve seen before so still investigating. is feature freeze the end of this week, or next RP: technically Monday. but this is a planned feature so there is some flexibility so we’ll see how the progress goes Scott: what’s the minimum python? RP: 3.5 or 3.6? Ross: 3.5 Scott: we could also lift the read-only feature and put that in for this release then work on the rest for the next release RP: well, we need read-only for hashequiv and prserv Scott: it’s already there for hashequiv. i don’t think it’s a huge need for this code. but i’ll keep working on it RP: we could do that as a backup plan, but i’d prefer to see it all go in for this release. i’m reluctant to do this. Scott: python 3.9 seems quite happy. the problem seems to be with the older versions. maybe there’s something we can do with the older versions to make them happy JPEW: hash equiv is a lot cleaner, it doesn’t have to do all the forking etc Scott: i thought i had it working (before i left) but i guess not. i’m seeing a strange ld.so bug (inconsistency detected by ld.so: dl-open worker assert dl_debug_initialize()->rstate == RT_CONSISTENT failed). not sure what this is, not what you’d expect out of a python program. looks like maybe loading debug symbols? when i attach gdb i don’t see any obvious problems. the coverage on the AB uses buildtools, what combos on the AB include the old python? RP: i think the really older ones all have buildtools tarball, but newer ones would run native PeterK: i think the latest python is 3.6 with the fstreams thing JPEW: i thought it was 3.6 too, i’m pretty sure i was the one who bumped it RP: i was thinking 3.6 for fstreams too when Ross said 3.5 PeterK: not that it helps you if you want 3.9 RP: but it does help somewhat Randy: (finds log) January 2021 RP: ah, the core does have the version bump, but it was not done in bitbake JPEW: i think it was something specific in oe-core that needs 3.6 and if someone is using bitbake without oe-core then they can still use 3.5 JPEW: is bitbake major version going to bump with overrides RP: it did JPEW: i meant bitbake 2.0.0 RP: not yet. i’m tempted for next LTS, but we’ll see. i’m getting tired of 1.x ;-) JPEW: let’s use dates JPEW: re spdx. if you go to poky-contrib there is a branch jpew-sbom which includes all the stuff i’ve done with spdx and sbom creation. please take a look and let me know if what we’re creating generates something that’s useful to you. if you do fossology scanning then please take a look at the output and let me know if that works for you Saul: i’m looking at it. do you have any plans about creating a single large image sbom instead of the relationship based one JPEW: originally i went down that road, it can be done if we can do it sanely. however we have to create different parts at different times in the build, so it’s just easier to have separate docs and then link them later. so we get 100’s and 100’s of docs, and then put them together in a tarball. Saul: townhall is tomorrow, looking forward to it. but i’ll look at scripts to pull it all in together into one single doc JPEW: that would actually make the documentation smaller because all the linking adds quite a bit. JPEW: also i wanted to leave open the possibility to link to spdx docs from the source code and pull all that into the big tarball. i think the lite-spdx group is trying to make things nicer (in this direction) for our (and others’) usecase, but not involved in that Saul: sometimes the external references cause issues. i threw some random ones at the validator and there were some warnings and errors. the tools are also 1.x version but they don’t properly validate the 2.x stuff. JPEW: they were validating against the online tools at one point, but i probably did something to mess it up. it’s annoying that the offline native tool is java based. it would be nice to validate as part of the build, but that’s a huge undertaking. there’s also the issue of identifying the spdx license using the ?? tool RP: who said to not use that tool? JPEW: you did RP: okay. well that’s what i’d use so go ahead JPEW: also need to verify that the license that we put in the file is a known and valid spdx license. sometimes the validator tool doesn’t accept it because of a small issue even though it is the same license RP: there’s an spdx-legal mailing list where stuff like this is being discussed. e.g. common licenses for distros. RP: glancing down your branch, i think we can start adding it JPEW: i’d like to target the next release. we could merge it now as-is, it’s functional but not 100% correct Saul: it’s pretty isolated JPEW: yes, just one class. if you don’t inherit it, it shouldn’t affect anything RP: i’m leaning towards adding it for this release as-is since it is so isolated because it is important and i’d like to see it get wider use Scott: townhall presentation meeting by Joshua tomorrow Saul: free registration, supply-chain discussions, NA timezone Scott: there are some other talks too that seem interesting (sigstore) RP: thanks to JPEW for putting in the presentation! sbom and reproducibility JPEW: sbom, reproducibility, CVE checking, buildtools, etc RP: re current patch status. lots of version changes in master-next Scott: yes myself and Jan-Simon noticed it. i’ll poke around in it Jon: on my todo list today, will review it Scott: i think the tune one might blow up AGL RP: it’s in master-next and Alex’s testing branch which i think shows green for AGL. it’s intel that blows up AlexB: yes, AGL is fine but Intel blows up. RP: AlexB make sure Anuj is aware of the meta-intel issue AlexB: sure SS: what’s it mean for the removal of the 5.4 linux-yocto recipe for dunfell? Bruce: i’ll keep sending them to you. i keep updating 4.19 and other things that still get updates. i’ll make sure to add “dunfell” in the cover letter SS: lots of hand-editing of colons and underscores RP: i suspect the conversion scripts could be reversed to change colons back to underscores RP: glibc 2.3.4 changes caused more issues than i anticipated. AB builds are green, but 2.3.4 on the host (builtdools tarball extended) or ?? cause issues. in some cases there are reproducibility issues. RP: libevent INT-AB monotonic test keeps failing off and on, but fails often enough to be annoying. will be the next one to come to grips with AlexB: yes, that one and the bitbake one RP: i’m pretending that tone doesn’t exist TrevorW: i want to convert meta-rockchip to use more of the kernel kmeta config features, what machine do you recommend i follow as a good example of doing it right? Bruce: i'll send you something TrevorW: is there any requirements or objections to adding new IMAGE_FEATUREs? i’m working on a zram IMAGE_FEATURE and would like to know if there’s any chance it would be rejected as an IMAGE_FEATURE so i could look at other approaches RP: IMAGE_FEATUREs have never been rejected that i know of TrevorW: they’re added very rarely and there aren’t many of them RP: they’re infrequent because there aren’t many. just be careful how you add the packagegroups to make sure you don’t add build dependencies. TrevorW: my feature will also need to add a kernel config. are there any examples of a feature that also pokes the kernel config? Bruce: check nfs ones Elberger: is there going to be a yocto-checklayer for dunfell? RP: i think it’s been enabled Elberger: i’m looking at the yocto console view and it’s not there, am i looking at the wrong thing RP: maybe it scrolled off the page, i’ll send you a link… https://autobuilder.yoctoproject.org/typhoon/#/builders/121/build s/208 looks like it failed in aws and meta-oe. Elberger: oh, it might have failed in aws because of a dependency on meta-oe. RP: true, yes. this isn’t an issue with meta-aws Elberger: how can maintainers do stuff on the AB RP: talk to Nico and I. probably need to wait for September TrevorG: python-cryptography test is failing because of a version mismatch, needs setuptools-rust which requires rust in oe-core Randy: look for my rust branch at poky-contrib
|
|
meta-gnome error
#yocto
yasminebenghozzi6@...
Hello, please can anyone help with this error ?
ERROR: ParseError at /home/yasmine/yocto/poky/meta-openembedded/meta-gnome/recipes-gnome/yelp/yelp_3.34.0.bb:7: Could not inherit file classes/itstool.bbclass this is the line 7: inherit gnomebase itstool autotools-brokensep gsettings gettext gtk-doc features_check mime-xdg
|
|
[meta-zephyr][PATCH] layer.conf: update machine confs with new tune locations
Naveen Saini
Added logic to make sure, it does not break with old releases.
Signed-off-by: Naveen Saini <naveen.kumar.saini@...> --- conf/layer.conf | 2 ++ conf/machine/include/tune-corei7-common.inc | 4 ++-- conf/machine/qemu-x86.conf | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/conf/layer.conf b/conf/layer.conf index 5f13c27..35f1075 100644 --- a/conf/layer.conf +++ b/conf/layer.conf @@ -16,3 +16,5 @@ LAYERVERSION_zephyr = "1" LAYERDEPENDS_zephyr = "core meta-python" LAYERSERIES_COMPAT_zephyr = "dunfell gatesgarth hardknott honister" + +X86_TUNE_DIR = "${@bb.utils.contains('LAYERSERIES_CORENAMES', 'honister', 'include/x86', 'include', d)}" diff --git a/conf/machine/include/tune-corei7-common.inc b/conf/machine/include/tune-corei7-common.inc index 509d190..b68fc05 100644 --- a/conf/machine/include/tune-corei7-common.inc +++ b/conf/machine/include/tune-corei7-common.inc @@ -1,6 +1,6 @@ DEFAULTTUNE ?= "corei7-64" -require conf/machine/include/tune-corei7.inc -require conf/machine/include/x86-base.inc +require conf/machine/${X86_TUNE_DIR}/tune-corei7.inc +require conf/machine/${X86_TUNE_DIR}/x86-base.inc # Add x86 to MACHINEOVERRIDE MACHINEOVERRIDES =. "x86:" diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf index 31ce80d..ae7716c 100644 --- a/conf/machine/qemu-x86.conf +++ b/conf/machine/qemu-x86.conf @@ -3,7 +3,7 @@ #@DESCRIPTION: Machine for Zephyr BOARD qemu_x86 require conf/machine/include/qemu.inc -require conf/machine/include/tune-i586.inc +require conf/machine/${X86_TUNE_DIR}/tune-i586.inc ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot" -- 2.17.1
|
|
[PATCH v2] bitbake/fetch2: Add a new variable 'BB_FETCH_ENV' to export Fetcher env
Mingrui Ren
From 1b0d7b4bb4a5b39f7ae0ce7d7ae5897a33637972 Mon Sep 17 00:00:00 2001
From: Mingrui Ren <jiladahe1997@...> Date: Mon, 23 Aug 2021 14:49:03 +0800 Subject: [PATCH v2] bitbake/fetch2: Add a new variable 'BB_FETCH_ENV' to export Fetcher env The environment variables used by Fetcher are hard-coded, and are obtained from HOST env instead of bitbake datastore This patch add a new variable 'BB_FETCH_ENV',and modify the default BB_ENV_EXTRAWHITE_OE for backwards compatibility, trying to fix the problems above. Signed-off-by: Mingrui Ren <jiladahe1997@...> --- changes in v2: a.changes the variable name from 'FETCH_ENV_WHITELIST' to 'BB_FETCH_ENV'. b.add 'BB_FETCH_ENV' in local.conf, rather than export it in host enviroment. c.modify existing BB_ENV_EXTRAWHITE_OE for backwards compatibility. d.Two commits recently modified this variable. The commit ID is: 348384135272ae7c62a11eeabcc43eddc957811f and 5dce2f3da20a14c0eb5229696561b0c5f6fce54c, So I adjusted the new variables in the patch. bitbake/lib/bb/fetch2/__init__.py | 34 ++++++++----------------------- bitbake/lib/bb/fetch2/wget.py | 2 +- meta-poky/conf/local.conf.sample | 12 +++++++++++ scripts/oe-buildenv-internal | 3 ++- 4 files changed, 24 insertions(+), 27 deletions(-) diff --git a/bitbake/lib/bb/fetch2/__init__.py b/bitbake/lib/bb/fetch2/__init__.py index 914fa5c024..cbbe32d1df 100644 --- a/bitbake/lib/bb/fetch2/__init__.py +++ b/bitbake/lib/bb/fetch2/__init__.py @@ -808,28 +808,13 @@ def localpath(url, d): fetcher = bb.fetch2.Fetch([url], d) return fetcher.localpath(url) -# Need to export PATH as binary could be in metadata paths -# rather than host provided -# Also include some other variables. -FETCH_EXPORT_VARS = ['HOME', 'PATH', - 'HTTP_PROXY', 'http_proxy', - 'HTTPS_PROXY', 'https_proxy', - 'FTP_PROXY', 'ftp_proxy', - 'FTPS_PROXY', 'ftps_proxy', - 'NO_PROXY', 'no_proxy', - 'ALL_PROXY', 'all_proxy', - 'GIT_PROXY_COMMAND', - 'GIT_SSH', - 'GIT_SSL_CAINFO', - 'GIT_SMART_HTTP', - 'SSH_AUTH_SOCK', 'SSH_AGENT_PID', - 'SOCKS5_USER', 'SOCKS5_PASSWD', - 'DBUS_SESSION_BUS_ADDRESS', - 'P4CONFIG', - 'SSL_CERT_FILE', - 'AWS_ACCESS_KEY_ID', - 'AWS_SECRET_ACCESS_KEY', - 'AWS_DEFAULT_REGION'] +def getfetchenv(d): + # Need to export PATH as binary could be in metadata paths + # rather than host provided + # Also include some other variables. + vars = ['HOME', 'PATH'] + vars.extend((d.getVar("BB_FETCH_ENV") or "").split()) + return vars def runfetchcmd(cmd, d, quiet=False, cleanup=None, log=None, workdir=None): """ @@ -839,7 +824,7 @@ def runfetchcmd(cmd, d, quiet=False, cleanup=None, log=None, workdir=None): Optionally remove the files/directories listed in cleanup upon failure """ - exportvars = FETCH_EXPORT_VARS + exportvars = getfetchenv(d) if not cleanup: cleanup = [] @@ -855,9 +840,8 @@ def runfetchcmd(cmd, d, quiet=False, cleanup=None, log=None, workdir=None): d.setVar("PV", "fetcheravoidrecurse") d.setVar("PR", "fetcheravoidrecurse") - origenv = d.getVar("BB_ORIGENV", False) for var in exportvars: - val = d.getVar(var) or (origenv and origenv.getVar(var)) + val = d.getVar(var) if val: cmd = 'export ' + var + '=\"%s\"; %s' % (val, cmd) diff --git a/bitbake/lib/bb/fetch2/wget.py b/bitbake/lib/bb/fetch2/wget.py index 29fcfbb3d1..0ce06ddb4f 100644 --- a/bitbake/lib/bb/fetch2/wget.py +++ b/bitbake/lib/bb/fetch2/wget.py @@ -306,7 +306,7 @@ class Wget(FetchMethod): # to scope the changes to the build_opener request, which is when the # environment lookups happen. newenv = {} - for name in bb.fetch2.FETCH_EXPORT_VARS: + for name in bb.fetch2.getfetchenv(d): value = d.getVar(name) if not value: origenv = d.getVar("BB_ORIGENV") diff --git a/meta-poky/conf/local.conf.sample b/meta-poky/conf/local.conf.sample index f1f6d690fb..4e8a6f0c77 100644 --- a/meta-poky/conf/local.conf.sample +++ b/meta-poky/conf/local.conf.sample @@ -267,6 +267,18 @@ PACKAGECONFIG:append:pn-qemu-system-native = " sdl" # #BB_SERVER_TIMEOUT = "60" +# Bitbake Fetcher Environment Variables +# +# Specific which environment variables in bitbake datastore used by fetcher when +# executing fetch task. +# NOTE: You may need to modify BB_ENV_EXTRAWHITE, in order to add environment +# variable into bitbake datastore first. +BB_FETCH_ENV ?= "HTTP_PROXY http_proxy HTTPS_PROXY https_proxy \ +FTP_PROXY ftp_proxy FTPS_PROXY ftps_proxy NO_PROXY no_proxy ALL_PROXY all_proxy \ +GIT_PROXY_COMMAND GIT_SSH GIT_SSL_CAINFO GIT_SMART_HTTP SSH_AUTH_SOCK SSH_AGENT_PID \ +SOCKS5_USER SOCKS5_PASSWD DBUS_SESSION_BUS_ADDRESS P4CONFIG SSL_CERT_FILE AWS_ACCESS_KEY_ID\ +AWS_SECRET_ACCESS_KEY AWS_DEFAULT_REGION" + # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to # track the version of this file when it was generated. This can safely be ignored if # this doesn't mean anything to you. diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index e0d920f2fc..29cb694790 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -111,7 +111,8 @@ HTTPS_PROXY https_proxy FTP_PROXY ftp_proxy FTPS_PROXY ftps_proxy ALL_PROXY \ all_proxy NO_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY \ SDKMACHINE BB_NUMBER_THREADS BB_NO_NETWORK PARALLEL_MAKE GIT_PROXY_COMMAND \ SOCKS5_PASSWD SOCKS5_USER SCREENDIR STAMPS_DIR BBPATH_EXTRA BB_SETSCENE_ENFORCE \ -BB_LOGCONFIG" +BB_LOGCONFIG HOME PATH GIT_SSH GIT_SSL_CAINFO GIT_SMART_HTTP DBUS_SESSION_BUS_ADDRESS \ +P4CONFIG SSL_CERT_FILE AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_DEFAULT_REGION" BB_ENV_EXTRAWHITE="$(echo $BB_ENV_EXTRAWHITE $BB_ENV_EXTRAWHITE_OE | tr ' ' '\n' | LC_ALL=C sort --unique | tr '\n' ' ')" -- 2.25.1
|
|
Re: [meta-mingw] [PATCH] grpc: remove nl2 requirement since it is optional
Sinan Kaya <okaya@...>
On 8/21/2021 3:27 PM, Joshua Watt wrote:
> EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON"Patch sent with subject: [meta-oe][PATCH] grpc: make SHARED library build optional I will wait until it gets merged to follow up here.
|
|
Re: Pyinstaller recipe in yocto
#yocto
Tim Orling
On Sun, Aug 22, 2021 at 10:33 AM Tim Orling via lists.yoctoproject.org <ticotimo=gmail.com@...> wrote:
If you desire the functionality of UPX, there is a recipe in meta-virtualization
|
|
Re: Pyinstaller recipe in yocto
#yocto
Tim Orling
On Sun, Aug 22, 2021 at 1:32 AM <yasminebenghozzi6@...> wrote: Good morning, The resolution of the images makes it a bit difficult to read the text, you are better off copy and pasting into the email or pastebin and sharing the link The recipe is failing during do_compile(), which is a hint that you need a -native recipe, not target recipe. DEPENDS += "python3-wheel-native" After that it will throw the 'already-stripped' QA Error: # ERROR: pyinstaller-4.5.1-r0 do_package: QA Issue: File '/usr/lib/python3.9/site-packages/PyInstaller/bootloader/Linux-64bit-intel/run' from pyinstaller was already stripped, this will prevent future debugging! [already-stripped] # ERROR: pyinstaller-4.5.1-r0 do_package: QA Issue: File '/usr/lib/python3.9/site-packages/PyInstaller/bootloader/Linux-64bit-intel/run_d' from pyinstaller was already stripped, this will prevent future debugging! [already-stripped] The fix for that is: INSANE_SKIP:${PN} += "already-stripped" But pyinstaller is a complicated program and has many more dependencies for run time (RDEPENDS). One way to help figure those out is to use 'devtool add' to create the original recipe. $ devtool add python3-pyinstaller https://files.pythonhosted.org/packages/a9/d9/9fdfb0ac2354d059e466d562689dbe53a23c4062019da2057f0eaed635e0/pyinstaller-4.5.1.tar.gz (we use Debian naming, so prefix the pypi name with python3-, the URL is from pypi 'Download FIles' ) In this case it resulted in a recipe with a parsing error, but normally this doesn't happen. Devtool detected a lot of dependencies, including two recipes that are not in YP/OE yet. I have created a WIP branch you can try to use moving forward, but you'll have to do the rest of the work yourself or with the help of the community.
|
|
remove meta-python2 from yocto
#yocto
yasminebenghozzi6@...
Hello,
I recently cloned into meta-python2 and I think it made an issue, so I want to remove it now, any help please?
|
|
Pyinstaller recipe in yocto
#yocto
yasminebenghozzi6@...
Good morning,
So please I need help, I 've been building the pyinstaller recipe but I got errors which I couldn't explain , because I have the recipe python3-wheel which got built perfectly. Can anyone help please?
|
|
Re: [meta-security][PATCH 1/2] image-with-hardened-binaries: add class
Hi,
On 21/08/2021 18:35, Armin Kuster wrote: Regarding the selftest, is there test for failure?If you run checksec manually against some binary e.g. ls.coreutils it outputs something like this: https://pastebin.com/JkeN1h3k Not sure what this should output. -armin
|
|
Re: [meta-security][PATCH 1/2] image-with-hardened-binaries: add class
Hello Max,
See feedback below On 8/13/21 6:18 AM, Maximilian Blenk wrote: Add class to analyze binaries with checksec.py. checksec.py is a toolI used these against current master and found some duplicate recipes in either Core or meta-python so I removed these. python3-asttokens_2.0.5.bb python3-colorama_%.bbappend python3-docopt_0.6.2.bb python3-setuptools-scm_6.0.1.bb python3-toml_%.bbappend see: https://gitlab.com/akuster/meta-security/-/commit/1332825d23eb8ff08e124422b3f25a030c032c0b I needed to covert to the new overrides scheme before I could build. see: https://gitlab.com/akuster/meta-security/-/commit/847bd7551acd3a9ca539b9beccd83a149bdd417d feel free to reuse those changes. Regarding the selftest, is there test for failure? I ran this against core-image-minimal and nothing was printed out. Does that mean its fine? You may want to remove the ".py" from python3-checksec.py-native_0.6.1.bb, its not needed. -armin
|
|
Re: [meta-mingw] [PATCH] grpc: remove nl2 requirement since it is optional
Joshua Watt
On Sat, Aug 21, 2021, 6:26 AM Richard Purdie <richard.purdie@...> wrote: On Fri, 2021-08-20 at 20:46 +0000, Sinan Kaya wrote: Yes, that's a good idea. Sinan, please make that change in meta-oe, then change this patch to remove it from PACKAGECONFIG
|
|
Re: [meta-mingw] [PATCH] grpc: remove nl2 requirement since it is optional
Richard Purdie
On Fri, 2021-08-20 at 20:46 +0000, Sinan Kaya wrote:
Signed-off-by: Sinan Kaya <okaya@...>Should we be making that a PACKAGECONFIG which mingw32 could change? Cheers, Richard
|
|
[meta-mingw] [PATCH] grpc: remove nl2 requirement since it is optional
Sinan Kaya <okaya@...>
Signed-off-by: Sinan Kaya <okaya@...>
--- .../openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend index a72496d..dc0ea42 100644 --- a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend +++ b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend @@ -1,2 +1,5 @@ +# doesn't build and not required +DEPENDS:remove:mingw32 = "libnsl2" + EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON" EXTRA_OECMAKE:append:mingw32 = " -DBUILD_SHARED_LIBS=OFF" -- 2.17.1
|
|
[meta-mingw] [PATCH 2/2] c-ares: disable shared build as it is broken
Sinan Kaya <okaya@...>
Signed-off-by: Sinan Kaya <okaya@...>
--- .../recipes-support/c-ares/c-ares_%.bbappend | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 dynamic-layers/openembedded-layers/recipes-support/c-ares/c-ares_%.bbappend diff --git a/dynamic-layers/openembedded-layers/recipes-support/c-ares/c-ares_%.bbappend b/dynamic-layers/openembedded-layers/recipes-support/c-ares/c-ares_%.bbappend new file mode 100644 index 0000000..8ef58f9 --- /dev/null +++ b/dynamic-layers/openembedded-layers/recipes-support/c-ares/c-ares_%.bbappend @@ -0,0 +1,2 @@ +EXTRA_OECMAKE:append:mingw32 = "-DCARES_SHARED=OFF" +EXTRA_OECMAKE:append:mingw32 = "-DCARES_STATIC=ON" -- 2.17.1
|
|
[meta-mingw] [PATCH 1/2] re2: disable shared build as it is broken
Sinan Kaya <okaya@...>
Signed-off-by: Sinan Kaya <okaya@...>
--- .../openembedded-layers/recipes-support/re2/re2_%.bbappend | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 dynamic-layers/openembedded-layers/recipes-support/re2/re2_%.bbappend diff --git a/dynamic-layers/openembedded-layers/recipes-support/re2/re2_%.bbappend b/dynamic-layers/openembedded-layers/recipes-support/re2/re2_%.bbappend new file mode 100644 index 0000000..16bb5a0 --- /dev/null +++ b/dynamic-layers/openembedded-layers/recipes-support/re2/re2_%.bbappend @@ -0,0 +1,2 @@ +EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON" +EXTRA_OECMAKE:append:mingw32 = "-DBUILD_SHARED_LIBS=OFF" -- 2.17.1
|
|