yocto@lists.yoctoproject.org

Re: cmake-based project with system lib dependency

Quentin Schulz

#50266

Hi Sergey,

On Tue, Aug 11, 2020 at 08:36:33PM +0300, Sergey Ivanov wrote:
Hi there.
I want to configure the cmake-based project with dependency on library
libuuid.
The latter is located under util-linux and populated in my
build/tmp/deploy/images/qemuarm/core-image-minimal-dev-qemuarm.manifest:

util-linux-dev armv7vet2hf_neon 2.35.1 (here should be header as well and
static library)
...
util-linux-uuidd armv7vet2hf_neon 2.35.1 (i believe the only library)
...
My bb file is:

SUMMARY = "Recipe to build the 'helloworld-cpp-direct-compile' in cpp"
SECTION = "common_templates"

SRC_URI = "file://CMakeLists.txt \
           file://foo.cpp \
           file://foo.h "
DEPENDS = "util-linux"

(DEPENDS is for build time dependencies and you add the recipe providing
the sources for it, RDEPENDS_${PN} is for runtime dependencies and you
add packages to it (it is common to have the same name for the recipe and
the main package built by it)).

inherit pkgconfig cmake

S = "${WORKDIR}"
OECMAKE_GENERATOR = "Unix Makefiles"
# project version seems to not be propagated properly
EXTRA_OECMAKE="-DCMAKE_PROJECT_VERSION=${PV}"


while my CMake file has:

pkg_check_modules(uuid REQUIRED IMPORTED_TARGET "uuid >= 2.25")


Now I obtain the error from cmake:
-- Checking for module 'uuid >= 2.25'
--   No package 'uuid' found
CMake Error at
recipe-sysroot-native/usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:467

What philosophy of yocto to make it work? In other words where 'stage' is
supposed to be located so pkgconfig will find library?
I can suggest watching/listening to Live Coding sessions done by Josef
available on Yocto project's Youtube channel:
https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj

It should help you get started and understand the basics.

Kind regards,
Quentin
-- 
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@streamunlimited.com, www.streamunlimited.com

Yocto Technical Team Minutes, Engineering Sync, for August 11 2020

Trevor Woerner

#50265

Yocto Technical Team Minutes, Engineering Sync, for August 11 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Armin Kuster, Bruce Ashfield, Jan-Simon
Möller, Tim Orling, Jeremey Puhlmann, Paul Barker, Mark Morton, Alejandro
H, Randy MacLeod, Michael Halstead, Richard Purdie, Trevor Gamblin,
(callin), Ross Burton, Peter Kjellerstedt, Steve Sakoman

== notes ==
- 3.2-M2 out of QA, in final release process, looks good
- now in 3.2-M3, last milestone for features
- 3.2-M4, in september, only for bug fixes
- 3.0.4 (last Zeus) should be built and out this week (if all goes well),
  this is the “stutter step”, then we go to 6 months
- some more AB failures added to the list
- some 3.2 bugs that don’t have owners

== general ==
RP: some “old” AB failures have reappeared, perhaps a lock file issue in
    bitbake
RP: there is a package data one that might be debuggable and reproducible

RP: relatively quiet week, a couple bitbake patches (<something?>, colourizing
    output)

MarkM: what’s the next step for sphinx?
RP: a list was made of the areas to work on (from Nico), we just need people
    to sign up
RP: the one I’m going to look at is how to get the versioning to work on the
    website

PaulB: meta-kernel layer, seems to be some issues with naming
Ross: we have been using meta-kernel, i can see an argument to rename to
    meta-mainline-kernel, perhaps, since meta-kernel is a bit generic
RP: my concern is that meta-kernel doesn’t convey what it does
PaulB: my intention was to make it a common place for common kernels (e.g.
    Linaro kernel can be used on a bunch of ARM boards). also my hope was to
    support back to kernels that aren’t “current” (e.g. 4.4). so it’s
    not just a “mainline” layer
RP: i believe there’s a way to get the mainline kernel with linux-yocto
PaulB: i need to be able to flick customers between, e.g. a 4.4 and a mainline
    quickly
TrevorW: the magic to get mainline with linux-yocto is to set
    PREFERRED_PROVIDER to linux-yocto-dev
RP: it’s a tricky situation, Bruce does a lot of work, sometimes work that
    doesn’t show up on the mailing list, I think collaborating with him
    would be a good approach. linux-yocto was created to reduce fragmentation.
    sometimes understanding linux-yocto can be tricky.
PaulB: maybe just carrying any differences that we need relative to
    linux-yocto might be better. some of my customers just want a raw mainline
    (with no other patches) since they also support e.g. Debian
Timo: one of the things i do over and over is explaining linux-yocto to people
    and how to use it
TrevorW: it was my intent to explain scc files and kernel patches with the
    last talk i gave at devday, if there are suggestions please let me know.
    hopefully those videos get published
Armin: one can use kernel branch overrides to use the v5.4/base (of
    linux-yocto.git)
RP: maybe we need more docs or information
PaulB: meta-kernel was meant to be lightweight, it doesn’t get as much
    testing as linux-yocto, it wasn’t meant to step on anyone’s toes
Timo: maybe this is an opportunity to take a look at the kernel development
    manual and make sure it is up to date
RP: maybe we could put a barebones kernel mainline recipe for the versions
    that are in each release (i’m not saying that’s a good idea, i’m
    just throwing out ideas), or maybe add more testing on AB for the
    variations of kernels that area already in each release (e.g. the -rt
    kernel)
PaulB: this all sounds good
TrevorW: a suggestion: rename recipes-kernel/linux to
    recipes-kernel/linux-yocto and then create a recipes-kernel/linux-mainline
    for PaulB’s work?
RP: that would only make sense under the assumption that this would be merged
    in oe-core
PaulB: we’re a ways off from that conversation, if ever
PaulB: i don’t think this is something that’s going to get resolved for
    M3, but maybe sometime after

cmake-based project with system lib dependency

Sergey Ivanov <icegood1980@...>

#50264

Hi there.

I want to configure the cmake-based project with dependency on library libuuid.

The latter is located under util-linux and populated in my
build/tmp/deploy/images/qemuarm/core-image-minimal-dev-qemuarm.manifest:

util-linux-dev armv7vet2hf_neon 2.35.1 (here should be header as well and static library)

...

util-linux-uuidd armv7vet2hf_neon 2.35.1 (i believe the only library)

...

My bb file is:

SUMMARY = "Recipe to build the 'helloworld-cpp-direct-compile' in cpp"
SECTION = "common_templates"

SRC_URI = "file://CMakeLists.txt \
file://foo.cpp \
file://foo.h "

inherit pkgconfig cmake

S = "${WORKDIR}"
OECMAKE_GENERATOR = "Unix Makefiles"
# project version seems to not be propagated properly
EXTRA_OECMAKE="-DCMAKE_PROJECT_VERSION=${PV}"

while my CMake file has:

pkg_check_modules(uuid REQUIRED IMPORTED_TARGET "uuid >= 2.25")

Now I obtain the error from cmake:
-- Checking for module 'uuid >= 2.25'
-- No package 'uuid' found
CMake Error at recipe-sysroot-native/usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:467

What philosophy of yocto to make it work? In other words where 'stage' is supposed to be located so pkgconfig will find library?

--

Kind regards,
Sergey Ivanov

Yocto Project Status WW32'20

Stephen Jolley

#50263

Current Dev Position: YP 3.2 M3

Next Deadline: YP 3.2 M3 build date 2020/8/31

Next Team Meetings:

Bug Triage meeting Thursday Aug. 13th at 7:30am PDT (https://zoom.us/j/454367603)
Monthly Project Meeting Tuesday Sept. 1st at 8am PDT (https://zoom.us/j/990892712)
Weekly Engineering Sync Tuesday Aug. 11th at 8am PDT (https://zoom.us/j/990892712)
Twitch - See https://www.twitch.tv/theyoctojester

Key Status/Updates:

YP 3.2 M2 is out of QA and going through release approval
We’re now in M3 which is the last milestone for new feature development for this release
YP 3.0.4 is due to be built this week and will be the last point release for zeus as we migrate over to our new LTS policy and cadence.
A number of new intermittent autobuilder failures were seen this week and logged in bugzilla including one showing signs of another bitbake lockfile race issue.
You can see the rest of the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated, unfortunately it is proving hard to find anyone interested in helping figure these out and they significantly hamper our testing.

One way to help the project is to help us with bugs that are currently unassigned but ideally needed during YP 3.2. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhancements.2FBugs
Help with any of the recent failed AUH recipe upgrades would also be appreciated.

YP 3.2 Milestone Dates:

YP 3.2 M2 should release soon.
YP 3.2 M3 build date 2020/8/31
YP 3.2 M3 Release date 2020/9/11
YP 3.2 M4 build date 2020/10/5
YP 3.2 M4 Release date 2020/10/30

Planned upcoming dot releases:

YP 3.0.4 build date 2020/8/10
YP 3.0.4 release date 2020/8/21
YP 3.1.3 build date 2020/9/14
YP 3.1.3 release date 2020/9/25

Tracking Metrics:

WDD 2404 (last week 2402) (https://wiki.yoctoproject.org/charts/combo.html)
Poky Patch Metrics

Total patches found: 1280 (last week 1271)
Patches in the Pending State: 500 (39%) [last week 495 (39%)]

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

* Email: sjolley.yp.pm@...

Re: libtool: library search path "/usr/lib" is unsafe for cross-compilation

Ross Burton

#50262

It's probably because the configure.ac or similar hard-codes a search
in /usr for some libraries and find them there.  This is *entirely* a
bug in the clamav configure.ac and you'll have to inspect it to
determine what library it is looking for, whether it can be turned
off, or whether it should be added as a build dependency in the
recipe.

Ross

On Tue, 11 Aug 2020 at 11:07, Charlie Davies
<charles.davies@whitetree.xyz> wrote:

Hi,

Are there any ideas as to why the issue above is happening?

Thanks,

Charlie

Re: libtool: library search path "/usr/lib" is unsafe for cross-compilation

Charlie Davies

#50261

Hi,

Are there any ideas as to why the issue above is happening?

Thanks,

Charlie

[meta-security][PATCH] sssd: Avoid nss function conflicts with glibc nss.h

hongxu

#50260

glibc 2.32 will define these varibles [1] which results in conflicts
with these static function names, backport a fix from upstream

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=499a92df8b9fc64a054cf3b7f728f8967fc1da7d

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 ...s-Collision-with-external-nss-symbol.patch | 77 +++++++++++++++++++
 recipes-security/sssd/sssd_1.16.4.bb          |  1 +
 2 files changed, 78 insertions(+)
 create mode 100644 recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch

diff --git a/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch b/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch
new file mode 100644
index 0000000..9c2bbec
--- /dev/null
+++ b/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch
@@ -0,0 +1,77 @@
+From a069e4186a3cb482226005d4bc73c6fb3dd35c79 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michal=20=C5=BDidek?= <mzidek@redhat.com>
+Date: Thu, 27 Feb 2020 06:50:40 +0100
+Subject: [PATCH] nss: Collision with external nss symbol
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+One of our internal static function names started
+to collide with external nss symbol. Additional
+sss_ suffix was added to avoid the collision.
+
+This is needed to unblock Fedora Rawhide's
+SSSD build.
+
+Reviewed-by: Pavel Březina <pbrezina@redhat.com>
+
+Upstream-Status: Backport [https://github.com/SSSD/sssd.git]
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ src/responder/nss/nss_cmd.c | 18 ++++++++++--------
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+diff --git a/src/responder/nss/nss_cmd.c b/src/responder/nss/nss_cmd.c
+index 25e663e..a4d4cfc 100644
+--- a/src/responder/nss/nss_cmd.c
++++ b/src/responder/nss/nss_cmd.c
+@@ -728,11 +728,13 @@ done:
+     talloc_free(cmd_ctx);
+ }
+ 
+-static void nss_setnetgrent_done(struct tevent_req *subreq);
++static void sss_nss_setnetgrent_done(struct tevent_req *subreq);
+ 
+-static errno_t nss_setnetgrent(struct cli_ctx *cli_ctx,
+-                               enum cache_req_type type,
+-                               nss_protocol_fill_packet_fn fill_fn)
++/* This function's name started to collide with external nss symbol,
++ * so it has additional sss_* prefix unlike other functions here. */
++static errno_t sss_nss_setnetgrent(struct cli_ctx *cli_ctx,
++                                   enum cache_req_type type,
++                                   nss_protocol_fill_packet_fn fill_fn)
+ {
+     struct nss_ctx *nss_ctx;
+     struct nss_state_ctx *state_ctx;
+@@ -774,7 +776,7 @@ static errno_t nss_setnetgrent(struct cli_ctx *cli_ctx,
+         goto done;
+     }
+ 
+-    tevent_req_set_callback(subreq, nss_setnetgrent_done, cmd_ctx);
++    tevent_req_set_callback(subreq, sss_nss_setnetgrent_done, cmd_ctx);
+ 
+     ret = EOK;
+ 
+@@ -787,7 +789,7 @@ done:
+     return EOK;
+ }
+ 
+-static void nss_setnetgrent_done(struct tevent_req *subreq)
++static void sss_nss_setnetgrent_done(struct tevent_req *subreq)
+ {
+     struct nss_cmd_ctx *cmd_ctx;
+     errno_t ret;
+@@ -1037,8 +1039,8 @@ static errno_t nss_cmd_initgroups_ex(struct cli_ctx *cli_ctx)
+ 
+ static errno_t nss_cmd_setnetgrent(struct cli_ctx *cli_ctx)
+ {
+-    return nss_setnetgrent(cli_ctx, CACHE_REQ_NETGROUP_BY_NAME,
+-                           nss_protocol_fill_setnetgrent);
++    return sss_nss_setnetgrent(cli_ctx, CACHE_REQ_NETGROUP_BY_NAME,
++                               nss_protocol_fill_setnetgrent);
+ }
+ 
+ static errno_t nss_cmd_getnetgrent(struct cli_ctx *cli_ctx)
+-- 
+2.21.0
+
diff --git a/recipes-security/sssd/sssd_1.16.4.bb b/recipes-security/sssd/sssd_1.16.4.bb
index 2c3c803..d66c027 100644
--- a/recipes-security/sssd/sssd_1.16.4.bb
+++ b/recipes-security/sssd/sssd_1.16.4.bb
@@ -17,6 +17,7 @@ SRC_URI = "https://releases.pagure.org/SSSD/${BPN}/${BP}.tar.gz \
            file://sssd.conf \
            file://volatiles.99_sssd \
            file://fix-ldblibdir.patch \
+           file://0001-nss-Collision-with-external-nss-symbol.patch \
            "
 
 SRC_URI[md5sum] = "757bbb6f15409d8d075f4f06cb678d50"
-- 
2.21.0

M+ & H bugs with Milestone Movements WW32

Stephen Jolley

#50259

All,

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

Priority	Bug ID	Short Description	Changer	Owner	Was	Became
Medium+	5322	Global DNS fallback mechanism not present in poky distro	kai.kang@...	kai.kang@...	3.2 M2	3.2 M3
	11449	Allow overriding classes to override overridden classes	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	11746	oe-selftest: capture self.logger messages in XML output	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	11766	nobody group added by systemd sysusers.d	yi.zhao@...	yi.zhao@...	3.2 M2	3.2 M3
	12060	It is possible to specify a PACKAGE and a PKG_ rename that conflict	kai.kang@...	kai.kang@...	3.2 M2	3.2 M3
	12090	bitbake resident server reconnect needed ?	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	12279	enhance manifest not found warning	kai.kang@...	kai.kang@...	3.2 M2	3.2 M4
	12368	persistent bitbake server does not re-parse if previous build was ctrl+C'd	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	12723	mysql requires unicode and char length filtering	david.reyna@...	david.reyna@...	3.2 M2	3.2 M3
	12970	uninative file should be versionned	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	12986	Failed to expand SRCPV on updateding SRC_URI using pn overrides and BBCLASSEXTEND	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13008	toaster testing	david.reyna@...	david.reyna@...	3.2 M2	3.2 M3
	13025	WIC image install support	kexin.hao@...	kexin.hao@...	3.2 M2	3.3
	13109	Implement CPE to package to Release mapping	david.reyna@...	david.reyna@...	3.2 M2	3.2 M3
	13103	[Bug][QA 2.7 M1 rc1][Toaster] "Recipes" table┬á and ┬á"machines" table are not getting populated after clicking┬áon imported layer as well as after clicking Machines Tab on project page	david.reyna@...	david.reyna@...	3.2 M2	3.2 M3
	13123	package.PackageTests.test_gdb_hardlink_debug failed	randy.macleod@...	randy.macleod@...	3.2 M2	3.2 M3
	13183	bitbake-layers crashes with incorrect layer configuration data is given (expected proper error printing and exit with error)	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13278	If git protocol doesn't work, you get a tar.gz clone from PREMIRROR which has git protocol origin	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13325	Add link to the output directory from LHS console view	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13355	RDEPENDS does not work properly for native builds (only supports recipe names, not package names)	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13424	devupstream doesn't work with mutilib	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13448	bitbake master appears to expand variables it should not need to	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13459	sdk: compiler targets glibc, even though rootfs uses musl-libc	randy.macleod@...	randy.macleod@...	3.2 M2	3.2 M3
	13520	many valgrind tests fail for arm64	randy.macleod@...	randy.macleod@...	3.2 M2	3.2 M4
	13599	Enhancement: Detect variables that shouldn't be defined in image scope, but in global (distro) scope	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13642	Split single "run-config" step into multiple steps	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13646	runtime tests sometimes can't login to the serial console on systemd images (generates warning)	kai.kang@...	kai.kang@...	3.2 M2	3.2 M3
	13669	Move Toaster testsuite-2 away from Testopia	david.reyna@...	david.reyna@...	3.2 M2	3.2 M3
	13676	selftest test_gdb_hardlink_debug failure	randy.macleod@...	randy.macleod@...	3.2 M2	3.2 M3
	13699	Prolonged recipe parsing times after removing tmp when the resident bitbake server is used	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13711	Parsing fails on externalsrc recipe containing both git and file in SRC_URI	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13729	Changing siteinfo files doesn't change task checksum	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13766	Using TCLIB=musl results in SDKs producing incompatible binaries	randy.macleod@...	randy.macleod@...	3.2 M2	3.2 M3
	13823	fetch2: PREMIRROR and SRC_URI with users on both url yields invalid username	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13838	[QA 3.1 M3 RC1] failure in ptest: valgrind.drd/tests/bar_bad and valgrind.drd/tests/bar_bad_xml	randy.macleod@...	randy.macleod@...	3.2 M2	3.2 M3
	13886	bitbake resident server does not honour --runonly or --runall options	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13891	insane.bbclass: do_package_qa hangs when checking a FIFO (named pipe) file	richard.purdie@...	richard.purdie@...	3.2 M2	3.2 M3
	13951	[QA 3.2 M1 RC1] failure in ptest: valgrind.memcheck/tests/badfree3 and valgrind.memcheck/tests/varinfo5	randy.macleod@...	randy.macleod@...	3.2 M2	3.2 M3

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

* Email: sjolley.yp.pm@...

Enhancements/Bugs closed WW32!

Stephen Jolley

#50258

All,

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

Who	Count
ross@...	2
akuster@...	1
timothy.t.orling@...	1
Grand Total	4

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

* Email: sjolley.yp.pm@...

Current high bug count owners for Yocto Project 3.2

Stephen Jolley

#50257

All,

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

Who	Count
david.reyna@...	10
ross@...	8
bluelightning@...	7
richard.purdie@...	7
mark.morton@...	7
michael@...	5
Qi.Chen@...	5
raj.khem@...	3
kai.kang@...	2
trevor.gamblin@...	2
randy.macleod@...	2
chee.yang.lee@...	2
yi.zhao@...	2
sakib.sajal@...	2
timothy.t.orling@...	2
kergoth@...	2
JPEWhacker@...	2
rpjday@...	2
kai.ruhnau@...	1
mostthingsweb@...	1
mark.hatle@...	1
liu.ming50@...	1
matthew.zeng@...	1
hongxu.jia@...	1
maxime.roussinbelanger@...	1
jpuhlman@...	1
jaewon@...	1
matt.ranostay@...	1
changqing.li@...	1
bruce.ashfield@...	1
Grand Total	84

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

* Email: sjolley.yp.pm@...

Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley

#50256

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

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 340 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.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then “3.2”.

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

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

* Email: sjolley.yp.pm@...

Re: [meta-cgl][PATCH] ucarp: force to use TLS1.2 during do_fetch

Jeremy Puhlman

#50255

Merged.

Show quoted text

On 8/9/2020 6:04 PM, Yu, Mingli wrote:
ping.

Thanks,

On 7/17/20 3:38 PM, Yu, Mingli wrote:
From: Mingli Yu <mingli.yu@windriver.com>

There comes below error when use buildtools [1]:
$ bitbake -cfetch ucarp
[snip]
--2020-07-17 06:39:31-- 
https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
Resolving download.pureftpd.org... 37.59.238.213
Connecting to download.pureftpd.org|37.59.238.213|:443... connected.
GnuTLS: A TLS fatal alert has been received.
GnuTLS: received alert [70]: Error in protocol version
Unable to establish SSL connection.

And can simply use below step to reproduce the above error.
$ wget https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
--2020-07-17 06:43:36-- 
https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
Resolving download.pureftpd.org... 37.59.238.213
Connecting to download.pureftpd.org|37.59.238.213|:443... connected.
GnuTLS: A TLS fatal alert has been received.
GnuTLS: received alert [70]: Error in protocol version
Unable to establish SSL connection.

$ wget --version
GNU Wget 1.20.3 built on linux-gnu.

Currently wget uses gnutls as the ssl backend as the below logic
in layers/openembedded-core/meta/recipes-extended/wget/wget.inc
PACKAGECONFIG[gnutls] = "--with-ssl=gnutls,,gnutls"

Check the link https://download.pureftpd.org/pub/ucarp/ and found
the file https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
already 10 years ago.
ucarp-1.5.2.tar.gz                                 31-Jan-2010 22:06              429089

Meanwhile we can use gnutls-cli-debug to diagnose the download.pureftpd.org
which hosts ucarp and it doesn't support TLS 1.3 but supports TLS 1.2 instead
as below.
$ gnutls-cli-debug 37.59.238.213
GnuTLS debug client 3.6.4
Checking 37.59.238.213:443
                         whether we need to disable TLS 1.2... no
                         whether we need to disable TLS 1.1... no
                         whether we need to disable TLS 1.0... no
                         whether %NO_EXTENSIONS is required... no
                                whether %COMPAT is required... yes
                              for TLS 1.0 (RFC2246) support... no
  for TLS 1.0 (RFC2246) support with TLS 1.0 record version... no
                              for TLS 1.1 (RFC4346) support... no
                                   fallback from TLS 1.1 to... failed
                              for TLS 1.2 (RFC5246) support... yes
                              for TLS 1.3 (RFC8446) support... no
[snip]

$ wget --secure-protocol=TLSv1_2 https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
--2020-07-17 07:07:08-- 
https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
Resolving download.pureftpd.org... 37.59.238.213
Connecting to download.pureftpd.org|37.59.238.213|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 429089 (419K) [text/plain]
Saving to: 'ucarp-1.5.2.tar.gz'

ucarp-1.5.2.tar.gz  100%[===================>] 419.03K 432KB/s    in 1.0s

2020-07-17 07:07:16 (432 KB/s) - 'ucarp-1.5.2.tar.gz' saved [429089/429089]

Considering gnutls doesn't fallback to TLS 1.2 automatically, so force ucarp
to use TLS1.2 to fix the above do_fetch error.

[1] https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#building-your-own-buildtools-tarball

Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
  meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
index 6f30bf7..d17baa0 100644
--- a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
+++ b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
@@ -34,7 +34,7 @@ DEPENDS = "libpcap"
    SYSTEMD_SERVICE_${PN} = "ucarp.service"
  SYSTEMD_AUTO_ENABLE = "disable"
-
+export FETCHCMD_wget = "/usr/bin/env wget --secure-protocol=TLSv1_2 -t 2 -T 30 --passive-ftp --no-check-certificate"
  EXTRA_OECONF += "--sysconfdir=${sysconfdir}/${BPN}"
    # fix the perms for config.rpath

-- 
Jeremy A. Puhlman
jpuhlman@mvista.com

Re: yocto compile simple c++

Quentin Schulz

#50254

Hi Sergey,

On Sat, Aug 08, 2020 at 12:12:40PM +0300, Sergey Ivanov wrote:
Hi there.
I'm newbie ib yocto and (of course) nothing works for me from scratch.
For testing purposes, i work with yocto 3.1 based on
5d47cdf448b6cff5bb7cc5b0ba0426b8235ec478 rev aka dunfell-23.0.0
MACHINE ?= "qemuarm" and DISTRO ?= "poky" (btw i tried poky-tony as well
but machine didn't start properly under qemu)

I created my new layer with next structure:
.
├── conf
│   └── layer.conf
├── COPYING.MIT
├── README
└── recipes-ice
    ├── COPYING.MITNo need.

    └── ice_helloworld
        ├── COPYING.MITNo need.

        ├── files
        │   ├── COPYING.MIT
        │   └── ice_helloworld.cpp
        └── ice_helloworld_0.1.bb

(i copied COPYING.MIT to )every single place because of error below) and i
obtained:

NOTE: Executing Tasks
WARNING: ice_helloworld-helloworld-0.1 do_populate_lic: Could not copy
license file
/media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/ice_helloworld-helloworld/COPYING.MIT
to
/media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/license-destdir/ice_helloworld/COPYING.MIT:
[Errno 2] No such file or directory:
'/media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/ice_helloworld-helloworld/COPYING.MIT'
ERROR: ice_helloworld-helloworld-0.1 do_populate_lic: QA Issue:
ice_helloworld: LIC_FILES_CHKSUM points to an invalid file:
/media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/ice_helloworld-helloworld/COPYING.MIT
[license-checksum]
ERROR: ice_helloworld-helloworld-0.1 do_populate_lic: Fatal QA errors
found, failing task.
ERROR: Logfile of failure stored in:
/media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/temp/log.do_populate_lic.133477
ERROR: Task
(/media/ice/slow_ext4/yocto_poky/meta-ice_layer/recipes-ice/ice_helloworld/ice_helloworld_0.1.bb:do_populate_lic)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 216 tasks of which 214 didn't need to be
rerun and 1 failed.




my bb file is:

SUMMARY = "Recipe to build the 'helloworld' in cpp"
SECTION = "ice"
LICENSE="MIT"
#LICENSE_PATH += "${LAYERDIR}"

PN = "ice_helloworld"No need, default is the name of the recipe file.

PV = "0.1"
No need, default is the version in the recipe file (if there's one).

meta-ice_layer/recipes-ice/ice_helloworld/ice_helloworld_0.1.bb will
produce:
PN = "ice_helloworld"
PV = "0.1"

SITE = "file://"
PACKAGE_VERSION_MAJOR = "${@bb.data.getVar('PV',d,1).split('.')[0]}"
PACKAGE_VERSION_MINOR = "${@bb.data.getVar('PV',d,1).split('.')[1]}"

SRC_URI = "${SITE}${PN}.cpp"SRC_URI = "${SITE}/${PN}.cpp"

SRC_URI[md5sum] = "bc9dc64a44f9685d0310b94400a4631c"
SRC_URI[sha256sum] =
"789e60072ea96371a35d5653d664b4c4b91e80ce2ea6d523d6caedab06a07a2a"
LIC_FILES_CHKSUM = "${SITE}COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
LIC_FILES_CHKSUM = "${SITE}/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

do_compile() {
    ${CXX} ${PN}.cpp -o ${PN}
}
Create a makefile/cmake instead, the logic of compiling your SW shouldn't be
in a build system.

do_install() {
    install -d ${D}${bindir}
    install -m 0755 ${PN} ${D}${bindir}
}
Same, create an install target in your makefile. If you do this well,
you don't even need your do_compile and do_install, it'll be
"automagical".

what could be wrong here?
-- 1. Missing / in your paths.

2. Also, **never** put uppercase letter or underscores in the name of
a recipe. So your recipe should be:
meta-ice_layer/recipes-ice/ice-helloworld/ice-helloworld_0.1.bb

The underscore is used in multiple places internally to separate
things so using an underscore is breaking some things in weird ways.

Fix 1 and 2 at least, create a makefile for added best practices.

Kind regards,
Quentin

Re: QA notification for completed autobuilder build (yocto-3.2_M2.rc1)

Sangeeta Jain

#50253

Hi all,

This is the full report for yocto-3.2_M2.rc1:  
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.  
No new defects are found in this cycle.

libinput ptest failed (BUG id:13997)

======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13997

Thanks,
Sangeeta

Show quoted text

-----Original Message-----
From: Poky Build User <pokybuild@debian-9-ty2.yocto.io>
Sent: Thursday, 30 July, 2020 3:34 AM
To: yocto@lists.yoctoproject.org
Cc: otavio@ossystems.com.br; yi.zhao@windriver.com; Sangal, Apoorv
<apoorv.sangal@intel.com>; Yeoh, Ee Peng <ee.peng.yeoh@intel.com>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@intel.com>;
richard.purdie@linuxfoundation.org; akuster808@gmail.com;
sjolley.yp.pm@gmail.com; Jain, Sangeeta <sangeeta.jain@intel.com>
Subject: QA notification for completed autobuilder build (yocto-3.2_M2.rc1)


A build flagged for QA (yocto-3.2_M2.rc1) was completed on the autobuilder
and is available at:


    https://autobuilder.yocto.io/pub/releases/yocto-3.2_M2.rc1


Build hash information:

bitbake: 91b809a0902ffd42be4edf7f0a7d25e6d354d822
meta-arm: 5ceb140f37195c1837b377828d13de3f9a351ffd
meta-gplv2: a8da8eb127a56561bf633ab53bec57fb5dbba537
meta-intel: 31840bc6cf6e1d86ef911ea214da2169a3c885ca
meta-kernel: 58a589c5aad5417abd099a961e3c1a5b083cdb90
meta-mingw: c8a0d13a5525fb4acc6da9793ad102b4fc5c141b
oecore: cdbd47dd7e1657b91b65a0940b7cbf119764240f
poky: 20e9df57217c5f37817653d2c3d492f2d4d37623



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org

Re: [meta-cgl][PATCH] ucarp: force to use TLS1.2 during do_fetch

Yu, Mingli

#50252

ping.

Thanks,

Show quoted text

On 7/17/20 3:38 PM, Yu, Mingli wrote:
From: Mingli Yu <mingli.yu@windriver.com>
There comes below error when use buildtools [1]:
$ bitbake -cfetch ucarp
[snip]
--2020-07-17 06:39:31--  https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
Resolving download.pureftpd.org... 37.59.238.213
Connecting to download.pureftpd.org|37.59.238.213|:443... connected.
GnuTLS: A TLS fatal alert has been received.
GnuTLS: received alert [70]: Error in protocol version
Unable to establish SSL connection.
And can simply use below step to reproduce the above error.
$ wget https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
--2020-07-17 06:43:36--  https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
Resolving download.pureftpd.org... 37.59.238.213
Connecting to download.pureftpd.org|37.59.238.213|:443... connected.
GnuTLS: A TLS fatal alert has been received.
GnuTLS: received alert [70]: Error in protocol version
Unable to establish SSL connection.
$ wget --version
GNU Wget 1.20.3 built on linux-gnu.
Currently wget uses gnutls as the ssl backend as the below logic
in layers/openembedded-core/meta/recipes-extended/wget/wget.inc
PACKAGECONFIG[gnutls] = "--with-ssl=gnutls,,gnutls"
Check the link https://download.pureftpd.org/pub/ucarp/ and found
the file https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
already 10 years ago.
ucarp-1.5.2.tar.gz                                 31-Jan-2010 22:06              429089
Meanwhile we can use gnutls-cli-debug to diagnose the download.pureftpd.org
which hosts ucarp and it doesn't support TLS 1.3 but supports TLS 1.2 instead
as below.
$ gnutls-cli-debug 37.59.238.213
GnuTLS debug client 3.6.4
Checking 37.59.238.213:443
                         whether we need to disable TLS 1.2... no
                         whether we need to disable TLS 1.1... no
                         whether we need to disable TLS 1.0... no
                         whether %NO_EXTENSIONS is required... no
                                whether %COMPAT is required... yes
                              for TLS 1.0 (RFC2246) support... no
  for TLS 1.0 (RFC2246) support with TLS 1.0 record version... no
                              for TLS 1.1 (RFC4346) support... no
                                   fallback from TLS 1.1 to... failed
                              for TLS 1.2 (RFC5246) support... yes
                              for TLS 1.3 (RFC8446) support... no
[snip]
$ wget --secure-protocol=TLSv1_2 https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
--2020-07-17 07:07:08--  https://download.pureftpd.org/pub/ucarp/ucarp-1.5.2.tar.gz
Resolving download.pureftpd.org... 37.59.238.213
Connecting to download.pureftpd.org|37.59.238.213|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 429089 (419K) [text/plain]
Saving to: 'ucarp-1.5.2.tar.gz'
ucarp-1.5.2.tar.gz  100%[===================>] 419.03K   432KB/s    in 1.0s
2020-07-17 07:07:16 (432 KB/s) - 'ucarp-1.5.2.tar.gz' saved [429089/429089]
Considering gnutls doesn't fallback to TLS 1.2 automatically, so force ucarp
to use TLS1.2 to fix the above do_fetch error.
[1] https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#building-your-own-buildtools-tarball
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
  meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
index 6f30bf7..d17baa0 100644
--- a/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
+++ b/meta-cgl-common/recipes-cgl/ucarp/ucarp_1.5.2.bb
@@ -34,7 +34,7 @@ DEPENDS = "libpcap"
  SYSTEMD_SERVICE_${PN} = "ucarp.service"
  SYSTEMD_AUTO_ENABLE = "disable"
-
+export FETCHCMD_wget = "/usr/bin/env wget --secure-protocol=TLSv1_2 -t 2 -T 30 --passive-ftp --no-check-certificate"
  EXTRA_OECONF += "--sysconfdir=${sysconfdir}/${BPN}"
  # fix the perms for config.rpath

dunfell: what would cause "ERROR: Nothing PROVIDES 'coreutils-native'."?

Robert P. J. Day

#50251

migrating from zeus to dunfell and, suddenly, some "ndisc"-related recipes no
longer build with:

  ERROR: Nothing PROVIDES 'coreutils-native'.

the offending recipe is from meta-networking/recipes-support, ndisc6_git.bb,
clearly at the line:

  DEPENDS = "coreutils-native"

whereupon "git blame" informs me that that line comes from here:

  commit 51272d11594e8609237e0e049b1f97ff95ab7d19
  Author: Sumit Garg <sumit.garg@linaro.org>
  Date:   Tue Jan 21 14:26:11 2020 +0530

    ndisc6: fix coreutils-native tool dependency

    coreutils-native tool dependency was implicitly met while building with
    source GCC tool-set which isn't the case with external tool-set.

    Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
    Signed-off-by: Khem Raj <raj.khem@gmail.com>

i've examined dunfell's coreutils recipe and i see nothing that suggests
i shouldn't be able to bitbake the native recipe -- BBCLASSEXTEND clearly
extends the recipe to include "native." so now i'm looking at the local
layer to see if there is something in a .conf file that deactivates the
native building of coreutils but i don't see anything suspicious.

  i'm sure i'm missing something obvious but i'm at a loss. thoughts?

rday

Re: yocto compile simple c++

codusnocturnus

#50250

I see. If you're going to provide the license with the recipe or code, then it needs to be in a subdirectory under the recipe file. So the only one in your tree that matters for this is .../recipes-ice/files/COPYING.MIT.

Then you will need to explicitly list it in SRC_URI:

SRC_URI = "${SITE}${PN}.cpp \

${SITE}COPYING.MIT"

An alternative, for common licenses, is to use a link like this:

LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

You will still need this for your recipe to find the license or your source file:

S = "${WORKDIR}"

Thanks,

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Show quoted text

On Sunday, August 9, 2020 2:48 AM, Sergey Ivanov <icegood1980@...> wrote:

Hi. Unfortunately i tried it and it is not my case. To be precise, i don't see COPYING.MIT at any sibfolder of
/media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld
at all...

сб, 8 авг. 2020 г. в 14:31, codusnocturnus via lists.yoctoproject.org <codusnocturnus=protonmail.com@...>:
Bitbake is unable to find the license file because it's looking in the wrong place. If you look at the contents of /media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/ice_helloworld-helloworld/ , you will probably find it to be empty, and you will find COPYING.MIT in the directory above it.

The reason is that ${S} (see https://www.yoctoproject.org/docs/3.1.2/ref-manual/ref-manual.html#var-S) defaults to a location where a tarball would be unpacked, but your recipe isn't using a tarball.

Add the following to your recipe:
S = "${WORKDIR}"

Thanks,

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, August 8, 2020 2:12 AM, Sergey Ivanov <icegood1980@...> wrote:

Hi there.
I'm newbie ib yocto and (of course) nothing works for me from scratch.
For testing purposes, i work with yocto 3.1 based on 5d47cdf448b6cff5bb7cc5b0ba0426b8235ec478 rev aka dunfell-23.0.0
MACHINE ?= "qemuarm" and DISTRO ?= "poky" (btw i tried poky-tony as well but machine didn't start properly under qemu)

I created my new layer with next structure:
.
├── conf
│   └── layer.conf
├── COPYING.MIT
├── README
└── recipes-ice
├── COPYING.MIT
└── ice_helloworld
├── COPYING.MIT
├── files
│   ├── COPYING.MIT
│   └── ice_helloworld.cpp
└── ice_helloworld_0.1.bb

(i copied COPYING.MIT to )every single place because of error below) and i obtained:

NOTE: Executing Tasks
WARNING: ice_helloworld-helloworld-0.1 do_populate_lic: Could not copy license file /media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/ice_helloworld-helloworld/COPYING.MIT to /media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/license-destdir/ice_helloworld/COPYING.MIT: [Errno 2] No such file or directory: '/media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/ice_helloworld-helloworld/COPYING.MIT'
ERROR: ice_helloworld-helloworld-0.1 do_populate_lic: QA Issue: ice_helloworld: LIC_FILES_CHKSUM points to an invalid file: /media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/ice_helloworld-helloworld/COPYING.MIT [license-checksum]
ERROR: ice_helloworld-helloworld-0.1 do_populate_lic: Fatal QA errors found, failing task.
ERROR: Logfile of failure stored in: /media/ice/slow_ext4/yocto_poky/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ice_helloworld/helloworld-0.1/temp/log.do_populate_lic.133477
ERROR: Task (/media/ice/slow_ext4/yocto_poky/meta-ice_layer/recipes-ice/ice_helloworld/ice_helloworld_0.1.bb:do_populate_lic) failed with exit code '1'
NOTE: Tasks Summary: Attempted 216 tasks of which 214 didn't need to be rerun and 1 failed.

my bb file is:

SUMMARY = "Recipe to build the 'helloworld' in cpp"
SECTION = "ice"
LICENSE="MIT"
#LICENSE_PATH += "${LAYERDIR}"

PN = "ice_helloworld"
PV = "0.1"

SITE = "file://"
PACKAGE_VERSION_MAJOR = "${@bb.data.getVar('PV',d,1).split('.')[0]}"
PACKAGE_VERSION_MINOR = "${@bb.data.getVar('PV',d,1).split('.')[1]}"

SRC_URI = "${SITE}${PN}.cpp"
SRC_URI[md5sum] = "bc9dc64a44f9685d0310b94400a4631c"
SRC_URI[sha256sum] = "789e60072ea96371a35d5653d664b4c4b91e80ce2ea6d523d6caedab06a07a2a"
LIC_FILES_CHKSUM = "${SITE}COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

do_compile() {
${CXX} ${PN}.cpp -o ${PN}
}

do_install() {
install -d ${D}${bindir}
install -m 0755 ${PN} ${D}${bindir}
}
what could be wrong here?
--
Kind regards,
Sergey Ivanov

--
Kind regards,
Sergey Ivanov

does yocto "LTS" stand for "Long Term Support" or "Long Term Stable"?

Robert P. J. Day

#50249

i've seen two different wiki pages suggest each of the above ... it
would be nice to be consistent.

rday

Re: [meta-cgl][PATCH] ucarp: don't hardcode the path for ifconfig

Jeremy Puhlman

#50248

Merged.

On 8/7/2020 1:47 AM, Yu, Mingli wrote:

From: Mingli Yu <mingli.yu@...>

Don't hardcode the path for the ifconfig command in case the path
for ifconfig on the system may be different from the hardcoded.

Signed-off-by: Mingli Yu <mingli.yu@...>
---
 meta-cgl-common/recipes-cgl/ucarp/ucarp/vip-down.sh | 2 +-
 meta-cgl-common/recipes-cgl/ucarp/ucarp/vip-up.sh   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-cgl-common/recipes-cgl/ucarp/ucarp/vip-down.sh b/meta-cgl-common/recipes-cgl/ucarp/ucarp/vip-down.sh
index a431c32..27e0d2b 100644
--- a/meta-cgl-common/recipes-cgl/ucarp/ucarp/vip-down.sh
+++ b/meta-cgl-common/recipes-cgl/ucarp/ucarp/vip-down.sh
@@ -4,4 +4,4 @@ exec 2> /dev/null
 #/sbin/ip addr del "$2"/24 dev "$1"
 
 # or alternatively:
-/sbin/ifconfig "$1":254 down
+ifconfig "$1":254 down
diff --git a/meta-cgl-common/recipes-cgl/ucarp/ucarp/vip-up.sh b/meta-cgl-common/recipes-cgl/ucarp/ucarp/vip-up.sh
index c1b8a4f..f81d578 100644
--- a/meta-cgl-common/recipes-cgl/ucarp/ucarp/vip-up.sh
+++ b/meta-cgl-common/recipes-cgl/ucarp/ucarp/vip-up.sh
@@ -4,4 +4,4 @@ exec 2> /dev/null
 #/sbin/ip addr add "$2"/24 dev "$1"
 
 # or alternatively:
-/sbin/ifconfig "$1":254 "$2" netmask 255.255.255.0 
+ifconfig "$1":254 "$2" netmask 255.255.255.0

-- 
Jeremy A. Puhlman
jpuhlman@...

Re: Yocto build failure -- supposedly due to opkg-4.2 download

Alex G.

#50247

On 8/4/20 2:07 PM, akuster808 wrote:
On 8/4/20 12:00 PM, Alex G. wrote:
Hi,

I'm trying to get started with yocto builds. My builds keep failing trying to build the qemu-x86 image.If I am not mistaken, many of the servers are down including downloads.yoctoproject.org.That was it. Waited a day, and then I was able to build. Thank you!

Alex