|
Re: Installing gfortran into native sysroot for libgfortran
On Wed, Jul 6, 2022 at 5:51 PM Gregory Anders <greg@...> wrote:
in your fortran app recipe you have to add DEPENDS = "libgfortran"
|
|
|
|
Installing gfortran into native sysroot for libgfortran
Gregory Anders <greg@...>
Hello,
I'm trying to compile libgfortran for a Xilinx Zynq SoC, which uses the arm-xilinx-linux-gnueabi toolchain. I have added FORTRAN:forcevariable = ",fortran" to my local.conf, which causes libgfortran to be built, but it fails in the configure stage with an error that it cannot find arm-xilinx-linux-gnueabi-gfortran. When I check the recipe-sysroot-native directory of libgfortran I indeed see that gfortran is not there (but -gcc, -g++, etc. are). Now I've been poking around the gcc recipe files trying to figure out why gfortran is not being installed, but I am coming up empty. I'm hoping someone on list know how to do this. How can I have gfortran installed into the native sysroot for libgfortran? Thanks, Greg
|
|
|
|
Re: Minutes: Yocto Project Weekly Triage Meeting 6/30/2022
On 2022-06-30 11:21, Sakib Sajal wrote:
This issue is understood, documented and resolved so ../Randy
-- # Randy MacLeod # Wind River Linux
|
|
|
|
Re: [PATCH yocto-autobuilder-helper 2/2] config.json: remove non-gpl3 job
On 6 Jul 2022, at 15:13, Alexander Kanavin <alex.kanavin@...> wrote:
Where and how the decision was made?Maybe ‘deprecated’ isn’t quite the right word to use here. However, meta-gpl2 is unmaintained. It has no active maintainers, and is worked on only when absolutely needed: in the last year there’s been one actual bug fix, the rest of the commits were related to metadata changes to core (license, override syntax, etc). By definition all of the software in meta-gplv2 is obsolete and almost certainly has security issues, but nobody is maintaining it. This has been bought up both here repeatedly, and in the Members calls. Nobody has shown willing to adopt the layer, fix any outstanding security issues, and maintain it. We likely need to discuss this again before formally deprecating it, but this shouldn’t be a surprise to anyone. Is there anyone who actually cares enough about meta-gplv2 to maintain it? This should be taken to oe-arch. Ross
|
|
|
|
Re: [PATCH yocto-autobuilder-helper 2/2] config.json: remove non-gpl3 job
Alexander Kanavin
Where and how the decision was made?
toggle quoted messageShow quoted text
Alex
On Wed, 6 Jul 2022 at 16:04, Ross Burton <ross.burton@...> wrote:
|
|
|
|
[PATCH yocto-autobuilder-helper 2/2] config.json: remove non-gpl3 job
meta-gplv2 is deprecated, so remove it from the autobuilder in master.
Signed-off-by: Ross Burton <ross.burton@...> --- config.json | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/config.json b/config.json index 7f7c2ad..c16812b 100644 --- a/config.json +++ b/config.json @@ -753,17 +753,6 @@ "BBTARGETS" : "build-appliance-image" } }, - "non-gpl3" : { - "NEEDREPOS" : ["poky", "meta-gplv2"], - "MACHINE" : "qemux86", - "BBTARGETS" : "core-image-minimal core-image-full-cmdline", - "extravars" : [ - "require conf/distro/include/disable-gplv3.inc" - ], - "EXTRACMDS" : [ - "../../yocto-autobuilder-helper/scripts/check-gplv3" - ] - }, "no-x11" : { "MACHINE" : "qemux86-64", "BBTARGETS" : "core-image-full-cmdline core-image-weston wor= ld", --=20 2.25.1
|
|
|
|
[PATCH yocto-autobuilder-helper 1/2] config.json: remove meta-gplv2 from the check-layer job
The meta-gplv2 layer is deprecated in master, so remove it from the
check-layer job. Signed-off-by: Ross Burton <ross.burton@...> --- config.json | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/config.json b/config.json index afae5e9..7f7c2ad 100644 --- a/config.json +++ b/config.json @@ -857,7 +857,7 @@ "TEMPLATE" : "reproducible" }, "check-layer" : { - "NEEDREPOS" : ["poky", "meta-gplv2", "meta-mingw"], + "NEEDREPOS" : ["poky", "meta-mingw"], "step1" : { "EXTRACMDS" : ["yocto-check-layer-wrapper ../meta-poky"] }, @@ -866,9 +866,6 @@ }, "step3" : { "EXTRACMDS" : ["yocto-check-layer-wrapper ../meta-mingw"= ] - }, - "step4" : { - "EXTRACMDS" : ["yocto-check-layer-wrapper ../meta-gplv2"= ] } }, "check-layer-nightly" : { --=20 2.25.1
|
|
|
|
Re: cve check report package version mismatch
#yocto
Re-adding yocto@.
This brings me to the handling of the "Unpatched" CVEs in the project. I can get some idea for which version of the package may have the mitigation for the CVE but there is no "mitigated_version" variable which helps me figure out the updated path in an automated way. I'm guessing that such a variable must be present internally in the cve_check class for it to detemine if the existing package version is lower than the mitigated version. Can I change the configuration for this information to also be printed in the cve log? This can probably also be added to the documentation (I don't mind volunteering for that)It’s not always a trivial “this version”, there’s a fairly complex expression in the CVE (see the CPE entry) which needs to be evaluated. Or there may not be a fixed release, or the CVE needs configuration changes. Basically, I don’t think it’s feasible to put a “fixed version” entry in the report that isn’t misleading. Whoever is reviewing the CVEs should actually read the CVE details and make a judgement on what to do. Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|
|
|
|
Re: cve check report package version mismatch
#yocto
Marta Rybczynska
On Tue, Jul 5, 2022 at 2:31 PM <gauravsuman007@...> wrote:
Hello Gaurav, The CVE STATUS "Patched" means that there was an issue in the past, but it is either fixed or otherwise mitigated. Open issues are marked as "Unpatched". If you'd like to see only Unpatched issues in the report, please use CVE_CHECK_REPORT_PATCHED = "0" in your local.conf or other place you have your OE configuration from. Kind regards, Marta
|
|
|
|
ksmanjunath681@...
is there anything i am missing here .
|
|
|
|
Recommended boot method for system using rauc, intel and efi.
Anders Gnistrup
Hi all
I am building a yocto BSP for an Intel system. The system is using rauc for updating and contains three sections, rescue, A and B, where A/B is the actual SW running. Since the system is Intel based a decision how to organise the partitions layout is needed.
Currently I am making a skeleton for the BSP.
This is the current layout
In arm systems boot selection is handling via scripting/rauc/uboot in boot section. But in intel there are at least three options.
1) Legacy boot
This will create the layout above, but it will depend on legacy bios boot. This will require writing the MBR and pointing to the boot where grub scripting handles the rauc stuff. It seems like a bad solution to add MBR is the loop.
2) EFI entry always points to boot partition.
grub + scripting in the boot partition will do a similar operation like in the arm system. This solution gives quite a lot of flexibility, but will depend on SW.
3) pure EFI+efibootmgr. This will eliminate the boot partition and grub scripting but since EFI file format must be VFAT (EFI standard) the rescue, A and B partition needs a split. That is:
The grub scripting is replaced by efibootmgr and EFI entries in NVRAM.
And now my questions
Q1
My yocto builder is using the wks plugin to define the partition layout,
https://docs.yoctoproject.org/singleindex.html#command-bootloader.
When setting the bootloader command it seems that the --configfile argument shall be used since there is no info in the EFI-nvram. WKS seems to work OK without the
--configfile argument when building an installer image. Building a fixed disk containing an installer rescue image seems to be a bit too much for the logic.
Q2
I can't decide between 2 or 3 and I need some guidelines/idea.
2 is SW based while 3 is using the EFI system. Basically, the grub scripting is partly replacing the EFI system but will introduce a more complex partitions layout, a more complex rauc bundle and a more complex installation/rescue. The rescue
partition shall be able to reset the system to factory default i.e. either reset entries in EFI-nvram or reset grub environment. Currently I am most up for grub scripting, solution 2, since all info is on the sata disk and not a combination of EFI-nvram
and sata disk. Further it seems that the yocto support for efibootmgr, EFI-nvram and rauc is a bit bleeding edge.
Regards Anders Gnistrup
|
|
|
|
Re: Unable to fetch repository from GitLab. Checksum mismatch
Quentin Schulz
Hi Rashmi,
toggle quoted messageShow quoted text
You only need to add ;protocol=https to your SRC_URI which starts with git://. git:// in SRC_URI is NOT the protocol used to download the sources, it is the way Bitbake knows which fetcher to use (in that case, the git fetcher). If you replace it with http, it's going to be the HTTP fetcher, which uses curl. It is not what you want to use for git repos. c.f. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#git-fetcher-git Hope this helps, Cheers, Quentin
On 7/5/22 17:51, rashmi pisal via lists.yoctoproject.org wrote:
Hello,
|
|
|
|
Unable to fetch repository from GitLab. Checksum mismatch
Hello,
I am building a software image and it fails when fetching a repository form GitLab. https://github.com/ajstarks/openvg Initially I was using git:// protocol to fetch the files but due to the GItLab ended support of git:// I am using https:// protocol. I am getting following error. Any help is appreciated. Thank you. ================================================================== NOTE: Running task 2097 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-openembedded/meta-oe/recipes-graphics/gphoto2/libgphoto2_2.5.8.bb:do_patch) NOTE: recipe libgphoto2-2.5.8-r0: task do_patch: Started NOTE: recipe libgphoto2-2.5.8-r0: task do_patch: Succeeded NOTE: Running task 2098 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-openembedded/meta-oe/recipes-support/glog/glog_0.3.4.bb:do_patch) NOTE: recipe glog-0.3.4-r0: task do_patch: Started NOTE: recipe glog-0.3.4-r0: task do_patch: Succeeded NOTE: Running task 2099 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta/recipes-devtools/perl/perl_5.24.1.bb:do_packagedata) NOTE: recipe perl-5.24.1-r0: task do_packagedata: Started NOTE: recipe perl-5.24.1-r0: task do_packagedata: Succeeded NOTE: Running task 2100 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-rebound/recipes-bsp/openvg/openvg.bb:do_fetch) NOTE: recipe openvg-1.0-r0: task do_fetch: Started WARNING: openvg-1.0-r0 do_fetch: Checksum mismatch for local file /var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg Cleaning and trying again. WARNING: openvg-1.0-r0 do_fetch: Renaming /var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg to /var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg_bad-checksum_ddfeecef70433040e18ee9e68481e7f3 WARNING: openvg-1.0-r0 do_fetch: Checksum failure encountered with download of https://github.com/ajstarks/openvg - will attempt other sources if available ERROR: openvg-1.0-r0 do_fetch: Fetcher failure for URL: 'https://github.com/ajstarks/openvg'. Checksum mismatch! File: '/var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg' has md5 checksum ddfeecef70433040e18ee9e68481e7f3 when a8b34f242afbf3cac74fc7d34a496b24 was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[md5sum] = "ddfeecef70433040e18ee9e68481e7f3" SRC_URI[sha256sum] = "7c67772c69b23d5b4cd298c7ddbf02938c3d11de04747c3243435e1463169669" Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified. ERROR: openvg-1.0-r0 do_fetch: Fetcher failure for URL: 'https://github.com/ajstarks/openvg'. Unable to fetch URL from any source. ERROR: openvg-1.0-r0 do_fetch: Function failed: base_do_fetch ERROR: Logfile of failure stored in: /var/lib/jenkins/workspace/yocto-rebound/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/openvg/1.0-r0/temp/log.do_fetch.30930 NOTE: recipe openvg-1.0-r0: task do_fetch: Failed ERROR: Task (/var/lib/jenkins/workspace/yocto-rebound/meta-rebound/recipes-bsp/openvg/openvg.bb:do_fetch) failed with exit code '1' NOTE: Running task 2101 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-gplv2/recipes-extended/gawk/gawk_3.1.5.bb:do_prepare_recipe_sysroot) NOTE: recipe gawk-3.1.5-r2: task do_prepare_recipe_sysroot: Started NOTE: recipe gawk-3.1.5-r2: task do_prepare_recipe_sysroot: Succeeded NOTE: recipe opencv-3.3+gitAUTOINC+87c27a074d_2a9d1b22ed_a62e20676a_34e4206aef_fccf7cd6a4-r0: task do_fetch: Succeeded NOTE: Tasks Summary: Attempted 2101 tasks of which 0 didn't need to be rerun and 1 failed. ====================================================================================
|
|
|
|
Yocto Project Status 05 July 2022 (WW27)
Current Dev Position: YP 4.1 M2 Next Deadline: 11th July 2022 YP 4.1 M2 Build Next Team Meetings:
Key Status/Updates:
Ways to contribute:
YP 4.1 Milestone Dates:
Upcoming dot releases:
Tracking Metrics:
The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Neal Caidin Program Manager, Program Management & Operations The Linux Foundation +1 (919) 238-9104 (w/h) +1 (919) 949-1861 (m)
|
|
|
|
Re: cve check report package version mismatch
#yocto
On 5 Jul 2022, at 13:31, gauravsuman007 via lists.yoctoproject.org <gauravsuman007=gmail.com@...> wrote:I’m not sure I understand what your concern is. We have version 1.6.0, the CVE was fixed in 1.3.3, so the security issue has been patched. The status is “patched” even if there’s not a literal patch in the recipe, it should be “mitigated” but we’d need to move to a new format to change the values. Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|
|
|
|
cve check report package version mismatch
#yocto
gauravsuman007@...
I used the cve check class by including it in the local.conf and then ran the bitbake build process for my image. I got a log of all the detected CVEs in the packages used in the build. However, on closer inspection, I noticed that the packages used in the build are already higher version than when the CVE was patched. Here is an example:
Is there something wrong with what the cve-check is reporting or is it not bothering to match the version numbers before reporting a CVE? Or maybe my understanding of the report is incorrect? Would really appreciate a feedback on this, seeing as how the documentation on the cve checker is sparse. Thanks, Gaurav
|
|
|
|
Re: [PATCH yocto-autobuilder-helper] run-docs-build: allow build warnings again
Richard Purdie
On Tue, 2022-07-05 at 13:21 +0200, Quentin Schulz wrote:
Hi Richard, Michael,Perhaps it is time we split the master build from the stable releases and used different buildtools tarballs for them? That has it's own set of challenges of course too. Cheers, Richard
|
|
|
|
[meta-mingw] [PATCH] wayland: explicitly disable tests
Alexander Kanavin
This addresses the failure with wayland 1.21:
| ../wayland-1.21.0/tests/meson.build:2:1: ERROR: Problem encountered: -Dtests=true requires -Dlibraries=true Signed-off-by: Alexander Kanavin <alex@...> --- recipes-graphics/wayland/wayland_%.bbappend | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/recipes-graphics/wayland/wayland_%.bbappend b/recipes-graphics/wayland/wayland_%.bbappend index e8ca57d..e4792b9 100644 --- a/recipes-graphics/wayland/wayland_%.bbappend +++ b/recipes-graphics/wayland/wayland_%.bbappend @@ -2,6 +2,5 @@ # compatible with i686 MinGW PACKAGECONFIG:remove:mingw32:i686 = "dtd-validation" -EXTRA_OECONF:class-nativesdk:mingw32 = "--disable-documentation --disable-libraries" -EXTRA_OEMESON:class-nativesdk:mingw32 = "-Ddocumentation=false -Dlibraries=false" +EXTRA_OEMESON:class-nativesdk:mingw32 = "-Ddocumentation=false -Dlibraries=false -Dtests=false" -- 2.30.2
|
|
|
|
Re: [PATCH yocto-autobuilder-helper] run-docs-build: allow build warnings again
Quentin Schulz
Hi Richard, Michael,
On 7/4/22 16:23, Richard Purdie wrote: On Mon, 2022-07-04 at 15:24 +0200, Quentin Schulz wrote:Some warnings are actually valid. Such is the case for the one that warranted https://git.yoctoproject.org/yocto-docs/commit/?id=9a797dedf6708da3e7ce789c5c8735e5d891cde4. The issue is that we build the docs from old versions with the same version of sphinx. Therefore, this patch fixes the issue in master but should also be backported to all other impacted versions, even the unmaintained ones. See https://docs.yoctoproject.org/dunfell/dev-manual/dev-manual-common-tasks.html#recipe-syntax, instead of a link we now have a path between quotes.Hi Michael,Enabling them for master could be a compromise, I'd take such a patch There are two ways to fix that one warning: - add intersphinx_disabled_reftypes=[] in conf.py manually from the run-docs-build script, c.f. https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#confval-intersphinx_disabled_reftypes - patch all (tagged and branch) releases from 3.2 to current master in scripts/docs-build-patches, I prefer the second option because it feels less hacky, but that means MANY times the same file added to docs-build-patches directory. The same could be done for the patch I just sent for yocto-docs to use the %s substitution characters for the cve extlinks to fix a warning. We could just apply this patch to affected releases (kirkstone-4.0.1 tag + kirkstone branch). I could technically request a backport to yocto-docs kirkstone branch, the only thing I don't like is bumping the min version requirement for sphinx for a release that was already released, but if that's okay with you, we could avoid having to add patches in the autobuilder for every new tagged release of kirkstone. I'm honestly not sure there's a lot of benefit in disabling the warnings for now, or enabling them only for select releases. I understand that this increases the maintenance burden on unmaintained branches every time we update the sphinx binary in the docs buildtools. However, we missed this new broken link for almost a month now, which shows we don't look at successful docs build logs from the autobuilder. Cheers, Quentin
|
|
|
|
Re: [PATCH 1/2] image-without-static-linkage: add class
Quentin Schulz
Hi Johannes,
Thanks for the patch. On 7/4/22 18:25, Johannes Schilling via lists.yoctoproject.org wrote: This class provides a new image QA check that tries to detect staticb/recipes-devtools/python/python3-packaging_%.bbappend new file mode 100644I would say to put this change directly in python3-packaging recipe, no need for a bbappend. diff --git a/recipes-security/cve-bin-tool/cve-bin-tool-native.bb b/recipes-security/cve-bin-tool/cve-bin-tool-native.bb I guess you could have all inherit in the same line (and also, pretty sure native class should be inherited last). +RDEPENDS_${PN} = "\RDEPENDS:${PN} + python3-rich-native \FILES:${PN}:append (also why append and not a simple += ?) +do_configure[noexec] = "1"a/recipes-security/cve-bin-tool/files/cve-bin-tool-static-linkage-checker b/recipes-security/cve-bin-tool/files/cve-bin-tool-static-linkage-checker new file mode 100644We at least need SPDX license tag here. +from importlib import import_moduleThis isn't a core module (yet?) as far as I could tell, so you're missing a DEPENDS/RDEPENDS on the python recipe/package that provides this python module. On a side note, I'm not entirely sure we would like to maintain a wrapper script specific to OE/Yocto in here. Is there any chance of seeing this or some variant upstreamed to cve-bin-tool git repo instead? Cheers, Quentin +
|
|
|