Date   

Re: cmake-based project with system lib dependency

Quentin Schulz
 

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
 

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@...>
 

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
 

Current Dev Position: YP 3.2 M3

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

 

Next Team Meetings:

 

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.

 

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:

 

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
 

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
 

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
 

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
 

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
 

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
 

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
 

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
 

Merged.

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
 

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.MIT
No need.

└── ice_helloworld
├── COPYING.MIT
No 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
 

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

-----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
 

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


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

Robert P. J. Day
 

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
 

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 ‐‐‐‐‐‐‐

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-Sdefaults 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
 

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
 

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.
 

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

2941 - 2960 of 53191