[OE-core] [PATCH] ethtool: fix 4.8 checksums
The mismatched checksums cause fatching failed in my setup. Signed-off-by: Jianxun Zhang --- I am not sure why I got this issue today, but it seems the upstream package has different checksums. Maintainer could help to check if this is a false patch. meta/recipes-extended/ethtool/ethtool_4.8.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-extended/ethtool/ethtool_4.8.bb b/meta/recipes-extended/ethtool/ethtool_4.8.bb index afaf2e2..ce3eaf3 100644 --- a/meta/recipes-extended/ethtool/ethtool_4.8.bb +++ b/meta/recipes-extended/ethtool/ethtool_4.8.bb @@ -11,8 +11,8 @@ SRC_URI = "https://downloads.yoctoproject.org/mirror/sources/ethtool-${PV}.tar.g file://avoid_parallel_tests.patch \ " -SRC_URI[md5sum] = "28c4a4d85c33f573c49ff6d81ec094fd" -SRC_URI[sha256sum] = "1bd82ebe3d41de1b7b0d8f4fb18a8e8466fba934c952bc5c5002836ffa8bb606" +SRC_URI[md5sum] = "992eab97607c64b7848edfd37f23da22" +SRC_URI[sha256sum] = "c8ea20b8d85898377ec130066008f9241ebcdd95ac85dbcc2d50b32fe2e2f934" inherit autotools ptest RDEPENDS_${PN}-ptest += "make" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Make locked sig file consistent
Sort keys of dict 'types' prior to dumping, in order to have identical output every time. This could make it a little easier to diff these human-readable dumps. Signed-off-by: Jianxun Zhang --- meta/lib/oe/sstatesig.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py index 8224e3a..c5875a8 100644 --- a/meta/lib/oe/sstatesig.py +++ b/meta/lib/oe/sstatesig.py @@ -197,7 +197,8 @@ class SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash): types[t].append(k) with open(sigfile, "w") as f: -for t in types: +l = sorted(types) +for t in l: f.write('SIGGEN_LOCKEDSIGS_%s = "\\\n' % t) types[t].sort() sortedk = sorted(types[t], key=lambda k: self.lockedpnmap[k.rsplit(".",1)[0]]) @@ -208,7 +209,7 @@ class SignatureGeneratorOEBasicHash(bb.siggen.SignatureGeneratorBasicHash): continue f.write("" + self.lockedpnmap[fn] + ":" + task + ":" + self.taskhash[k] + " \\\n") f.write('"\n') -f.write('SIGGEN_LOCKEDSIGS_TYPES_%s = "%s"' % (self.machine, " ".join(list(types.keys() +f.write('SIGGEN_LOCKEDSIGS_TYPES_%s = "%s"' % (self.machine, " ".join(l))) def checkhashes(self, missed, ret, sq_fn, sq_task, sq_hash, sq_hashfn, d): warn_msgs = [] -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rmc: Fix compiling issue with musl
> On Nov 14, 2016, at 2:50 PM, Khem Raj wrote: > > > > On 11/14/16 2:10 PM, Jianxun Zhang wrote: >> | src/rmcl/rmcl.c: In function 'query_policy_from_db': >> | src/rmcl/rmcl.c:254:25: error: unknown type name 'ssize_t' >> | ssize_t cmd_name_len = strlen((char *)&rmc_db[policy_idx]) + 1; >> | ^~~~ >> >> The musl C lib provides ssize_t but we need to enable it >> with a macro. >> >> Signed-off-by: Jianxun Zhang >> --- >> Before maintainer(s) push "merge" button, please read this short summary. >> I feel there could be a better syntax to do it. And We could need to get >> an ack from Hernandez, Alejandro who reported this issue and seems still >> have (other) compiling errors even with this patch. >> >> I submit this patch based on my thoughts and test out of tiny config. >> >> Tests: >> () Specify TCLIBC = "musl" in local.conf in my build dir. >> () Build quark >> () I can see this issue happens without the fix >> () With this patch and do clean builds for quark and corei7-64, >> Compiling passes. Boot test passed on RMC targets quark and Broxton-m. >> >> Thanks >> >> >> common/recipes-bsp/rmc/rmc.bb | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb >> index aeaf12e..61a1bdb 100644 >> --- a/common/recipes-bsp/rmc/rmc.bb >> +++ b/common/recipes-bsp/rmc/rmc.bb >> @@ -24,6 +24,8 @@ COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*" >> >> EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"' >> >> +EXTRA_OEMAKE_append_libc-musl = '" -D__NEED_ssize_t"' > > this is not right way to handle it. you should be doing something like > #include in your source file Khem, Thanks lot for your review even when I wrongly submit it here! I tried it first but didn’t succeed for some reason with the suggested change. Let me try it again... > > >> + >> # from gnu-efi, we should align arch-mapping with it. >> def rmc_efi_arch(d): >> import re -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rmc: Fix compiling issue with musl
OOPS. Please ignore this patch. It is for another BSP project! > On Nov 14, 2016, at 2:10 PM, Jianxun Zhang > wrote: > > | src/rmcl/rmcl.c: In function 'query_policy_from_db': > | src/rmcl/rmcl.c:254:25: error: unknown type name 'ssize_t' > | ssize_t cmd_name_len = strlen((char *)&rmc_db[policy_idx]) + 1; > | ^~~~ > > The musl C lib provides ssize_t but we need to enable it > with a macro. > > Signed-off-by: Jianxun Zhang > --- > Before maintainer(s) push "merge" button, please read this short summary. > I feel there could be a better syntax to do it. And We could need to get > an ack from Hernandez, Alejandro who reported this issue and seems still > have (other) compiling errors even with this patch. > > I submit this patch based on my thoughts and test out of tiny config. > > Tests: > () Specify TCLIBC = "musl" in local.conf in my build dir. > () Build quark > () I can see this issue happens without the fix > () With this patch and do clean builds for quark and corei7-64, > Compiling passes. Boot test passed on RMC targets quark and Broxton-m. > > Thanks > > > common/recipes-bsp/rmc/rmc.bb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb > index aeaf12e..61a1bdb 100644 > --- a/common/recipes-bsp/rmc/rmc.bb > +++ b/common/recipes-bsp/rmc/rmc.bb > @@ -24,6 +24,8 @@ COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*" > > EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"' > > +EXTRA_OEMAKE_append_libc-musl = '" -D__NEED_ssize_t"' > + > # from gnu-efi, we should align arch-mapping with it. > def rmc_efi_arch(d): > import re > -- > 2.7.4 > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] rmc: Fix compiling issue with musl
| src/rmcl/rmcl.c: In function 'query_policy_from_db': | src/rmcl/rmcl.c:254:25: error: unknown type name 'ssize_t' | ssize_t cmd_name_len = strlen((char *)&rmc_db[policy_idx]) + 1; | ^~~~ The musl C lib provides ssize_t but we need to enable it with a macro. Signed-off-by: Jianxun Zhang --- Before maintainer(s) push "merge" button, please read this short summary. I feel there could be a better syntax to do it. And We could need to get an ack from Hernandez, Alejandro who reported this issue and seems still have (other) compiling errors even with this patch. I submit this patch based on my thoughts and test out of tiny config. Tests: () Specify TCLIBC = "musl" in local.conf in my build dir. () Build quark () I can see this issue happens without the fix () With this patch and do clean builds for quark and corei7-64, Compiling passes. Boot test passed on RMC targets quark and Broxton-m. Thanks common/recipes-bsp/rmc/rmc.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb index aeaf12e..61a1bdb 100644 --- a/common/recipes-bsp/rmc/rmc.bb +++ b/common/recipes-bsp/rmc/rmc.bb @@ -24,6 +24,8 @@ COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*" EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"' +EXTRA_OEMAKE_append_libc-musl = '" -D__NEED_ssize_t"' + # from gnu-efi, we should align arch-mapping with it. def rmc_efi_arch(d): import re -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Question for OE variable "LABELS"
The current OE document has this LABELS variable and OE has some code to support its usage. But if I just set LABELS in a BSP conf or local.conf file, the build will show the warning message: WARNING: core-image-minimal-1.0-r0 do_bootimg: Found potential conflicted var LABELS, please use LABELS_LIVE rather than LABELS" Does anyone know a “proper” usage of LABELS so it won’t trigger the warning message? From the code I dig out, it doesn’t seem so: in meta//classes/live-vm-common.bbclass: def set_live_vm_vars(d, suffix): vars = ['GRUB_CFG', 'SYSLINUX_CFG', 'ROOT', 'LABELS', 'INITRD'] for var in vars: var_with_suffix = var + '_' + suffix if d.getVar(var, True): bb.warn('Found potential conflicted var %s, please use %s rather than %s' % \ (var, var_with_suffix, var)) elif d.getVar(var_with_suffix, True): d.setVar(var, d.getVar(var_with_suffix, True)) Notice there is another corner case of false alarm when LABELS have same value of LABEL_LIVE or VM. I can have a small patch to change it, but hope to know the intended behaviors first. Thanks -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] sqlite3: Revert ad601c7962 from 3.14.1 amalgamation package
It turns out this change between 3.12.2 and 3.13 introduces a 2% increase of build time based on statistic data in bz10367. The added patch is forged by diffing the new sqlite3.c generated from reverting the change in raw source of sqlite3 project, and then manually migrate the delta to a sqlite3.c from the 3.14.1 tarball package because what recipes reference is actually a generated C code (amalgamation) release package and we cannot apply the real change to 3.14.1 cleanly due to so many changes happened. Fixes [YOCTO #10367] Signed-off-by: Jianxun Zhang --- V2 adds "Upstream Status: Inappropriate" in the commit msg in the patch file. Thanks to Saul's reminder. ...1c7962-that-brings-2-increase-of-build-ti.patch | 56 ++ meta/recipes-support/sqlite/sqlite3_3.14.1.bb | 5 +- 2 files changed, 60 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-support/sqlite/files/0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch diff --git a/meta/recipes-support/sqlite/files/0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch b/meta/recipes-support/sqlite/files/0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch new file mode 100644 index 000..26540b2 --- /dev/null +++ b/meta/recipes-support/sqlite/files/0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch @@ -0,0 +1,56 @@ +From 4b286b441e8efa9a34eb0db8227748ebffd91c35 Mon Sep 17 00:00:00 2001 +From: Jianxun Zhang +Date: Thu, 13 Oct 2016 09:24:21 -0700 +Subject: [PATCH] revert ad601c7962 that brings 2% increase of build time. + +The comment of the change in sqlite fossil project is: +"For in-memory databases, it does not matter if pcache +entries are marked "clean" or "writable"." + +Upstream Status: Inappropriate + +Signed-off-by: Jianxun Zhang +--- + sqlite3.c | 12 +++- + 1 file changed, 3 insertions(+), 9 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index ccddfe6..ecae550 100644 +--- a/sqlite3.c b/sqlite3.c +@@ -13146,7 +13146,7 @@ struct PgHdr { + sqlite3_pcache_page *pPage;/* Pcache object page handle */ + void *pData; /* Page data */ + void *pExtra; /* Extra content */ +- PgHdr *pDirty; /* Transient list of dirty sorted by pgno */ ++ PgHdr *pDirty; /* Transient list of dirty pages */ + Pager *pPager; /* The pager this page is part of */ + Pgno pgno; /* Page number for this page */ + #ifdef SQLITE_CHECK_PAGES +@@ -43504,13 +43504,7 @@ bitvec_end: + /* #include "sqliteInt.h" */ + + /* +-** A complete page cache is an instance of this structure. Every +-** entry in the cache holds a single page of the database file. The +-** btree layer only operates on the cached copy of the database pages. +-** +-** A page cache entry is "clean" if it exactly matches what is currently +-** on disk. A page is "dirty" if it has been modified and needs to be +-** persisted to disk. ++** A complete page cache is an instance of this structure. + ** + ** pDirty, pDirtyTail, pSynced: + ** All dirty pages are linked into the doubly linked list using +@@ -48314,7 +48308,7 @@ static int pager_end_transaction(Pager *pPager, int hasMaster, int bCommit){ + pPager->pInJournal = 0; + pPager->nRec = 0; + if( rc==SQLITE_OK ){ +-if( pagerFlushOnCommit(pPager, bCommit) ){ ++if( MEMDB || pagerFlushOnCommit(pPager, bCommit) ){ + sqlite3PcacheCleanAll(pPager->pPCache); + }else{ + sqlite3PcacheClearWritable(pPager->pPCache); +-- +2.7.4 + diff --git a/meta/recipes-support/sqlite/sqlite3_3.14.1.bb b/meta/recipes-support/sqlite/sqlite3_3.14.1.bb index 3af0d2f..7c8fa40 100644 --- a/meta/recipes-support/sqlite/sqlite3_3.14.1.bb +++ b/meta/recipes-support/sqlite/sqlite3_3.14.1.bb @@ -3,7 +3,10 @@ require sqlite3.inc LICENSE = "PD" LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=65f0a57ca6928710b418c094b3570bb0" -SRC_URI = "http://www.sqlite.org/2016/sqlite-autoconf-${SQLITE_PV}.tar.gz"; +SRC_URI = "\ + http://www.sqlite.org/2016/sqlite-autoconf-${SQLITE_PV}.tar.gz \ + file://0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch \ + " SRC_URI[md5sum] = "3634a90a3f49541462bcaed3474b2684" SRC_URI[sha256sum] = "bc7182476900017becb81565ecea7775d46ab747a97281aa610f4f45881c47a6" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sqlite3: Revert ad601c7962 from 3.14.1 amalgamation package
It turns out this change between 3.12.2 and 3.13 introduces a 2% increase of build time based on statistic data in bz10367. The added patch is forged by diffing the new sqlite3.c generated from reverting the change in raw source of sqlite3 project, and then manually migrate the delta to a sqlite3.c from the 3.14.1 tarball package because what recipes reference is actually a generated C code (amalgamation) release package and we cannot apply the real change to 3.14.1 cleanly due to so many changes happened. Fixes [YOCTO #10367] Signed-off-by: Jianxun Zhang --- The statistic data can be found in PDF reports in https://bugzilla.yoctoproject.org/show_bug.cgi?id=10367 Most of test was done with minimal build for qemu 64 bit on pocy tip 3a73fe0efcb7aee because it is impossible to keep up with any current tip on master for a time-consuming perf debugging. A basic boot test and build time measurement on the latest(?) poky tip 371ab635086e287 was conducted before this submission. If you have any new kinky issues in build or run time, let me know and I will have a look at it to see if this sqlite change causes it. ...1c7962-that-brings-2-increase-of-build-ti.patch | 54 ++ meta/recipes-support/sqlite/sqlite3_3.14.1.bb | 5 +- 2 files changed, 58 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-support/sqlite/files/0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch diff --git a/meta/recipes-support/sqlite/files/0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch b/meta/recipes-support/sqlite/files/0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch new file mode 100644 index 000..fba2ebe --- /dev/null +++ b/meta/recipes-support/sqlite/files/0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch @@ -0,0 +1,54 @@ +From 2cc091d812ab0074c5b8ec06436ea1b646745d77 Mon Sep 17 00:00:00 2001 +From: Jianxun Zhang +Date: Thu, 13 Oct 2016 09:24:21 -0700 +Subject: [PATCH] revert ad601c7962 that brings 2% increase of build time. + +The comment of the change in sqlite fossil project is: +"For in-memory databases, it does not matter if pcache +entries are marked "clean" or "writable"." + +Signed-off-by: Jianxun Zhang +--- + sqlite3.c | 12 +++- + 1 file changed, 3 insertions(+), 9 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index ccddfe6..ecae550 100644 +--- a/sqlite3.c b/sqlite3.c +@@ -13146,7 +13146,7 @@ struct PgHdr { + sqlite3_pcache_page *pPage;/* Pcache object page handle */ + void *pData; /* Page data */ + void *pExtra; /* Extra content */ +- PgHdr *pDirty; /* Transient list of dirty sorted by pgno */ ++ PgHdr *pDirty; /* Transient list of dirty pages */ + Pager *pPager; /* The pager this page is part of */ + Pgno pgno; /* Page number for this page */ + #ifdef SQLITE_CHECK_PAGES +@@ -43504,13 +43504,7 @@ bitvec_end: + /* #include "sqliteInt.h" */ + + /* +-** A complete page cache is an instance of this structure. Every +-** entry in the cache holds a single page of the database file. The +-** btree layer only operates on the cached copy of the database pages. +-** +-** A page cache entry is "clean" if it exactly matches what is currently +-** on disk. A page is "dirty" if it has been modified and needs to be +-** persisted to disk. ++** A complete page cache is an instance of this structure. + ** + ** pDirty, pDirtyTail, pSynced: + ** All dirty pages are linked into the doubly linked list using +@@ -48314,7 +48308,7 @@ static int pager_end_transaction(Pager *pPager, int hasMaster, int bCommit){ + pPager->pInJournal = 0; + pPager->nRec = 0; + if( rc==SQLITE_OK ){ +-if( pagerFlushOnCommit(pPager, bCommit) ){ ++if( MEMDB || pagerFlushOnCommit(pPager, bCommit) ){ + sqlite3PcacheCleanAll(pPager->pPCache); + }else{ + sqlite3PcacheClearWritable(pPager->pPCache); +-- +2.7.4 + diff --git a/meta/recipes-support/sqlite/sqlite3_3.14.1.bb b/meta/recipes-support/sqlite/sqlite3_3.14.1.bb index 3af0d2f..7c8fa40 100644 --- a/meta/recipes-support/sqlite/sqlite3_3.14.1.bb +++ b/meta/recipes-support/sqlite/sqlite3_3.14.1.bb @@ -3,7 +3,10 @@ require sqlite3.inc LICENSE = "PD" LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=65f0a57ca6928710b418c094b3570bb0" -SRC_URI = "http://www.sqlite.org/2016/sqlite-autoconf-${SQLITE_PV}.tar.gz"; +SRC_URI = "\ + http://www.sqlite.org/2016/sqlite-autoconf-${SQLITE_PV}.tar.gz \ + file://0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch \ + " SRC_URI[md5sum] = "3634a90a3f49541462bcaed3474b2684" SRC_URI[sha256sum] = "bc7182476900017becb81565ecea7775d46ab747a97281aa610f4f45881c47a6" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] parselogs: Update uvesafb errors in qemu whitelist
This change only whitelists the timeout message in infinite wait case in uvesafb driver. With the latest timeout patch introducing infinite wait in uvesafb driver, we whitelist the timeout message since it works as a warning for issues related to timeout not to be fixed in build servers. We remove other errors for bug-discovering purposes in some cases where these lines are still worthy to be caught (not whitelisted): The removed errors show up again in the infinite wait case. It indicates a different root cause or the timeout patch doesn't work correctly. Timeout happens when developers explicitly set a non-negative timeout of a limited period to wait for task completion in uvesafb driver. Timeout or/and errors occur when kernel doesn't have the latest timeout patch in driver. Note: The latest timeout patch is tracked by: a2966330bcd29e99c0403235edb29433b0c53d56 [YOCTO #8245] Signed-off-by: Jianxun Zhang --- NOTE: I don't have an AB server setup to really test it before submission. Please review it carefully before merge this patch. Let me know if there any way I can test it, or we just wait any result from AB server... Thanks meta/lib/oeqa/runtime/parselogs.py | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/meta/lib/oeqa/runtime/parselogs.py b/meta/lib/oeqa/runtime/parselogs.py index 763c42f..40247d2 100644 --- a/meta/lib/oeqa/runtime/parselogs.py +++ b/meta/lib/oeqa/runtime/parselogs.py @@ -63,11 +63,7 @@ qemux86_common = [ "fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.", "can't claim BAR ", 'amd_nb: Cannot enumerate AMD northbridges', -'uvesafb: 5000 ms task timeout error', -'detected fb_set_par error, error code: -22', -'Getting VBE info block failed', -'vbe_init() failed with -22', -'uvesafb: mode switch failed', +'uvesafb: 5000 ms task timeout, infinitely waiting', 'tsc: HPET/PMTIMER calibration failed', ] + common_errors -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu: fix: cp command cannot find tests/Makeflie
Note the patch is based on 958c05b on master-next branch in poky. Thanks > On Sep 8, 2016, at 12:20 PM, Saul Wold wrote: > > From: Jianxun Zhang > > bitbake qemu > > This error shows up: > > ERROR: qemu-2.7.0-r1 do_install_ptest_base: Function failed: > do_install_ptest_base > ... > cp: cannot stat '...tmp/work/core2-64-poky-linux/qemu/2.7.0-r1 > /qemu-2.7.0/tests/Makefile: No such file or directory > ... > > Commit 46e7b70699d8bf4db08c8bb5111974318dd5416d in qemu project > renamed tests/Makefile to tests/Makefile.include, we apply the > same change in recipe accordingly to fix this issue. > > Fixes [YOCTO #10245] > --- > meta/recipes-devtools/qemu/qemu.inc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-devtools/qemu/qemu.inc > b/meta/recipes-devtools/qemu/qemu.inc > index d724aa4..b46e7f7 100644 > --- a/meta/recipes-devtools/qemu/qemu.inc > +++ b/meta/recipes-devtools/qemu/qemu.inc > @@ -76,7 +76,7 @@ do_install_ptest() { > cp -rL ${B}/tests ${D}${PTEST_PATH} > find ${D}${PTEST_PATH}/tests -type f -name "*.[Sshcod]" | xargs -i rm > -rf {} > > - cp ${S}/tests/Makefile ${D}${PTEST_PATH}/tests > + cp ${S}/tests/Makefile.include ${D}${PTEST_PATH}/tests > } > > do_install () { > -- > 2.7.4 > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2][PROPOSED] libcap: remove dependency on attr
85f38a573fc47472ab792e813b6f6b6f0b1df112 in libcap drops this dependency. Not seeing much necessity of using EXTRA_OECONF (which doesn't seem effective) for the left, we purge these code in libcap recipe. Signed-off-by: Jianxun Zhang --- Limited test is performed by building this recipe individually. Refer to the cover letter before merge. meta/recipes-support/libcap/libcap_2.25.bb | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/meta/recipes-support/libcap/libcap_2.25.bb b/meta/recipes-support/libcap/libcap_2.25.bb index bc29310..3b7876a 100644 --- a/meta/recipes-support/libcap/libcap_2.25.bb +++ b/meta/recipes-support/libcap/libcap_2.25.bb @@ -27,11 +27,8 @@ do_configure() { sed -e '/shell gperf/cifeq (,yes)' -i libcap/Makefile } -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'attr', '', d)}" PACKAGECONFIG_class-native ??= "" -PACKAGECONFIG[attr] = "LIBATTR=yes,LIBATTR=no,attr" - EXTRA_OEMAKE = " \ INDENT= \ lib=${@os.path.basename('${libdir}')} \ @@ -46,12 +43,11 @@ EXTRA_OEMAKE_append_class-target = " SYSTEM_HEADERS=${STAGING_INCDIR}" CFLAGS += "-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" do_compile() { - oe_runmake ${EXTRA_OECONF} + oe_runmake } do_install() { oe_runmake install \ - ${EXTRA_OECONF} \ DESTDIR="${D}" \ prefix="${prefix}" \ SBINDIR="${sbindir}" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2][PROPOSED] libcap fix and update
Need some experts to review this patch series. I am not really sure for if what I fixed is a valid case or if fix is the best answer. The validation before submission is very limited too. I ran into the compiling issue when build an application and found this recipe cannot be built without specifying anything. I don't feel the existing options are passed to make with test, and guess EXTRA_CONF won't work with this makefile-based project. The second patch is a following-up when I saw there is another option in the similar situation and seems to be obsolete now. Jianxun Zhang (2): libcap: fix compiling issue when not having libpam libcap: remove dependency on attr meta/recipes-support/libcap/libcap_2.25.bb | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2][PROPOSED] libcap: fix compiling issue when not having libpam
Select a genericx86-64 target and run bitbake libcap This error shows up: - pam_cap.c:19:34: fatal error: security/pam_modules.h: No such file or directory #include ^ compilation terminated. Makefile:23: recipe for target 'pam_cap.o' failed make[1]: *** [pam_cap.o] Error 1 - The option PAM_CAP=yes/no is not effectively passed to make. We change to EXTRA_OEMAKE, instead of EXTRA_OECONF which PACKAGECONFIG deals with, for this Makefile-based project. Signed-off-by: Jianxun Zhang --- Limited test is performed by building this recipe only. Refer to the cover letter before merge. meta/recipes-support/libcap/libcap_2.25.bb | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/meta/recipes-support/libcap/libcap_2.25.bb b/meta/recipes-support/libcap/libcap_2.25.bb index 8f3f11e..bc29310 100644 --- a/meta/recipes-support/libcap/libcap_2.25.bb +++ b/meta/recipes-support/libcap/libcap_2.25.bb @@ -5,7 +5,7 @@ HOMEPAGE = "http://sites.google.com/site/fullycapable/"; LICENSE = "BSD | GPLv2" LIC_FILES_CHKSUM = "file://License;md5=3f84fd6f29d453a56514cb7e4ead25f1" -DEPENDS = "hostperl-runtime-native" +DEPENDS = "hostperl-runtime-native ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}" SRC_URI = "${KERNELORG_MIRROR}/linux/libs/security/linux-privs/${BPN}2/${BPN}-${PV}.tar.xz \ file://0001-ensure-the-XATTR_NAME_CAPS-is-defined-when-it-is-use.patch \ @@ -27,18 +27,17 @@ do_configure() { sed -e '/shell gperf/cifeq (,yes)' -i libcap/Makefile } -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '', d)} \ - ${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'attr', '', d)}" +PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'attr', '', d)}" PACKAGECONFIG_class-native ??= "" PACKAGECONFIG[attr] = "LIBATTR=yes,LIBATTR=no,attr" -PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam" EXTRA_OEMAKE = " \ INDENT= \ lib=${@os.path.basename('${libdir}')} \ RAISE_SETFCAP=no \ DYNAMIC=yes \ + ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'PAM_CAP=yes', 'PAM_CAP=no', d)} \ " EXTRA_OEMAKE_append_class-target = " SYSTEM_HEADERS=${STAGING_INCDIR}" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel.bbclass: include signing keys when copying files required for module builds
Bruce, Ping~~~ Could you or anyone have a look on this patch? It is for https://bugzilla.yoctoproject.org/show_bug.cgi?id=9805 Thanks > On Aug 12, 2016, at 7:10 AM, Waldo Mattias > wrote: > > The absence of certs/signing_key.* in $kerneldir made signing of > out-of-tree kernel modules fail (silently). Add copying of these files > during the shared_workdir task. > > Signed-off-by: Mattias Waldo > --- > meta/classes/kernel.bbclass | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > index 6e3e81e..2bfd65c 100644 > --- a/meta/classes/kernel.bbclass > +++ b/meta/classes/kernel.bbclass > @@ -295,6 +295,8 @@ do_shared_workdir () { >cp .config $kerneldir/ >mkdir -p $kerneldir/include/config >cp include/config/kernel.release > $kerneldir/include/config/kernel.release > + mkdir -p $kerneldir/certs > + cp certs/signing_key.* $kerneldir/certs > ># We can also copy over all the generated files and avoid special cases ># like version.h, but we've opted to keep this small until file creep > starts > -- > 2.9.2 > > > > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] parselogs: Ignore uvesafb timeouts
> On Aug 19, 2016, at 8:29 AM, Richard Purdie > wrote: > > We're periodically seeing uvesafb timeouts on the autobuilder. Whitelist these > errors as there is little it seems we can do about them and we therefore > choose to ignore them rather than fail the builds. > > [YOCTO #8245] > > There is a better solution proposed in the bug with a -1 timeout however > this avoids failed builds until such times as that is implemented. I am working on the -1 timeout patch. It could take another several days for dev and validation in next week. Please just go ahead to merge this for any urgency. Refer to my inline clarification too. > > Signed-off-by: Richard Purdie > > diff --git a/meta/lib/oeqa/runtime/parselogs.py > b/meta/lib/oeqa/runtime/parselogs.py > index 1cfe804..777af57 100644 > --- a/meta/lib/oeqa/runtime/parselogs.py > +++ b/meta/lib/oeqa/runtime/parselogs.py > @@ -63,6 +63,9 @@ qemux86_common = [ > "fail to add MMCONFIG information, can't access extended PCI > configuration space under this bridge.", > "can't claim BAR ", > 'amd_nb: Cannot enumerate AMD northbridges', > +'uvesafb: 5000 ms task timeout error’, This line will be whitelisted even when the -1 timeout patch is in because we cannot fix bandwidth issue on AB server and still wanna keep this log visible as heads up. > +'detected fb_set_par error, error code: -22', > +'uvesafb: mode switch failed’\ These errors from callers should not be whitelisted with the -1 timeout patch. Once we have that patch merged, they are still valid errors to indicate a non-timeout root case, or that patch doesn’t do the expected job. The problem of whitelisting is we could miss other cases in call chains, or cover other root causes of a same error. This is another variant: [ 126.670550] uvesafb: 5000 ms task timeout error [ 126.673310] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) [ 126.673684] uvesafb: vbe_init() failed with -22 (bz8245 comment #23) You may want to add “Getting VBE..” lines in this patch too, just don’t be confused when seeing another new uncaught variant. > ] + common_errors > > ignore_errors = { > > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] REPLACEMENT: Gummiboot to Systemd-boot
Dear All, The gummiboot has been merged into systemd project and is “systemd-boot” now. The project at the location referred in recipes is obsoleted and not maintained any more. The systemd-boot provides same functionality of gummiboot from my understanding and test. Seeing no much benefit to keep gummiboot, we suggest to replace it with systemd-boot in OE. Please refer to the below list for a proposed plan and what’s done on systemd-boot so far. () Build systemd-boot without dependency on the rest of systemd (merged in OE master) () wic plugin & wks for systemd-boot (merged in OE master) () New test cases by QA (done) () New test target by QA (done) () Overall document update for the replacement (patch in bz9707, reviewed) () Propose the plan (this letter) () If you have any work derived from gummiboot like patches, scripts, recipes or bbclasses in your layers, you will have to migrate such work onto systemd-boot accordingly. If you find any features gummiboot supports but not available on systemd-boot yet, please let us know and we will re-evaluate the situation before taking the next step. () Purge all implementation around gummiboot in OE after, say, 30 days. All gummiboot functions are still available in this period until cleaning up starts. Feel free to suggest us another time line if you need. Change in documentation could happen prior to this step. To enable systemd-boot, use the same interface for gummiboot and other EFI bootloaders: EFI_PROVIDER = "systemd-boot" We appreciate help from groups (BSP dev, QA, documentation...) in this task. Any feedback is welcome. Thanks -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wic: rename and amend systemd-boot wks file
Rename wks for systemd-boot per the suggestion from community. Also amend description to distinguish it from others when running "wic list images". Signed-off-by: Jianxun Zhang --- .../wic/canned-wks/{mksystemd-bootdisk.wks => systemd-bootdisk.wks} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename scripts/lib/wic/canned-wks/{mksystemd-bootdisk.wks => systemd-bootdisk.wks} (77%) diff --git a/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks b/scripts/lib/wic/canned-wks/systemd-bootdisk.wks similarity index 77% rename from scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks rename to scripts/lib/wic/canned-wks/systemd-bootdisk.wks index df706e8..d80189b 100644 --- a/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks +++ b/scripts/lib/wic/canned-wks/systemd-bootdisk.wks @@ -1,6 +1,6 @@ -# short-description: Create an EFI disk image +# short-description: Create an EFI disk image with systemd-boot # long-description: Creates a partitioned EFI disk image that the user -# can directly dd to boot media. +# can directly dd to boot media. The selected bootloader is systemd-boot. part /boot --source bootimg-efi --sourceparams="loader=systemd-boot" --ondisk sda --label msdos --active --align 1024 -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] DO NOT MERGE [PATCHv2 2/2]: wic: clone gummiboot wks for systemd-boot
I just found V1 of this patch has been merged. I will rebase this V2 and re-submit it. Thanks > On Jul 19, 2016, at 12:04 PM, Jianxun Zhang > wrote: > > This wks is just a copy of gummiboot wks with bootloader > changed to systemd-boot. A very basic boot test on a X86 > target is done with a direct-boot image generated by: > > wic create systemd-bootdisk -e core-image-minimal > > Because we plan to replace gummiboot with systemd-boot at any > time in the future, we summarize history (as much as I can) of > the current gummiboot wks before it's gone: > > - > commit 7d4bb40905fab38fb3db1d0e17afbc803622f00c > Author: Ed Bartosh > Date: Wed Sep 2 13:58:02 2015 +0300 > >wic: get rid of scripts/lib/image > >Moved content of scripts/lib/image/ to scripts/lib/wic as >one directory with the same name as a tool is self-explanatory >and less confusing than two. > >(From OE-Core rev: 5dc02d572794298b3362378cea3d7da654456c44) > >Signed-off-by: Ed Bartosh >Signed-off-by: Richard Purdie > > commit 77561e719181d58289687373eebadce764f838a7 > Author: Ed Bartosh > Date: Wed Sep 2 13:58:01 2015 +0300 > >wic: use ext4 in canned .wks files > >Latest kernel doesn't have ext3 compiled in. Wic images produced >from canned .wks can't boot because of that. Switching to ext4 >fixes this issue. > >(From OE-Core rev: d281a65a81f369fc8d75023b8f911ce4106969c1) > >Signed-off-by: Ed Bartosh >Signed-off-by: Richard Purdie > > commit 072657ce98414afdd6f68941847e21fc5ce496c7 > Author: Tom Zanussi > Date: Mon Aug 11 20:35:41 2014 -0500 > >wic: Add mkgummidisk kickstart file > >This is the same as mkefidisk but uses gummiboot instead of grub-efi. > >(From OE-Core rev: 5979409ebfab0bb07b3c2b2fcf14a722c441f07b) > >Signed-off-by: Tom Zanussi >Signed-off-by: Richard Purdie > - > > Signed-off-by: Jianxun Zhang > --- > Just get a hand on this work. V2 addresses name of new wks from > V1 review. > > scripts/lib/wic/canned-wks/systemd-bootdisk.wks | 11 +++ > 1 file changed, 11 insertions(+) > create mode 100644 scripts/lib/wic/canned-wks/systemd-bootdisk.wks > > diff --git a/scripts/lib/wic/canned-wks/systemd-bootdisk.wks > b/scripts/lib/wic/canned-wks/systemd-bootdisk.wks > new file mode 100644 > index 000..d80189b > --- /dev/null > +++ b/scripts/lib/wic/canned-wks/systemd-bootdisk.wks > @@ -0,0 +1,11 @@ > +# short-description: Create an EFI disk image with systemd-boot > +# long-description: Creates a partitioned EFI disk image that the user > +# can directly dd to boot media. The selected bootloader is systemd-boot. > + > +part /boot --source bootimg-efi --sourceparams="loader=systemd-boot" > --ondisk sda --label msdos --active --align 1024 > + > +part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align > 1024 > + > +part swap --ondisk sda --size 44 --label swap1 --fstype=swap > + > +bootloader --timeout=10 --append="rootwait rootfstype=ext4 > console=ttyPCH0,115200 console=tty0 vmalloc=256MB snd-hda-intel.enable_msi=0" > -- > 2.7.4 > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] wic: clone gummiboot wks for systemd-boot
> On Jul 11, 2016, at 10:37 AM, Khem Raj wrote: > > On Mon, Jul 11, 2016 at 10:03 AM, Jianxun Zhang > wrote: >> >>> On Jul 8, 2016, at 1:58 PM, Khem Raj wrote: >>> >>> On Fri, Jul 8, 2016 at 10:44 AM, Jianxun Zhang >>> wrote: >>>> This wks is just a copy of gummiboot wks with bootloader >>>> changed to systemd-boot. A very basic boot test on a X86 >>>> target is done with a direct-boot image generated by: >>>> >>>> wic create mksystemd-bootdisk -e core-image-minimal >>> >>> prefixing wks file with mk is that a nomenclature. if no then lets avoid it >> Khem, >> I thought following gummiboot wks naming is a safe call. :-) >> I can change it to any new name suggested, just want to avoid any ambiguity >> for a V2: >> Do you and others think “systemd-bootdisk” is a good name for new wks? >> > > yes looks better > I have submitted V2 several days ago to address Khem’s suggestion to rename mksystemd-bootdisk.wks to systemd-boot.wks. But today I found this V1 has been merged in OE master (4c9b1a4). I am not sure if it means maintainers made decision to prefer V1. You could see both wks files for same thing once V2 gets merged too. Worrying about a duplicate merge for V2, I will notice people in V2 thread. Thanks > >> Thanks >>> >>>> >>>> Because we plan to replace gummiboot with systemd-boot at any >>>> time in the future, we summarize history (as much as I can) of >>>> the current gummiboot wks before it's gone: >>>> >>>> - >>>> commit 7d4bb40905fab38fb3db1d0e17afbc803622f00c >>>> Author: Ed Bartosh >>>> Date: Wed Sep 2 13:58:02 2015 +0300 >>>> >>>> wic: get rid of scripts/lib/image >>>> >>>> Moved content of scripts/lib/image/ to scripts/lib/wic as >>>> one directory with the same name as a tool is self-explanatory >>>> and less confusing than two. >>>> >>>> (From OE-Core rev: 5dc02d572794298b3362378cea3d7da654456c44) >>>> >>>> Signed-off-by: Ed Bartosh >>>> Signed-off-by: Richard Purdie >>>> >>>> commit 77561e719181d58289687373eebadce764f838a7 >>>> Author: Ed Bartosh >>>> Date: Wed Sep 2 13:58:01 2015 +0300 >>>> >>>> wic: use ext4 in canned .wks files >>>> >>>> Latest kernel doesn't have ext3 compiled in. Wic images produced >>>> from canned .wks can't boot because of that. Switching to ext4 >>>> fixes this issue. >>>> >>>> (From OE-Core rev: d281a65a81f369fc8d75023b8f911ce4106969c1) >>>> >>>> Signed-off-by: Ed Bartosh >>>> Signed-off-by: Richard Purdie >>>> >>>> commit 072657ce98414afdd6f68941847e21fc5ce496c7 >>>> Author: Tom Zanussi >>>> Date: Mon Aug 11 20:35:41 2014 -0500 >>>> >>>> wic: Add mkgummidisk kickstart file >>>> >>>> This is the same as mkefidisk but uses gummiboot instead of grub-efi. >>>> >>>> (From OE-Core rev: 5979409ebfab0bb07b3c2b2fcf14a722c441f07b) >>>> >>>> Signed-off-by: Tom Zanussi >>>> Signed-off-by: Richard Purdie >>>> - >>>> >>>> Signed-off-by: Jianxun Zhang >>>> --- >>>> scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks | 11 +++ >>>> 1 file changed, 11 insertions(+) >>>> create mode 100644 scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks >>>> >>>> diff --git a/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks >>>> b/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks >>>> new file mode 100644 >>>> index 000..df706e8 >>>> --- /dev/null >>>> +++ b/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks >>>> @@ -0,0 +1,11 @@ >>>> +# short-description: Create an EFI disk image >>>> +# long-description: Creates a partitioned EFI disk image that the user >>>> +# can directly dd to boot media. >>>> + >>>> +part /boot --source bootimg-efi --sourceparams="loader=systemd-boot" >>>> --ondisk sda --label msdos --active --align 1024 >>>> + >>>> +part / --source rootfs --ondisk sda --fstype=ext4 --label platform >>>> --align 1024 >>>> + >>>> +part swap --ondisk sda --size 44 --label swap1 --fstype=swap >>>> + >>>> +bootloader --timeout=10 --append="rootwait rootfstype=ext4 >>>> console=ttyPCH0,115200 console=tty0 vmalloc=256MB >>>> snd-hda-intel.enable_msi=0" >>>> -- >>>> 2.7.4 >>>> >>>> -- >>>> ___ >>>> Openembedded-core mailing list >>>> Openembedded-core@lists.openembedded.org >>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2 2/2] wic: clone gummiboot wks for systemd-boot
This wks is just a copy of gummiboot wks with bootloader changed to systemd-boot. A very basic boot test on a X86 target is done with a direct-boot image generated by: wic create systemd-bootdisk -e core-image-minimal Because we plan to replace gummiboot with systemd-boot at any time in the future, we summarize history (as much as I can) of the current gummiboot wks before it's gone: - commit 7d4bb40905fab38fb3db1d0e17afbc803622f00c Author: Ed Bartosh Date: Wed Sep 2 13:58:02 2015 +0300 wic: get rid of scripts/lib/image Moved content of scripts/lib/image/ to scripts/lib/wic as one directory with the same name as a tool is self-explanatory and less confusing than two. (From OE-Core rev: 5dc02d572794298b3362378cea3d7da654456c44) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie commit 77561e719181d58289687373eebadce764f838a7 Author: Ed Bartosh Date: Wed Sep 2 13:58:01 2015 +0300 wic: use ext4 in canned .wks files Latest kernel doesn't have ext3 compiled in. Wic images produced from canned .wks can't boot because of that. Switching to ext4 fixes this issue. (From OE-Core rev: d281a65a81f369fc8d75023b8f911ce4106969c1) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie commit 072657ce98414afdd6f68941847e21fc5ce496c7 Author: Tom Zanussi Date: Mon Aug 11 20:35:41 2014 -0500 wic: Add mkgummidisk kickstart file This is the same as mkefidisk but uses gummiboot instead of grub-efi. (From OE-Core rev: 5979409ebfab0bb07b3c2b2fcf14a722c441f07b) Signed-off-by: Tom Zanussi Signed-off-by: Richard Purdie - Signed-off-by: Jianxun Zhang --- Just get a hand on this work. V2 addresses name of new wks from V1 review. scripts/lib/wic/canned-wks/systemd-bootdisk.wks | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 scripts/lib/wic/canned-wks/systemd-bootdisk.wks diff --git a/scripts/lib/wic/canned-wks/systemd-bootdisk.wks b/scripts/lib/wic/canned-wks/systemd-bootdisk.wks new file mode 100644 index 000..d80189b --- /dev/null +++ b/scripts/lib/wic/canned-wks/systemd-bootdisk.wks @@ -0,0 +1,11 @@ +# short-description: Create an EFI disk image with systemd-boot +# long-description: Creates a partitioned EFI disk image that the user +# can directly dd to boot media. The selected bootloader is systemd-boot. + +part /boot --source bootimg-efi --sourceparams="loader=systemd-boot" --ondisk sda --label msdos --active --align 1024 + +part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align 1024 + +part swap --ondisk sda --size 44 --label swap1 --fstype=swap + +bootloader --timeout=10 --append="rootwait rootfstype=ext4 console=ttyPCH0,115200 console=tty0 vmalloc=256MB snd-hda-intel.enable_msi=0" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2 1/2] wic: add systemd-boot option in EFI boot image plugin
The new systemd-boot enabled in OE is the old gummiboot merged into systemd project. Our intention is to replace gummiboot with systemd-boot in OE once every feature based on gummiboot is supported with systemd-boot. Before we can purge gummiboot, we temporarily keep both of the two bootloaders supported. Patch doesn't do replacement for every "gummi" occurrence. We think cleaning can be done in background after we disable people to use gummiboot, so we just keep change small and safe this time. Signed-off-by: Jianxun Zhang --- scripts/lib/wic/plugins/source/bootimg-efi.py | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py b/scripts/lib/wic/plugins/source/bootimg-efi.py index 3a16861..8bc3622 100644 --- a/scripts/lib/wic/plugins/source/bootimg-efi.py +++ b/scripts/lib/wic/plugins/source/bootimg-efi.py @@ -84,7 +84,7 @@ class BootimgEFIPlugin(SourcePlugin): @classmethod def do_configure_gummiboot(cls, hdddir, creator, cr_workdir): """ -Create loader-specific (gummiboot) config +Create loader-specific systemd-boot/gummiboot config """ install_cmd = "install -d %s/loader" % hdddir exec_cmd(install_cmd) @@ -149,7 +149,8 @@ class BootimgEFIPlugin(SourcePlugin): try: if source_params['loader'] == 'grub-efi': cls.do_configure_grubefi(hdddir, creator, cr_workdir) -elif source_params['loader'] == 'gummiboot': +elif source_params['loader'] == 'gummiboot' \ + or source_params['loader'] == 'systemd-boot': cls.do_configure_gummiboot(hdddir, creator, cr_workdir) else: msger.error("unrecognized bootimg-efi loader: %s" % source_params['loader']) @@ -189,7 +190,8 @@ class BootimgEFIPlugin(SourcePlugin): exec_cmd(cp_cmd, True) shutil.move("%s/grub.cfg" % cr_workdir, "%s/hdd/boot/EFI/BOOT/grub.cfg" % cr_workdir) -elif source_params['loader'] == 'gummiboot': +elif source_params['loader'] == 'gummiboot' \ + or source_params['loader'] == 'systemd-boot': cp_cmd = "cp %s/EFI/BOOT/* %s/EFI/BOOT" % (bootimg_dir, hdddir) exec_cmd(cp_cmd, True) else: -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] wic: clone gummiboot wks for systemd-boot
> On Jul 8, 2016, at 1:58 PM, Khem Raj wrote: > > On Fri, Jul 8, 2016 at 10:44 AM, Jianxun Zhang > wrote: >> This wks is just a copy of gummiboot wks with bootloader >> changed to systemd-boot. A very basic boot test on a X86 >> target is done with a direct-boot image generated by: >> >> wic create mksystemd-bootdisk -e core-image-minimal > > prefixing wks file with mk is that a nomenclature. if no then lets avoid it Khem, I thought following gummiboot wks naming is a safe call. :-) I can change it to any new name suggested, just want to avoid any ambiguity for a V2: Do you and others think “systemd-bootdisk” is a good name for new wks? Thanks > >> >> Because we plan to replace gummiboot with systemd-boot at any >> time in the future, we summarize history (as much as I can) of >> the current gummiboot wks before it's gone: >> >> - >> commit 7d4bb40905fab38fb3db1d0e17afbc803622f00c >> Author: Ed Bartosh >> Date: Wed Sep 2 13:58:02 2015 +0300 >> >>wic: get rid of scripts/lib/image >> >>Moved content of scripts/lib/image/ to scripts/lib/wic as >>one directory with the same name as a tool is self-explanatory >>and less confusing than two. >> >>(From OE-Core rev: 5dc02d572794298b3362378cea3d7da654456c44) >> >>Signed-off-by: Ed Bartosh >>Signed-off-by: Richard Purdie >> >> commit 77561e719181d58289687373eebadce764f838a7 >> Author: Ed Bartosh >> Date: Wed Sep 2 13:58:01 2015 +0300 >> >>wic: use ext4 in canned .wks files >> >>Latest kernel doesn't have ext3 compiled in. Wic images produced >>from canned .wks can't boot because of that. Switching to ext4 >>fixes this issue. >> >>(From OE-Core rev: d281a65a81f369fc8d75023b8f911ce4106969c1) >> >>Signed-off-by: Ed Bartosh >>Signed-off-by: Richard Purdie >> >> commit 072657ce98414afdd6f68941847e21fc5ce496c7 >> Author: Tom Zanussi >> Date: Mon Aug 11 20:35:41 2014 -0500 >> >>wic: Add mkgummidisk kickstart file >> >>This is the same as mkefidisk but uses gummiboot instead of grub-efi. >> >>(From OE-Core rev: 5979409ebfab0bb07b3c2b2fcf14a722c441f07b) >> >>Signed-off-by: Tom Zanussi >>Signed-off-by: Richard Purdie >> - >> >> Signed-off-by: Jianxun Zhang >> --- >> scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks | 11 +++ >> 1 file changed, 11 insertions(+) >> create mode 100644 scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks >> >> diff --git a/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks >> b/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks >> new file mode 100644 >> index 000..df706e8 >> --- /dev/null >> +++ b/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks >> @@ -0,0 +1,11 @@ >> +# short-description: Create an EFI disk image >> +# long-description: Creates a partitioned EFI disk image that the user >> +# can directly dd to boot media. >> + >> +part /boot --source bootimg-efi --sourceparams="loader=systemd-boot" >> --ondisk sda --label msdos --active --align 1024 >> + >> +part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align >> 1024 >> + >> +part swap --ondisk sda --size 44 --label swap1 --fstype=swap >> + >> +bootloader --timeout=10 --append="rootwait rootfstype=ext4 >> console=ttyPCH0,115200 console=tty0 vmalloc=256MB snd-hda-intel.enable_msi=0" >> -- >> 2.7.4 >> >> -- >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] wic: add systemd-boot option in EFI boot image plugin
The new systemd-boot enabled in OE is the old gummiboot merged into systemd project. Our intention is to replace gummiboot with systemd-boot in OE once every feature based on gummiboot is supported with systemd-boot. Before we can purge gummiboot, we temporarily keep both of the two bootloaders supported. Patch doesn't do replacement for every "gummi" occurrence. We think cleaning can be done in background after we disable people to use gummiboot, so we just keep change small and safe this time. Signed-off-by: Jianxun Zhang --- scripts/lib/wic/plugins/source/bootimg-efi.py | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py b/scripts/lib/wic/plugins/source/bootimg-efi.py index 3a16861..8bc3622 100644 --- a/scripts/lib/wic/plugins/source/bootimg-efi.py +++ b/scripts/lib/wic/plugins/source/bootimg-efi.py @@ -84,7 +84,7 @@ class BootimgEFIPlugin(SourcePlugin): @classmethod def do_configure_gummiboot(cls, hdddir, creator, cr_workdir): """ -Create loader-specific (gummiboot) config +Create loader-specific systemd-boot/gummiboot config """ install_cmd = "install -d %s/loader" % hdddir exec_cmd(install_cmd) @@ -149,7 +149,8 @@ class BootimgEFIPlugin(SourcePlugin): try: if source_params['loader'] == 'grub-efi': cls.do_configure_grubefi(hdddir, creator, cr_workdir) -elif source_params['loader'] == 'gummiboot': +elif source_params['loader'] == 'gummiboot' \ + or source_params['loader'] == 'systemd-boot': cls.do_configure_gummiboot(hdddir, creator, cr_workdir) else: msger.error("unrecognized bootimg-efi loader: %s" % source_params['loader']) @@ -189,7 +190,8 @@ class BootimgEFIPlugin(SourcePlugin): exec_cmd(cp_cmd, True) shutil.move("%s/grub.cfg" % cr_workdir, "%s/hdd/boot/EFI/BOOT/grub.cfg" % cr_workdir) -elif source_params['loader'] == 'gummiboot': +elif source_params['loader'] == 'gummiboot' \ + or source_params['loader'] == 'systemd-boot': cp_cmd = "cp %s/EFI/BOOT/* %s/EFI/BOOT" % (bootimg_dir, hdddir) exec_cmd(cp_cmd, True) else: -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] wic: clone gummiboot wks for systemd-boot
This wks is just a copy of gummiboot wks with bootloader changed to systemd-boot. A very basic boot test on a X86 target is done with a direct-boot image generated by: wic create mksystemd-bootdisk -e core-image-minimal Because we plan to replace gummiboot with systemd-boot at any time in the future, we summarize history (as much as I can) of the current gummiboot wks before it's gone: - commit 7d4bb40905fab38fb3db1d0e17afbc803622f00c Author: Ed Bartosh Date: Wed Sep 2 13:58:02 2015 +0300 wic: get rid of scripts/lib/image Moved content of scripts/lib/image/ to scripts/lib/wic as one directory with the same name as a tool is self-explanatory and less confusing than two. (From OE-Core rev: 5dc02d572794298b3362378cea3d7da654456c44) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie commit 77561e719181d58289687373eebadce764f838a7 Author: Ed Bartosh Date: Wed Sep 2 13:58:01 2015 +0300 wic: use ext4 in canned .wks files Latest kernel doesn't have ext3 compiled in. Wic images produced from canned .wks can't boot because of that. Switching to ext4 fixes this issue. (From OE-Core rev: d281a65a81f369fc8d75023b8f911ce4106969c1) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie commit 072657ce98414afdd6f68941847e21fc5ce496c7 Author: Tom Zanussi Date: Mon Aug 11 20:35:41 2014 -0500 wic: Add mkgummidisk kickstart file This is the same as mkefidisk but uses gummiboot instead of grub-efi. (From OE-Core rev: 5979409ebfab0bb07b3c2b2fcf14a722c441f07b) Signed-off-by: Tom Zanussi Signed-off-by: Richard Purdie - Signed-off-by: Jianxun Zhang --- scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks diff --git a/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks b/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks new file mode 100644 index 000..df706e8 --- /dev/null +++ b/scripts/lib/wic/canned-wks/mksystemd-bootdisk.wks @@ -0,0 +1,11 @@ +# short-description: Create an EFI disk image +# long-description: Creates a partitioned EFI disk image that the user +# can directly dd to boot media. + +part /boot --source bootimg-efi --sourceparams="loader=systemd-boot" --ondisk sda --label msdos --active --align 1024 + +part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align 1024 + +part swap --ondisk sda --size 44 --label swap1 --fstype=swap + +bootloader --timeout=10 --append="rootwait rootfstype=ext4 console=ttyPCH0,115200 console=tty0 vmalloc=256MB snd-hda-intel.enable_msi=0" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd-boot: Set COMPATIBLE_HOST in recipe
We apply the same setting in the existing gummiboot to COMPATIBLE_HOST, so that it properly stops build for unsupported architectures. Signed-off-by: Jianxun Zhang --- meta/recipes-bsp/systemd-boot/systemd-boot.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-bsp/systemd-boot/systemd-boot.bb b/meta/recipes-bsp/systemd-boot/systemd-boot.bb index 87e9871..0dc0fa3 100644 --- a/meta/recipes-bsp/systemd-boot/systemd-boot.bb +++ b/meta/recipes-bsp/systemd-boot/systemd-boot.bb @@ -14,6 +14,7 @@ EXTRA_OECONF = " --enable-gnuefi \ # Imported from gummiboot recipe TUNE_CCARGS_remove = "-mfpmath=sse" +COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux" do_compile() { SYSTEMD_BOOT_EFI_ARCH="ia32" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world 2016-06-07
> On Jun 9, 2016, at 12:03 AM, Martin Jansa wrote: > > This report includes python3 changes, there are few more failures, but > it's hard to see what is new, so I've sent couple PNBLACKLISTs for > recipes reported in previous 2 reports which are still failing with > glibc-2.24 and gcc-6. Hopefully next report will show only "new" issues > caused by python3 switch. > > == Number of issues - stats == > {| class='wikitable' > !|Date !!colspan='3'|Failed tasks > !!colspan='6'|Failed depencencies!!|Signatures > !!colspan='12'|QA !!Comment > |- > ||||qemuarm ||qemux86 ||qemux86_64 > ||qemuarm||max||min ||qemux86||max||min ||all ||already-stripped > ||libdir||textrel ||build-deps||file-rdeps > ||version-going-backwards ||host-user-contaminated > ||installed-vs-shipped ||unknown-configure-option ||symlink-to-sysroot > ||invalid-pkgconfig ||pkgname || > |- > ||2016-06-07 ||34||40||39||84||38||37||92||42 > ||41||0 ||0 ||0 ||1 ||3 > ||18||0 ||0 ||0 ||0 > ||0 ||0 ||0 || > |} > > http://www.openembedded.org/wiki/Bitbake_World_Status > > == Failed tasks 2016-06-07 == > > INFO: jenkins-job.sh-1.8.10 Complete log available at > http://logs.nslu2-linux.org/buildlogs/oe/world/log.report.20160608_203844.log > > === common (31) === >* meta-browser/recipes-mozilla/firefox/firefox_38.7.1esr.bb, do_compile >* > meta-openembedded/meta-gnome/recipes-gnome/gnome/gnome-terminal_2.30.2.bb, > do_compile >* > meta-openembedded/meta-gnome/recipes-gnome/gnome-session/gnome-session_2.32.1.bb, > do_compile >* > meta-openembedded/meta-gnome/recipes-gnome/gtksourceview/gtksourceview2_2.10.5.bb, > do_compile >* > meta-openembedded/meta-gnome/recipes-gnome/gweather/libgweather_2.30.3.bb, > do_compile >* > meta-openembedded/meta-gnome/recipes-gnome/libgnome/libgnomeui_2.24.3.bb, > do_compile >* meta-openembedded/meta-gnome/recipes-gnome/pimlico/tasks_0.19.bb, > do_compile >* meta-openembedded/meta-gnome/recipes-support/goffice/goffice_0.10.1.bb, > do_compile >* meta-openembedded/meta-gpe/recipes-support/fbreader/fbreader_0.12.10.bb, > do_compile >* > meta-openembedded/meta-multimedia/recipes-dvb/tvheadend/tvheadend_git.bb, > do_compile >* > meta-openembedded/meta-networking/recipes-connectivity/crda/crda_3.18.bb, > do_compile >* > meta-openembedded/meta-networking/recipes-connectivity/lftp/lftp_4.6.3a.bb, > do_compile >* > meta-openembedded/meta-networking/recipes-support/curlpp/curlpp_0.7.3.bb, > do_compile >* meta-openembedded/meta-oe/recipes-benchmark/glmark2/glmark2_git.bb, > do_configure >* meta-openembedded/meta-oe/recipes-connectivity/libqmi/libqmi_1.12.6.bb, > do_compile >* meta-openembedded/meta-oe/recipes-connectivity/thrift/thrift_0.9.3.bb, > do_compile >* > meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvstreams_4.6.1.bb, > do_compile >* meta-openembedded/meta-oe/recipes-extended/collectd/collectd_5.5.0.bb, > do_compile >* > meta-openembedded/meta-oe/recipes-extended/mml-widget/gtkmathview_0.8.0.bb, > do_compile >* meta-openembedded/meta-oe/recipes-extended/tcsh/tcsh_6.18.01.bb, > do_compile >* > meta-openembedded/meta-oe/recipes-graphics/glcompbench/glcompbench_2012.08.bb, > do_configure >* meta-openembedded/meta-oe/recipes-navigation/geos/geos_3.4.2.bb, > do_compile >* > meta-openembedded/meta-oe/recipes-support/canonical-multitouch/grail_3.1.0.bb, > do_compile >* meta-openembedded/meta-oe/recipes-support/libjs/libjs-jquery_1.7.2.bb, > do_unpack >* meta-openembedded/meta-oe/recipes-support/opencv/opencv_3.1.bb, > do_compile >* meta-openembedded/meta-oe/recipes-support/openwbem/openwbem_3.2.3.bb, > do_compile >* > meta-openembedded/meta-oe/recipes-support/postgresql/postgresql_9.4.5.bb, > do_configure >* meta-openembedded/meta-oe/recipes-test/fwts/fwts_git.bb, do_compile >* meta-openembedded/meta-ruby/recipes-devtools/ruby/bundler_git.bb, > do_fetch >* > meta-smartphone/meta-fso/recipes-freesmartphone/freesmartphone/libframeworkd-glib_git.bb, > do_compile >* meta-webos-ports/meta-luneui/recipes-webos/librolegen/librolegen.bb, > do_compile > > === common-x86 (8) === >* meta-browser/recipes-browser/chromium/cef3_280796.bb, do_compile >* meta-browser/recipes-browser/chromium/chromium_48.0.2548.0.bb, do_compile >* meta-openembedded/meta-gnome/recipes-gnome/evince/evince_3.18.2.bb, > do_compile >* meta-openembedded/meta-multimedia/recipes-multimedia/faac/faac_1.28.bb, > do_compile >* meta-openembedded/meta-oe/recipes-benchmark/iperf/iperf_2.0.5.bb, > do_compile >
Re: [OE-core] [PATCH] systemd: support systemd-boot as a stand-alone EFI bootloader
On 05/26/2016 04:25 PM, Saul Wold wrote: On Thu, 2016-05-05 at 11:20 -0700, Jianxun Zhang wrote: The "systemd-boot" is gummiboot now included into systemd project. The old gummiboot project supported in OE is dead. Our intention is to get a gummiboot-like EFI bootloader without much dependency on systemd and its features. This work is largely derived from the existing bbclass and recipes of gummiboot and systemd. (commit tip: ee25d0e3987d7732a2e46e1640693b4cf419a9fc) Please refer to the history up to the tip for authorship and credit information for the original works. To enable the systemd-boot in build, add this line EFI_PROVIDER = "systemd-boot" in your machine conf file. Signed-off-by: Jianxun Zhang Review-by: Saul Wold Tested-by: Saul Wold Saul, I appreciate your review and test! Could any maintainer or reviewer provide some feedback? --- meta/classes/systemd-boot.bbclass | 124 ++ meta/recipes-bsp/systemd-boot/systemd-boot.bb | 35 meta/recipes-core/systemd/systemd.inc | 25 ++ meta/recipes-core/systemd/systemd_229.bb | 26 +- 4 files changed, 186 insertions(+), 24 deletions(-) create mode 100644 meta/classes/systemd-boot.bbclass create mode 100644 meta/recipes-bsp/systemd-boot/systemd-boot.bb create mode 100644 meta/recipes-core/systemd/systemd.inc diff --git a/meta/classes/systemd-boot.bbclass b/meta/classes/systemd-boot.bbclass new file mode 100644 index 000..9e9398a --- /dev/null +++ b/meta/classes/systemd-boot.bbclass @@ -0,0 +1,124 @@ +# Copyright (C) 2016 Intel Corporation +# +# Released under the MIT license (see COPYING.MIT) + +# systemd-boot.bbclass - The "systemd-boot" is essentially the gummiboot merged into systemd. +#The original standalone gummiboot project is dead without any more +#maintenance. As a start point, we replace all gummitboot occurrences +#with systemd-boot in gummiboot.bbclass to have a base version of this +#systemd-boot.bbclass. +# +# Set EFI_PROVIDER = "systemd-boot" to use systemd-boot on your live images instead of grub-efi +# (images built by image-live.bbclass or image-vm.bbclass) + +do_bootimg[depends] += "${MLPREFIX}systemd-boot:do_deploy" +do_bootdirectdisk[depends] += "${MLPREFIX}systemd-boot:do_deploy" + +EFIDIR = "/EFI/BOOT" + +SYSTEMD_BOOT_CFG ?= "${S}/loader.conf" +SYSTEMD_BOOT_ENTRIES ?= "" +SYSTEMD_BOOT_TIMEOUT ?= "10" + +# Need UUID utility code. +inherit fs-uuid + +efi_populate() { +DEST=$1 + +EFI_IMAGE="systemd-bootia32.efi" +DEST_EFI_IMAGE="bootia32.efi" +if [ "${TARGET_ARCH}" = "x86_64" ]; then +EFI_IMAGE="systemd-bootx64.efi" +DEST_EFI_IMAGE="bootx64.efi" +fi + +install -d ${DEST}${EFIDIR} +# systemd-boot requires these paths for configuration files +# they are not customizable so no point in new vars +install -d ${DEST}/loader +install -d ${DEST}/loader/entries +install -m 0644 ${DEPLOY_DIR_IMAGE}/${EFI_IMAGE} ${DEST}${EFIDIR}/${DEST_EFI_IMAGE} +install -m 0644 ${SYSTEMD_BOOT_CFG} ${DEST}/loader/loader.conf +for i in ${SYSTEMD_BOOT_ENTRIES}; do +install -m 0644 ${i} ${DEST}/loader/entries +done +} + +efi_iso_populate() { +iso_dir=$1 +efi_populate $iso_dir +mkdir -p ${EFIIMGDIR}/${EFIDIR} +cp $iso_dir/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR} +cp $iso_dir/vmlinuz ${EFIIMGDIR} +EFIPATH=$(echo "${EFIDIR}" | sed 's/\//\\/g') +echo "fs0:${EFIPATH}\\${DEST_EFI_IMAGE}" > ${EFIIMGDIR}/startup.nsh +if [ -f "$iso_dir/initrd" ] ; then +cp $iso_dir/initrd ${EFIIMGDIR} +fi +} + +efi_hddimg_populate() { +efi_populate $1 +} + +python build_efi_cfg() { +s = d.getVar("S", True) +labels = d.getVar('LABELS', True) +if not labels: +bb.debug(1, "LABELS not defined, nothing to do") +return + +if labels == []: +bb.debug(1, "No labels, nothing to do") +return + +cfile = d.getVar('SYSTEMD_BOOT_CFG', True) +try: + cfgfile = open(cfile, 'w') +except OSError: +raise bb.build.funcFailed('Unable to open %s' % (cfile)) + +cfgfile.write('# Automatically created by OE\n') +cfgfile.write('default %s\n' % (labels.split()[0])) +timeout = d.getVar('SYSTEMD_BOOT_TIMEOUT', True) +if timeout: +cfgfile.write('timeout %s\n' % timeout) +else: +cfgfile.write('timeout 10\n') +cfgfile.close() + +for label in labels.split(): +
[OE-core] [PATCH] systemd: support systemd-boot as a stand-alone EFI bootloader
Dear maintainers, This change is the primary step to enable EFI bootloader in systemd project. It is actually the gummiboot which has been included in systemd project. The gummiboot referred in OE recipes is dead. The intention is to enable it as a stand-alone bootloader without bothering too much of the existing systemd. Usage is same as other supported EFI bootloaders. Considering there are many bits working with systemd in Yocto and we cannot cover every corner in test prior to this submission, I suggest you have a close look on the patch before merging it. If no regerssion or significant bugs show in field, we will provide patches to replace gummiboot with systemd-boot by: () Add new oetest for systemd-boot () Update documents for replacement () Purge gummiboot in OE (may provide a dev-friendly message in gummiboot stuff as a reminder in build) Thanks Jianxun Zhang (1): systemd: support systemd-boot as a stand-alone EFI bootloader meta/classes/systemd-boot.bbclass | 124 ++ meta/recipes-bsp/systemd-boot/systemd-boot.bb | 35 meta/recipes-core/systemd/systemd.inc | 25 ++ meta/recipes-core/systemd/systemd_229.bb | 26 +- 4 files changed, 186 insertions(+), 24 deletions(-) create mode 100644 meta/classes/systemd-boot.bbclass create mode 100644 meta/recipes-bsp/systemd-boot/systemd-boot.bb create mode 100644 meta/recipes-core/systemd/systemd.inc -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd: support systemd-boot as a stand-alone EFI bootloader
The "systemd-boot" is gummiboot now included into systemd project. The old gummiboot project supported in OE is dead. Our intention is to get a gummiboot-like EFI bootloader without much dependency on systemd and its features. This work is largely derived from the existing bbclass and recipes of gummiboot and systemd. (commit tip: ee25d0e3987d7732a2e46e1640693b4cf419a9fc) Please refer to the history up to the tip for authorship and credit information for the original works. To enable the systemd-boot in build, add this line EFI_PROVIDER = "systemd-boot" in your machine conf file. Signed-off-by: Jianxun Zhang --- meta/classes/systemd-boot.bbclass | 124 ++ meta/recipes-bsp/systemd-boot/systemd-boot.bb | 35 meta/recipes-core/systemd/systemd.inc | 25 ++ meta/recipes-core/systemd/systemd_229.bb | 26 +- 4 files changed, 186 insertions(+), 24 deletions(-) create mode 100644 meta/classes/systemd-boot.bbclass create mode 100644 meta/recipes-bsp/systemd-boot/systemd-boot.bb create mode 100644 meta/recipes-core/systemd/systemd.inc diff --git a/meta/classes/systemd-boot.bbclass b/meta/classes/systemd-boot.bbclass new file mode 100644 index 000..9e9398a --- /dev/null +++ b/meta/classes/systemd-boot.bbclass @@ -0,0 +1,124 @@ +# Copyright (C) 2016 Intel Corporation +# +# Released under the MIT license (see COPYING.MIT) + +# systemd-boot.bbclass - The "systemd-boot" is essentially the gummiboot merged into systemd. +#The original standalone gummiboot project is dead without any more +#maintenance. As a start point, we replace all gummitboot occurrences +#with systemd-boot in gummiboot.bbclass to have a base version of this +#systemd-boot.bbclass. +# +# Set EFI_PROVIDER = "systemd-boot" to use systemd-boot on your live images instead of grub-efi +# (images built by image-live.bbclass or image-vm.bbclass) + +do_bootimg[depends] += "${MLPREFIX}systemd-boot:do_deploy" +do_bootdirectdisk[depends] += "${MLPREFIX}systemd-boot:do_deploy" + +EFIDIR = "/EFI/BOOT" + +SYSTEMD_BOOT_CFG ?= "${S}/loader.conf" +SYSTEMD_BOOT_ENTRIES ?= "" +SYSTEMD_BOOT_TIMEOUT ?= "10" + +# Need UUID utility code. +inherit fs-uuid + +efi_populate() { +DEST=$1 + +EFI_IMAGE="systemd-bootia32.efi" +DEST_EFI_IMAGE="bootia32.efi" +if [ "${TARGET_ARCH}" = "x86_64" ]; then +EFI_IMAGE="systemd-bootx64.efi" +DEST_EFI_IMAGE="bootx64.efi" +fi + +install -d ${DEST}${EFIDIR} +# systemd-boot requires these paths for configuration files +# they are not customizable so no point in new vars +install -d ${DEST}/loader +install -d ${DEST}/loader/entries +install -m 0644 ${DEPLOY_DIR_IMAGE}/${EFI_IMAGE} ${DEST}${EFIDIR}/${DEST_EFI_IMAGE} +install -m 0644 ${SYSTEMD_BOOT_CFG} ${DEST}/loader/loader.conf +for i in ${SYSTEMD_BOOT_ENTRIES}; do +install -m 0644 ${i} ${DEST}/loader/entries +done +} + +efi_iso_populate() { +iso_dir=$1 +efi_populate $iso_dir +mkdir -p ${EFIIMGDIR}/${EFIDIR} +cp $iso_dir/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR} +cp $iso_dir/vmlinuz ${EFIIMGDIR} +EFIPATH=$(echo "${EFIDIR}" | sed 's/\//\\/g') +echo "fs0:${EFIPATH}\\${DEST_EFI_IMAGE}" > ${EFIIMGDIR}/startup.nsh +if [ -f "$iso_dir/initrd" ] ; then +cp $iso_dir/initrd ${EFIIMGDIR} +fi +} + +efi_hddimg_populate() { +efi_populate $1 +} + +python build_efi_cfg() { +s = d.getVar("S", True) +labels = d.getVar('LABELS', True) +if not labels: +bb.debug(1, "LABELS not defined, nothing to do") +return + +if labels == []: +bb.debug(1, "No labels, nothing to do") +return + +cfile = d.getVar('SYSTEMD_BOOT_CFG', True) +try: + cfgfile = open(cfile, 'w') +except OSError: +raise bb.build.funcFailed('Unable to open %s' % (cfile)) + +cfgfile.write('# Automatically created by OE\n') +cfgfile.write('default %s\n' % (labels.split()[0])) +timeout = d.getVar('SYSTEMD_BOOT_TIMEOUT', True) +if timeout: +cfgfile.write('timeout %s\n' % timeout) +else: +cfgfile.write('timeout 10\n') +cfgfile.close() + +for label in labels.split(): +localdata = d.createCopy() + +overrides = localdata.getVar('OVERRIDES', True) +if not overrides: +raise bb.build.FuncFailed('OVERRIDES not defined') + +entryfile = "
[OE-core] openssl parallel make error (again)?
One of my builds hit parallel make error in openssl today. After some search, I guess it could be an old issue and see parallel make has been toggling several times around this problem in openssl recipe in the history. Is anyone or auto-builder seeing same issue recently? | ../../libcrypto.so: file not recognized: File truncated | collect2: error: ld returned 1 exit status | make[3]: *** [link_o.gnu] Error 1 BTW, my build is based on poky master and meta-intel master. MACHINE is intel-corei7-64, though I don't think BSP layer is related... Thanks -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Backport Request: kernel-yocto: fix checkout bare-cloned kernel repositories
Please help to bring this patch to Jethro branch: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4487e3a4205188cf53930147c7e88d98f0d8a8e0 This fix was from updating kernel labs for Jethro and we think it should be a good one on Jethro. Thanks lot! -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Backport Request: meta-yocto-bsp: Remove uvesafb (v86d) from generic x86 features
Please Jethro branch owner help to backport this patch to jethro branch: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=6af89812e8a9931ffed63768ed85367519bf7aef This request is for bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=8987 Thanks lot! -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] Explicitly mapping between i386/x86_64 and x86 for kernel ARCH
For a bare-bone kernel recipe which specifies 32 bit x86 target, a 64 bit .config will be generated from do_configure task when building 32-bit qemux86, once all of these conditions are true: () arch of host is x86_64 () kernel source tree used in build has commit ffee0de41 which actually chooses i386 or x86_64 defconfig by asking host when ARCH is "x86" (arch/x86/Makefile) () bare-bone kernel recipe inherits directly from kernel without other special treatments. Build will fail because of the mismatched kernel architecture. The patch sets ARCH i386 or x86_64 explicitly to configure task to avoid this host contamination. Kernel artifact is also changed so that it can map i386 and x64 back to arch/x86 when needed. Signed-off-by: Jianxun Zhang --- The old V1 broke lttng-modules building in the last submission. This V2 updates kernel artifact to fix it. Considering there are multiple references of ARCH in poky, a better test coverage is suggested before merging it to mainline, even I have done some build tests prior to submission. meta/classes/kernel-arch.bbclass | 4 +++- meta/classes/kernel.bbclass | 15 --- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass index 3ed5986..d8b180e 100644 --- a/meta/classes/kernel-arch.bbclass +++ b/meta/classes/kernel-arch.bbclass @@ -21,7 +21,9 @@ def map_kernel_arch(a, d): valid_archs = d.getVar('valid_archs', True).split() -if re.match('(i.86|athlon|x86.64)$', a): return 'x86' +if re.match('i.86$', a): return 'i386' +elif re.match('x86.64$', a):return 'x86_64' +elif re.match('athlon$', a):return 'x86' elif re.match('armeb$', a): return 'arm' elif re.match('aarch64$', a): return 'arm64' elif re.match('aarch64_be$', a):return 'arm64' diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 997376d..5c3287b 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -317,9 +317,18 @@ do_shared_workdir () { cp -fR include/generated/* $kerneldir/include/generated/ fi - if [ -d arch/${ARCH}/include/generated ]; then - mkdir -p $kerneldir/arch/${ARCH}/include/generated/ - cp -fR arch/${ARCH}/include/generated/* $kerneldir/arch/${ARCH}/include/generated/ + # When ARCH is set to i386 or x86_64, we need to map ARCH to the real name of src + # dir (x86) under arch/ of kenrel tree, so that we can find correct source to copy. + + if [ "${ARCH}" = "i386" ] || [ "${ARCH}" = "x86_64" ]; then + KERNEL_SRCARCH=x86 + else + KERNEL_SRCARCH=${ARCH} + fi + + if [ -d arch/${KERNEL_SRCARCH}/include/generated ]; then + mkdir -p $kerneldir/arch/${KERNEL_SRCARCH}/include/generated/ + cp -fR arch/${KERNEL_SRCARCH}/include/generated/* $kerneldir/arch/${KERNEL_SRCARCH}/include/generated/ fi } -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Explicitly map ARCH to 32 or 64 bit for Intel machines
For a bare-bone kernel recipe which specifies 32 bit x86 target, a 64 bit .config will be generated from do_configure task when building 32-bit qemux86, once all of these conditions are true: () arch of host is x86_64 () kernel source tree used in build has commit ffee0de41 which actually chooses i386 or x86_64 defconfig by asking host arch if ARCH is "x86" (arch/x86/Makefile) () bare-bone kernel recipe inherits directly from kernel without other special treatment Build will fail in this case because of the mismatched architecture of kernel image after compiling. The patch sets ARCH i386 or x86_64 explicitly to configure task to avoid this host contamination. Signed-off-by: Jianxun Zhang --- meta/classes/kernel-arch.bbclass | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass index 3ed5986..d8b180e 100644 --- a/meta/classes/kernel-arch.bbclass +++ b/meta/classes/kernel-arch.bbclass @@ -21,7 +21,9 @@ def map_kernel_arch(a, d): valid_archs = d.getVar('valid_archs', True).split() -if re.match('(i.86|athlon|x86.64)$', a): return 'x86' +if re.match('i.86$', a): return 'i386' +elif re.match('x86.64$', a):return 'x86_64' +elif re.match('athlon$', a):return 'x86' elif re.match('armeb$', a): return 'arm' elif re.match('aarch64$', a): return 'arm64' elif re.match('aarch64_be$', a):return 'arm64' -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core