Date   

Re: do_unpack() ISO Image

Richard Purdie
 

On Thu, 2020-09-17 at 20:09 -0700, Chuck Wolber wrote:

Hi all,

I have a need to unpack an ISO image during do_unpack. This does not
appear to be one of the extensions that is handled by default, so I
am working out a way to use xorriso to do this for me.

I can get this to work in the following way, but it involves calling
an executable running on the build host, which only works by luck
since the host executable is the same architecture as what I am
currently building. I would like to do this in a portable way that
does not break when I try to build for a different architecture.

DEPENDS += "xorriso"

do_unpack_append() {
bb.build.exec_func('unpack_iso', d)
}

unpack_iso() {
/usr/bin/xorriso -osirrox on -indev ${WORKDIR}/${PN}_${PV}.iso
-extract / ${S}
}


From looking at base.bbclass, it _seems_ as if my solution involves
something like this:

d.appendVarFlag('do_unpack', 'depends', '
xorriso:do_populate_sysroot')

But it is unclear exactly where that would go within my recipe. Any
thoughts?
You can do the same thing with:

do_unpack[depends] += " xorriso:do_populate_sysroot"

but note that you want xorriso-native, not xorriso.

Cheers,

Richard


Re: Yocto recipe for Tailscale #yocto #golang

Nicolas Jeker
 

Hi Mike,

On Thu, 2020-09-17 at 22:43 -0700, Mike Thompson via
lists.yoctoproject.org wrote:
Does anyone know if there is an existing bitbake recipe for building
the Tailscale client daemon and CLI tool from the following source?
A search on Google yielded no obvious links.

https://github.com/tailscale/tailscale
I usually search on the OpenEmbedded layer index:
http://layers.openembedded.org/layerindex/branch/master/recipes/?q=tailscale

Seems like you are right, there seems to be no recipe available. Be
aware that not all recipes/layers are listed there, but the majority
are.


The Tailscale client for Linux looks to be built using the Go
language which is a complete unknown to me. I've built very simple
recipes before for basic Makefile and Automake built software, but I
suppose Go brings a new set of challenges.

If an existing recipe is not available, any words of wisdom before I
get started on this?
I never used Go in the Yocto/OpenEmbedded environment, but I'm sure
somebody else who has more experience will be able to help. To get
started with writing a new recipe I usually get my inspiration from
similar recipes (similar language, build system, dependencies, etc.).

Thanks,

Mike Thompson


Yocto recipe for Tailscale #yocto #golang

Mike Thompson
 

Does anyone know if there is an existing bitbake recipe for building the Tailscale client daemon and CLI tool from the following source?  A search on Google yielded no obvious links.

https://github.com/tailscale/tailscale

The Tailscale client for Linux looks to be built using the Go language which is a complete unknown to me. I've built very simple recipes before for basic Makefile and Automake built software, but I suppose Go brings a new set of challenges.

If an existing recipe is not available, any words of wisdom before I get started on this?

Thanks,

Mike Thompson

 


[meta-zephyr][PATCH] zephyr-kernel: add Zephyr RTOS version 2.3.0 support

yock.gen.mah@...
 

From: yockgenm <yock.gen.mah@intel.com>

Signed-off-by: yockgenm <yock.gen.mah@intel.com>
---
classes/zephyr-kernel-src.bbclass | 12 ++++----
.../{qemu_4.2.%.bbappend => qemu_5.1.%.bbappend} | 0
.../zephyr-kernel/zephyr-kernel-common.inc | 1 +
.../zephyr-kernel/zephyr-kernel-src_2.2.bb | 33 ----------------------
.../zephyr-kernel/zephyr-kernel-src_2.3.bb | 24 ++++++++++++++++
.../zephyr-kernel/zephyr-kernel-test.inc | 7 ++---
6 files changed, 35 insertions(+), 42 deletions(-)
rename recipes-devtools/qemu/{qemu_4.2.%.bbappend => qemu_5.1.%.bbappend} (100%)
delete mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.2.bb
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.3.bb

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
index 653cb9b..d202293 100644
--- a/classes/zephyr-kernel-src.bbclass
+++ b/classes/zephyr-kernel-src.bbclass
@@ -1,13 +1,15 @@
#Set relevant variables based on Zephyr kernel version

-PREFERRED_VERSION_zephyr-kernel ??= "2.2.0"
+PREFERRED_VERSION_zephyr-kernel ??= "2.3.0"

-SRCREV = "d39cb42d0920d5658fad358ad5b91de75d747a20"
+SRCREV = "b8c78e254ff875680e99c9f131fbe285c4575927"
+SRCREV_cmsis = "542b2296e6d515b265e25c6b7208e8fea3014f90"

-SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.2-branch \
+SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.3-branch \
+ git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
file://0001-cmake-add-yocto-toolchain.patch \
"
-PV = "2.2.0"
+PV = "2.3.0"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

@@ -15,7 +17,7 @@ ZEPHYR_TEST_SRCDIR = "tests/legacy/kernel/"

python () {
src_pn = d.getVar('PREFERRED_VERSION_zephyr-kernel', True)
- if src_pn == '2.2.0':
+ if src_pn == '2.3.0':
return
else:
bb.error("Unsupported Zephyr kernel version requested")
diff --git a/recipes-devtools/qemu/qemu_4.2.%.bbappend b/recipes-devtools/qemu/qemu_5.1.%.bbappend
similarity index 100%
rename from recipes-devtools/qemu/qemu_4.2.%.bbappend
rename to recipes-devtools/qemu/qemu_5.1.%.bbappend
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index d7147d5..aaf71a8 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -14,6 +14,7 @@ ZEPHYR_MAKE_OUTPUT = "zephyr.elf"


EXTRA_OECMAKE = " -DZEPHYR_BASE=${S} -DZEPHYR_GCC_VARIANT=yocto -DBOARD=${BOARD} -DARCH=${ARCH} -DCROSS_COMPILE=${CROSS_COMPILE} -DZEPHYR_SYSROOT=${ZEPHYR_SYSROOT} -DZEPHYR_TOOLCHAIN_VARIANT=yocto"
+EXTRA_OECMAKE_append_arm = " -DZEPHYR_MODULES=${S}/modules/cmsis"
export ZEPHYR_BASE="${S}"


diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.2.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.2.bb
deleted file mode 100644
index a3e1c28..0000000
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.2.bb
+++ /dev/null
@@ -1,33 +0,0 @@
-
-LICENSE = "Apache-2.0"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"
-
-# tag v2.2
-SRCREV="d39cb42d0920d5658fad358ad5b91de75d747a20"
-SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.2-branch \
- file://0001-cmake-add-yocto-toolchain.patch \
- "
-inherit cmake
-PV = "2.2.0"
-S = "${WORKDIR}/git"
-
-IMAGE_NO_MANIFEST = "1"
-INHIBIT_DEFAULT_DEPS = "1"
-
-do_configure[noexec] = "1"
-do_compile[noexec] = "1"
-
-do_compile () {
-}
-
-do_install () {
- kerneldir=${D}/usr/src/zephyr
- install -d $kerneldir
- cp -r ${S}/* $kerneldir
-}
-
-PACKAGES = "${PN}"
-FILES_${PN} = "/usr/src/zephyr"
-
-SYSROOT_DIRS += "/usr/src/zephyr"
-
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.3.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.3.bb
new file mode 100644
index 0000000..8e8b5b8
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.3.bb
@@ -0,0 +1,24 @@
+
+inherit zephyr-kernel-src
+inherit cmake
+
+S = "${WORKDIR}/git"
+
+IMAGE_NO_MANIFEST = "1"
+INHIBIT_DEFAULT_DEPS = "1"
+
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+
+do_install () {
+ kerneldir=${D}/usr/src/zephyr
+ install -d $kerneldir
+ cp -r ${S}/* $kerneldir
+}
+
+PACKAGES = "${PN}"
+FILES_${PN} = "/usr/src/zephyr"
+
+SYSROOT_DIRS += "/usr/src/zephyr"
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
index 65da7e8..7ab9bd4 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
@@ -1,4 +1,4 @@
-ZEPHYRTESTS_remove = "fifo fp_sharing lifo mbox mem_heap mem_pool \
+ZEPHYRTESTS_remove = "fifo fpu_sharing lifo mbox mem_heap mem_pool \
mem_protect mem_slab msgq mutex pipe profiling sched semaphore \
stack threads tickless timer workq"

@@ -22,13 +22,12 @@ ZEPHYRTESTS_remove = "gen_isr_table spinlock smp mp"
# List of all available kernel tests
ZEPHYRTESTS = " \
common \
- context \
- critical \
+ context \
device \
early_sleep \
fatal \
fifo \
- fp_sharing \
+ fpu_sharing \
gen_isr_table \
interrupt \
lifo \
--
2.7.4


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

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.2_M3.rc1.
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Wednesday, September 23.

Thanks,
Sangeeta

-----Original Message-----
From: Pokybuild User <pokybuild@ubuntu2004-ty-2.yocto.io>
Sent: Friday, 18 September, 2020 12:18 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_M3.rc1)


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


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


Build hash information:

bitbake: 29081375659e3dcf1c578cd98ab2c8a2e9f07ca8
meta-arm: 1f3cf5812c91cdc15f63737bf9b30cce665b2999
meta-gplv2: a8da8eb127a56561bf633ab53bec57fb5dbba537
meta-intel: f7580d72763653893c06e1d9ece7a77c4adb8485
meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
meta-mingw: 30a051401c0a73dfff486ca4d0303b434816200f
oecore: 4e7506882cabf3936f0269c2a98f61c7d595d613
poky: c6bc20857cd1bdfd25dfc50e413be84d1d12b189



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



do_unpack() ISO Image

Chuck Wolber
 


Hi all,

I have a need to unpack an ISO image during do_unpack. This does not appear to be one of the extensions that is handled by default, so I am working out a way to use xorriso to do this for me.

I can get this to work in the following way, but it involves calling an executable running on the build host, which only works by luck since the host executable is the same architecture as what I am currently building. I would like to do this in a portable way that does not break when I try to build for a different architecture.

DEPENDS += "xorriso"

do_unpack_append() {
    bb.build.exec_func('unpack_iso', d)
}

unpack_iso() {
   /usr/bin/xorriso -osirrox on -indev ${WORKDIR}/${PN}_${PV}.iso -extract / ${S}
}


From looking at base.bbclass, it _seems_ as if my solution involves something like this:

d.appendVarFlag('do_unpack', 'depends', ' xorriso:do_populate_sysroot')

But it is unclear exactly where that would go within my recipe. Any thoughts?

Thank you,

..Ch:W..

--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


Re: Emulator tool for imx8m #linux #devtool #yocto

Khem Raj
 

On Thu, Sep 17, 2020 at 6:43 AM Amrun Nisha.R <amrunnishar@gmail.com> wrote:

Hi,

Actually I'm working on the DART-IMX8M board. I can able to build the image in linux machine and run it on the board. But for every build, i have to run the image on board. I have checked on the qemu but it is not supported for the machine imx8mq-var-dart.
Is there any emulator can be used for imx8mq-var-dart?
closed you can get is qemuarm64, you can also use package management
in image and install/update/remove individual packages. something like
https://imxdev.gitlab.io/tutorial/How_to_apt-get_to_the_Yocto_Project_image/



QA notification for completed autobuilder build (yocto-3.2_M3.rc1)

Pokybuild User
 

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


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


Build hash information:

bitbake: 29081375659e3dcf1c578cd98ab2c8a2e9f07ca8
meta-arm: 1f3cf5812c91cdc15f63737bf9b30cce665b2999
meta-gplv2: a8da8eb127a56561bf633ab53bec57fb5dbba537
meta-intel: f7580d72763653893c06e1d9ece7a77c4adb8485
meta-kernel: cb7f0dc5bb1ea0998c8d4fcb486148d4cab575f4
meta-mingw: 30a051401c0a73dfff486ca4d0303b434816200f
oecore: 4e7506882cabf3936f0269c2a98f61c7d595d613
poky: c6bc20857cd1bdfd25dfc50e413be84d1d12b189



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


Re: [yocto-builds] relocate_sdk.py is failing when installing yocto3.1.2 SDK

Randy MacLeod
 

Hi Vijay,

I have redirected this thread to the main yocto list.
The yocto-builds list is for automated build outputs
rather than discussions.


What distro are you using?
What version of python3 is provided by that distro?
On Ubu-20.04, fyi:
$ grep python3 /.../oe-core.git/scripts/relocate_sdk.py
#!/usr/bin/env python3
$ python3 --version
Python 3.8.2

../Randy

On 2020-09-17 9:49 a.m., Ansurivijay Ramana wrote:

Classification: HCL Internal

Hi ,

 

I have added my layer and builded the SDK in yocto 3.1.2 but relocate_sdk.py is failing when installing.

 

Please help me in fixing this.

 

./poky-glibc-x86_64-core-image-sato-sdk-core2-32-qemux86-toolchain-3.1.2.sh

Poky (Yocto Project Reference Distro) SDK installer version 3.1.2

=================================================================

Enter target directory for SDK (default: /opt/poky/3.1.2): /home/vijay/build/test3

You are about to install the SDK to "/home/vijay/build/test3". Proceed [Y/n]? Y

Extracting SDK.........................................................................................................................................................................................................................................................................done

Setting it up...Traceback (most recent call last):

  File "/home/vijay/build/test3/relocate_sdk.py", line 244, in <module>

    change_dl_sysdirs(e)

  File "/home/vijay/build/test3/relocate_sdk.py", line 118, in change_dl_sysdirs

    sh_offset, sh_size = struct.unpack("<24xQQ24x", sh_hdr)

struct.error: unpack requires a string argument of length 64

SDK could not be set up. Relocate script failed. Abort!

 

Thanks & Regards,

Vijay

::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.





-- 
# Randy MacLeod
# Wind River Linux


Re: Emulator tool for imx8m #linux #devtool #yocto

Andy Pont
 

Hello!

Actually I'm working on the DART-IMX8M board. I can able to build the image in linux machine and run it on the board. But for every build, i have to run the image on board. I have checked on the qemu but it is not supported for the machine imx8mq-var-dart.
Is there any emulator can be used for imx8mq-var-dart?
Generally speaking, at the point when we get to working with boards we are needing to interact with the outside world so we have to run on the target hardware. Once U-Boot (or equivalent) is up and running then we speed the development process up using TFTP/NFS to boot the Linux kernel and mount the root file system.

It saves all the messing around programming on-board flash devices or SD cards whilst the image is in flux. It also means that all the application developers are using the same and the latest configuration rather than having flash devices with old versions potentially causing problems.

It might help a little!

-Andy.


Emulator tool for imx8m #linux #devtool #yocto

Amrun Nisha.R
 

Hi,

Actually I'm working on the DART-IMX8M board. I can able to build the image in linux machine and run it on the board. But for every build, i have to run the image on board. I have checked on the qemu but it is not supported for the machine imx8mq-var-dart. 
Is there any emulator can be used for imx8mq-var-dart?


Re: wvdial

Maciej Pijanowski
 


On 17.09.2020 13:35, Maciej Pijanowski wrote:


On 17.09.2020 13:25, Zoltan Kerenyi Nagy wrote:
now there is only one issue has left:

ERROR: ExpansionError during parsing /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb                                                                                       | ETA:  0:00:00
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable do_fetch[file-checksums], expression was ${@bb.fetch.get_checksum_file_list(d)}  ${@get_lic_checksum_file_list(d)} which triggered exception NoMethodError: Could not find a fetcher which supports the URL: 'files://typo_pon.wvdial.1.patch'


I'm sorry, but you I think you really do need a pair of glasses ;)
It's supposed to be file:// not file:// in the URL.

It's supposed to be file:// not files:// in the URL.



This is the bb recipe:

HOMEPAGE = "http://www.alumnit.ca/wiki/?WvDial"
DESCRIPTION = "WvDial is a program that makes it easy to connect your Linux workstation to the Internet."

LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605"

inherit pkgconfig

DEPENDS = "wvstreams"
RDEPENDS_${PN} = "ppp"

SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.bz2 \
           files://typo_pon.wvdial.1.patch \
          "

SRC_URI[md5sum] = "d81642557d175d8e0818f4721c27dfcf"
SRC_URI[sha256sum] = "a2ce46c8c36870a0f2fa92ea64566df7251fb2d8d5aa2f6ef2b08d188287352e"

EXTRA_OEMAKE = ""
export WVLINK="${LD}"

PARALLEL_MAKE = ""

BUILD_CPPFLAGS += "-I${STAGING_INCDIR}/wvstreams"

do_configure() {
    sed -i 's/LDFLAGS+=-luniconf/LIBS+=-luniconf/' ${S}/Makefile
}

do_install() {
    oe_runmake prefix=${D}/usr PPPDIR=${D}/etc/ppp/peers install
}
# http://errors.yoctoproject.org/Errors/Details/186959/
EXCLUDE_FROM_WORLD_libc-musl = "1"

Ive  re-generated the md5 and sha256 hashes, and all the warnings have disapeared.

Here is the patch:
if I modify teh 3rd line to "Index: wvdial-1.61/files/pon.wvdial.1" - the error is the same

Remove warnings found by lintian
Last-Update: 2011-01-09
Index: wvdial-1.61/pon.wvdial.1
===================================================================
--- wvdial-1.61.orig/pon.wvdial.1	2011-01-09 21:33:03.000000000 +0300
+++ wvdial-1.61/pon.wvdial.1	2011-01-09 21:33:15.000000000 +0300
@@ -8,13 +8,11 @@
 .SH DESCRIPTION
 .B pon.wvdial
 .br
-.TR
 .B poff.wvdial
 .br
 .RS
 Replacement scripts for pon and poff.
 .RE
-\."
 .SH SEE ALSO
 .BR wvdial (1),
 .BR pon (1),



-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com
-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com


Re: wvdial

Maciej Pijanowski
 


On 17.09.2020 13:25, Zoltan Kerenyi Nagy wrote:
now there is only one issue has left:

ERROR: ExpansionError during parsing /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb                                                                                       | ETA:  0:00:00
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable do_fetch[file-checksums], expression was ${@bb.fetch.get_checksum_file_list(d)}  ${@get_lic_checksum_file_list(d)} which triggered exception NoMethodError: Could not find a fetcher which supports the URL: 'files://typo_pon.wvdial.1.patch'


I'm sorry, but you I think you really do need a pair of glasses ;)
It's supposed to be file:// not file:// in the URL.


This is the bb recipe:

HOMEPAGE = "http://www.alumnit.ca/wiki/?WvDial"
DESCRIPTION = "WvDial is a program that makes it easy to connect your Linux workstation to the Internet."

LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605"

inherit pkgconfig

DEPENDS = "wvstreams"
RDEPENDS_${PN} = "ppp"

SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.bz2 \
           files://typo_pon.wvdial.1.patch \
          "

SRC_URI[md5sum] = "d81642557d175d8e0818f4721c27dfcf"
SRC_URI[sha256sum] = "a2ce46c8c36870a0f2fa92ea64566df7251fb2d8d5aa2f6ef2b08d188287352e"

EXTRA_OEMAKE = ""
export WVLINK="${LD}"

PARALLEL_MAKE = ""

BUILD_CPPFLAGS += "-I${STAGING_INCDIR}/wvstreams"

do_configure() {
    sed -i 's/LDFLAGS+=-luniconf/LIBS+=-luniconf/' ${S}/Makefile
}

do_install() {
    oe_runmake prefix=${D}/usr PPPDIR=${D}/etc/ppp/peers install
}
# http://errors.yoctoproject.org/Errors/Details/186959/
EXCLUDE_FROM_WORLD_libc-musl = "1"

Ive  re-generated the md5 and sha256 hashes, and all the warnings have disapeared.

Here is the patch:
if I modify teh 3rd line to "Index: wvdial-1.61/files/pon.wvdial.1" - the error is the same

Remove warnings found by lintian
Last-Update: 2011-01-09
Index: wvdial-1.61/pon.wvdial.1
===================================================================
--- wvdial-1.61.orig/pon.wvdial.1	2011-01-09 21:33:03.000000000 +0300
+++ wvdial-1.61/pon.wvdial.1	2011-01-09 21:33:15.000000000 +0300
@@ -8,13 +8,11 @@
 .SH DESCRIPTION
 .B pon.wvdial
 .br
-.TR
 .B poff.wvdial
 .br
 .RS
 Replacement scripts for pon and poff.
 .RE
-\."
 .SH SEE ALSO
 .BR wvdial (1),
 .BR pon (1),




-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com


wvdial

Zoltan Kerenyi Nagy
 

now there is only one issue has left:

ERROR: ExpansionError during parsing /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb                                                                                       | ETA:  0:00:00
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable do_fetch[file-checksums], expression was ${@bb.fetch.get_checksum_file_list(d)}  ${@get_lic_checksum_file_list(d)} which triggered exception NoMethodError: Could not find a fetcher which supports the URL: 'files://typo_pon.wvdial.1.patch'

This is the bb recipe:

HOMEPAGE = "http://www.alumnit.ca/wiki/?WvDial"
DESCRIPTION = "WvDial is a program that makes it easy to connect your Linux workstation to the Internet."

LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605"

inherit pkgconfig

DEPENDS = "wvstreams"
RDEPENDS_${PN} = "ppp"

SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.bz2 \
           files://typo_pon.wvdial.1.patch \
          "

SRC_URI[md5sum] = "d81642557d175d8e0818f4721c27dfcf"
SRC_URI[sha256sum] = "a2ce46c8c36870a0f2fa92ea64566df7251fb2d8d5aa2f6ef2b08d188287352e"

EXTRA_OEMAKE = ""
export WVLINK="${LD}"

PARALLEL_MAKE = ""

BUILD_CPPFLAGS += "-I${STAGING_INCDIR}/wvstreams"

do_configure() {
    sed -i 's/LDFLAGS+=-luniconf/LIBS+=-luniconf/' ${S}/Makefile
}

do_install() {
    oe_runmake prefix=${D}/usr PPPDIR=${D}/etc/ppp/peers install
}
# http://errors.yoctoproject.org/Errors/Details/186959/
EXCLUDE_FROM_WORLD_libc-musl = "1"

Ive  re-generated the md5 and sha256 hashes, and all the warnings have disapeared.

Here is the patch:
if I modify teh 3rd line to "Index: wvdial-1.61/files/pon.wvdial.1" - the error is the same

Remove warnings found by lintian
Last-Update: 2011-01-09
Index: wvdial-1.61/pon.wvdial.1
===================================================================
--- wvdial-1.61.orig/pon.wvdial.1	2011-01-09 21:33:03.000000000 +0300
+++ wvdial-1.61/pon.wvdial.1	2011-01-09 21:33:15.000000000 +0300
@@ -8,13 +8,11 @@
 .SH DESCRIPTION
 .B pon.wvdial
 .br
-.TR
 .B poff.wvdial
 .br
 .RS
 Replacement scripts for pon and poff.
 .RE
-\."
 .SH SEE ALSO
 .BR wvdial (1),
 .BR pon (1),


[PATCH yocto-autobuilder-helper] auh: correct the SMTP server in config file

Alexander Kanavin
 

Michael Halstead has confirmed this.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
scripts/auh-config/upgrade-helper.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/auh-config/upgrade-helper.conf b/scripts/auh-config/upgrade-helper.conf
index b012600..5284b4a 100644
--- a/scripts/auh-config/upgrade-helper.conf
+++ b/scripts/auh-config/upgrade-helper.conf
@@ -9,7 +9,7 @@ blacklist=linux-libc-headers linux-yocto alsa-utils-scripts build-appliance-imag
# only recipes belonging to maintainers in whitelist will be attempted
#maintainers_whitelist=anibal.limon@linux.intel.com
# SMTP server
-smtp=smtp1.yoctoproject.org:25
+smtp=mail.yoctoproject.org:25
# from whom should the mails arrive
from=auh@auh.yoctoproject.org
# who should get the status mail with statistics, at the end
--
2.28.0


Re: RFC: Changes to meta-kernel layer

Jack Mitchell
 

On 17/09/2020 10:40, Bas Mevissen wrote:
On 2020-09-17 10:43, Paul Barker wrote:

Hi folks,

After a bit of a break I'm looking again at the meta-kernel layer and
I've got some changes planned. I'd like to get some feedback on these
from anyone who has looked at or used the meta-kernel layer.

1) Change the name to meta-vanilla-kernel. This reflects the focus on
providing a fast moving layer for vanilla kernel recipes, covering
only what is available on kernel.org. Other common kernel recipes
(e.g. Linaro or Android common kernels) will no longer be considered
for acceptance into this layer. This clear focus should hopefully
reduce some of the confusion about the goals of this layer.
I would suggest calling it something like meta-kernel.org then. Naming
something "vanilla" might cause confusion as well.
I wasn't going to be blamed for the bike shedding of this but as we've
gotten started I'll stick my oar in. My suggestion would be
meta-mainline-kernel, meta-linux-kernel or potentially
meta-upstream-kernel but I'm not so keen on that. Vanilla is a confusing
term for people not in the game and you know at some point there will be
a "vanilla-pi" or "vanilla" board where you're going to hit confusion.

As an aside I saw no issues with meta-kernel as it's _the_ Linux kernel
from _the_ Linux kernel git repositories. Confusion due to doublespeak
from downstream kernel vendors should be corrected and not adhered to.


2) The dunfell branch will no longer get new non-LTS kernel recipes.
Providing non-LTS recipes on a stable branch has led to people
depending on kernels which are now out of their support period - I'd
like to drop the recipes for the 5.3.y and 5.6.y kernels but users are
depending on them so I'll have to keep them. To avoid this
proliferating, only LTS kernels and the bleeding edge mainline recipe
will be updated on the stable branch from now >>
3) Aggressively drop end-of-life kernels on the master branch.

4) Drop all non-LTS kernel recipes in the gatesgarth branch when it is
created.
I think these are fair, I can't speak for how other people are using the
layer but I would imagine as with most embedded boards, they're using
the tooling rather than the plain upstream recipes and the real value is
in catching problems with -next kernel compilation early and the
fixes/features pushed back to kernel.bbclass.

5) Document the test coverage for meta-kernel. We don't test perf,
lttng or any out-of-tree modules. This layer isn't meant to replace
the linux-yocto recipes, the goals are different. If you're releasing
products based on meta-kernel you obviously need to do your own
testing on the components you're actually using.
I wouldn't be expecting anything more than basic build and boot on qemu
to be fair. Again, IMO the value of this is in the toolchain test and
tooling.


6) Document the policy for kernel patches. Patches for the kernel will
only be carried in this layer as a last resort. Kernel patches should
be submitted upstream and go through the usual process for inclusion
in the stable kernel releases.
Compilation patches only I would say.


7) Disable GitLab CI for this layer. It's costing me about £70 per
month to run CI for this layer and I need to eliminate that expense.
If anyone can sponsor this or host the CI service that would be welcome.

8) Add Jon Mason and Ross Burton (both at ARM) as backup maintainers
to reduce the bus factor for the layer. I'll continue to be the
primary maintainer for this layer but this will give some coverage if
I'm unable to continue working on it.

Thanks,

--

Paul Barker
Konsulko Group
Cheers,
Jack.


split rootfs into partitions for rauc

Daniel Ammann
 

Hi

Is it possible to split a rootfs image into two images for two partitions?
Let's say I have a rootfs, but I want to split out /usr/local/applicationx into
a separate image so that I can have it on a different partition. The goal is to
have two ext4 images, one with everything except /usr/local/applicationx and
one with just /usr/local/applicationx.

Thanks, Daniel

--
bytes at work
Technoparkstrasse 7
CH-8406 Winterthur
Switzerland

phone: +41 52 550 50 67


Re: RFC: Changes to meta-kernel layer

Bas Mevissen
 

On 2020-09-17 10:43, Paul Barker wrote:

Hi folks,
After a bit of a break I'm looking again at the meta-kernel layer and I've got some changes planned. I'd like to get some feedback on these from anyone who has looked at or used the meta-kernel layer.
1) Change the name to meta-vanilla-kernel. This reflects the focus on providing a fast moving layer for vanilla kernel recipes, covering only what is available on kernel.org. Other common kernel recipes (e.g. Linaro or Android common kernels) will no longer be considered for acceptance into this layer. This clear focus should hopefully reduce some of the confusion about the goals of this layer.
I would suggest calling it something like meta-kernel.org then. Naming something "vanilla" might cause confusion as well.

2) The dunfell branch will no longer get new non-LTS kernel recipes. Providing non-LTS recipes on a stable branch has led to people depending on kernels which are now out of their support period - I'd like to drop the recipes for the 5.3.y and 5.6.y kernels but users are depending on them so I'll have to keep them. To avoid this proliferating, only LTS kernels and the bleeding edge mainline recipe will be updated on the stable branch from now on.
I would recommend maintaining a "kernel-stable" moving target recipe that tracks the latest stable version of kernel.org. This is of use for people needing a very recent kernel, while needing a stable environment for the rest of the system (so where master is no option).

3) Aggressively drop end-of-life kernels on the master branch.
Always good to keep the amount of kernels at an absolut minimum to limit the amount of testing and maintenance.

4) Drop all non-LTS kernel recipes in the gatesgarth branch when it is created.
See 2); additionally the next-to-be-lts might be considered

5) Document the test coverage for meta-kernel. We don't test perf, lttng or any out-of-tree modules. This layer isn't meant to replace the linux-yocto recipes, the goals are different. If you're releasing products based on meta-kernel you obviously need to do your own testing on the components you're actually using.
6) Document the policy for kernel patches. Patches for the kernel will only be carried in this layer as a last resort. Kernel patches should be submitted upstream and go through the usual process for inclusion in the stable kernel releases.
7) Disable GitLab CI for this layer. It's costing me about £70 per month to run CI for this layer and I need to eliminate that expense. If anyone can sponsor this or host the CI service that would be welcome.
8) Add Jon Mason and Ross Burton (both at ARM) as backup maintainers to reduce the bus factor for the layer. I'll continue to be the primary maintainer for this layer but this will give some coverage if I'm unable to continue working on it.
And spreading the workload of course!

Thanks,
--
Paul Barker
Konsulko Group
Regards,

Bas.


RFC: Changes to meta-kernel layer

 

Hi folks,

After a bit of a break I'm looking again at the meta-kernel layer and I've got some changes planned. I'd like to get some feedback on these from anyone who has looked at or used the meta-kernel layer.

1) Change the name to meta-vanilla-kernel. This reflects the focus on providing a fast moving layer for vanilla kernel recipes, covering only what is available on kernel.org. Other common kernel recipes (e.g. Linaro or Android common kernels) will no longer be considered for acceptance into this layer. This clear focus should hopefully reduce some of the confusion about the goals of this layer.

2) The dunfell branch will no longer get new non-LTS kernel recipes. Providing non-LTS recipes on a stable branch has led to people depending on kernels which are now out of their support period - I'd like to drop the recipes for the 5.3.y and 5.6.y kernels but users are depending on them so I'll have to keep them. To avoid this proliferating, only LTS kernels and the bleeding edge mainline recipe will be updated on the stable branch from now on.

3) Aggressively drop end-of-life kernels on the master branch.

4) Drop all non-LTS kernel recipes in the gatesgarth branch when it is created.

5) Document the test coverage for meta-kernel. We don't test perf, lttng or any out-of-tree modules. This layer isn't meant to replace the linux-yocto recipes, the goals are different. If you're releasing products based on meta-kernel you obviously need to do your own testing on the components you're actually using.

6) Document the policy for kernel patches. Patches for the kernel will only be carried in this layer as a last resort. Kernel patches should be submitted upstream and go through the usual process for inclusion in the stable kernel releases.

7) Disable GitLab CI for this layer. It's costing me about £70 per month to run CI for this layer and I need to eliminate that expense. If anyone can sponsor this or host the CI service that would be welcome.

8) Add Jon Mason and Ross Burton (both at ARM) as backup maintainers to reduce the bus factor for the layer. I'll continue to be the primary maintainer for this layer but this will give some coverage if I'm unable to continue working on it.

Thanks,

--
Paul Barker
Konsulko Group


Re: wvdial

Bas Mevissen
 

On 2020-09-17 10:02, Zoltan Kerenyi Nagy wrote:

Hi,
Here is the error now, all the files are there, it says that 04_signed_request.diff is not there:
WARNING: wvstreams-4.6.1-r0 do_fetch: Failed to fetch URL file://04_signed_request.diff, attempting MIRRORS if available
ERROR: wvstreams-4.6.1-r0 do_fetch: Fetcher failure: Unable to find file file://04_signed_request.diff anywhere. The paths that were searched were:
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/nodistro
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/nodistro
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/nodistro
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/barix-ipam400
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/barix-ipam400
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/barix-ipam400
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/sun8i
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/sun8i
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/sun8i
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/armv7ve
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/armv7ve
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/armv7ve
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/arm
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/arm
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/arm
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/
/home/kerenyiz/oe-core/build/downloads
ERROR: wvstreams-4.6.1-r0 do_fetch: Fetcher failure for URL: 'file://04_signed_request.diff'. Unable to fetch URL from any source.
It is the first local file on the list, so this hints that it is probably a file location issue and not a file naming one.

ERROR: wvstreams-4.6.1-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /home/kerenyiz/oe-core/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/wvstreams/4.6.1-r0/temp/log.do_fetch.8864
ERROR: Task (/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams_4.6.1.bb:do_fetch) failed with exit code '1'
Here i sthe folder structure:
├── file
Here is your problem: this directory should be named "wvstreams"

│ ├── 0001-build-fix-parallel-make.patch
│ ├── 0001-Check-for-limits.h-during-configure.patch
│ ├── 0001-Forward-port-to-OpenSSL-1.1.x.patch
│ ├── 0002-wvrules.mk-Use-_DEFAULT_SOURCE.patch
│ ├── 0002-wvtask-Dont-use-ucontext-on-non-glibc-systems.patch
│ ├── 0003-wvtask-Check-for-HAVE_LIBC_STACK_END-only-on-glibc-s.patch
│ ├── 0004-wvcrash-Replace-use-of-basename-API.patch
│ ├── 0005-check-for-libexecinfo-during-configure.patch
│ ├── 04_signed_request.diff
│ ├── 05_gcc.diff
│ ├── 06_gcc-4.7.diff
│ ├── 07_buildflags.diff
│ ├── argp.patch
│ ├── gcc-6.patch
│ └── openssl-buildfix.patch
└── wvstreams_4.6.1.bb
And this is the recipie file:
HOMEPAGE = "http://alumnit.ca/wiki/index.php?page=WvStreams";
SUMMARY = "WvStreams is a network programming library in C++"
LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=55ca817ccb7d5b5b66355690e9abc605"
DEPENDS = "zlib openssl (>= 0.9.8) dbus readline"
DEPENDS_append_libc-musl = " argp-standalone libexecinfo"
SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.gz \
file://04_signed_request.diff \
file://05_gcc.diff \
file://06_gcc-4.7.diff \
file://07_buildflags.diff \
file://gcc-6.patch \
file://argp.patch \
file://0001-Check-for-limits.h-during-configure.patch \
file://0002-wvtask-Dont-use-ucontext-on-non-glibc-systems.patch \
file://0003-wvtask-Check-for-HAVE_LIBC_STACK_END-only-on-glibc-s.patch \
file://0004-wvcrash-Replace-use-of-basename-API.patch \
file://0005-check-for-libexecinfo-during-configure.patch \
file://0001-build-fix-parallel-make.patch \
file://0002-wvrules.mk-Use-_DEFAULT_SOURCE.patch \
file://openssl-buildfix.patch \
file://0001-Forward-port-to-OpenSSL-1.1.x.patch \
"
SRC_URI[md5sum] = "2760dac31a43d452a19a3147bfde571c"
SRC_URI[sha256sum] = "8403f5fbf83aa9ac0c6ce15d97fd85607488152aa84e007b7d0621b8ebc07633"
inherit autotools-brokensep pkgconfig
TARGET_CFLAGS_append = " -fno-tree-dce -fno-optimize-sibling-calls"
LDFLAGS_append = " -Wl,-rpath-link,${CROSS_DIR}/${TARGET_SYS}/lib"
EXTRA_OECONF = " --without-tcl --without-qt --without-pam --without-valgrind"
PACKAGES_prepend = "libuniconf "
PACKAGES_prepend = "uniconfd "
PACKAGES_prepend = "libwvstreams-base "
PACKAGES_prepend = "libwvstreams-extras "
PACKAGES_prepend = "${PN}-valgrind "
RPROVIDES_${PN}-dbg += "libuniconf-dbg uniconfd-dbg libwvstreams-base-dbg libwvstreams-extras-dbg"
FILES_libuniconf = "${libdir}/libuniconf.so.*"
FILES_uniconfd = "${sbindir}/uniconfd ${sysconfdir}/uniconf.conf ${localstatedir}/uniconf"
FILES_libwvstreams-base = "${libdir}/libwvutils.so.*"
FILES_libwvstreams-extras = "${libdir}/libwvbase.so.* ${libdir}/libwvstreams.so.*"
FILES_${PN}-valgrind = "${libdir}/valgrind/wvstreams.supp"
RDEPENDS_${PN} += "perl"

1341 - 1360 of 52044