[yocto] PXE Boot on Yocto Intel Hardware
Hi Guys, We are trying to set up PXE boot in Yocto. Our hardware is Apollo Lake based SoC (intel-core-i7), I used tftp32 utility, started dns, tftp and dhcp server and put "bootx64.efi" as boot file When I do "PXE Boot" from hardware, it successfully copies the bootx64.efi file into the hardware and displays GRUB cli. What should I do for me to flash the .hddimg over PXE Thanks for your time and patience. Regards, Jamal, Software Specialist, NCR Corporation -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto layers missing thud branches
On Tue, 2018-11-20 at 16:21 -0700, akuster808 wrote: > > On 11/20/18 4:05 PM, Richard Purdie wrote: > > On Mon, 2018-11-19 at 09:47 +1300, Paul Eggleton wrote: > > > On Monday, 19 November 2018 12:11:35 AM NZDT Max Krummenacher wrote: > > > > Am Samstag, den 17.11.2018, 15:50 -0800 schrieb akuster808: > > > > > Can the maintainers of meta-qt3, meta-qt4, meta-selinux, and > > > > > meta-cgl > > > > > please add a "Thud" branch > > > > > > > > > > > > > While at it, the following patches declaring thud compatibility are > > > > not > > > > yet applied: > > > > > > > > https://lists.yoctoproject.org/pipermail/yocto/2018-October/042780.html > > https://lists.yoctoproject.org/pipermail/yocto/2018-October/042922.html > > https://lists.yoctoproject.org/pipermail/yocto/2018-October/042923.html > > > I have just taken care of meta-qt3 and meta-qt4, FWIW. > > > > Given we don't test those any more, should we be pushing these new > > branches? > > Are the branching schemes in sync with what we test , build or both? > I think we should be clear what is built or built and tested if there > are exception. > > > The 2.6 release notes called out so it may lead to the conclusion its > tested. > > Release Name: meta-qt3-thud-20.0.0 > Branch: thud > Tag: thud-20.0.0 > Hash: 02f273cba6c25f5cf20cb66d8a417a83772c3179 > md5: 7b73bf1132428ea898938b03815cad21 Scripts may have put that in the release notes and even done tagging but I'm fairly sure it doesn't get built or tested... I think processes are being followed without review. Yes, I probably should have caught this before now but I'm not alone in that :(. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto layers missing thud branches
On 11/20/18 4:05 PM, Richard Purdie wrote: > On Mon, 2018-11-19 at 09:47 +1300, Paul Eggleton wrote: >> On Monday, 19 November 2018 12:11:35 AM NZDT Max Krummenacher wrote: >>> Am Samstag, den 17.11.2018, 15:50 -0800 schrieb akuster808: Can the maintainers of meta-qt3, meta-qt4, meta-selinux, and meta-cgl please add a "Thud" branch >>> While at it, the following patches declaring thud compatibility are >>> not >>> yet applied: >>> > https://lists.yoctoproject.org/pipermail/yocto/2018-October/042780.html > https://lists.yoctoproject.org/pipermail/yocto/2018-October/042922.html > https://lists.yoctoproject.org/pipermail/yocto/2018-October/042923.html >> I have just taken care of meta-qt3 and meta-qt4, FWIW. > Given we don't test those any more, should we be pushing these new > branches? Are the branching schemes in sync with what we test , build or both? I think we should be clear what is built or built and tested if there are exception. The 2.6 release notes called out so it may lead to the conclusion its tested. Release Name: meta-qt3-thud-20.0.0 Branch: thud Tag: thud-20.0.0 Hash: 02f273cba6c25f5cf20cb66d8a417a83772c3179 md5: 7b73bf1132428ea898938b03815cad21 - armin > > Cheers, > > Richard > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto layers missing thud branches
On Mon, 2018-11-19 at 09:47 +1300, Paul Eggleton wrote: > On Monday, 19 November 2018 12:11:35 AM NZDT Max Krummenacher wrote: > > Am Samstag, den 17.11.2018, 15:50 -0800 schrieb akuster808: > > > Can the maintainers of meta-qt3, meta-qt4, meta-selinux, and > > > meta-cgl > > > please add a "Thud" branch > > > > > > > While at it, the following patches declaring thud compatibility are > > not > > yet applied: > > https://lists.yoctoproject.org/pipermail/yocto/2018-October/042780.html > > https://lists.yoctoproject.org/pipermail/yocto/2018-October/042922.html > > https://lists.yoctoproject.org/pipermail/yocto/2018-October/042923.html > > I have just taken care of meta-qt3 and meta-qt4, FWIW. Given we don't test those any more, should we be pushing these new branches? Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] include in the image mtd-utils-ubifs
All I am trying to include the ubi-utils (ubiformat etc in my image. I included mtd-utils in CORE_IMAGE_EXTRA_INSTALL which appears to result in building the system. Except these are not included in my image. I was told to include the package mtd-utils-ubifs to the list of packages. Not clear how I could do this. Anyone can point me in the right direction? 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] [meta-mingw][PATCH v2 2/2] cmake: add support for building nativesdk-cmake
Build nativesdk-cmake and dependency libs without without openssl.
Signed-off-by: Samuli Piippo
---
recipes-devtools/cmake/cmake_%.bbappend | 7 +++
recipes-extended/libarchive/libarchive_%.bbappend | 1 +
recipes-support/curl/curl_%.bbappend | 2 ++
3 files changed, 10 insertions(+)
create mode 100644 recipes-devtools/cmake/cmake_%.bbappend
create mode 100644 recipes-extended/libarchive/libarchive_%.bbappend
create mode 100644 recipes-support/curl/curl_%.bbappend
diff --git a/recipes-devtools/cmake/cmake_%.bbappend
b/recipes-devtools/cmake/cmake_%.bbappend
new file mode 100644
index 000..d9d7ceb
--- /dev/null
+++ b/recipes-devtools/cmake/cmake_%.bbappend
@@ -0,0 +1,7 @@
+DEPENDS_remove_mingw32 = "ncurses"
+
+cmake_do_generate_toolchain_file_append_mingw32() {
+cat >> ${WORKDIR}/toolchain.cmake
[yocto] [meta-mingw][PATCH] mingw-w64-{headers, runtime, winpthreads}: Upgrade 5.0.3 -> 6.0.0
Upgrades the MinGW support recipes to the latest version
Signed-off-by: Joshua Watt
---
...pl.h-do-not-define-_xgetbv-for-GCC-8.patch | 43 ---
.../mingw-w64/mingw-w64-headers/epsilon.patch | 16 ---
recipes-devtools/mingw-w64/mingw-w64.inc | 14 ++
...b => nativesdk-mingw-w64-headers_6.0.0.bb} | 11 +
...b => nativesdk-mingw-w64-runtime_6.0.0.bb} | 8 +---
... nativesdk-mingw-w64-winpthreads_6.0.0.bb} | 8 +---
6 files changed, 17 insertions(+), 83 deletions(-)
delete mode 100644
recipes-devtools/mingw-w64/mingw-w64-headers/0001-intrin-impl.h-do-not-define-_xgetbv-for-GCC-8.patch
delete mode 100644 recipes-devtools/mingw-w64/mingw-w64-headers/epsilon.patch
create mode 100644 recipes-devtools/mingw-w64/mingw-w64.inc
rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-headers_5.0.3.bb =>
nativesdk-mingw-w64-headers_6.0.0.bb} (53%)
rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-runtime_5.0.3.bb =>
nativesdk-mingw-w64-runtime_6.0.0.bb} (70%)
rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-winpthreads_5.0.3.bb =>
nativesdk-mingw-w64-winpthreads_6.0.0.bb} (64%)
diff --git
a/recipes-devtools/mingw-w64/mingw-w64-headers/0001-intrin-impl.h-do-not-define-_xgetbv-for-GCC-8.patch
b/recipes-devtools/mingw-w64/mingw-w64-headers/0001-intrin-impl.h-do-not-define-_xgetbv-for-GCC-8.patch
deleted file mode 100644
index 366afdc..000
---
a/recipes-devtools/mingw-w64/mingw-w64-headers/0001-intrin-impl.h-do-not-define-_xgetbv-for-GCC-8.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-Upstream-Status: Backport
-Signed-off-by: Ross Burton
-
-From 63d69029386701955e8fa10ac14be8d2316faf6f Mon Sep 17 00:00:00 2001
-From: Mateusz
-Date: Mon, 22 Jan 2018 20:58:48 +0100
-Subject: [PATCH] intrin-impl.h: do not define _xgetbv for GCC 8
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-GCC 8 from r248028 has defined function _xgetbv and we should
-avoid double definition of this function.
-
-Signed-off-by: Mateusz Brzostek
-Signed-off-by: Martin Storsjö
- mingw-w64-headers/include/psdk_inc/intrin-impl.h | 2 ++
- 1 file changed, 2 insertions(+)
-
-diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
-index 7da3238b..4990b0ae 100644
a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
-+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
-@@ -1405,6 +1405,7 @@ __buildmov(__movsd, unsigned __LONG32, "d")
- #define __INTRINSIC_DEFINED___movsd
- #endif /* __INTRINSIC_PROLOG */
-
-+#if !defined(__GNUC__) || __GNUC__ < 8 /* GCC 8 has already defined _xgetbv */
- /* NOTE: This should be in immintrin.h */
- #if __INTRINSIC_PROLOG(_xgetbv)
- unsigned __int64 _xgetbv(unsigned int);
-@@ -1426,6 +1427,7 @@ unsigned __int64 _xgetbv(unsigned int index)
- }
- #define __INTRINSIC_DEFINED__xgetbv
- #endif /* __INTRINSIC_PROLOG */
-+#endif /* __GNUC__ < 8 */
-
- #endif /* defined(__x86_64__) || defined(_AMD64_) || defined(__i386__) ||
defined(_X86_) */
-
---
-2.11.0
-
diff --git a/recipes-devtools/mingw-w64/mingw-w64-headers/epsilon.patch
b/recipes-devtools/mingw-w64/mingw-w64-headers/epsilon.patch
deleted file mode 100644
index 10213ee..000
--- a/recipes-devtools/mingw-w64/mingw-w64-headers/epsilon.patch
+++ /dev/null
@@ -1,16 +0,0 @@
-mpfr 3.1.2 references these symbols and fails if they're not defined.
-
-Index: mingw-w64-headers/crt/float.h
-===
mingw-w64-headers/crt.orig/float.h 2012-07-17 11:03:12.0 +
-+++ mingw-w64-headers/crt/float.h 2013-08-13 08:23:20.0 +
-@@ -111,6 +111,9 @@
- #define FLT_ROUNDS 1
-
- #define _FLOAT_H___
-+
-+ #define DBL_EPSILON __DBL_EPSILON__
-+ #define FLT_EPSILON __FLT_EPSILON__
- #endif
- #endif
- #endif
diff --git a/recipes-devtools/mingw-w64/mingw-w64.inc
b/recipes-devtools/mingw-w64/mingw-w64.inc
new file mode 100644
index 000..8c68bcc
--- /dev/null
+++ b/recipes-devtools/mingw-w64/mingw-w64.inc
@@ -0,0 +1,14 @@
+LICENSE = "ZPL-2.1"
+LIC_FILES_CHKSUM =
"file://${WORKDIR}/mingw-w64-v${PV}/COPYING;md5=bb936f0e04d8f1e19ad545100cee9654"
+
+COMPATIBLE_HOST = ".*-mingw.*"
+
+SRC_URI =
"${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2"
+
+SRC_URI[md5sum] = "cf5673f6d689bb5e02863e6284cc3d03"
+SRC_URI[sha256sum] =
"805e11101e26d7897fce7d49cbb140d7bac15f3e085a91e0001e80b2adaf48f0"
+
+UPSTREAM_CHECK_URI =
"http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/;
+UPSTREAM_CHECK_REGEX = "mingw-w64-v(?P(\d+[\.\-_]*)+)\.tar"
+
+
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_6.0.0.bb
similarity index 53%
rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_6.0.0.bb
index
[yocto] Yocto Project Status WW47’18
Current Dev Position: YP 2.7 M1. Next Deadline: YP 2.7 M1 Cutoff is Dec. 10, 2018 SWAT Team Rotation: · SWAT lead is currently: Paul · SWAT team rotation: Paul -> Ross on Nov. 23, 2018 · SWAT team rotation: Ross -> Amanda on Nov. 30, 2018 · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: · YP 2.6 (thud) was released based on rc1. · We’d like to thank everyone who was involved in 2.6 for making what is shaping up to be a great project release. This applied to everyone involved, be it through patches, docs, bug triage, autobuilder, QA, programme management, bug reporting, sysadmin or anything else, it all goes to helping the releases (and hence the project) being successful. · YP 2.4.4 (Rocko) is in QA and 93% complete. See: https://wiki.yoctoproject.org/wiki/2.4_QA_Status · Master has opened for new changes for 2.7 M1 and patches are being tested and merged as usual. · The next release will be ‘warrior’ followed by ‘zeus’. · The AUH has sent out patches for various upgrades recently which is timely for merging into 2.7 so lets collect those up and get them merged! · There are some autobuilder changes happening at the moment to assist us with the QA changes happening in 2.7. We updated to the recent buildbot 1.6.0 release which contained bug fixes for some UI glitches we were seeing (was good to be able to work with the latest code!). Planned Releases for YP 2.7: · YP 2.7 M1 Cutoff is Dec. 10, 2018 · YP 2.7 M1 Release Target is Dec. 21, 2018 · YP 2.7 M2 Cutoff is Jan. 21, 2019 · YP 2.7 M2 Release Target is Feb. 1, 2019 · YP 2.7 M3 Cutoff is Feb. 25, 2019 · YP 2.7 M3 Release Target is Mar. 8, 2019 · YP 2.7 M4 Cutoff is Apr. 1, 2019 · YP 2.7 M4 Release Target is Apr. 26, 2019 Planned upcoming dot releases: · YP 2.4.4 (Rocko) is in QA. See: https://wiki.yoctoproject.org/wiki/2.4_QA_Status · YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done. · YP 2.6.1 (Thud) will be targeted after YP 2.7 M1 is done. · YP 2.5.3 (Sumo) will be targeted after YP 2.7 M4 is done. · YP 2.6.2 (Thud) will be targeted after YP 2.5.3 is done. Tracking Metrics: · WDD 2418 (last week 2402) (https://wiki.yoctoproject.org/charts/combo.html) · Poky Patch Metrics oTotal patches found: 1711 (last week 1716) oPercentage of patches in the Pending State: 738 (43%) [last week 739 (43%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.7_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
Re: [yocto] PermissionError when using image_list_installed_packages
Your recipe is a non-image recipe, so what image do you expect it to list
the manifest of?
On Tue, 20 Nov 2018 at 08:16, Norman Stetter
wrote:
> Hi,
>
>
>
> I am currently working on a BitBake task, which generates a html file
> containing a table of all packages used in my image.
>
>
>
> To get a list of all packages I want to use 'image_list_installed_packages'
> from 'oe.rootfs', the way it is used in 'license.bbclass’.
>
>
>
> My minimal test recipe looks like this:
>
>
>
> SUMMARY = "Test recipe"
> SECTION = "examples"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = "
> file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>
> inherit license
>
>
> python do_licensesinfo() {
> from oe.rootfs import image_list_installed_packages
> pkgs = image_list_installed_packages(d)
> }
> addtask licensesinfo
>
> When I run the task 'licensesinfo' it fails giving this log:
>
>
>
> DEBUG: Executing python function do_licensesinfo
> ERROR: Error executing a python function in exec_python_func()
> autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure
> was:
> File: 'exec_python_func() autogenerated', lineno: 2, function:
> 0001:
> *** 0002:do_licensesinfo(d)
> 0003:
> File:
> '/home/norman.stetter/build/yocto-rocko/sources/meta-guf/meta/recipes-bsp/images/
> guf-image-licenses.bb', lineno: 11, function: do_licensesinfo
> 0007:
> 0008:
> 0009:python do_licensesinfo() {
> 0010: from oe.rootfs import image_list_installed_packages
> *** 0011: pkgs = image_list_installed_packages(d)
> 0012:}
> 0013:addtask licensesinfo
> 0014:
> 0015:
> File:
> '/home/norman.stetter/build/yocto-rocko/sources/poky/meta/lib/oe/rootfs.py',
> lineno: 1026, function: image_list_installed_packages
> 1022:rootfs_dir = d.getVar('IMAGE_ROOTFS')
> 1023:
> 1024:img_type = d.getVar('IMAGE_PKGTYPE')
> 1025:if img_type == "rpm":
> *** 1026:return RpmPkgsList(d, rootfs_dir).list_pkgs()
> 1027:elif img_type == "ipk":
> 1028:return OpkgPkgsList(d, rootfs_dir,
> d.getVar("IPKGCONF_TARGET")).list_pkgs()
> 1029:elif img_type == "deb":
> 1030:return DpkgPkgsList(d, rootfs_dir).list_pkgs()
> File:
> '/home/norman.stetter/build/yocto-rocko/sources/poky/meta/lib/oe/package_manager.py',
> lineno: 258, function: list_pkgs
> 0254:pass
> 0255:
> 0256:class RpmPkgsList(PkgsList):
> 0257:def list_pkgs(self):
> *** 0258:return RpmPM(self.d, self.rootfs_dir,
> self.d.getVar('TARGET_VENDOR')).list_installed()
> 0259:
> 0260:class OpkgPkgsList(PkgsList):
> 0261:def __init__(self, d, rootfs_dir, config_file):
> 0262:super(OpkgPkgsList, self).__init__(d, rootfs_dir)
> File:
> '/home/norman.stetter/build/yocto-rocko/sources/poky/meta/lib/oe/package_manager.py',
> lineno: 689, function: list_installed
> 0685:symlinks=True)
> 0686:
> 0687:def list_installed(self):
> 0688:output = self._invoke_dnf(["repoquery", "--installed",
> "--queryformat", "Package: %{name} %{arch} %{version}
> %{name}-%{version}-%{release}.%{arch}.rpm\nDependencies:\n%{requires}\nRecommendations:\n%{recommends}\nDependenciesEndHere:\n"],
> *** 0689: print_output = False)
> 0690:packages = {}
> 0691:current_package = None
> 0692:current_deps = None
> 0693:current_state = "initial"
> File:
> '/home/norman.stetter/build/yocto-rocko/sources/poky/meta/lib/oe/package_manager.py',
> lineno: 734, function: _invoke_dnf
> 0730: "--setopt=logdir=%s" %
> (self.d.getVar('T'))
> 0731:]
> 0732:cmd = [dnf_cmd] + standard_dnf_args + dnf_args
> 0733:try:
> *** 0734:output =
> subprocess.check_output(cmd,stderr=subprocess.STDOUT).decode("utf-8")
> 0735:if print_output:
> 0736:bb.note(output)
> 0737:return output
> 0738:except subprocess.CalledProcessError as e:
> File: '/usr/lib/python3.5/subprocess.py', lineno: 626, function:
> check_output
> 0622:# empty string. That is maintained here for backwards
> compatibility.
> 0623:kwargs['input'] = '' if kwargs.get('universal_newlines',
> False) else b''
> 0624:
> 0625:return run(*popenargs, stdout=PIPE, timeout=timeout,
> check=True,
> *** 0626: **kwargs).stdout
> 0627:
> 0628:
> 0629:class CompletedProcess(object):
> 0630:"""A process that has finished running.
> File: '/usr/lib/python3.5/subprocess.py', lineno: 693, function: run
> 0689:if 'stdin' in kwargs:
> 0690:raise ValueError('stdin and input arguments may not
> both be used.')
> 0691:kwargs['stdin'] = PIPE
> 0692:
>
[yocto] PermissionError when using image_list_installed_packages
Hi,
I am currently working on a BitBake task, which generates a html file
containing a table of all packages used in my image.
To get a list of all packages I want to use 'image_list_installed_packages'
from 'oe.rootfs', the way it is used in 'license.bbclass'.
My minimal test recipe looks like this:
SUMMARY = "Test recipe"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
inherit license
python do_licensesinfo() {
from oe.rootfs import image_list_installed_packages
pkgs = image_list_installed_packages(d)
}
addtask licensesinfo
When I run the task 'licensesinfo' it fails giving this log:
DEBUG: Executing python function do_licensesinfo
ERROR: Error executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function:
0001:
*** 0002:do_licensesinfo(d)
0003:
File:
'/home/norman.stetter/build/yocto-rocko/sources/meta-guf/meta/recipes-bsp/images/guf-image-licenses.bb',
lineno: 11, function: do_licensesinfo
0007:
0008:
0009:python do_licensesinfo() {
0010: from oe.rootfs import image_list_installed_packages
*** 0011: pkgs = image_list_installed_packages(d)
0012:}
0013:addtask licensesinfo
0014:
0015:
File:
'/home/norman.stetter/build/yocto-rocko/sources/poky/meta/lib/oe/rootfs.py',
lineno: 1026, function: image_list_installed_packages
1022:rootfs_dir = d.getVar('IMAGE_ROOTFS')
1023:
1024:img_type = d.getVar('IMAGE_PKGTYPE')
1025:if img_type == "rpm":
*** 1026:return RpmPkgsList(d, rootfs_dir).list_pkgs()
1027:elif img_type == "ipk":
1028:return OpkgPkgsList(d, rootfs_dir,
d.getVar("IPKGCONF_TARGET")).list_pkgs()
1029:elif img_type == "deb":
1030:return DpkgPkgsList(d, rootfs_dir).list_pkgs()
File:
'/home/norman.stetter/build/yocto-rocko/sources/poky/meta/lib/oe/package_manager.py',
lineno: 258, function: list_pkgs
0254:pass
0255:
0256:class RpmPkgsList(PkgsList):
0257:def list_pkgs(self):
*** 0258:return RpmPM(self.d, self.rootfs_dir,
self.d.getVar('TARGET_VENDOR')).list_installed()
0259:
0260:class OpkgPkgsList(PkgsList):
0261:def __init__(self, d, rootfs_dir, config_file):
0262:super(OpkgPkgsList, self).__init__(d, rootfs_dir)
File:
'/home/norman.stetter/build/yocto-rocko/sources/poky/meta/lib/oe/package_manager.py',
lineno: 689, function: list_installed
0685:symlinks=True)
0686:
0687:def list_installed(self):
0688:output = self._invoke_dnf(["repoquery", "--installed",
"--queryformat", "Package: %{name} %{arch} %{version}
%{name}-%{version}-%{release}.%{arch}.rpm\nDependencies:\n%{requires}\nRecommendations:\n%{recommends}\nDependenciesEndHere:\n"],
*** 0689: print_output = False)
0690:packages = {}
0691:current_package = None
0692:current_deps = None
0693:current_state = "initial"
File:
'/home/norman.stetter/build/yocto-rocko/sources/poky/meta/lib/oe/package_manager.py',
lineno: 734, function: _invoke_dnf
0730: "--setopt=logdir=%s" %
(self.d.getVar('T'))
0731:]
0732:cmd = [dnf_cmd] + standard_dnf_args + dnf_args
0733:try:
*** 0734:output =
subprocess.check_output(cmd,stderr=subprocess.STDOUT).decode("utf-8")
0735:if print_output:
0736:bb.note(output)
0737:return output
0738:except subprocess.CalledProcessError as e:
File: '/usr/lib/python3.5/subprocess.py', lineno: 626, function: check_output
0622:# empty string. That is maintained here for backwards
compatibility.
0623:kwargs['input'] = '' if kwargs.get('universal_newlines',
False) else b''
0624:
0625:return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
*** 0626: **kwargs).stdout
0627:
0628:
0629:class CompletedProcess(object):
0630:"""A process that has finished running.
File: '/usr/lib/python3.5/subprocess.py', lineno: 693, function: run
0689:if 'stdin' in kwargs:
0690:raise ValueError('stdin and input arguments may not both
be used.')
0691:kwargs['stdin'] = PIPE
0692:
*** 0693:with Popen(*popenargs, **kwargs) as process:
0694:try:
0695:stdout, stderr = process.communicate(input,
timeout=timeout)
0696:except TimeoutExpired:
0697:process.kill()
File: '/usr/lib/python3.5/subprocess.py', lineno: 947, function: __init__
0943:startupinfo, creationflags,
