[yocto] NPM support on Dunfell

2022-04-11 Thread Joel Winarske 
I'm seeing some gaps and performance issues.

Examples:
1. Setting NPM_INSTALL_DEV = "1" I am rewarded with:

169
npm
ERR! Could not install from
"../../__w/meta-flutter/rpi4-drm-dunfell-latest/raspberrypi4-64/tmp/work/aarch64-poky-linux/webthings-gateway/1.0.0+gitAUTOINC+4c600fc973-r0/git/node_modules/@babel/compat-data"
as it does not contain a package.json file.
170


The upstream build uses equivalent to:
npm --user root --cache "${NPM_CACHE}" ci
./node_modules/.bin/webpack
npm --cache "${NPM_CACHE}" prune --production

2. Running npm_do_configure is taking 48+ minutes.  Granted it's a large
project, but basically the configure task is running uni-proc.

Who is the POC supporting NPM on Dunfell?

Thanks,
Joel

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56737): https://lists.yoctoproject.org/g/yocto/message/56737
Mute This Topic: https://lists.yoctoproject.org/mt/90410752/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-gplv2][PATCH] readline: add config file for pkgconfig

2022-04-11 Thread Yu, Mingli 
From: Mingli Yu 

After bind upgrade to 9.18.x, the below change introduced [1],
all supported libraries have accompanying .pc files now.
ba2376b9e0 Update and cleanup the readline library support

Otherwise, there comes below error during do_configure.
 $ bitbake bind
 | configure: error: Package requirements (readline) were not met:
 |
 | No package 'readline' found

So backport patches [2] to add support .pc file for readline to
fix the above issue.

[1] 
https://gitlab.isc.org/isc-projects/bind9/-/commit/ba2376b9e03b9bd214242c987609a658ef24ec41
[2] 
https://git.savannah.gnu.org/cgit/readline.git/commit/?id=d49a9082c0e15bba8cd3d8cc0a994409cf823cac

Signed-off-by: Mingli Yu 
---
 .../0001-Makefile.in-add-readline.pc.in.patch | 135 ++
 .../readline/readline-5.2/readline.pc.in  |  12 ++
 recipes-core/readline/readline_5.2.bb |   6 +-
 3 files changed, 152 insertions(+), 1 deletion(-)
 create mode 100644 
recipes-core/readline/readline-5.2/0001-Makefile.in-add-readline.pc.in.patch
 create mode 100644 recipes-core/readline/readline-5.2/readline.pc.in

diff --git 
a/recipes-core/readline/readline-5.2/0001-Makefile.in-add-readline.pc.in.patch 
b/recipes-core/readline/readline-5.2/0001-Makefile.in-add-readline.pc.in.patch
new file mode 100644
index 000..d9d36a0
--- /dev/null
+++ 
b/recipes-core/readline/readline-5.2/0001-Makefile.in-add-readline.pc.in.patch
@@ -0,0 +1,135 @@
+From 20141946db72908e23c11d946937e945fb7e527d Mon Sep 17 00:00:00 2001
+From: Chet Ramey 
+Date: Mon, 11 Apr 2022 18:06:03 +0800
+Subject: [PATCH] Makefile.in: add readline.pc.in
+
+Add config file for pkgconfig.
+
+Upstream-Status: Backport 
[https://git.savannah.gnu.org/cgit/readline.git/commit/?id=d49a9082c0e15bba8cd3d8cc0a994409cf823cac]
+
+Signed-off-by: Mingli Yu 
+---
+ MANIFEST |  1 +
+ Makefile.in  | 26 --
+ configure.in | 11 ++-
+ 3 files changed, 31 insertions(+), 7 deletions(-)
+
+diff --git a/MANIFEST b/MANIFEST
+index b288fb6..f5b583b 100644
+--- a/MANIFEST
 b/MANIFEST
+@@ -19,6 +19,7 @@ config.h.in  f
+ configure f
+ configure.in  f
+ Makefile.in   f
++readline.pc.inf
+ ansi_stdlib.h f
+ chardefs.hf
+ history.h f
+diff --git a/Makefile.in b/Makefile.in
+index 87df428..e4233f7 100644
+--- a/Makefile.in
 b/Makefile.in
+@@ -57,6 +57,7 @@ mandir = @mandir@
+ includedir = @includedir@
+ datadir = @datadir@
+ localedir = $(datadir)/locale
++pkgconfigdir = ${libdir}/pkgconfig
+ 
+ infodir = @infodir@
+ 
+@@ -133,7 +134,7 @@ DOCUMENTATION = $(DOCSOURCE) $(DOCOBJECT) $(DOCSUPPORT)
+ 
+ CREATED_MAKEFILES = Makefile doc/Makefile examples/Makefile shlib/Makefile
+ CREATED_CONFIGURE = config.status config.h config.cache config.log \
+-  stamp-config stamp-h
++  stamp-config stamp-h readline.pc
+ CREATED_TAGS = TAGS tags
+ 
+ INSTALLED_HEADERS = readline.h chardefs.h keymaps.h history.h tilde.h \
+@@ -217,9 +218,18 @@ uninstall-headers:
+ 
+ maybe-uninstall-headers: uninstall-headers
+ 
++install-pc: installdirs
++  -$(INSTALL_DATA) $(BUILD_DIR)/readline.pc 
$(DESTDIR)$(pkgconfigdir)/readline.pc
++
++uninstall-pc:
++  -test -n "$(pkgconfigdir)" && cd $(DESTDIR)$(pkgconfigdir) && \
++  ${RM} readline.pc
++
++maybe-uninstall-pc: uninstall-pc
++
+ install:  $(INSTALL_TARGETS)
+ 
+-install-static: installdirs $(STATIC_LIBS) install-headers install-doc
++install-static: installdirs $(STATIC_LIBS) install-headers install-doc 
install-pc
+   -$(MV) $(DESTDIR)$(libdir)/libreadline.a 
$(DESTDIR)$(libdir)/libreadline.old
+   $(INSTALL_DATA) libreadline.a $(DESTDIR)$(libdir)/libreadline.a
+   -test -n "$(RANLIB)" && $(RANLIB) $(DESTDIR)$(libdir)/libreadline.a
+@@ -230,17 +240,18 @@ install-static: installdirs $(STATIC_LIBS) 
install-headers install-doc
+ installdirs: $(srcdir)/support/mkinstalldirs
+   -$(SHELL) $(srcdir)/support/mkinstalldirs $(DESTDIR)$(includedir) \
+   $(DESTDIR)$(includedir)/readline $(DESTDIR)$(libdir) \
+-  $(DESTDIR)$(infodir) $(DESTDIR)$(man3dir)
++  $(DESTDIR)$(infodir) $(DESTDIR)$(man3dir) \
++  $(DESTDIR)$(pkgconfigdir)
+ 
+-uninstall: uninstall-headers uninstall-doc
++uninstall: uninstall-headers uninstall-doc uninstall-pc
+   -test -n "$(DESTDIR)$(libdir)" && cd $(DESTDIR)$(libdir) && \
+   ${RM} libreadline.a libreadline.old libhistory.a libhistory.old 
$(SHARED_LIBS)
+   -( cd shlib; ${MAKE} ${MFLAGS} DESTDIR=${DESTDIR} uninstall )
+ 
+-install-shared: installdirs install-headers shared install-doc
++install-shared: installdirs install-headers shared install-doc install-pc
+   -( cd shlib ; ${MAKE} ${MFLAGS} DESTDIR=${DESTDIR} install )
+   
+-uninstall-shared: maybe-uninstall-headers
++uninstall-shared: maybe-uninstall-headers maybe-uninstall-pc
+   -( cd shlib; ${MAKE} ${MFLAGS} DESTDIR=${DESTDIR} uninstall )
+ 
+ install-doc:  installdirs
+@@ -281,6 +292,9 @@ distclean m

[yocto] [meta-security][dunfell][PATCH 2/2] sssd: CVE-2021-3621: shell command injection in sssctl

2022-04-11 Thread Jeremy Puhlman 
From: Hitendra Prajapati 

Source: https://github.com/SSSD/sssd
MR: 114189
Type: Security Fix
Disposition: Backport from 
https://github.com/SSSD/sssd/commit/7ab83f97e1cbefb78ece17232185bdd2985f0bbe
ChangeID: 4588f47f3eeb42a6640e6c1a0d886a9c95f5729c
Description:

CVE: CVE-2021-3621
sssd: shell command injection in sssctl.

Signed-off-by: Hitendra Prajapati 
Signed-off-by: Jeremy A. Puhlman 
---
 .../sssd/files/0001-CVE-2021-3621.patch   | 290 ++
 recipes-security/sssd/sssd_1.16.4.bb  |   2 +
 2 files changed, 292 insertions(+)
 create mode 100644 recipes-security/sssd/files/0001-CVE-2021-3621.patch

diff --git a/recipes-security/sssd/files/0001-CVE-2021-3621.patch 
b/recipes-security/sssd/files/0001-CVE-2021-3621.patch
new file mode 100644
index 000..36efb24
--- /dev/null
+++ b/recipes-security/sssd/files/0001-CVE-2021-3621.patch
@@ -0,0 +1,290 @@
+From 87a2574f43aa95200a7ee6db614b2bd67b248f59 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati 
+Date: Thu, 13 Jan 2022 09:42:57 +0530
+Subject: [PATCH] CVE-2021-3621
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+CVE: CVE-2021-3621
+Upstream-Status: Backport from 
https://github.com/SSSD/sssd/commit/7ab83f97e1cbefb78ece17232185bdd2985f0bbe
+
+:relnote: A flaw was found in SSSD, where the sssctl command was
+vulnerable to shell command injection via the logs-fetch and
+cache-expire subcommands. This flaw allows an attacker to trick
+the root user into running a specially crafted sssctl command,
+such as via sudo, to gain root access. The highest threat from this
+vulnerability is to confidentiality, integrity, as well as system
+availability.
+This patch fixes a flaw by replacing system() with execvp().
+
+:fixes: CVE-2021-3621
+
+Reviewed-by: Pavel Březina 
+
+Signed-off-by: Hitendra Prajapati 
+---
+ src/tools/sssctl/sssctl.c  | 40 +---
+ src/tools/sssctl/sssctl.h  |  2 +-
+ src/tools/sssctl/sssctl_data.c | 57 +++---
+ src/tools/sssctl/sssctl_logs.c | 32 +++
+ 4 files changed, 73 insertions(+), 58 deletions(-)
+
+diff --git a/src/tools/sssctl/sssctl.c b/src/tools/sssctl/sssctl.c
+index afaa84b..765f3cf 100644
+--- a/src/tools/sssctl/sssctl.c
 b/src/tools/sssctl/sssctl.c
+@@ -97,24 +97,37 @@ sssctl_prompt(const char *message,
+ return SSSCTL_PROMPT_ERROR;
+ }
+ 
+-errno_t sssctl_run_command(const char *command)
++errno_t sssctl_run_command(const char *const argv[])
+ {
+ int ret;
++int wstatus;
+ 
+-DEBUG(SSSDBG_TRACE_FUNC, "Running %s\n", command);
++DEBUG(SSSDBG_TRACE_FUNC, "Running '%s'\n", argv[0]);
+ 
+-ret = system(command);
++ret = fork();
+ if (ret == -1) {
+-DEBUG(SSSDBG_CRIT_FAILURE, "Unable to execute %s\n", command);
+ fprintf(stderr, _("Error while executing external command\n"));
+ return EFAULT;
+-} else if (WEXITSTATUS(ret) != 0) {
+-DEBUG(SSSDBG_CRIT_FAILURE, "Command %s failed with [%d]\n",
+-  command, WEXITSTATUS(ret));
+-fprintf(stderr, _("Error while executing external command\n"));
+-return EIO;
+ }
+ 
++if (ret == 0) {
++/* cast is safe - see
++https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
++"The statement about argv[] and envp[] being constants ... "
++*/
++execvp(argv[0], discard_const_p(char * const, argv));
++fprintf(stderr,_("Error while executing external command\n"));
++_exit(1);
++} else {
++if (waitpid(ret, &wstatus, 0) == -1) {
++fprintf(stderr,_("Error while executing external command 
'%s'\n"), argv[0]);
++return EFAULT;
++} else if (WEXITSTATUS(wstatus) != 0) {
++fprintf(stderr,_("Command '%s' failed with [%d]\n"),
++  argv[0], WEXITSTATUS(wstatus));
++return EIO;
++}
++}
+ return EOK;
+ }
+ 
+@@ -132,11 +145,14 @@ static errno_t sssctl_manage_service(enum 
sssctl_svc_action action)
+ #elif defined(HAVE_SERVICE)
+ switch (action) {
+ case SSSCTL_SVC_START:
+-return sssctl_run_command(SERVICE_PATH" sssd start");
++return sssctl_run_command(
++  (const char *[]){SERVICE_PATH, "sssd", "start", NULL});
+ case SSSCTL_SVC_STOP:
+-return sssctl_run_command(SERVICE_PATH" sssd stop");
++return sssctl_run_command(
++  (const char *[]){SERVICE_PATH, "sssd", "stop", NULL});
+ case SSSCTL_SVC_RESTART:
+-return sssctl_run_command(SERVICE_PATH" sssd restart");
++return sssctl_run_command(
++  (const char *[]){SERVICE_PATH, "sssd", "restart", 
NULL});
+ }
+ #endif
+ 
+diff --git a/src/tools/sssctl/sssctl.h b/src/tools/sssctl/sssctl.h
+index 70fc19e..71f798b 100644
+--- a/src/tools/sssctl/sssctl.h
 b/src/tools/sssctl/sssctl.h
+@@ -42,7 +42,7 @@ enum sssctl_prompt_result
+ sssctl

[yocto] [meta-security][dunfell][PATCH 1/2] sssd: re-package to fix QA issues

2022-04-11 Thread Jeremy Puhlman 
Source: meta-security:honister
MR: 113808
Type: Defect Fix
Disposition: Merged from honister
ChangeID: be0e4f3c73eeb04d1c79d99d3377c89659abe420
Description:

It packages all file in ${libdir} to package sssd, including the .so
symlink files. Then it causes QA issues:

| ERROR: QA Issue: sssd rdepends on dbus-dev [dev-deps]
| ERROR: QA Issue: sssd rdepends on ding-libs-dev [dev-deps]

So re-package sssd then the .so symlink files and .pc files are packaged
to sssd-dev which should be.

File ${libdir}/libsss_sudo.so is not a symlink file but packaged to
sssd-dev too. Then causes another QA issue:

| ERROR: sssd-2.5.2-r0 do_package_qa: QA Issue:
-dev package sssd-dev contains non-symlink .so '/usr/lib/libsss_sudo.so' 
[dev-elf]

So create a new sub-package libsss-sudo to package file libsss_sudo.so
and make sssd rdepends on it.

JP: Update for version differences.

Signed-off-by: Kai Kang 
Signed-off-by: Armin Kuster 
(cherry picked from commit e81c15f851ca5396c78c8737967ee38db0ebe0cd)
Signed-off-by: Jeremy A. Puhlman 
---
 recipes-security/sssd/sssd_1.16.4.bb | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/recipes-security/sssd/sssd_1.16.4.bb 
b/recipes-security/sssd/sssd_1.16.4.bb
index 916f1ac..186c9e0 100644
--- a/recipes-security/sssd/sssd_1.16.4.bb
+++ b/recipes-security/sssd/sssd_1.16.4.bb
@@ -116,10 +116,17 @@ SYSTEMD_SERVICE_${PN} = " \
 "
 SYSTEMD_AUTO_ENABLE = "disable"
 
-FILES_${PN} += "${libdir} ${datadir} ${base_libdir}/security/pam_sss.so"
-FILES_${PN}-dev = " ${includedir}/* ${libdir}/*la ${libdir}/*/*la"
-
-# The package contains symlinks that trip up insane
-INSANE_SKIP_${PN} = "dev-so"
-
-RDEPENDS_${PN} = "bind dbus libldb libpam"
+PACKAGES =+ "libsss-sudo libsss-autofs"
+ALLOW_EMPTY_libsss-sudo = "1"
+ALLOW_EMPTY_libsss-autofs = "1"
+
+FILES_${PN}-dev += "${libdir}/sssd/modules/lib*.so"
+FILES_${PN} += "${base_libdir}/security/pam_sss*.so  \
+${datadir}/dbus-1/system-services/*.service \
+${libdir}/krb5/* \
+${libdir}/ldb/* \
+"
+FILES_libsss-autofs = "${libdir}/sssd/modules/libsss_autofs.so"
+FILES_libsss-sudo = "${libdir}/libsss_sudo.so"
+
+RDEPENDS_${PN} = "bind dbus libldb libpam libsss-sudo libsss-autofs"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56734): https://lists.yoctoproject.org/g/yocto/message/56734
Mute This Topic: https://lists.yoctoproject.org/mt/90408552/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] M+ & H bugs with Milestone Movements WW15

2022-04-11 Thread Stephen Jolley 
All,

YP M+ or high bugs which moved to a new milestone in WW15 are listed below: 


Priority

Bug ID

Short Description

Changer

Owner

Was

Became


Medium+

  14495

Implement CVE checking on all packages in a SBOM/manifest

randy.macl...@windriver.com

r...@burtonini.com

3.5 M4

3.6 M1

Thanks, 

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com  

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56733): https://lists.yoctoproject.org/g/yocto/message/56733
Mute This Topic: https://lists.yoctoproject.org/mt/90408365/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Enhancements/Bugs closed WW15!

2022-04-11 Thread Stephen Jolley 
All,

The below were the owners of enhancements or bugs closed during the last
week!


Who

Count


ki...@ukr.net

1


tim.orl...@konsulko.com

1


randy.macl...@windriver.com

1


workjagade...@gmail.com

1


Grand Total

4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56732): https://lists.yoctoproject.org/g/yocto/message/56732
Mute This Topic: https://lists.yoctoproject.org/mt/90408348/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Current high bug count owners for Yocto Project 3.5

2022-04-11 Thread Stephen Jolley 
All,

Below is the list as of top 38 bug owners as of the end of WW15 of who have
open medium or higher bugs and enhancements against YP 3.5.   There are 13
possible work days left until the final release candidates for YP 3.5 needs
to be released.


Who

Count


michael.opdenac...@bootlin.com

34


r...@burtonini.com

24


randy.macl...@windriver.com

15


bruce.ashfi...@gmail.com

13


richard.pur...@linuxfoundation.org

11


david.re...@windriver.com

11


trevor.gamb...@windriver.com

7


mhalst...@linuxfoundation.org

7


bluelightn...@bluelightning.org

6


sakib.sa...@windriver.com

6


chee.yang@intel.com

4


jpewhac...@gmail.com

3


hongxu@windriver.com

3


saul.w...@windriver.com

2


qi.c...@windriver.com

2


kai.k...@windriver.com

2


pgowda@gmail.com

2


ms...@mvista.com

2


akuster...@gmail.com

2


ticot...@gmail.com

1


and...@gherzan.com

1


alejan...@enedino.org

1


open.sou...@oleksandr-kravchuk.com

1


thomas.per...@bootlin.com

1


yi.z...@windriver.com

1


pa...@zhukoff.net

1


pokyli...@reliableembeddedsystems.com

1


alexandre.bell...@bootlin.com

1


raj.k...@gmail.com

1


mostthings...@gmail.com

1


aeh...@gmail.com

1


jon.ma...@arm.com

1


matthew...@posteo.net

1


tim.orl...@konsulko.com

1


nicolas.deche...@linaro.org

1


sundeep.kokko...@gmail.com

1


mark.ha...@kernel.crashing.org

1


john.kaldas.e...@gmail.com

1


Grand Total

175

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56731): https://lists.yoctoproject.org/g/yocto/message/56731
Mute This Topic: https://lists.yoctoproject.org/mt/90408255/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2022-04-11 Thread Stephen Jolley 
All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 410
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now,  "3.5, "3.6", "3.99" and "Future", the more pressing/urgent
issues being in "3.5" and then "3.6".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56730): https://lists.yoctoproject.org/g/yocto/message/56730
Mute This Topic: https://lists.yoctoproject.org/mt/90408241/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Alessandro Tagliapietra 
Tested with updated honister branch, same error

-- 
Alessandro Tagliapietra


On Mon, Apr 11, 2022 at 2:41 PM Alessandro Tagliapietra <
tagliapietra.alessan...@gmail.com> wrote:

> I'm using honister (it's from a few months ago, I'm currently
> rebuilding using the latest commit)
>
> On Mon, Apr 11, 2022 at 2:29 PM Khem Raj  wrote:
>
>> which release branch are you using?
>>
>> On Mon, Apr 11, 2022 at 2:27 PM Alessandro Tagliapietra
>>  wrote:
>> >
>> > Removing works, the build succeeded, however I can't test if it's
>> actually needed by the package, I'll try that tomorrow.
>> > Regarding file paths for example file linux-arm/node.napi.armv7.node is
>> in these paths:
>> >
>> >
>> image/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
>> >
>> packages-split/node-red-node-serialport/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
>> >
>> npm-build/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
>> >
>> package/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
>> >
>> npm/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
>> >
>> > so it seems to be in node-red-node-serialport which is our package so
>> INSANE_SKIP_${PN} += "already-stripped arch" should work.
>> >
>> >
>> > On Mon, Apr 11, 2022 at 2:14 PM Khem Raj  wrote:
>> >>
>> >>
>> >>
>> >> On Mon, Apr 11, 2022 at 1:43 PM Alessandro Tagliapietra <
>> tagliapietra.alessan...@gmail.com> wrote:
>> >>>
>> >>> On Mon, Apr 11, 2022 at 1:36 PM Khem Raj  wrote:
>> 
>> 
>>  what package folders do you see under packages-split/ folder in your
>>  build area for this recipe ?
>> >>>
>> >>>
>> >>> The ones I've added in the INSANE_SKIP
>> >>>
>> >>> ls -lah
>> /home/alex/Projects/yocto/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/node-red-node-serialport/1.0.1-r0/packages-split
>> >>> total 32K
>> >>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport
>> >>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dbg
>> >>> drwxr-xr-x 2 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dev
>> >>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-doc
>> >>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04
>> node-red-node-serialport-locale
>> >>> -rw-r--r-- 1 alex alex   57 Apr  6 16:04
>> node-red-node-serialport.shlibdeps
>> >>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-src
>> >>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04
>> node-red-node-serialport-staticdev
>> >>
>> >>
>> >> Ok then next thing you want to check is where the reported stripped
>> file is located and even if it does not work then perhaps look into
>> removing these files if they are not needed
>> >>>
>> >>>
>> >>>
>>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56729): https://lists.yoctoproject.org/g/yocto/message/56729
Mute This Topic: https://lists.yoctoproject.org/mt/90398675/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Alessandro Tagliapietra 
I'm using honister (it's from a few months ago, I'm currently
rebuilding using the latest commit)

On Mon, Apr 11, 2022 at 2:29 PM Khem Raj  wrote:

> which release branch are you using?
>
> On Mon, Apr 11, 2022 at 2:27 PM Alessandro Tagliapietra
>  wrote:
> >
> > Removing works, the build succeeded, however I can't test if it's
> actually needed by the package, I'll try that tomorrow.
> > Regarding file paths for example file linux-arm/node.napi.armv7.node is
> in these paths:
> >
> >
> image/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
> >
> packages-split/node-red-node-serialport/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
> >
> npm-build/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
> >
> package/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
> >
> npm/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
> >
> > so it seems to be in node-red-node-serialport which is our package so
> INSANE_SKIP_${PN} += "already-stripped arch" should work.
> >
> >
> > On Mon, Apr 11, 2022 at 2:14 PM Khem Raj  wrote:
> >>
> >>
> >>
> >> On Mon, Apr 11, 2022 at 1:43 PM Alessandro Tagliapietra <
> tagliapietra.alessan...@gmail.com> wrote:
> >>>
> >>> On Mon, Apr 11, 2022 at 1:36 PM Khem Raj  wrote:
> 
> 
>  what package folders do you see under packages-split/ folder in your
>  build area for this recipe ?
> >>>
> >>>
> >>> The ones I've added in the INSANE_SKIP
> >>>
> >>> ls -lah
> /home/alex/Projects/yocto/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/node-red-node-serialport/1.0.1-r0/packages-split
> >>> total 32K
> >>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport
> >>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dbg
> >>> drwxr-xr-x 2 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dev
> >>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-doc
> >>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04
> node-red-node-serialport-locale
> >>> -rw-r--r-- 1 alex alex   57 Apr  6 16:04
> node-red-node-serialport.shlibdeps
> >>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-src
> >>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04
> node-red-node-serialport-staticdev
> >>
> >>
> >> Ok then next thing you want to check is where the reported stripped
> file is located and even if it does not work then perhaps look into
> removing these files if they are not needed
> >>>
> >>>
> >>>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56728): https://lists.yoctoproject.org/g/yocto/message/56728
Mute This Topic: https://lists.yoctoproject.org/mt/90398675/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Khem Raj 
which release branch are you using?

On Mon, Apr 11, 2022 at 2:27 PM Alessandro Tagliapietra
 wrote:
>
> Removing works, the build succeeded, however I can't test if it's actually 
> needed by the package, I'll try that tomorrow.
> Regarding file paths for example file linux-arm/node.napi.armv7.node is in 
> these paths:
>
> image/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
> packages-split/node-red-node-serialport/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
> npm-build/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
> package/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
> npm/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
>
> so it seems to be in node-red-node-serialport which is our package so 
> INSANE_SKIP_${PN} += "already-stripped arch" should work.
>
>
> On Mon, Apr 11, 2022 at 2:14 PM Khem Raj  wrote:
>>
>>
>>
>> On Mon, Apr 11, 2022 at 1:43 PM Alessandro Tagliapietra 
>>  wrote:
>>>
>>> On Mon, Apr 11, 2022 at 1:36 PM Khem Raj  wrote:


 what package folders do you see under packages-split/ folder in your
 build area for this recipe ?
>>>
>>>
>>> The ones I've added in the INSANE_SKIP
>>>
>>> ls -lah 
>>> /home/alex/Projects/yocto/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/node-red-node-serialport/1.0.1-r0/packages-split
>>> total 32K
>>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport
>>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dbg
>>> drwxr-xr-x 2 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dev
>>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-doc
>>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-locale
>>> -rw-r--r-- 1 alex alex   57 Apr  6 16:04 node-red-node-serialport.shlibdeps
>>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-src
>>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-staticdev
>>
>>
>> Ok then next thing you want to check is where the reported stripped file is 
>> located and even if it does not work then perhaps look into removing these 
>> files if they are not needed
>>>
>>>
>>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56727): https://lists.yoctoproject.org/g/yocto/message/56727
Mute This Topic: https://lists.yoctoproject.org/mt/90398675/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Alessandro Tagliapietra 
Removing works, the build succeeded, however I can't test if it's actually
needed by the package, I'll try that tomorrow.
Regarding file paths for example file linux-arm/node.napi.armv7.node is in
these paths:

image/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
packages-split/node-red-node-serialport/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
npm-build/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
package/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node
npm/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node

so it seems to be in node-red-node-serialport which is our package
so INSANE_SKIP_${PN} += "already-stripped arch" should work.


On Mon, Apr 11, 2022 at 2:14 PM Khem Raj  wrote:

>
>
> On Mon, Apr 11, 2022 at 1:43 PM Alessandro Tagliapietra <
> tagliapietra.alessan...@gmail.com> wrote:
>
>> On Mon, Apr 11, 2022 at 1:36 PM Khem Raj  wrote:
>>
>>>
>>> what package folders do you see under packages-split/ folder in your
>>> build area for this recipe ?
>>>
>>
>> The ones I've added in the INSANE_SKIP
>>
>> ls -lah
>> /home/alex/Projects/yocto/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/node-red-node-serialport/1.0.1-r0/packages-split
>> total 32K
>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport
>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dbg
>> drwxr-xr-x 2 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dev
>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-doc
>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-locale
>> -rw-r--r-- 1 alex alex   57 Apr  6 16:04
>> node-red-node-serialport.shlibdeps
>> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-src
>> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04
>> node-red-node-serialport-staticdev
>>
>
> Ok then next thing you want to check is where the reported stripped file
> is located and even if it does not work then perhaps look into removing
> these files if they are not needed
>
>>
>>
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56726): https://lists.yoctoproject.org/g/yocto/message/56726
Mute This Topic: https://lists.yoctoproject.org/mt/90398675/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Khem Raj 
On Mon, Apr 11, 2022 at 1:43 PM Alessandro Tagliapietra <
tagliapietra.alessan...@gmail.com> wrote:

> On Mon, Apr 11, 2022 at 1:36 PM Khem Raj  wrote:
>
>>
>> what package folders do you see under packages-split/ folder in your
>> build area for this recipe ?
>>
>
> The ones I've added in the INSANE_SKIP
>
> ls -lah
> /home/alex/Projects/yocto/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/node-red-node-serialport/1.0.1-r0/packages-split
> total 32K
> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport
> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dbg
> drwxr-xr-x 2 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dev
> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-doc
> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-locale
> -rw-r--r-- 1 alex alex   57 Apr  6 16:04 node-red-node-serialport.shlibdeps
> drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-src
> drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-staticdev
>

Ok then next thing you want to check is where the reported stripped file is
located and even if it does not work then perhaps look into removing these
files if they are not needed

>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56725): https://lists.yoctoproject.org/g/yocto/message/56725
Mute This Topic: https://lists.yoctoproject.org/mt/90398675/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Alessandro Tagliapietra 
On Mon, Apr 11, 2022 at 1:36 PM Khem Raj  wrote:

>
> what package folders do you see under packages-split/ folder in your
> build area for this recipe ?
>

The ones I've added in the INSANE_SKIP

ls -lah
/home/alex/Projects/yocto/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/node-red-node-serialport/1.0.1-r0/packages-split
total 32K
drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport
drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dbg
drwxr-xr-x 2 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-dev
drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-doc
drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-locale
-rw-r--r-- 1 alex alex   57 Apr  6 16:04 node-red-node-serialport.shlibdeps
drwxr-xr-x 3 alex alex 4.0K Apr 11 13:23 node-red-node-serialport-src
drwxr-xr-x 2 alex alex 4.0K Apr  6 16:04 node-red-node-serialport-staticdev

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56724): https://lists.yoctoproject.org/g/yocto/message/56724
Mute This Topic: https://lists.yoctoproject.org/mt/90398675/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Khem Raj 
On Mon, Apr 11, 2022 at 1:27 PM Alessandro Tagliapietra
 wrote:
>
> Thank you for helping!
>
> The package is node-red-node-serialport, it doesn't seem to create child 
> packages for the dependencies, the nodejs deps only reside in the package 
> node-modules folder.
> The packages-split only contained node-red-node-serialport-* packages.
>

what package folders do you see under packages-split/ folder in your
build area for this recipe ?

> So I've tried to add the skips for these child packages too:
>
> INSANE_SKIP_${PN} += "already-stripped arch"
> INSANE_SKIP_${PN}-dbg += "already-stripped arch"
> INSANE_SKIP_${PN}-dev += "already-stripped arch"
> INSANE_SKIP_${PN}-doc += "already-stripped arch"
> INSANE_SKIP_${PN}-locale += "already-stripped arch"
> INSANE_SKIP_${PN}-src += "already-stripped arch"
> INSANE_SKIP_${PN}-staticdev += "already-stripped arch"
>
> and I still get the error.
>
> I've then tried to remove them:
>
> do_install:prepend() {
> rm -Rf 
> ${NPM_BUILD}/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds
> }
>
> and it seems to work, however I would like to keep them as the armv7 is the 
> one that's probably used for the raspberry.
> Any other things I can try to ignore the QA check?
>
> Thank you
>
>
> On Mon, Apr 11, 2022 at 11:27 AM Khem Raj  wrote:
>>
>> The prebuilds are for other architectures. so perhaps you can rm them
>> in a do_install_append() or if they are really needed
>> you perhaps would also need INSANE_SKIP_ = "arch" eventually
>>
>> is your recipe called node-red-node-serialport ?
>> INSANE_SKIP_${PN} is only accounting for one output package. You
>> perhaps will need to specify it for all the packages generated by this
>> recipe.
>> so check where these files are landing in packages-split/ folder in
>> the build area of this recipe
>>
>> On Mon, Apr 11, 2022 at 9:13 AM Alessandro Tagliapietra
>>  wrote:
>> >
>> > I've created an npm package recipe for node-red-node-serialport using
>> >
>> > devtool add 
>> > "npm://registry.npmjs.org;package=node-red-node-serialport;version=1.0.1"
>> >
>> > which generated this recipe.
>> >
>> > The problem is when building I get
>> >
>> > WARNING: node-red-node-serialport-1.0.1-r0 do_compile: Use of configs 
>> > argument of NpmEnvironment.run() function is deprecated. Please use args 
>> > argument instead.
>> > WARNING: node-red-node-serialport-1.0.1-r0 do_compile: Use of configs 
>> > argument of NpmEnvironment.run() function is deprecated. Please use args 
>> > argument instead.
>> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
>> > '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm/node.napi.armv7.node'
>> >  from node-red-node-serialport was already stripped, this will prevent 
>> > future debugging! [already-stripped]
>> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
>> > '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm64/node.napi.armv8.node'
>> >  from node-red-node-serialport was already stripped, this will prevent 
>> > future debugging! [already-stripped]
>> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
>> > '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv6.node'
>> >  from node-red-node-serialport was already stripped, this will prevent 
>> > future debugging! [already-stripped]
>> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
>> > '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node'
>> >  from node-red-node-serialport was already stripped, this will prevent 
>> > future debugging! [already-stripped]
>> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
>> > '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm64/node.napi.armv8.node'
>> >  from node-red-node-serialport was already stripped, this will prevent 
>> > future debugging! [already-stripped]
>> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
>> > '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.glibc.node'
>> >  from node-red-node-serialport was already stripped, this will prevent 
>> > future debugging! [already-stripped]
>> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
>> > '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.musl.node'
>> >  from node-red-node-serialport was already stripped, this will prevent 
>> > future debugging! [already-stripped]
>> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: Fatal QA errors 
>> > found, failing task.
>> > ERROR: Logfile of failure stored in: 
>> > /home/alex/Pro

Re: [yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Alessandro Tagliapietra 
Thank you for helping!

The package is node-red-node-serialport, it doesn't seem to create child
packages for the dependencies, the nodejs deps only reside in the package
node-modules folder.
The packages-split only contained node-red-node-serialport-* packages.

So I've tried to add the skips for these child packages too:

INSANE_SKIP_${PN} += "already-stripped arch"
INSANE_SKIP_${PN}-dbg += "already-stripped arch"
INSANE_SKIP_${PN}-dev += "already-stripped arch"
INSANE_SKIP_${PN}-doc += "already-stripped arch"
INSANE_SKIP_${PN}-locale += "already-stripped arch"
INSANE_SKIP_${PN}-src += "already-stripped arch"
INSANE_SKIP_${PN}-staticdev += "already-stripped arch"

and I still get the error.

I've then tried to remove them:

do_install:prepend() {
rm -Rf
${NPM_BUILD}/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds
}

and it seems to work, however I would like to keep them as the armv7 is the
one that's probably used for the raspberry.
Any other things I can try to ignore the QA check?

Thank you


On Mon, Apr 11, 2022 at 11:27 AM Khem Raj  wrote:

> The prebuilds are for other architectures. so perhaps you can rm them
> in a do_install_append() or if they are really needed
> you perhaps would also need INSANE_SKIP_ = "arch"
> eventually
>
> is your recipe called node-red-node-serialport ?
> INSANE_SKIP_${PN} is only accounting for one output package. You
> perhaps will need to specify it for all the packages generated by this
> recipe.
> so check where these files are landing in packages-split/ folder in
> the build area of this recipe
>
> On Mon, Apr 11, 2022 at 9:13 AM Alessandro Tagliapietra
>  wrote:
> >
> > I've created an npm package recipe for node-red-node-serialport using
> >
> > devtool add "npm://registry.npmjs.org
> ;package=node-red-node-serialport;version=1.0.1"
> >
> > which generated this recipe.
> >
> > The problem is when building I get
> >
> > WARNING: node-red-node-serialport-1.0.1-r0 do_compile: Use of configs
> argument of NpmEnvironment.run() function is deprecated. Please use args
> argument instead.
> > WARNING: node-red-node-serialport-1.0.1-r0 do_compile: Use of configs
> argument of NpmEnvironment.run() function is deprecated. Please use args
> argument instead.
> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm/node.napi.armv7.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm64/node.napi.armv8.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv6.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm64/node.napi.armv8.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.glibc.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.musl.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> > ERROR: node-red-node-serialport-1.0.1-r0 do_package: Fatal QA errors
> found, failing task.
> > ERROR: Logfile of failure stored in:
> /home/alex/Projects/yocto/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/node-red-node-serialport/1.0.1-r0/temp/log.do_package.75444
> > ERROR: Task
> (/home/alex/Projects/yocto/meta-things5/recipes-devtools/node-red-node-serialport/node-red-node-serialport_1.0.1.bb:do_package)
> failed with exit code '1'
> >
> > I've tried to add
> >
> > INSANE_SKIP_${PN} += "already-stri

Re: [yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Khem Raj 
The prebuilds are for other architectures. so perhaps you can rm them
in a do_install_append() or if they are really needed
you perhaps would also need INSANE_SKIP_ = "arch" eventually

is your recipe called node-red-node-serialport ?
INSANE_SKIP_${PN} is only accounting for one output package. You
perhaps will need to specify it for all the packages generated by this
recipe.
so check where these files are landing in packages-split/ folder in
the build area of this recipe

On Mon, Apr 11, 2022 at 9:13 AM Alessandro Tagliapietra
 wrote:
>
> I've created an npm package recipe for node-red-node-serialport using
>
> devtool add 
> "npm://registry.npmjs.org;package=node-red-node-serialport;version=1.0.1"
>
> which generated this recipe.
>
> The problem is when building I get
>
> WARNING: node-red-node-serialport-1.0.1-r0 do_compile: Use of configs 
> argument of NpmEnvironment.run() function is deprecated. Please use args 
> argument instead.
> WARNING: node-red-node-serialport-1.0.1-r0 do_compile: Use of configs 
> argument of NpmEnvironment.run() function is deprecated. Please use args 
> argument instead.
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm/node.napi.armv7.node'
>  from node-red-node-serialport was already stripped, this will prevent future 
> debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm64/node.napi.armv8.node'
>  from node-red-node-serialport was already stripped, this will prevent future 
> debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv6.node'
>  from node-red-node-serialport was already stripped, this will prevent future 
> debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node'
>  from node-red-node-serialport was already stripped, this will prevent future 
> debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm64/node.napi.armv8.node'
>  from node-red-node-serialport was already stripped, this will prevent future 
> debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.glibc.node'
>  from node-red-node-serialport was already stripped, this will prevent future 
> debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File 
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.musl.node'
>  from node-red-node-serialport was already stripped, this will prevent future 
> debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: Fatal QA errors found, 
> failing task.
> ERROR: Logfile of failure stored in: 
> /home/alex/Projects/yocto/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/node-red-node-serialport/1.0.1-r0/temp/log.do_package.75444
> ERROR: Task 
> (/home/alex/Projects/yocto/meta-things5/recipes-devtools/node-red-node-serialport/node-red-node-serialport_1.0.1.bb:do_package)
>  failed with exit code '1'
>
> I've tried to add
>
> INSANE_SKIP_${PN} += "already-stripped"
>
> in the recipe and in a bbappend but I still get the error.
>
> Why? I need to get this out asap so any help is appreciated.
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56721): https://lists.yoctoproject.org/g/yocto/message/56721
Mute This Topic: https://lists.yoctoproject.org/mt/90398675/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Jose Quaresma 
Alessandro Tagliapietra  escreveu no dia
segunda, 11/04/2022 à(s) 17:13:

> I've created an npm package recipe for node-red-node-serialport
>  using
>
> devtool add "npm://registry.npmjs.org
> ;package=node-red-node-serialport;version=1.0.1"
>
> which generated this
>  recipe.
>
> The problem is when building I get
>
> WARNING: node-red-node-serialport-1.0.1-r0 do_compile: Use of configs
> argument of NpmEnvironment.run() function is deprecated. Please use args
> argument instead.
> WARNING: node-red-node-serialport-1.0.1-r0 do_compile: Use of configs
> argument of NpmEnvironment.run() function is deprecated. Please use args
> argument instead.
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm/node.napi.armv7.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm64/node.napi.armv8.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv6.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm64/node.napi.armv8.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.glibc.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.musl.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: Fatal QA errors
> found, failing task.
> ERROR: Logfile of failure stored in:
> /home/alex/Projects/yocto/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/node-red-node-serialport/1.0.1-r0/temp/log.do_package.75444
> ERROR: Task
> (/home/alex/Projects/yocto/meta-things5/recipes-devtools/node-red-node-serialport/node-red-node-serialport_1.0.1.bb:do_package)
> failed with exit code '1'
>
> I've tried to add
>
> INSANE_SKIP_${PN} += "already-stripped"
>
> in the recipe and in a bbappend but I still get the error.
>
> Why? I need to get this out asap so any help is appreciated.
>

Hi Alessandro,

This is because the package that you are building is already compiled and
there seems to be too many archs.
Your target archs is arm (cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi) and
it is pre builded for a bunch of arch (prebuilds/linux-XX, where XX is the
arch).
Yocto can cross compile the code for you and probably you don't need the
pre-built binaries.

Jose


> 
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56720): https://lists.yoctoproject.org/g/yocto/message/56720
Mute This Topic: https://lists.yoctoproject.org/mt/90398675/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [Question] How to handle GPLv3 packages?

2022-04-11 Thread Khem Raj 
On Mon, Apr 11, 2022 at 1:29 AM Mans Zigher  wrote:
>
> This is my first time working with them so I am learning a lot but
> never encountered anything like it. Trying to look into what it would
> require to move to a newer version it appears as if they have set up
> their layers inside the poky dir and then they are using COREBASE when
> one layer depends on the content of another layer. So again something
> that should have been fairly simple will now require some additional
> work. But thanks for all your help I appreciate it. I am getting a bit
> off topic in this thread.

This will be valiant effort but my advice is don't go alone if you
want to undertake this
SOC sdks have lot of nitty gritty issues that will pop up along the
way and unless you
have someone from SOC suppliers actively supporting you on this upgrade you will
burn your time to no end.

>
> For anyone having issues with enabling INCOMPATIBLE_LICENSE make sure
> to set it per image but before that you will have to make sure you are
> not including any packages that have the incompatible license there is
> some tedious work but it needs to be done.

Perhaps a write-up will be beneficial for someone who trips into these
issues in future.

>
> Thanks
>
> Den mån 11 apr. 2022 kl 09:16 skrev Alexander Kanavin 
> :
> >
> > It's a contracting issue. You need to specify in writing that the
> > vendor cannot provide ancient Yocto. Otherwise they won't bother.
> >
> > Alex
> >
> > On Mon, 11 Apr 2022 at 09:13, Måns  wrote:
> > >
> > > Yes I know. Not sure why QC is stuck on Thud. Even newer releases from
> > > QC for the target that we are working on is stuck at Thud.
> > >
> > > Mans
> > >
> > > Den fre 8 apr. 2022 kl 18:59 skrev Alexander Kanavin 
> > > :
> > > >
> > > > Thud has been EOL for a long time. You can see when the support been
> > > > added here (end of 2019 it seems):
> > > > https://git.yoctoproject.org/poky/log/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next
> > > >
> > > > Alex
> > > >
> > > > On Fri, 8 Apr 2022 at 18:56, Måns  wrote:
> > > > >
> > > > > I am currently on Thud so I am missing the support from what I can
> > > > > tell to set INCOMPATIBLE_LICENSE per image. I have tried to find the
> > > > > commit that adds that support but am having some problems finding it.
> > > > > Do you maybe know what I should look for to find the commit that adds
> > > > > this support?
> > > > >
> > > > > Thanks
> > > > >
> > > > > Den fre 8 apr. 2022 kl 10:16 skrev Alexander Kanavin 
> > > > > :
> > > > > >
> > > > > > Hello Mans,
> > > > > >
> > > > > > please refer to the tests we have for the feature:
> > > > > > https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next#n95
> > > > > > (line 95 and below)
> > > > > >
> > > > > > The key bit is:
> > > > > > INCOMPATIBLE_LICENSE:pn-core-image-minimal = "GPL-3.0* LGPL-3.0*"
> > > > > > e.g. apply the restriction only to core-image-minimal.
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > On Fri, 8 Apr 2022 at 08:06, Måns  wrote:
> > > > > > >
> > > > > > > Hi Alex,
> > > > > > >
> > > > > > > Could you maybe clarify what you mean with "setting
> > > > > > > INCOMPATIBLE_LICENSE per image"? Do you mean that you have one
> > > > > > > specific image that is used when you build an image for release 
> > > > > > > to the
> > > > > > > customer and then one image for development?
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Den ons 6 apr. 2022 kl 11:04 skrev Alexander Kanavin 
> > > > > > > :
> > > > > > > >
> > > > > > > > I'd suggest you start by setting INCOMPATIBLE_LICENSE per 
> > > > > > > > image, e.g.
> > > > > > > > enable gpl3 ban only in the images that ship to the customers 
> > > > > > > > and not
> > > > > > > > across the entire build. Then carefully look at what pulls in 
> > > > > > > > bash
> > > > > > > > into those images and why, and reconfigure those pieces to not 
> > > > > > > > do that
> > > > > > > > (e.g. by reconfiguring the PACKAGECONFIGs), or rewrite the 
> > > > > > > > scripts in
> > > > > > > > posix shell.
> > > > > > > >
> > > > > > > > Alex
> > > > > > > >
> > > > > > > > On Wed, 6 Apr 2022 at 10:59, Mans Zigher 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I cannot use GPLv3 packages in our image build. I am no legal 
> > > > > > > > > expert
> > > > > > > > > but from what I can understand most companies will not be 
> > > > > > > > > able to
> > > > > > > > > comply with this license without allowing the customer to 
> > > > > > > > > compile and
> > > > > > > > > deploy a new version of any GPLv3 package to the target. I 
> > > > > > > > > know it is
> > > > > > > > > possible to comply with this but we are using secure boot and 
> > > > > > > > > have not
> > > > > > > > > the time and probably no interest in setting up a solution for
> > > > > > > > > allowing customers to be able to deploy GPLv3 packages on the 
> >

[yocto] Skipping already-stripped check doesn't work

2022-04-11 Thread Alessandro Tagliapietra 
I've created an npm package recipe for node-red-node-serialport ( 
https://www.npmjs.com/package/node-red-node-serialport ) using

devtool add 
"npm://registry.npmjs.org;package=node-red-node-serialport;version=1.0.1"

which generated this ( 
https://gist.github.com/alex88/e0e1bca5ac07137229839120f8bfe273 ) recipe.

The problem is when building I get

> 
> WARNING: node-red-node-serialport-1.0.1-r0 do_compile: Use of configs
> argument of NpmEnvironment.run() function is deprecated. Please use args
> argument instead.
> WARNING: node-red-node-serialport-1.0.1-r0 do_compile: Use of configs
> argument of NpmEnvironment.run() function is deprecated. Please use args
> argument instead.
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm/node.napi.armv7.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm64/node.napi.armv8.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv6.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm64/node.napi.armv8.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.glibc.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: QA Issue: File
> '/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.musl.node'
> from node-red-node-serialport was already stripped, this will prevent
> future debugging! [already-stripped]
> ERROR: node-red-node-serialport-1.0.1-r0 do_package: Fatal QA errors
> found, failing task.
> ERROR: Logfile of failure stored in:
> /home/alex/Projects/yocto/build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/node-red-node-serialport/1.0.1-r0/temp/log.do_package.75444
> 
> ERROR: Task
> (/home/alex/Projects/yocto/meta-things5/recipes-devtools/node-red-node-serialport/node-red-node-serialport_1.0.1.bb:do_package)
> failed with exit code '1'
> 

I've tried to add

INSANE_SKIP_${PN} += "already-stripped"

in the recipe and in a bbappend but I still get the error.

Why? I need to get this out asap so any help is appreciated.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56718): https://lists.yoctoproject.org/g/yocto/message/56718
Mute This Topic: https://lists.yoctoproject.org/mt/90398675/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [Question] How to handle GPLv3 packages?

2022-04-11 Thread Mans Zigher 
This is my first time working with them so I am learning a lot but
never encountered anything like it. Trying to look into what it would
require to move to a newer version it appears as if they have set up
their layers inside the poky dir and then they are using COREBASE when
one layer depends on the content of another layer. So again something
that should have been fairly simple will now require some additional
work. But thanks for all your help I appreciate it. I am getting a bit
off topic in this thread.

For anyone having issues with enabling INCOMPATIBLE_LICENSE make sure
to set it per image but before that you will have to make sure you are
not including any packages that have the incompatible license there is
some tedious work but it needs to be done.

Thanks

Den mån 11 apr. 2022 kl 09:16 skrev Alexander Kanavin :
>
> It's a contracting issue. You need to specify in writing that the
> vendor cannot provide ancient Yocto. Otherwise they won't bother.
>
> Alex
>
> On Mon, 11 Apr 2022 at 09:13, Måns  wrote:
> >
> > Yes I know. Not sure why QC is stuck on Thud. Even newer releases from
> > QC for the target that we are working on is stuck at Thud.
> >
> > Mans
> >
> > Den fre 8 apr. 2022 kl 18:59 skrev Alexander Kanavin 
> > :
> > >
> > > Thud has been EOL for a long time. You can see when the support been
> > > added here (end of 2019 it seems):
> > > https://git.yoctoproject.org/poky/log/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next
> > >
> > > Alex
> > >
> > > On Fri, 8 Apr 2022 at 18:56, Måns  wrote:
> > > >
> > > > I am currently on Thud so I am missing the support from what I can
> > > > tell to set INCOMPATIBLE_LICENSE per image. I have tried to find the
> > > > commit that adds that support but am having some problems finding it.
> > > > Do you maybe know what I should look for to find the commit that adds
> > > > this support?
> > > >
> > > > Thanks
> > > >
> > > > Den fre 8 apr. 2022 kl 10:16 skrev Alexander Kanavin 
> > > > :
> > > > >
> > > > > Hello Mans,
> > > > >
> > > > > please refer to the tests we have for the feature:
> > > > > https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next#n95
> > > > > (line 95 and below)
> > > > >
> > > > > The key bit is:
> > > > > INCOMPATIBLE_LICENSE:pn-core-image-minimal = "GPL-3.0* LGPL-3.0*"
> > > > > e.g. apply the restriction only to core-image-minimal.
> > > > >
> > > > > Alex
> > > > >
> > > > > On Fri, 8 Apr 2022 at 08:06, Måns  wrote:
> > > > > >
> > > > > > Hi Alex,
> > > > > >
> > > > > > Could you maybe clarify what you mean with "setting
> > > > > > INCOMPATIBLE_LICENSE per image"? Do you mean that you have one
> > > > > > specific image that is used when you build an image for release to 
> > > > > > the
> > > > > > customer and then one image for development?
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Den ons 6 apr. 2022 kl 11:04 skrev Alexander Kanavin 
> > > > > > :
> > > > > > >
> > > > > > > I'd suggest you start by setting INCOMPATIBLE_LICENSE per image, 
> > > > > > > e.g.
> > > > > > > enable gpl3 ban only in the images that ship to the customers and 
> > > > > > > not
> > > > > > > across the entire build. Then carefully look at what pulls in bash
> > > > > > > into those images and why, and reconfigure those pieces to not do 
> > > > > > > that
> > > > > > > (e.g. by reconfiguring the PACKAGECONFIGs), or rewrite the 
> > > > > > > scripts in
> > > > > > > posix shell.
> > > > > > >
> > > > > > > Alex
> > > > > > >
> > > > > > > On Wed, 6 Apr 2022 at 10:59, Mans Zigher  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I cannot use GPLv3 packages in our image build. I am no legal 
> > > > > > > > expert
> > > > > > > > but from what I can understand most companies will not be able 
> > > > > > > > to
> > > > > > > > comply with this license without allowing the customer to 
> > > > > > > > compile and
> > > > > > > > deploy a new version of any GPLv3 package to the target. I know 
> > > > > > > > it is
> > > > > > > > possible to comply with this but we are using secure boot and 
> > > > > > > > have not
> > > > > > > > the time and probably no interest in setting up a solution for
> > > > > > > > allowing customers to be able to deploy GPLv3 packages on the 
> > > > > > > > target.
> > > > > > > > We are trying to make use of INCOMPATIBLE_LICENSE but that 
> > > > > > > > results in
> > > > > > > > several issues. We have made sure that we don't include GPLv3 
> > > > > > > > in the
> > > > > > > > image build using a manual process but would like to use
> > > > > > > > INCOMPATIBLE_LICENSE to alert any developer about the issue. It 
> > > > > > > > seems
> > > > > > > > like INCOMPATIBLE_LICENSE is a bit harsh since it will catch any
> > > > > > > > packages even if it is only part of the SDK and also for native
> > > > > > > > packages that are not part of the image build.
> > > > > > > >
> > > > > > > > I cannot

Re: [yocto] [Question] How to handle GPLv3 packages?

2022-04-11 Thread Alexander Kanavin 
It's a contracting issue. You need to specify in writing that the
vendor cannot provide ancient Yocto. Otherwise they won't bother.

Alex

On Mon, 11 Apr 2022 at 09:13, Måns  wrote:
>
> Yes I know. Not sure why QC is stuck on Thud. Even newer releases from
> QC for the target that we are working on is stuck at Thud.
>
> Mans
>
> Den fre 8 apr. 2022 kl 18:59 skrev Alexander Kanavin :
> >
> > Thud has been EOL for a long time. You can see when the support been
> > added here (end of 2019 it seems):
> > https://git.yoctoproject.org/poky/log/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next
> >
> > Alex
> >
> > On Fri, 8 Apr 2022 at 18:56, Måns  wrote:
> > >
> > > I am currently on Thud so I am missing the support from what I can
> > > tell to set INCOMPATIBLE_LICENSE per image. I have tried to find the
> > > commit that adds that support but am having some problems finding it.
> > > Do you maybe know what I should look for to find the commit that adds
> > > this support?
> > >
> > > Thanks
> > >
> > > Den fre 8 apr. 2022 kl 10:16 skrev Alexander Kanavin 
> > > :
> > > >
> > > > Hello Mans,
> > > >
> > > > please refer to the tests we have for the feature:
> > > > https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next#n95
> > > > (line 95 and below)
> > > >
> > > > The key bit is:
> > > > INCOMPATIBLE_LICENSE:pn-core-image-minimal = "GPL-3.0* LGPL-3.0*"
> > > > e.g. apply the restriction only to core-image-minimal.
> > > >
> > > > Alex
> > > >
> > > > On Fri, 8 Apr 2022 at 08:06, Måns  wrote:
> > > > >
> > > > > Hi Alex,
> > > > >
> > > > > Could you maybe clarify what you mean with "setting
> > > > > INCOMPATIBLE_LICENSE per image"? Do you mean that you have one
> > > > > specific image that is used when you build an image for release to the
> > > > > customer and then one image for development?
> > > > >
> > > > > Thanks
> > > > >
> > > > > Den ons 6 apr. 2022 kl 11:04 skrev Alexander Kanavin 
> > > > > :
> > > > > >
> > > > > > I'd suggest you start by setting INCOMPATIBLE_LICENSE per image, 
> > > > > > e.g.
> > > > > > enable gpl3 ban only in the images that ship to the customers and 
> > > > > > not
> > > > > > across the entire build. Then carefully look at what pulls in bash
> > > > > > into those images and why, and reconfigure those pieces to not do 
> > > > > > that
> > > > > > (e.g. by reconfiguring the PACKAGECONFIGs), or rewrite the scripts 
> > > > > > in
> > > > > > posix shell.
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > On Wed, 6 Apr 2022 at 10:59, Mans Zigher  
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I cannot use GPLv3 packages in our image build. I am no legal 
> > > > > > > expert
> > > > > > > but from what I can understand most companies will not be able to
> > > > > > > comply with this license without allowing the customer to compile 
> > > > > > > and
> > > > > > > deploy a new version of any GPLv3 package to the target. I know 
> > > > > > > it is
> > > > > > > possible to comply with this but we are using secure boot and 
> > > > > > > have not
> > > > > > > the time and probably no interest in setting up a solution for
> > > > > > > allowing customers to be able to deploy GPLv3 packages on the 
> > > > > > > target.
> > > > > > > We are trying to make use of INCOMPATIBLE_LICENSE but that 
> > > > > > > results in
> > > > > > > several issues. We have made sure that we don't include GPLv3 in 
> > > > > > > the
> > > > > > > image build using a manual process but would like to use
> > > > > > > INCOMPATIBLE_LICENSE to alert any developer about the issue. It 
> > > > > > > seems
> > > > > > > like INCOMPATIBLE_LICENSE is a bit harsh since it will catch any
> > > > > > > packages even if it is only part of the SDK and also for native
> > > > > > > packages that are not part of the image build.
> > > > > > >
> > > > > > > I cannot be the only one with this problem so how are other 
> > > > > > > companies
> > > > > > > solving this issue? Are they just not using the 
> > > > > > > INCOMPATIBLE_LICENSE?
> > > > > > > Are you setting up a parallel process for checking for any
> > > > > > > incompatible licenses issues?
> > > > > > >
> > > > > > > A more specific issue is that there are so many packages with bash
> > > > > > > dependencies which are pulling in bash which is GPLv3 so how have 
> > > > > > > you
> > > > > > > solved that? Currently we have done some pretty uggly hacks which 
> > > > > > > I am
> > > > > > > not that happy with but we needed to keep it out of the image.
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > 
> > > > > > >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56716): https://lists.yoctoproject.org/g/yocto/message/56716
Mute This Topic: https://lists.yoctoproject.org/mt/90285507/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub

Re: [yocto] [Question] How to handle GPLv3 packages?

2022-04-11 Thread Mans Zigher 
Yes I know. Not sure why QC is stuck on Thud. Even newer releases from
QC for the target that we are working on is stuck at Thud.

Mans

Den fre 8 apr. 2022 kl 18:59 skrev Alexander Kanavin :
>
> Thud has been EOL for a long time. You can see when the support been
> added here (end of 2019 it seems):
> https://git.yoctoproject.org/poky/log/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next
>
> Alex
>
> On Fri, 8 Apr 2022 at 18:56, Måns  wrote:
> >
> > I am currently on Thud so I am missing the support from what I can
> > tell to set INCOMPATIBLE_LICENSE per image. I have tried to find the
> > commit that adds that support but am having some problems finding it.
> > Do you maybe know what I should look for to find the commit that adds
> > this support?
> >
> > Thanks
> >
> > Den fre 8 apr. 2022 kl 10:16 skrev Alexander Kanavin 
> > :
> > >
> > > Hello Mans,
> > >
> > > please refer to the tests we have for the feature:
> > > https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next#n95
> > > (line 95 and below)
> > >
> > > The key bit is:
> > > INCOMPATIBLE_LICENSE:pn-core-image-minimal = "GPL-3.0* LGPL-3.0*"
> > > e.g. apply the restriction only to core-image-minimal.
> > >
> > > Alex
> > >
> > > On Fri, 8 Apr 2022 at 08:06, Måns  wrote:
> > > >
> > > > Hi Alex,
> > > >
> > > > Could you maybe clarify what you mean with "setting
> > > > INCOMPATIBLE_LICENSE per image"? Do you mean that you have one
> > > > specific image that is used when you build an image for release to the
> > > > customer and then one image for development?
> > > >
> > > > Thanks
> > > >
> > > > Den ons 6 apr. 2022 kl 11:04 skrev Alexander Kanavin 
> > > > :
> > > > >
> > > > > I'd suggest you start by setting INCOMPATIBLE_LICENSE per image, e.g.
> > > > > enable gpl3 ban only in the images that ship to the customers and not
> > > > > across the entire build. Then carefully look at what pulls in bash
> > > > > into those images and why, and reconfigure those pieces to not do that
> > > > > (e.g. by reconfiguring the PACKAGECONFIGs), or rewrite the scripts in
> > > > > posix shell.
> > > > >
> > > > > Alex
> > > > >
> > > > > On Wed, 6 Apr 2022 at 10:59, Mans Zigher  
> > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I cannot use GPLv3 packages in our image build. I am no legal expert
> > > > > > but from what I can understand most companies will not be able to
> > > > > > comply with this license without allowing the customer to compile 
> > > > > > and
> > > > > > deploy a new version of any GPLv3 package to the target. I know it 
> > > > > > is
> > > > > > possible to comply with this but we are using secure boot and have 
> > > > > > not
> > > > > > the time and probably no interest in setting up a solution for
> > > > > > allowing customers to be able to deploy GPLv3 packages on the 
> > > > > > target.
> > > > > > We are trying to make use of INCOMPATIBLE_LICENSE but that results 
> > > > > > in
> > > > > > several issues. We have made sure that we don't include GPLv3 in the
> > > > > > image build using a manual process but would like to use
> > > > > > INCOMPATIBLE_LICENSE to alert any developer about the issue. It 
> > > > > > seems
> > > > > > like INCOMPATIBLE_LICENSE is a bit harsh since it will catch any
> > > > > > packages even if it is only part of the SDK and also for native
> > > > > > packages that are not part of the image build.
> > > > > >
> > > > > > I cannot be the only one with this problem so how are other 
> > > > > > companies
> > > > > > solving this issue? Are they just not using the 
> > > > > > INCOMPATIBLE_LICENSE?
> > > > > > Are you setting up a parallel process for checking for any
> > > > > > incompatible licenses issues?
> > > > > >
> > > > > > A more specific issue is that there are so many packages with bash
> > > > > > dependencies which are pulling in bash which is GPLv3 so how have 
> > > > > > you
> > > > > > solved that? Currently we have done some pretty uggly hacks which I 
> > > > > > am
> > > > > > not that happy with but we needed to keep it out of the image.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > 
> > > > > >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56715): https://lists.yoctoproject.org/g/yocto/message/56715
Mute This Topic: https://lists.yoctoproject.org/mt/90285507/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-