Hello all,

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

======= Summary ========
Beaglebone can not boot up, hence all beaglebone test case are blocked in this release.
No high milestone defects.

2 new defects and 3 ptest failures are found:

1. The beaglebone can not bootup (BUG id:14052)
This bug blocked all beaglebone test cases.
2. failure in oe-core manual test: test_dependency_explorer_is_launched (BUG id:14055)
3. valgrind ptest failed (BUG id:14051)
4. parted ptest failed (BUG id:14050)
5. pango ptest failed (BUG id:14049)

======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14052
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14055
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14051
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14050
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14049 This is the full report for yocto-3.2_M3.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

Thanks,
Sangeeta

From: "Mah, Yock Gen" <yock.gen.mah@intel.com>

Signed-off-by: Mah, Yock Gen <yock.gen.mah@intel.com>
---
classes/zephyr-kernel-src.bbclass | 16 ++++++---
.../{qemu_4.2.%.bbappend => qemu_%.bbappend} | 0
.../zephyr-kernel/zephyr-kernel-common.inc | 3 +-
.../zephyr-kernel/zephyr-kernel-src_2.2.bb | 33 -------------------
.../zephyr-kernel/zephyr-kernel-src_2.3.bb | 24 ++++++++++++++
.../zephyr-kernel/zephyr-kernel-test.inc | 5 ++-
6 files changed, 39 insertions(+), 42 deletions(-)
rename recipes-devtools/qemu/{qemu_4.2.%.bbappend => qemu_%.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..50e46af 100644
--- a/classes/zephyr-kernel-src.bbclass
+++ b/classes/zephyr-kernel-src.bbclass
@@ -1,13 +1,19 @@
#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_FORMAT = "default_cmsis"
+SRCREV_default = "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;name=default \
+ 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+git${SRCPV}"
+
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

@@ -15,7 +21,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_%.bbappend
similarity index 100%
rename from recipes-devtools/qemu/qemu_4.2.%.bbappend
rename to recipes-devtools/qemu/qemu_%.bbappend
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 7e569ed..7fa4b25 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -15,13 +15,14 @@ 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}"


# We always need a toolchain to cross-compile.
INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "gcc-cross-${TARGET_ARCH} libgcc ${TOOLCHAIN_TARGET_TASK} gperf-native"
-DEPENDS += " python3-pyelftools-native python3-pyyaml-native"
+DEPENDS += " python3-pyelftools-native python3-pyyaml-native python3-pykwalify-native"
CROSS_COMPILE = "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"

DEPENDS_append_qemuall = " qemu-native qemu-helper-native"
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..faf28bd 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"

@@ -23,12 +23,11 @@ ZEPHYRTESTS_remove = "gen_isr_table spinlock smp mp"
ZEPHYRTESTS = " \
common \
context \
- critical \
device \
early_sleep \
fatal \
fifo \
- fp_sharing \
+ fpu_sharing \
gen_isr_table \
interrupt \
lifo \
--
2.25.1

Hi Greg,

On Mon, Sep 21, 2020 at 09:46:51PM +0000, Greg Wilson-Lindberg wrote:

 I have a custom recipe that copies a .so, that libMotors.so calls functions in another libcanfestival.so.

When I first added in the copy of the .so
I didn't have an RDEPENDS and Yocto printed out an warning listing the package that it wanted. I added an RDEPENDS_${PN}
with all of the packages listed, but I'm still getting an error for the first libMotors.so:

ERROR: userconfig-1.0-r0 do_package_qa: QA Issue: /home/sakura/lib/libMotors.so.1.0.0 contained in package userconfig requires libcanfestival.so, but no providers found in RDEPENDS_userconfig? [file-rdeps]

In userdepends I added:

RDEPENDS_${PN} += "canfestival libelf libgcrypt pcsc-lite-lib qtbase qtdeclarative qtserialport zint"

Package canfestival_3-asc in has:

FILES_${PN} = "/usr/lib/libcanfestival.so /usr/lib/libcanfestival_unix.so /usr/lib/libcanfestival_can_socket.so"

.so files are installed in the -dev package even with the line above.

Please have a look here: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries
if there is really no way for you to avoid having a non-versioned library.

You can check if .so files are part of a package by using
`oe-pkgdata-util find-path /usr/lib/libcanfestival.so`

Cheers,
Quentin

On 9/21/20 5:17 AM, srijan.nandi@gmail.com wrote:

/Seems that some leftovers from System V still reside in YOCTO...
Correct???

Yocto project supports sysvinit as init system option as well so no there are no leftovers.

/
Not sure about that.
The problem I faced was because there was a sshd.socket that had the following line in it. The sshd.socket comes with openssh.
Conflicts=sshd.service
So I had two options. either to add the ExecStartPre in the sshd.service file or to remove the Conflicts line in sshd.socket.
I choose to remove the Conflicts line and add the following in the sshd.socket file.
After=network.target
Before=sshd.service

Usually you use socket activation for sshd then you would enable sshd.socket and not sshd.service, socket will be listening on incoming connections on ssh port ( 22 by defaault ) and launch sshd.service whenever there is incoming ssh connection request. I suggest you should perhaps follow this approach as well, its also efficient due to its on-demand launch nature.

Thanks and Regards,
-=Srijan Nandi

On 9/21/20 1:28 AM, Matteo Facchinetti wrote:

Hi,
I need to preinstall a package in a specific directory in my target image.
In detail I use RPM package manager and I like to include RPM packages in my target to provide a way to install services only when used.
This is useful when you don't have an internet connection.
Is there a way to do this?
Opinions are welcome.

it seems you want to bundle unstalled packages ( rpms ) in your firmware, perhaps you can look at adding a ROOTFS_POSTPROCESS_COMMAND and copy the needed packages, but you need to be sure that all dependencies(rpms) are also made available as part of this bundle
and you have to check this consistency everytime you update firmware

Regards,
Matteo
Sirius Electronic Systems

 I have a custom recipe that copies a .so, that libMotors.so calls functions in another libcanfestival.so.

When I first added in the copy of the .so
I didn't have an RDEPENDS and Yocto printed out an warning listing the package that it wanted. I added an RDEPENDS_${PN} 
with all of the packages listed, but I'm still getting an error for the first libMotors.so:

ERROR: userconfig-1.0-r0 do_package_qa: QA Issue: /home/sakura/lib/libMotors.so.1.0.0 contained in package userconfig requires libcanfestival.so, but no providers found in RDEPENDS_userconfig? [file-rdeps]

In userdepends I added:

RDEPENDS_${PN} += "canfestival libelf libgcrypt pcsc-lite-lib qtbase qtdeclarative qtserialport zint"

Package canfestival_3-asc in has:

FILES_${PN} = "/usr/lib/libcanfestival.so /usr/lib/libcanfestival_unix.so /usr/lib/libcanfestival_can_socket.so"

which seems to me like it should satisfy the requirements of the RDEPENDS, but it is not. bitbake initially gave me a warning 
that listed canfestival as needing to be added to an RDEPENDS for userconfig. But now it is saying that it can't figure out
what package supplies the libcanfestival.so file.

Can someone help me to understand what is going on? How do I explicitly say that a package supplies a given file?

You could try with PROVIDES: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PROVIDES

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

URLs no longer point to a valid location. Update to the current
location.

Signed-off-by: Jon Mason <jon.mason@arm.com>
---
classes/zephyr-kernel-src.bbclass | 2 +-
recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.6.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
index d7aa81bfaa62..cd1503dc1299 100644
--- a/classes/zephyr-kernel-src.bbclass
+++ b/classes/zephyr-kernel-src.bbclass
@@ -3,7 +3,7 @@
PREFERRED_VERSION_zephyr-kernel ??= "1.6.0"

SRCREV = "d4e799d77a36eaf6d678b357c207411ec32b2d62"
-SRC_URI = "git://gerrit.zephyrproject.org/r/zephyr.git;protocol=https;branch=v1.6.0-branch \
+SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v1.6-branch \
file://Makefile.toolchain.yocto "
PV = "1.6.0"

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.6.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.6.bb
index df373e850c94..b47e8ac1b7d0 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.6.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.6.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

# tag v1.6.0
SRCREV="d4e799d77a36eaf6d678b357c207411ec32b2d62"
-SRC_URI = "git://gerrit.zephyrproject.org/r/zephyr.git;protocol=https;branch=v1.6.0-branch"
+SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v1.6-branch"
SRC_URI += "file://Makefile.toolchain.yocto"

PV = "1.6.0"
--
2.20.1

Zephyr refuses to compile due to missing python dependencies.

Signed-off-by: Jon Mason <jon.mason@arm.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index d7147d5b7b86..7e569edb694c 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -2,6 +2,7 @@

ZEPHYR_INHERIT_CLASSES += "zephyr cmake"
inherit ${ZEPHYR_INHERIT_CLASSES}
+inherit python3native

# There shouldn't be a manifest for zephyr kernels since there is no root
# filesystem.
@@ -20,6 +21,7 @@ export ZEPHYR_BASE="${S}"
# We always need a toolchain to cross-compile.
INHIBIT_DEFAULT_DEPS = "1"
DEPENDS += "gcc-cross-${TARGET_ARCH} libgcc ${TOOLCHAIN_TARGET_TASK} gperf-native"
+DEPENDS += " python3-pyelftools-native python3-pyyaml-native"
CROSS_COMPILE = "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"

DEPENDS_append_qemuall = " qemu-native qemu-helper-native"
--
2.20.1

I have a custom recipe that copies a .so, that libMotors.so calls functions in another libcanfestival.so.

When I first added in the copy of the .so
I didn't have an RDEPENDS and Yocto printed out an warning listing the package that it wanted. I added an RDEPENDS_${PN}
with all of the packages listed, but I'm still getting an error for the first libMotors.so:

ERROR: userconfig-1.0-r0 do_package_qa: QA Issue: /home/sakura/lib/libMotors.so.1.0.0 contained in package userconfig requires libcanfestival.so, but no providers found in RDEPENDS_userconfig? [file-rdeps]

In userdepends I added:

RDEPENDS_${PN} += "canfestival libelf libgcrypt pcsc-lite-lib qtbase qtdeclarative qtserialport zint"

Package canfestival_3-asc in has:

FILES_${PN} = "/usr/lib/libcanfestival.so /usr/lib/libcanfestival_unix.so /usr/lib/libcanfestival_can_socket.so"

which seems to me like it should satisfy the requirements of the RDEPENDS, but it is not. bitbake initially gave me a warning
that listed canfestival as needing to be added to an RDEPENDS for userconfig. But now it is saying that it can't figure out
what package supplies the libcanfestival.so file.

Can someone help me to understand what is going on? How do I explicitly say that a package supplies a given file?

Add

DEPENDS += "libzip"

in failing recipe ( .bb) file.

On Mon, Sep 21, 2020 at 12:40 AM Jaymin Dabhi via
lists.yoctoproject.org
<jaymin.dabhi=vivaldi.net@lists.yoctoproject.org> wrote:

I seemed to have resolved all my issues getting a Yocto Bitbake recipe for the Tailscale client and CLI utility.

For future reference and in case it helps others, below is my Bitbake recipe:

Hi Mike,

Could you send your tailscale recipe to meta-openembedded/meta-networking?
    Email: OpenEmbedded Development mailing list <openembedded-devel@...>
    Instructions: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

It looks like all the work is done aside from an email!

../Randy

------------------------------------------------

# tailscale_1.0.5.bb

SUMMARY = "Tailscale client and daemon for Linux"

HOMEPAGE = "github.com/tailscale/tailscale"

SECTION = "net"

 

LICENSE = "CLOSED"

LIC_FILES_CHKSUM = "file://src/${GO_IMPORT}/LICENSE;md5=d995c1c44529856a0f35a5ad43e51cc5"

 

SRC_URI = "git://github.com/tailscale/tailscale.git;nobranch=1;tag=v${PV}"

 

inherit go-mod systemd

 

GO_IMPORT = "tailscale.com"

GO_WORKDIR = "${GO_IMPORT}"

GO_INSTALL = "${GO_IMPORT}/cmd/tailscale ${GO_IMPORT}/cmd/tailscaled"

 

FILES_${PN} += "${systemd_unitdir}/*"

 

do_install() {

    install -d ${D}/${bindir}

    install -d ${D}/${sbindir}

    install ${B}/bin/tailscale ${D}/${bindir}/tailscale

    install ${B}/bin/tailscaled ${D}/${sbindir}/tailscaled

 

    if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then

        install -d ${D}${sysconfdir}/default/

        install -m 0644 ${WORKDIR}/build/src/${GO_IMPORT}/cmd/tailscaled/tailscaled.defaults ${D}${sysconfdir}/default/tailscaled

 

        install -d ${D}${systemd_unitdir}/system

        install -m 0644 ${WORKDIR}/build/src/${GO_IMPORT}/cmd/tailscaled/tailscaled.service ${D}${systemd_unitdir}/system/tailscaled.service

 

        install -d ${D}${sysconfdir}/systemd/system/multi-user.target.wants/

        ln -s ${systemd_unitdir}/system/tailscaled.service ${D}${sysconfdir}/systemd/system/multi-user.target.wants/tailscaled.service

    fi

}

 

SYSTEMD_PACKAGES = "${PN}"

SYSTEMD_SERVICE_${PN} = "tailscaled.service"

SYSTEMD_AUTO_ENABLE = "enable"

------------------------------------------------

 

When installed on my target system, systemd reports the following for the tailscaled daemon:

------------------------------------------------

[[0;1;32m●[[0m tailscaled.service - Tailscale node agent

     Loaded: loaded (/lib/systemd/system/tailscaled.service; enabled; vendor preset: enabled)

     Active: [[0;1;32mactive (running)[[0m since Sat 2020-09-19 20:46:02 UTC; 4min 44s ago

       Docs: https://tailscale.com/kb/

   Main PID: 252 (tailscaled)

      Tasks: 13 (limit: 19081)

     Memory: 56.5M

     CGroup: /system.slice/tailscaled.service

             └─252 /usr/sbin/tailscaled --state=/var/lib/tailscale/tailscaled.state --socket=/run/tailscale/tai

lscaled.sock --port 41641

 

Sep 19 20:48:03 amber tailscaled[252]: 7.2M/39.1M control: cancelMapSafely: synced=false

Sep 19 20:48:03 amber tailscaled[252]: 7.2M/39.1M control: cancelMapSafely: wrote to channel

Sep 19 20:48:03 amber tailscaled[252]: 7.2M/39.1M control: mapRoutine: new map needed while idle.

Sep 19 20:48:03 amber tailscaled[252]: 7.2M/39.1M control: mapRoutine: state:url-visit-required

Sep 19 20:48:03 amber tailscaled[252]: 7.3M/39.1M LinkChange(isExpensive=false); needsRebind=false

Sep 19 20:48:03 amber tailscaled[252]: 7.3M/39.1M magicsock: starting endpoint update (link-change-minor)

Sep 19 20:48:03 amber tailscaled[252]: 7.6M/39.1M LinkChange(isExpensive=false); needsRebind=false

Sep 19 20:48:03 amber tailscaled[252]: 7.6M/39.1M magicsock: starting endpoint update (link-change-minor)

Sep 19 20:48:03 amber tailscaled[252]: 7.5M/39.1M LinkChange(isExpensive=false); needsRebind=false

Sep 19 20:48:03 amber tailscaled[252]: 7.2M/39.1M magicsock: starting endpoint update (link-change-minor)

------------------------------------------------

 

And ifconfig reports the following:

------------------------------------------------

# ifconfig

tailscale0 Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          inet6 addr: fe80::7f12:8835:cc06:b3e7/64 Scope:Link

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1280  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:500 

          RX bytes:0 (0.0 B)  TX bytes:825 (825.0 B)

------------------------------------------------

Thank you to Khem for the tip on looking into "inherit go-mod" and patience while I sorted through this.

 

Mike Thompson

 

-- 
# Randy MacLeod
# Wind River Linux

Seems strange to me too...I had been troubleshooting the sshd.service issue for two days. There was no logs, nothing. I was just hitting the wall. I tried a lot of combinations to get it to work but all failed.

The sshd.service was starting, if I manually did a systemctl start sshd.service. But always failed at startup. At times it would start and then get a signal 15 terminating and would close the daemon.

After not able to resolve the issue, I started checking all the other services. Every other service was starting at bootup just fine except sshd.

Not finding anything else to troubleshoot. I happened to stumble upon the sshd.socket and the Conflicts part of it. Did a hit and trial and it worked. Technically I still am not sure as to why..

-=Srijan Nandi

There was a sshd.socket file in /lib/systemd/system which had the following line in it.

Interesting... Pushed/forced me to think.

There is no formal dependency between sshd.service and sshd.socket!

[vuser@fedora32-ssd systemd]$ systemctl list-dependencies sshd.service
| grep ssh
sshd.service
● ├─sshd-keygen.target
● │ ├─sshd-keygen@ecdsa.service
● │ ├─sshd-keygen@ed25519.service
● │ └─sshd-keygen@rsa.service
[vuser@fedora32-ssd systemd]$ systemctl list-dependencies sshd.service
| grep socket
● ├─lvm2-lvmetad.socket
● ├─lvm2-lvmpolld.socket
[vuser@fedora32-ssd systemd]$ systemctl list-dependencies sshd.socket
| grep sshd
sshd.socket

Strange... Isn't it?!

Zoran
_______

On Sat, Sep 19, 2020 at 3:37 PM <srijan.nandi@gmail.com> wrote:

Hello All,

I finally got it to work!!!

There was a sshd.socket file in /lib/systemd/system which had the following line in it.

Conflicts=sshd.service

I remove it and added the following two lines:

After=network.target
Before=sshd.service

And that did the trick. Now sshd service starts on every boot.

Thanks,
-=Srijan Nandi

On Fri, Sep 18, 2020 at 7:30 AM Samuli Piippo <samuli.piippo@qt.io> wrote:

Set SDK_VENDOR to '-w64', which makes the host triplet match what GCC
expect to find when using mingw32-w64. This enables features that are
not functional in the classic mingw32, but have been implemented in the
mingw32-w64.

Does this enable it for the i686 toolchain also? Does that make sense?

Disable 32bit libs from the runtime component when compiling for 64bit,
which were enabled as a side effect of the GCC config change.

Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
---
conf/machine-sdk/include/mingw32-common.inc | 3 +++
.../mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb | 2 ++
2 files changed, 5 insertions(+)

diff --git a/conf/machine-sdk/include/mingw32-common.inc b/conf/machine-sdk/include/mingw32-common.inc
index 9011ded..bc6c91e 100644
--- a/conf/machine-sdk/include/mingw32-common.inc
+++ b/conf/machine-sdk/include/mingw32-common.inc
@@ -1,4 +1,7 @@
SDK_OS = "mingw32"
+SDK_VENDOR_mingw32 = "-w64"
+SDK_VENDOR_sdkmingw32 = "-w64"
+
NATIVESDKLIBC = "libc-mingw"

PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32 = "nativesdk-mingw-w64-runtime"
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
index cf39c6a..9f79ffe 100644
--- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
+++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
@@ -19,6 +19,8 @@ PROVIDES += "virtual/nativesdk-libintl"

TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"

+EXTRA_OECONF_x86-64 = "--disable-lib32"
+
do_configure() {
oe_runconf
}
--
2.17.1

Seems that some leftovers from System V still reside in YOCTO... Correct???

Not sure about that. 

The problem I faced was because there was a sshd.socket that had the following line in it. The sshd.socket comes with openssh. 

Conflicts=sshd.service

So I had two options. either to add the ExecStartPre in the sshd.service file or to remove the Conflicts line in sshd.socket. 

I choose to remove the Conflicts line and add the following in the sshd.socket file.

After=network.target
Before=sshd.service

Thanks and Regards,
-=Srijan Nandi