|
Re: Updating Yocto
Mikko Rapeli
Hi,
On Mon, Feb 22, 2021 at 12:12:21PM -0500, Claude Bing wrote: Hello all. My organization has been working with Yocto recently, and weWhen both yocto update and your own changes are modifying the same recipes, then conflicts can occur. Most of the time, these recipes have not been extended in our project,If builds are failing, then your environment is breaking something. It might even be the BSP layers that you use. Are we doing something wrong, or is there a more acceptable way toI update all open source meta layers for every run of the update and also resolve any issues by digging into details why the failure happened. I've done dunfell updates with several BSP layers for multiple arm64 SoC's and have not seen major issues. What is useful and one of the best practices, is to clear the bitbake tmp directory in between builds. Depending on details, there can be some cruft there which fails when rebuilding. Cheers, -Mikko
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [error-report-web][PATCH] report-error.bbclass: Add layer and bitbake version info to error report
Milan Shah
Hi All, This has not been reviewed yet and it is given since January 6th. Please review it and provide review comments if any as soon as possible to resolve this issue. Thanks & Regards, Milan Shah
On Mon, Feb 1, 2021 at 10:06 AM Milan Shah <mshah@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Trouble booting basic x86 image
Paul D. DeRocco
Yocto Gatesgarth, using meta-intel to build core-image-minimal
Intel D2700MUD mini-ITX mobo with D2700 Atom Ordinary USB 2.0 flash drive I followed the instructions in the meta-intel README, and had no problems building the intel-core2-32 and intel-corei7-64 machines, as well as the latter with an x32 tune. But whenever I try to boot any of them, I get the following stuff from the kernel: usb 1-6: new high-speed USB device number 4 using ehci-pci usb-storage 1-6:1.0: USB Mass Storage device detected usb-storage 1-6:1.0: Quirks match for vid 090c pid 1000: 400 scsi host4: usb-storage 1-6:1.0 scsi 4:0:0:0: Direct-Access FLASH Drive SM_USB20 1100 PQ: 0 ANSI: 4 sd 4:0:0:0: Attached scsi generic sg0 type 0 sd 4:0:0:0: [sda] 3932160 512-byte logical blocks: (2.01 GB/1.88 GiB) sd 4:0:0:0: [sda] Write Protect is off sd 4:0:0:0: [sda] No Caching mode page found sd 4:0:0:0: [sda] Assume drive cache: write through sda: sd 4:0:0:0: [sda] Attached SCSI removable disk (countdown from 27 to 0) Mounted filesystems Available block devices major minor #blocks name 1 0 4096 ram0 ... (others edited out) 1 15 4096 ram15 8 0 1966080 sda Cannot find rootfs.img file in /run/media/* , dropping to a shell At this point, it doesn't drop to a shell, but just sits there, responding to keys by echoing them, so I have no way of investigating. Ctrl-Alt-Del reboots. Since there is no kernel serial output on this board, even though the kernel command requests it, I videoed the startup, but didn't anything that looked suspicious. I didn't see any message, though, about mounting anything in /run/media. As I've said, I've tried three different builds, totally generic except for using the Intel BSP layer. I've tried two different USB drives. I've tried it with EFI enabled and disabled in the BIOS. I've looked at the drive on the PC, and the contents look normal. So why can't it find the rootfs.img file, which is right there on sda, large as life? Anyone have any ideas what I could be doing wrong? -- Ciao, Paul D. DeRocco Paul mailto:pderocco@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
#toolchain #sdk #qt5 - compiler missing from from do_populate_sdk
#toolchain
#sdk
#qt5
vitalEol
Hi,
We have a functioning image built for our device/platform based on Ti Processor SDK 04.03.00.05; at this point I'm trying to build an SDK for the image that I can distribute to other members of our development team to develop Qt5-based application for our platform. I want to build an SDK installer that includes additional Qt5 components which aren't included in the default Ti SDK like QtConnectivity and QtVirtualKeyboard. I've tried several methods to build the SDK including:
None of the resulting SDK installers appear to include the compiler, after sourcing the environment script I get the following: micheal:buildData$ source /buildData/customToolchain/environment-setup-armv7ahf-neon-linux-gnueabi
micheal:buildData$ $CC
bash: arm-linux-gnueabihf-gcc: command not found
micheal:buildData$
I know that in the past I did manage to get a working SDK/Toolchain using one of the methods above though at the moment none seem to work for me. Regards, Evan
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [error-report-web][PATCH] parser: make contains_tag ignore non-str fields
Yi Fan Yu
RP,
if you want to get this merged too that would be great. yifan
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[error-report-web][PATCH] Update to be compatible with python3.5
Yi Fan Yu
mostly changed the way to access request.GET
also tested on python2.7 to be backward compatible Signed-off-by: Yi Fan Yu <yifan.yu@...> --- Post/parser.py | 2 +- Post/views.py | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/Post/parser.py b/Post/parser.py index f54482a..f411e02 100644 --- a/Post/parser.py +++ b/Post/parser.py @@ -17,7 +17,7 @@ from django.core.urlresolvers import reverse class Parser: def __init__(self, data): - self.data = data + self.data = data.decode('utf-8') # returns true if the values contain '<' char # Ignore the failures field (which is an array anyway) diff --git a/Post/views.py b/Post/views.py index cc6aed9..fe7100e 100644 --- a/Post/views.py +++ b/Post/views.py @@ -15,9 +15,9 @@ from django.shortcuts import HttpResponse, render from django.views.decorators.csrf import csrf_exempt from django.shortcuts import redirect from Post.models import BuildFailure, Build, ErrorType -from parser import Parser +from Post.parser import Parser from django.conf import settings -from createStatistics import Statistics +from Post.createStatistics import Statistics from django.core.paginator import Paginator, EmptyPage from django.core.exceptions import FieldError, ObjectDoesNotExist from django.http import JsonResponse @@ -65,12 +65,12 @@ def addData(request, return_json=False): if return_json: response = JsonResponse(result) else: - if not result.has_key('error'): + if not 'error' in result: response = HttpResponse("Your entry can be found here: "+result['build_url']) else: response = HttpResponse(result['error']) - if result.has_key('error'): + if 'error' in result: response.status_code=500 else: if return_json: @@ -125,7 +125,7 @@ def search(request, mode=results_mode.LATEST, **kwargs): items = BuildFailure.objects.all() - if request.GET.has_key("limit"): + if "limit" in request.GET: try: n_limit = int(request.GET['limit']) if n_limit > 0: @@ -202,14 +202,14 @@ def search(request, mode=results_mode.LATEST, **kwargs): ], } - if request.GET.has_key("filter") and request.GET.has_key("type"): + if "filter" in request.GET and "type" in request.GET: items = apply_filter(context, items, request.GET['type'], request.GET['filter']) if mode == results_mode.SPECIAL_SUBMITTER and hasattr(settings,"SPECIAL_SUBMITTER"): #Special submitter mode see settings.py to enable name = settings.SPECIAL_SUBMITTER['name'] items = items.filter(BUILD__NAME__istartswith=name) - elif mode == results_mode.SEARCH and request.GET.has_key("query"): + elif mode == results_mode.SEARCH and "query" in request.GET: query = request.GET["query"] items = items.filter( -- 2.25.1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.6.rc1)
Sangeeta Jain
Hi all,
toggle quoted messageShow quoted text
Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.6.rc1 We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowTurbot 32-bit 2. Coffee Lake 3. NUC 7 4. NUC 6 5. Edgerouter 6. Beaglebone ETA for completion is next Thursday, February 25. Thanks, Sangeeta
-----Original Message-----
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Kernel Header UAPI Issue
Karthik Poduval
Hi Khem and Bruce, I got the patch from raspberry pi github and it looked like it put the header into include/uapi/linux/dma-heap.h, for kernel 5.4 it doesn't look like there is a need for a Kbuild file. Are any special steps needed for exporting the header (I thought kernel 5.4 exports everything from include/uapi directory) ? The linux-libc-headers sound like the issue. Thanks for the pointers, I will dig up further based on the suggestions and revert.
On Mon, Feb 22, 2021 at 5:14 PM Bruce Ashfield <bruce.ashfield@...> wrote: On Mon, Feb 22, 2021 at 7:52 PM Karthik Poduval --
Regards, Karthik Poduval
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Kernel Header UAPI Issue
Bruce Ashfield
On Mon, Feb 22, 2021 at 7:52 PM Karthik Poduval
<karthik.poduval@...> wrote:
That's coming from the linux-libc-headers, your new upi header is not part of the libc-headers package, so it won't show up there. And no, it shouldn't be part of that recipe and the libc-headers should not be generated from the current state of whatever kernel is being built. You need to arrange for it to be exported and staged separately (look for examples of 'sysroot_stage' variants in the meta-data, you can bbappend the behaviour to your kernel recipe), or your code can look for the header in the kernel shared workdir (STAGING_KERNEL_BUILDDIR) by adding that to your include paths in the recipe. As khem also mentioned, you'll need to make sure that the uapi header is not just patched in, but properly exported. Bruce
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Kernel Header UAPI Issue
On Mon, Feb 22, 2021 at 4:52 PM Karthik Poduval
<karthik.poduval@...> wrote: What does patch look like? just adding the file is not enough, it should be added to makefiles to be exported as UAPI header --
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Kernel Header UAPI Issue
Karthik Poduval
I have a 5.4 kernel where I applied a patch (using a .scc file) from
kernel 5.6 which brings in dmabuf heaps. The patch exports a uapi header include/uapi/linux/dma-heap.h. I am trying to write an application that uses dmabuf with a recipe (no special DEPENDS). It is able to find #include<linux/dma-buf.h> but not #include<linux/dma-heap.h> (this file is introduced in the patch) I looked at the recipe's sysroot recipe-sysroot/usr/linux/include and dma-buf.h is there but not dma-heap.h Why is the header not being imported ? -- Regards, Karthik Poduval
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[PATCH yocto-autobuilder-helper] send-qa-email: Save the QA email in case it doesn't reach the mailing lists.
Michael Halstead
Signed-off-by: Michael Halstead <mhalstead@...>
--- scripts/send-qa-email | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/scripts/send-qa-email b/scripts/send-qa-email index 6785df3..1b69307 100755 --- a/scripts/send-qa-email +++ b/scripts/send-qa-email @@ -145,6 +145,10 @@ Build hash information: \n ''' % (args.release, args.publish_dir.replace(web_root, web_url), buildhashes) +# Store a copy of the email in case it doesn't reach the lists +with open(os.path.join(args.publish_dir, "qa-email"), "wb") as qa_email: + qa_email.write(email.encode('utf-8')) + utils.printheader("Sending QA email") env = os.environ.copy() # Many distros have sendmail in */sbin -- 2.29.2
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
QA notification for completed autobuilder build (yocto-3.1.6.rc1)
Pokybuild User <pokybuild@...>
A build flagged for QA (yocto-3.1.6.rc1) was completed on the autobuilder and is available at:
https://autobuilder.yocto.io/pub/releases/yocto-3.1.6.rc1 Build hash information: bitbake: fa94374baea75a94e3a488126ca7d8e241a77acd meta-arm: 02c660521619ddb7a9495d65403aaa2636747ce8 meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac meta-intel: 4bd62a7e154b8c9e8a114f452d3b062d8d058118 meta-kernel: f793168bd19af3d8c5a260dd35f387ed9a31794b meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 oecore: a8debddd6cbdd70db74e096d72f97fbee008ee63 poky: a13bda44fcda4e79e9aed39ca1495eabecb6a7b7 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.purdie@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enhancements/Bugs closed WW08!
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Current high bug count owners for Yocto Project 3.3
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Newcomer & Unassigned Bugs - Help Needed
Stephen Jolley
All,
The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.
Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 354 unassigned or newcomer bugs.
We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.
Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [opkg-devel] [opkg-utils PATCH v2] Makefile: separate manpages and utils install
Alex Stewart
Hey Ryan,
This looks good to me. I'll merge this patch tomorrow, if there are no objections. Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stewart@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Updating Yocto
Claude Bing
Hello all. My organization has been working with Yocto recently, and we
have noticed that there are often weird errors encountered after updating revisions within a release branch (e.g., 3.1.3 -> 3.1.5). Is there an accepted process to merging in upstream changes? Here is a distillation of our workflow: * Yocto releases 3.1.0 / dunfell * Create a local tracking branch for the Yocto release "sample-yocto-dunfell" based on upstream 3.1.0 tag / dunfell branch. This is necessary because some of our local tooling is located in the top level directory and it is a pain to copy the files each time. * Create firmware with Yocto * Yocto releases 3.1.x * Merge upstream yocto-3.1.x tag into local tracking branch * Create firmware with Yocto Sometimes, after this last step, we encounter problems where patches cannot be applied, or files cannot be found when bitbake tries to build the recipes. We have tried deleting build/{tmp,sstate-cache} whenever we merge upstream changes, but random errors still persist. For each of these packages, if we run "bitbake -c cleanall", the error goes away. Most of the time, these recipes have not been extended in our project, so they are purely meta-oe / meta packages. Are we doing something wrong, or is there a more acceptable way to handle updates? How tightly should meta-openembedded be tied to the core Yocto release? -- Regards, Claude Bing
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH 5/5] nikito: Update common-licenses references to match new names
Signed-off-by: Armin Kuster <akuster808@...>
--- recipes-scanners/buck-security/buck-security_0.7.bb | 2 +- recipes-scanners/checksecurity/checksecurity_2.0.15.bb | 2 +- recipes-security/nikto/nikto_2.1.6.bb | 2 +- recipes-security/redhat-security/redhat-security_1.0.bb | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/recipes-scanners/buck-security/buck-security_0.7.bb b/recipes-scanners/buck-security/buck-security_0.7.bb index 179eeda..20a1fb0 100644 --- a/recipes-scanners/buck-security/buck-security_0.7.bb +++ b/recipes-scanners/buck-security/buck-security_0.7.bb @@ -3,7 +3,7 @@ DESCRIPTION = "Buck-Security is a security scanner for Debian and Ubuntu Linux. system. This enables you to quickly overview the security status of your Linux system." SECTION = "security" LICENSE = "GPL-2.0" -LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6" +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6" SRC_URI = "http://sourceforge.net/projects/buck-security/files/buck-security/buck-security_${PV}/${BPN}_${PV}.tar.gz" diff --git a/recipes-scanners/checksecurity/checksecurity_2.0.15.bb b/recipes-scanners/checksecurity/checksecurity_2.0.15.bb index 204123d..0161b4c 100644 --- a/recipes-scanners/checksecurity/checksecurity_2.0.15.bb +++ b/recipes-scanners/checksecurity/checksecurity_2.0.15.bb @@ -2,7 +2,7 @@ SUMMARY = "basic system security checks" DESCRIPTION = "checksecurity is a simple package which will scan your system for several simple security holes." SECTION = "security" LICENSE = "GPL-2.0" -LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6" +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6" SRC_URI = "http://ftp.de.debian.org/debian/pool/main/c/checksecurity/checksecurity_${PV}.tar.gz \ file://setuid-log-folder.patch \ diff --git a/recipes-security/nikto/nikto_2.1.6.bb b/recipes-security/nikto/nikto_2.1.6.bb index 2d2c46c..615cc30 100644 --- a/recipes-security/nikto/nikto_2.1.6.bb +++ b/recipes-security/nikto/nikto_2.1.6.bb @@ -4,7 +4,7 @@ SECTION = "security" HOMEPAGE = "https://cirt.net/Nikto2" LICENSE = "GPLv2" -LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6" +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6" SRCREV = "f1bbd1a8756c076c8fd4f4dd0bc34a8ef215ae79" SRC_URI = "git://github.com/sullo/nikto.git \ diff --git a/recipes-security/redhat-security/redhat-security_1.0.bb b/recipes-security/redhat-security/redhat-security_1.0.bb index 56f734c..0d70dc6 100644 --- a/recipes-security/redhat-security/redhat-security_1.0.bb +++ b/recipes-security/redhat-security/redhat-security_1.0.bb @@ -2,7 +2,7 @@ SUMMARY = "redhat security tools" DESCRIPTION = "Tools used by redhat linux distribution for security checks" SECTION = "security" LICENSE = "GPLv2" -LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6" +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6" SRC_URI = "file://find-chroot-py.sh \ file://find-chroot.sh \ -- 2.17.1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH 4/5] scap-security-guide: Inherit python3targetconfig
Signed-off-by: Armin Kuster <akuster808@...>
--- .../scap-security-guide/scap-security-guide.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc index 32fce0f..d1a9511 100644 --- a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc +++ b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc @@ -10,7 +10,7 @@ DEPENDS = "openscap-native python3 python3-pyyaml-native python3-jinja2-native l S = "${WORKDIR}/git" -inherit cmake pkgconfig python3native +inherit cmake pkgconfig python3native python3targetconfig STAGING_OSCAP_BUILDDIR = "${TMPDIR}/work-shared/openscap/oscap-build-artifacts" export OSCAP_CPE_PATH="${STAGING_OSCAP_BUILDDIR}${datadir_native}/openscap/cpe" -- 2.17.1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|