Date   

meta-virtualization/docker/containerd issue seen

Monsees, Steven C (US)
 

 

I am trying to build in basic docker functionality for container support…

 

I am zeus based, and am building docker and docker-ce-contrib.

 

When I manually start the dockerd in the background I am seeing a timeout when attempting to use containerd.

 

Any ideas as ti why I am getting this error or how I might resolve it ?

(see bottom)

 

Thanks,

Steve

 

Initialization complete. Sending init complete message

Running indefinitely

 

root@sbca-default which docker

/usr/bin/docker

root@sbca-default docker --version

Docker version 19.03.2-ce, build 6a30dfc

root@sbca-default docker info

Client:

Debug Mode: false

 

Server:

Containers: 0

  Running: 0

  Paused: 0

  Stopped: 0

Images: 0

Server Version: 19.03.2-ce

Storage Driver: overlay2

  Backing Filesystem: extfs

  Supports d_type: true

  Native Overlay Diff: true

Logging Driver: json-file

Cgroup Driver: cgroupfs

Plugins:

  Volume: local

  Network: bridge host ipvlan macvlan null overlay

  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog

Swarm: inactive

Runtimes: runc

Default Runtime: runc

Init Binary: docker-init

containerd version: fd103cb716352c7e19768e4fed057f71d68902a0.m

runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f-dirty

init version: fec3683-dirty (expected: fec3683b971d9)

Kernel Version: 4.19.135-intel-pk-standard

OSType: linux

Architecture: x86_64

CPUs: 8

Total Memory: 15.51GiB

Name: sbca-default

ID: YFQW:EPJT:TSJU:C64F:NU57:RAJL:X5IC:J5IT:MRTP:SIGS:RI25:KUFQ

Docker Root Dir: /var/lib/docker

Debug Mode: false

Registry: https://index.docker.io/v1/

Labels:

Experimental: false

Insecure Registries:

  localhost:5000

  127.0.0.0/8

Registry Mirrors:

  http://localhost:5000/

Live Restore Enabled: false

 

root@sbca-default /usr/share/docker/check-config.sh

info: reading kernel config from /proc/config.gz ...

 

Generally Necessary:

- cgroup hierarchy: properly mounted [/sys/fs/cgroup]

- CONFIG_NAMESPACES: enabled

- CONFIG_NET_NS: enabled

- CONFIG_PID_NS: enabled

- CONFIG_IPC_NS: enabled

- CONFIG_UTS_NS: enabled

- CONFIG_CGROUPS: enabled

- CONFIG_CGROUP_CPUACCT: enabled

- CONFIG_CGROUP_DEVICE: enabled

- CONFIG_CGROUP_FREEZER: enabled

- CONFIG_CGROUP_SCHED: enabled

- CONFIG_CPUSETS: enabled

- CONFIG_MEMCG: enabled

- CONFIG_KEYS: enabled

- CONFIG_VETH: enabled

- CONFIG_BRIDGE: enabled (as module)

- CONFIG_BRIDGE_NETFILTER: enabled (as module)

- CONFIG_NF_NAT_IPV4: enabled (as module)

- CONFIG_IP_NF_FILTER: enabled (as module)

- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)

- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)

- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)

- CONFIG_NETFILTER_XT_MATCH_IPVS: enabled (as module)

- CONFIG_IP_NF_NAT: enabled (as module)

- CONFIG_NF_NAT: enabled (as module)

- CONFIG_NF_NAT_NEEDED: enabled

- CONFIG_POSIX_MQUEUE: enabled

 

Optional Features:

- CONFIG_USER_NS: enabled

- CONFIG_SECCOMP: enabled

- CONFIG_CGROUP_PIDS: enabled

- CONFIG_MEMCG_SWAP: enabled

- CONFIG_MEMCG_SWAP_ENABLED: enabled

    (cgroup swap accounting is currently enabled)

- CONFIG_LEGACY_VSYSCALL_EMULATE: enabled

- CONFIG_BLK_CGROUP: enabled

- CONFIG_BLK_DEV_THROTTLING: enabled

- CONFIG_IOSCHED_CFQ: enabled

- CONFIG_CFQ_GROUP_IOSCHED: enabled

- CONFIG_CGROUP_PERF: enabled

- CONFIG_CGROUP_HUGETLB: enabled

- CONFIG_NET_CLS_CGROUP: enabled

- CONFIG_CGROUP_NET_PRIO: enabled

- CONFIG_CFS_BANDWIDTH: enabled

- CONFIG_FAIR_GROUP_SCHED: enabled

- CONFIG_RT_GROUP_SCHED: enabled

- CONFIG_IP_NF_TARGET_REDIRECT: enabled (as module)

- CONFIG_IP_VS: enabled (as module)

- CONFIG_IP_VS_NFCT: enabled

- CONFIG_IP_VS_PROTO_TCP: enabled

- CONFIG_IP_VS_PROTO_UDP: enabled

- CONFIG_IP_VS_RR: enabled (as module)

- CONFIG_EXT4_FS: enabled

- CONFIG_EXT4_FS_POSIX_ACL: enabled

- CONFIG_EXT4_FS_SECURITY: enabled

- Network Drivers:

  - "overlay":

    - CONFIG_VXLAN: enabled

      Optional (for encrypted networks):

      - CONFIG_CRYPTO: enabled

      - CONFIG_CRYPTO_AEAD: enabled

      - CONFIG_CRYPTO_GCM: enabled (as module)

      - CONFIG_CRYPTO_SEQIV: enabled

      - CONFIG_CRYPTO_GHASH: enabled (as module)

      - CONFIG_XFRM: enabled

      - CONFIG_XFRM_USER: enabled (as module)

      - CONFIG_XFRM_ALGO: enabled

      - CONFIG_INET_ESP: enabled (as module)

      - CONFIG_INET_XFRM_MODE_TRANSPORT: enabled

  - "ipvlan":

    - CONFIG_IPVLAN: enabled

  - "macvlan":

    - CONFIG_MACVLAN: enabled

    - CONFIG_DUMMY: enabled

  - "ftp,tftp client in container":

    - CONFIG_NF_NAT_FTP: enabled (as module)

    - CONFIG_NF_CONNTRACK_FTP: enabled (as module)

    - CONFIG_NF_NAT_TFTP: enabled (as module)

    - CONFIG_NF_CONNTRACK_TFTP: enabled (as module)

- Storage Drivers:

  - "aufs":

    - CONFIG_AUFS_FS: missing

  - "btrfs":

    - CONFIG_BTRFS_FS: enabled

    - CONFIG_BTRFS_FS_POSIX_ACL: enabled

  - "devicemapper":

    - CONFIG_BLK_DEV_DM: enabled

    - CONFIG_DM_THIN_PROVISIONING: enabled

  - "overlay":

    - CONFIG_OVERLAY_FS: enabled

  - "zfs":

    - /dev/zfs: missing

    - zfs command: missing

    - zpool command: missing

 

Limits:

- /proc/sys/kernel/keys/root_maxkeys: 1000000

 

root@sbca-default

root@sbca-default dockerd --iptables=false &

[1] 5887

root@sbca-default INFO[2021-12-23T17:27:10.246973295Z] Starting up                                  

INFO[2021-12-23T17:27:10.247572882Z] libcontainerd: containerd is still running    pid=893

INFO[2021-12-23T17:27:10.247608835Z] parsed scheme: "unix"                         module=grpc

INFO[2021-12-23T17:27:10.247660984Z] scheme "unix" not registered, fallback to default scheme  module=grpc

INFO[2021-12-23T17:27:10.247678448Z] ccResolverWrapper: sending update to cc: {[{unix:///var/run/docker/containerd/containerd.sock 0  <nil>}] }  module=grpc

INFO[2021-12-23T17:27:10.247686677Z] ClientConn switching balancer to "pick_first"  module=grpc

INFO[2021-12-23T17:27:10.247731766Z] pickfirstBalancer: HandleSubConnStateChange: 0xc0006f5780, CONNECTING  module=grpc

failed to start containerd: timeout waiting for containerd to start

 

[1]+ done(1)                 dockerd --iptables=false

root@sbca-default

 


Minutes: Yocto Project Weekly Triage Meeting 12/23/2021

Trevor Gamblin
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Randy, Richard, Saul, Stephen, Steve, Trevor

ARs:

Happy Holidays!

Notes:

No triage meeting on December 30th

Medium+ 3.5 Unassigned Enhancements/Bugs: 75 (Last week 76)

Medium+ 3.99 Unassigned Enhancements/Bugs: 38 (Last week 38)

AB Bugs: 70 (Last week 73)


Re: Where to define udev to load kernel modules in boot?

Quentin Schulz
 

Hi JH,

On December 23, 2021 11:28:55 AM GMT+01:00, JH <jupiter.hce@...> wrote:
Hi,

I built an OE/Yocto IoT device to include kernel modules of usb_wwan,
usbserial, mwifiex_sdio, mwifiex etc, there is one udev from
meta-freescale/recipes-core/udev/udev-rules-imx/10-imx.rules

# ls /etc/udev/rules.d
10-imx.rules touchscreen.rules

My device does not have a touchscreen so that touchscreen.rules should
not be there. The 10-imx.rules does not define any kernel modules
usb_wwan, usbserial, mwifiex_sdio, mwifiex, the device does not have
video or any input

# cat /etc/udev/rules.d/10-imx.rules
KERNEL=="mc13783_connectiv*", NAME="mc13783_connectivity"
# Anyone has readonly permission to IIM device file
KERNEL=="mxc_iim", MODE="0444", SYMLINK+="mxc_mem"
KERNEL=="mxs_viim", MODE="0444", SYMLINK+="mxc_mem"
KERNEL=="mxc_ipu", MODE="0666"
KERNEL=="mxc_vpu", MODE="0666"
SUBSYSTEM=="video", MODE="0660"
KERNEL=="fb[0-9]", MODE="0660", GROUP="video"
KERNEL=="gsl_kmod", MODE="0660", GROUP="video"
KERNEL=="galcore", MODE="0660", GROUP="video"

How can I define udev in recipes to make the system to load kernel
modules of usb_wwan, usbserial, mwifiex_sdio, mwifiex in boot?
IIRC, you need to add your package to KERNEL_MODULE_AUTOLOAD, c.f. https://docs.yoctoproject.org/ref-manual/variables.html#term-KERNEL_MODULE_AUTOLOAD

Cheers,
Quentin

Thank you.

Kind regards,

- jh


Where to define udev to load kernel modules in boot?

JH
 

Hi,

I built an OE/Yocto IoT device to include kernel modules of usb_wwan,
usbserial, mwifiex_sdio, mwifiex etc, there is one udev from
meta-freescale/recipes-core/udev/udev-rules-imx/10-imx.rules

# ls /etc/udev/rules.d
10-imx.rules touchscreen.rules

My device does not have a touchscreen so that touchscreen.rules should
not be there. The 10-imx.rules does not define any kernel modules
usb_wwan, usbserial, mwifiex_sdio, mwifiex, the device does not have
video or any input

# cat /etc/udev/rules.d/10-imx.rules
KERNEL=="mc13783_connectiv*", NAME="mc13783_connectivity"
# Anyone has readonly permission to IIM device file
KERNEL=="mxc_iim", MODE="0444", SYMLINK+="mxc_mem"
KERNEL=="mxs_viim", MODE="0444", SYMLINK+="mxc_mem"
KERNEL=="mxc_ipu", MODE="0666"
KERNEL=="mxc_vpu", MODE="0666"
SUBSYSTEM=="video", MODE="0660"
KERNEL=="fb[0-9]", MODE="0660", GROUP="video"
KERNEL=="gsl_kmod", MODE="0660", GROUP="video"
KERNEL=="galcore", MODE="0660", GROUP="video"

How can I define udev in recipes to make the system to load kernel
modules of usb_wwan, usbserial, mwifiex_sdio, mwifiex in boot?

Thank you.

Kind regards,

- jh


Re: [meta-raspberrypi][PATCH] xserver-xorg: remove xshmfence configure option

Yu, Mingli
 

On 12/9/21 1:37 PM, Khem Raj wrote:
**[Please note: This e-mail is from an EXTERNAL e-mail address]
On Wed, Dec 8, 2021 at 7:03 PM Yu, Mingli <mingli.yu@... <mailto:mingli.yu@...>> wrote:
From: Mingli Yu <mingli.yu@...
<mailto:mingli.yu@...>>
After the commit [1] introduced in openembedded-core layer,
some configure options is't carried over include xshmfence
option, so remove the xshmfence configure option to silence
the below warning.
  WARNING: xserver-xorg-2_21.1.1-r0 do_configure: QA Issue:
xserver-xorg: invalid PACKAGECONFIG: xshmfence [invalid-packageconfig]
That’s ok to remove it but more importantly does it work now without this option
First we should keep consistent with the change with openembedded-core(https://git.openembedded.org/openembedded-core/commit/?id=e05abd87ee5d23750c641d0129d9c83db68ee2e8) and also not found any issue related to this option until now.

Thanks,

[1]
https://git.openembedded.org/openembedded-core/commit/?id=e05abd87ee5d23750c641d0129d9c83db68ee2e8
<https://urldefense.com/v3/__https://git.openembedded.org/openembedded-core/commit/?id=e05abd87ee5d23750c641d0129d9c83db68ee2e8__;!!AjveYdw8EvQ!O1dnnmQhKwEt9e40TMNLjFCci501QrS-7Erm4Fz5co01OzoGEk8NfXDGEi2vpfa5oCE$>
Signed-off-by: Mingli Yu <mingli.yu@...
<mailto:mingli.yu@...>>
---
 recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
b/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
index 25829c2..ee4812f 100644
--- a/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
+++ b/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
@@ -1,4 +1,4 @@
-OPENGL_PKGCONFIGS:rpi = "dri glx
${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', 'dri3
xshmfence glamor', '', d)}"
+OPENGL_PKGCONFIGS:rpi = "dri glx
${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', 'dri3
glamor', '', d)}"
 # when using userland graphic KHR/khrplatform.h is provided by
userland but virtual/libgl is provided by mesa-gl where
 # we explicitly delete KHR/khrplatform.h since its already coming
from userland package
--
2.17.1


Docker exec/attach not working on overlayed root

Beek, Léon van de
 

Hi Bruce,

 

To be honest, I am not quite sure where to ask this, as it is a very specific scenario, so feel free to forward me and my question to someone/somewhere else.

 

Situation:

  • Yocto Hardknott running meta-virtualization, meta-raspberrypi with Docker installed: Dockers works fine and is tested. Docker exec and attach works too
  • Now changed the rootfs to be squashfs, and an overlay of root + a RW ext4 partition is changed to be / at boot. This script is based on: https://github.com/cmhe/meta-readonly-rootfs-overlay
  • Docker’s overlay2 file driver does not work on top of an overlay: https://docs.docker.com/storage/storagedriver/select-storage-driver/
  • Solution: create /etc/docker/daemon.json with the line in it: “data-root”=”/docker-data”. Note: /docker-data is a separate EXT4 partition on the SD card.
  • Restart machine/dockerd. The result is that we see the /docker-data is now full of docker files and the containers and overlay2 folders are there. Docker info shows: Storage driver: overlay2
    Containers run fine. Hello-world example runs. Alpine runs, and when starting Alpine with -it arguments I can mess around in shell all I want, everything works.
  • Problem: Whenever I create a container, for example: docker run -d -t –name=test alpine, and later try to exec into it using “docker exec test echo hello” I get this result:
    Error running exec: OCI-runtime exec failed: exec failed: container_linux.go:367”starting container process caused: read init-p: connection reset by peer: unknown
  • I restarted dockerd with –log-level=debug and noticed that it says: attach: stderr: begin, stream copy error: reading from a closed fifo. (Same for stdout)

 

I removed the overlaying again and can confirm that exec and attach also worked before adding this, but on Google I can not find a single thing that closely relates to the issue I am facing.

 

Hope any of you might be able to help me out here, I feel truly stuck on this.

 

Kind regards,

Léon van de Beek


Re: Bitbake: checksums handling for local directories

Shmuel Hazan
 

On Wed, 2021-12-22 at 18:10 +0000, Richard Purdie wrote:
On Wed, 2021-12-22 at 17:54 +0000, Shmuel Hazan wrote:
I noticed a strange behavior of bitbake, and I am not sure whether
it is a
bug:

Let say that I have a simple recipe that takes the directory
`THISDIR/files/A`
and install all the files inside of it:

...
SRC_URI = "file://A/" 
S = "${WORKDIR}/A"
do_install() {
    install -m 644 ${S}/* ${D}
}
...

Let say that I have one file called "my_file" inside of that
directory.

It will work great, and I will get a package with "/myfile" --
until I will
rename a file to "/myfile1" in the directory. Since the file
content stayed
the same, do_fetch won't be triggered and as a result, the package
will stay
the same and have "/myfile".

The only proper way to workaround it was to mark this recipe's
do_fetch as
nostamp:

do_fetch[nostamp] = "1"

I am currently working with bitbake 1.46.0.

Questions:
1. Is this a known issue?
2. I could not find any reference to a similar issue / a recent
change that
could have caused the issue, am I doing something wrong here?
I'm pretty sure we fixed bugs like that in more recent versions.
Thanks! 

For a reference, b4975d2ecf615ac4c240808fbc5a3f879a93846b
(fetch2/checksum/siggen: Fix taskhashes not tracking file directories)
from 2~ months ago seems to solve that issue.

I see that the checksum code was not changed for a long time, is there
a chance that someone would accept a backport of this commit to
Dunfell/1.46?

Cheers,

Richard


Re: Bitbake: checksums handling for local directories

Richard Purdie
 

On Wed, 2021-12-22 at 17:54 +0000, Shmuel Hazan wrote:
I noticed a strange behavior of bitbake, and I am not sure whether it is a
bug:

Let say that I have a simple recipe that takes the directory `THISDIR/files/A`
and install all the files inside of it:

...
SRC_URI = "file://A/" 
S = "${WORKDIR}/A"
do_install() {
    install -m 644 ${S}/* ${D}
}
...

Let say that I have one file called "my_file" inside of that directory.

It will work great, and I will get a package with "/myfile" -- until I will
rename a file to "/myfile1" in the directory. Since the file content stayed
the same, do_fetch won't be triggered and as a result, the package will stay
the same and have "/myfile".

The only proper way to workaround it was to mark this recipe's do_fetch as
nostamp:

do_fetch[nostamp] = "1"

I am currently working with bitbake 1.46.0.

Questions:
1. Is this a known issue?
2. I could not find any reference to a similar issue / a recent change that
could have caused the issue, am I doing something wrong here?
I'm pretty sure we fixed bugs like that in more recent versions.

Cheers,

Richard


Bitbake: checksums handling for local directories

Shmuel Hazan
 

Hi everyone,

I noticed a strange behavior of bitbake, and I am not sure whether it is a bug:

Let say that I have a simple recipe that takes the directory `THISDIR/files/A` and install all the files inside of it:

...
SRC_URI = "file://A/" 
S = "${WORKDIR}/A"
do_install() {
    install -m 644 ${S}/* ${D}
}
...

Let say that I have one file called "my_file" inside of that directory.

It will work great, and I will get a package with "/myfile" -- until I will rename a file to "/myfile1" in the directory. Since the file content stayed the same, do_fetch won't be triggered and as a result, the package will stay the same and have "/myfile".

The only proper way to workaround it was to mark this recipe's do_fetch as nostamp:

do_fetch[nostamp] = "1"

I am currently working with bitbake 1.46.0.

Questions:
1. Is this a known issue?
2. I could not find any reference to a similar issue / a recent change that could have caused the issue, am I doing something wrong here?

Thanks,
Shmuel.


docker buildx for yocto #yocto

lavkhush2208@...
 

Hello Guys
I want to build "docker/buildx" from github source :- https://github.com/docker/buildx.git

procedure which i am following:-


1. $  git clone https://github.com/docker/buildx.git && cd buildx
2. $  make install 


after this step I am facing an issue:- 
 
docker: 'buildx' is not a docker command.
See 'docker --help'
which: no buildx in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin)
Makefile:8: *** recipe commences before first target.  Stop.
 

if something is missing, please update me so that i can modify.


T&R
lavkhush


Re: [OE-core] [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.13.rc1)

Steve Sakoman
 

On Tue, Dec 21, 2021 at 5:50 AM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2021-12-21 at 15:12 +0000, Jose Quaresma wrote:


Richard Purdie <richard.purdie@...> escreveu no dia terça,
21/12/2021 à(s) 14:19:
On Tue, 2021-12-21 at 11:15 +0000, Jose Quaresma wrote:


Teoh, Jay Shen <jay.shen.teoh@...> escreveu no dia terça, 21/12/2021
à(s) 07:46:
Hi all,

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

======= Summary ========
No high milestone defects.

new issue found

Bug 14669 - [QA 3.1.13 RC1] failure in ptest :gstreamer1.0.gstreamer-
1.0/pipelines_seek.test


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

This patch is a bug fix 14669
https://lists.openembedded.org/g/openembedded-core/message/159911
Great, thanks!

I assume we don't need that in the version on master as it is already
present?


https://git.yoctoproject.org/poky/commit/?id=7b90027aac9fa41b3dc98765151d761df8dabb97
The first version of the patch on the master branch is this one and it fixes
the [YOCTO #14194].
I cherry-picked that with some adaptation for dunfell but the content is the
same.

We need the patch on master as well and we will drop it with the gstreamer
1.20 update.
Thanks for the info, we're ok with master then and can backport this.
It will be in my next patchset for dunfell.

Steve


Cheers,

Richard




Re: [OE-core] [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.13.rc1)

Richard Purdie
 

On Tue, 2021-12-21 at 15:12 +0000, Jose Quaresma wrote:


Richard Purdie <richard.purdie@...> escreveu no dia terça,
21/12/2021 à(s) 14:19:
On Tue, 2021-12-21 at 11:15 +0000, Jose Quaresma wrote:


Teoh, Jay Shen <jay.shen.teoh@...> escreveu no dia terça, 21/12/2021
à(s) 07:46:
Hi all,

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

======= Summary ========
No high milestone defects.

new issue found

Bug 14669 - [QA 3.1.13 RC1] failure in ptest :gstreamer1.0.gstreamer-
1.0/pipelines_seek.test


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

This patch is a bug fix 14669
https://lists.openembedded.org/g/openembedded-core/message/159911
 
Great, thanks!

I assume we don't need that in the version on master as it is already
present?


https://git.yoctoproject.org/poky/commit/?id=7b90027aac9fa41b3dc98765151d761df8dabb97
The first version of the patch on the master branch is this one and it fixes
the [YOCTO #14194].
I cherry-picked that with some adaptation for dunfell but the content is the
same.

We need the patch on master as well and we will drop it with the gstreamer
1.20 update.
Thanks for the info, we're ok with master then and can backport this.

Cheers,

Richard


Yocto Project Status WW51`21

Stephen Jolley
 

Current Dev Position: YP 3.5 M2

Next Deadline: 17th Jan. 2022 YP 3.5 M2 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.5 M1 and YP 3.1.13 have both been through QA and are likely to be released this week.
  • The next status report will be sent next year on 4th January with no report next week (28th Dec).
  • We have maintenance to the autobuilder planned to fit SSDs to speed up IO and update the host distros to more modern equivalents. This is scheduled for next few days (22nd-24th) and the autobuilder will be unavailable during the work. There may be bring up issues with the new distros.
  • Intermittent issues continue to be at record high levels and help is very much welcome in trying to resolve them. You can see 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

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M1 is ready for release
  • YP 3.5 M2 build date 2022/01/17
  • YP 3.5 M2 Release date 2022/01/28
  • YP 3.5 M3 build date 2022/02/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.1.13 is ready for release
  • YP 3.1.14 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.3.5 build date 2022/02/14
  • YP 3.3.5 Release date 2022/02/25
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.3.6 build date 2022/03/28
  • YP 3.3.6 Release date 2022/04/08
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

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: [OE-core] [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.13.rc1)

Jose Quaresma
 



Richard Purdie <richard.purdie@...> escreveu no dia terça, 21/12/2021 à(s) 14:19:
On Tue, 2021-12-21 at 11:15 +0000, Jose Quaresma wrote:
>
>
> Teoh, Jay Shen <jay.shen.teoh@...> escreveu no dia terça, 21/12/2021
> à(s) 07:46:
> > Hi all,
> >
> > This is the full report for yocto-3.1.13.rc1: 
> > https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
> >
> > ======= Summary ========
> > No high milestone defects.
> >
> > new issue found
> >
> > Bug 14669 - [QA 3.1.13 RC1] failure in ptest :gstreamer1.0.gstreamer-
> > 1.0/pipelines_seek.test
> >
> >
> > ======= Bugs ========
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14669
> >
>
>
> This patch is a bug fix 14669
> https://lists.openembedded.org/g/openembedded-core/message/159911
>  

Great, thanks!

I assume we don't need that in the version on master as it is already present?


The first version of the patch on the master branch is this one and it fixes the [YOCTO #14194].
I cherry-picked that with some adaptation for dunfell but the content is the same.

We need the patch on master as well and we will drop it with the gstreamer 1.20 update.

Jose
 

Cheers,

Richard



--
Best regards,

José Quaresma


Re: [OE-core] [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.13.rc1)

Richard Purdie
 

On Tue, 2021-12-21 at 11:15 +0000, Jose Quaresma wrote:


Teoh, Jay Shen <jay.shen.teoh@...> escreveu no dia terça, 21/12/2021
à(s) 07:46:
Hi all,

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

======= Summary ========
No high milestone defects.

new issue found

Bug 14669 - [QA 3.1.13 RC1] failure in ptest :gstreamer1.0.gstreamer-
1.0/pipelines_seek.test


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

This patch is a bug fix 14669
https://lists.openembedded.org/g/openembedded-core/message/159911
 
Great, thanks!

I assume we don't need that in the version on master as it is already present?

Cheers,

Richard


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.13.rc1)

Jose Quaresma
 



Teoh, Jay Shen <jay.shen.teoh@...> escreveu no dia terça, 21/12/2021 à(s) 07:46:
Hi all,

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

======= Summary ========
No high milestone defects.

new issue found

Bug 14669 - [QA 3.1.13 RC1] failure in ptest :gstreamer1.0.gstreamer-1.0/pipelines_seek.test


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

This patch is a bug fix 14669
 


Thanks,
Jay

>-----Original Message-----
>From: qa-build-notification@... <qa-build-
>notification@...> On Behalf Of Richard Purdie
>Sent: Wednesday, 15 December, 2021 3:40 PM
>To: <yocto@...> <yocto@...>
>Cc: qa-build-notification <qa-build-notification@...>
>Subject: [qa-build-notification] QA notification for completed autobuilder build
>(yocto-3.1.13.rc1)
>
>A build flagged for QA (yocto-3.1.13.rc1) was completed on the autobuilder and is
>available at:
>
>
>    https://autobuilder.yocto.io/pub/releases/yocto-3.1.13.rc1
>
>
>Build hash information:
>
>bitbake: f18b65d0b9a6b983d53bde491e1bf2ca56949444
>meta-agl: 6d1ab9f3bb270a773ec5d2f7c8c856796833b559
>meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c
>meta-aws: 9979cfa676105cb68cfadfdaeabf044d7c919319
>meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
>meta-intel: 87984115eb6ed1a4c17204629dcb100f6b76fe82
>meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
>meta-openembedded: 69f94af4d91215e7d4e225bab54bf3bcfee42f1c
>oecore: 90a07178ea26be453d101c2e8b33d3a0f437635d
>poky: 795339092f87672e4f68e4d3bc4cfd0e252d1831
>
>
>
>This is an automated message from the Yocto Project Autobuilder
>Git: git://git.yoctoproject.org/yocto-autobuilder2
>Email: richard.purdie@...
>
>
>
>
>
>
>






--
Best regards,

José Quaresma


[meta-zephyr][PATCH] zephyr-kernel: upgrade 2.7.0 -> 2.7.1

Jing Hui Tham
 

From: JingHuiTham <jing.hui.tham@...>

Zephyr 2.7.1 release notes:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v2.7.1

Signed-off-by: JingHuiTham <jing.hui.tham@...>
---
...ephyr-kernel-src-2.7.0.inc => zephyr-kernel-src-2.7.1.inc} | 4 ++--
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
rename recipes-kernel/zephyr-kernel/{zephyr-kernel-src-2.7.0.inc => zephyr-kernel-src-2.7.1.inc} (90%)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.1.inc
similarity index 90%
rename from recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
rename to recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.1.inc
index 2fdda35..9d31c69 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.1.inc
@@ -1,6 +1,6 @@
SRCREV_FORMAT = "default_cmsis"
SRCREV_cmsis = "b0612c97c1401feeb4160add6462c3627fe90fc7"
-SRCREV_default = "3f826560aaf81a444018293bd6acce3c339fe150"
+SRCREV_default = "e4da3e528088a34a9989f5a50e7ed3149d57de92"
SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
SRCREV_lvgl = "31acbaa36e9e74ab88ac81e3d21e7f1d00a71136"
SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
@@ -11,7 +11,7 @@ SRCREV_stm32 = "5c8275071ec1cf160bfe8c18bbd9330a7d714dc8"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"

ZEPHYR_BRANCH = "v2.7-branch"
-PV = "2.7.0+git${SRCPV}"
+PV = "2.7.1+git${SRCPV}"

SRC_URI:append = " \
file://0001-cmake-add-yocto-toolchain.patch \
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index c973c2a..da1efea 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -23,5 +23,5 @@ SRC_URI = "\
S = "${WORKDIR}/git"

# Default to a stable version
-PREFERRED_VERSION_zephyr-kernel ??= "2.7.0"
+PREFERRED_VERSION_zephyr-kernel ??= "2.7.1"
include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
--
2.33.1


[meta-tensorflow][PATCH 3/3] tensorflow-lite: add recipe

Julien STEPHAN
 

Adding 2.6.1 tensorflow-lite recipe.
This recipe is directly based on the corresponding 2.6.1 tensorflow
recipe.

It has been build tested with latest honister and tested on
several mediatek soc using benchmark_model and label_image (C++ and
python)

Signed-off-by: Julien STEPHAN <jstephan@...>
---
.../tensorflow/tensorflow-lite_2.6.1.bb | 156 ++++++++++++++++++
1 file changed, 156 insertions(+)
create mode 100644 recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb

diff --git a/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb b/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
new file mode 100644
index 0000000..104e5a3
--- /dev/null
+++ b/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
@@ -0,0 +1,156 @@
+include tensorflow.inc
+
+SRC_URI += " \
+ file://0001-add-yocto-toolchain-to-support-cross-compiling.patch \
+ file://0001-fix-build-tensorflow-lite-examples-label_image-label.patch \
+ file://0001-label_image-tweak-default-model-location.patch \
+ file://0001-label_image.lite-tweak-default-model-location.patch \
+ file://0001-CheckFeatureOrDie-use-warning-to-avoid-die.patch \
+ file://0001-support-32-bit-x64-and-arm-for-yocto.patch \
+ file://0001-Revert-set-distinct_host_configuration-false-by-defa.patch \
+ file://0001-fix-default-Bazel-toolchain-not-work.patch \
+ file://0001-distutils-is-deprecated-in-Python-3.10-cross.patch \
+ file://BUILD.in \
+ file://BUILD.yocto_compiler \
+ file://cc_config.bzl.tpl \
+ file://yocto_compiler_configure.bzl \
+ "
+
+SRC_URI += "https://storage.googleapis.com/download.tensorflow.org/models/inception_v3_2016_08_28_frozen.pb.tar.gz;name=model-inv3"
+SRC_URI[model-inv3.md5sum] = "a904ddf15593d03c7dd786d552e22d73"
+SRC_URI[model-inv3.sha256sum] = "7045b72a954af4dce36346f478610acdccbf149168fa25c78e54e32f0c723d6d"
+
+SRC_URI += "https://storage.googleapis.com/download.tensorflow.org/models/tflite/mobilenet_v1_1.0_224_quant_and_labels.zip;name=model-mobv1"
+SRC_URI[model-mobv1.md5sum] = "38ac0c626947875bd311ef96c8baab62"
+SRC_URI[model-mobv1.sha256sum] = "2f8054076cf655e1a73778a49bd8fd0306d32b290b7e576dda9574f00f186c0f"
+
+RDEPENDS:${PN} += " \
+ python3 \
+ python3-core \
+ python3-numpy \
+"
+
+export PYTHON_BIN_PATH="${PYTHON}"
+export PYTHON_LIB_PATH="${STAGING_LIBDIR_NATIVE}/${PYTHON_DIR}/site-packages"
+
+export CROSSTOOL_PYTHON_INCLUDE_PATH="${STAGING_INCDIR}/python${PYTHON_BASEVERSION}${PYTHON_ABI}"
+
+do_configure:append () {
+ if [ ! -e ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-target.h ];then
+ mv ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig.h ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-target.h
+ fi
+
+ install -m 644 ${STAGING_INCDIR_NATIVE}/python${PYTHON_BASEVERSION}${PYTHON_ABI}/pyconfig.h \
+ ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-native.h
+
+ cat > ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig.h <<ENDOF
+#if defined (_PYTHON_INCLUDE_TARGET)
+#include "pyconfig-target.h"
+#elif defined (_PYTHON_INCLUDE_NATIVE)
+#include "pyconfig-native.h"
+#else
+#error "_PYTHON_INCLUDE_TARGET or _PYTHON_INCLUDE_NATIVE is not defined"
+#endif // End of #if defined (_PYTHON_INCLUDE_TARGET)
+
+ENDOF
+
+ mkdir -p ${S}/third_party/toolchains/yocto/
+ sed "s#%%CPU%%#${BAZEL_TARGET_CPU}#g" ${WORKDIR}/BUILD.in > ${S}/third_party/toolchains/yocto/BUILD
+ chmod 644 ${S}/third_party/toolchains/yocto/BUILD
+ install -m 644 ${WORKDIR}/cc_config.bzl.tpl ${S}/third_party/toolchains/yocto/
+ install -m 644 ${WORKDIR}/yocto_compiler_configure.bzl ${S}/third_party/toolchains/yocto/
+ install -m 644 ${WORKDIR}/BUILD.yocto_compiler ${S}
+
+ CT_NAME=$(echo ${HOST_PREFIX} | rev | cut -c 2- | rev)
+ SED_COMMAND="s#%%CT_NAME%%#${CT_NAME}#g"
+ SED_COMMAND="${SED_COMMAND}; s#%%WORKDIR%%#${WORKDIR}#g"
+ SED_COMMAND="${SED_COMMAND}; s#%%YOCTO_COMPILER_PATH%%#${BAZEL_OUTPUTBASE_DIR}/external/yocto_compiler#g"
+
+ sed -i "${SED_COMMAND}" ${S}/BUILD.yocto_compiler \
+ ${S}/WORKSPACE
+
+ ${TF_CONFIG} \
+ ./configure
+}
+
+TF_TARGET_EXTRA ??= ""
+
+export CUSTOM_BAZEL_FLAGS = " \
+ ${TF_ARGS_EXTRA} \
+ --jobs=auto \
+ -c opt \
+ --cpu=${BAZEL_TARGET_CPU} \
+ --crosstool_top=@local_config_yocto_compiler//:toolchain \
+ --host_crosstool_top=@bazel_tools//tools/cpp:toolchain \
+"
+
+do_compile () {
+ export CT_NAME=$(echo ${HOST_PREFIX} | rev | cut -c 2- | rev)
+ unset CC
+
+ ${BAZEL} build \
+ ${CUSTOM_BAZEL_FLAGS} \
+ --copt -DTF_LITE_DISABLE_X86_NEON --copt -DMESA_EGL_NO_X11_HEADERS \
+ tensorflow/lite:libtensorflowlite.so \
+ tensorflow/lite/tools/benchmark:benchmark_model \
+ //tensorflow/lite/examples/label_image:label_image \
+ ${TF_TARGET_EXTRA}
+
+ # build pip package
+ ${S}/tensorflow/lite/tools/pip_package/build_pip_package_with_bazel.sh
+
+}
+
+do_install() {
+ install -d ${D}${libdir}
+ install -m 644 ${S}/bazel-bin/tensorflow/lite/libtensorflowlite.so \
+ ${D}${libdir}
+
+ install -d ${D}${sbindir}
+ install -m 755 ${S}/bazel-bin/tensorflow/lite/tools/benchmark/benchmark_model \
+ ${D}${sbindir}
+
+ install -m 755 ${S}/bazel-bin/tensorflow/lite/examples/label_image/label_image \
+ ${D}${sbindir}/label_image
+
+ install -d ${D}${datadir}/label_image
+ install -m 644 ${WORKDIR}/imagenet_slim_labels.txt ${D}${datadir}/label_image
+ install -m 644 ${WORKDIR}/inception_v3_2016_08_28_frozen.pb \
+ ${D}${datadir}/label_image
+ install -m 644 ${S}/tensorflow/examples/label_image/data/grace_hopper.jpg \
+ ${D}${datadir}/label_image
+
+ install -m 644 ${WORKDIR}/labels_mobilenet_quant_v1_224.txt ${D}${datadir}/label_image
+ install -m 644 ${WORKDIR}/mobilenet_v1_1.0_224_quant.tflite \
+ ${D}${datadir}/label_image
+ install -m 644 ${S}/tensorflow/lite/examples/label_image/testdata/grace_hopper.bmp \
+ ${D}${datadir}/label_image
+
+
+ #echo "Installing pip package"
+ install -d ${D}/${PYTHON_SITEPACKAGES_DIR}
+ ${STAGING_BINDIR_NATIVE}/pip3 install --disable-pip-version-check -v \
+ -t ${D}/${PYTHON_SITEPACKAGES_DIR} --no-cache-dir --no-deps \
+ ${S}/tensorflow/lite/tools/pip_package/gen/tflite_pip/python3/dist/tflite_runtime-${PV}-*.whl
+
+}
+
+FILES:${PN} += "${libdir} ${sbindir} ${datadir}/*"
+INSANE_SKIP:${PN} += "dev-so \
+ already-stripped \
+ "
+
+SOLIBS = ".so"
+FILES_SOLIBSDEV = ""
+ALLOW_EMPTY:${PN} = "1"
+
+FILES:${PN} += "${libdir} /home/root/*"
+
+inherit siteinfo unsupportarch
+python __anonymous() {
+ if d.getVar("SITEINFO_ENDIANNESS") == 'be':
+ msg = "\nIt failed to use pre-build model to do predict/inference on big-endian platform"
+ msg += "\n(such as qemumips), since upstream does not support big-endian very well."
+ msg += "\nDetails: https://github.com/tensorflow/tensorflow/issues/16364"
+ bb.warn(msg)
+}
--
2.34.1


[meta-tensorflow][PATCH 2/3] bazel.class: rename BAZEL_ARGS to BAZEL_STARTUP_OPTIONS

Julien STEPHAN
 

BAZEL_ARGS variable contains bazel startup options so rename the
variable to be more explicit. Moreover upstream tensorflow uses the
variable name BAZEL_STARTUP_OPTIONS inside
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/lite/tools/pip_package/build_pip_package_with_bazel.sh#L97
so we can keep consistency with upstream and this would be useful for
future tensorflow-lite recipe

Signed-off-by: Julien STEPHAN <jstephan@...>
---
classes/bazel.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/classes/bazel.bbclass b/classes/bazel.bbclass
index e232d30..ccdfd74 100644
--- a/classes/bazel.bbclass
+++ b/classes/bazel.bbclass
@@ -7,7 +7,7 @@ inherit bazel-base

BAZEL_DIR ?= "${WORKDIR}/bazel"
BAZEL_OUTPUTBASE_DIR ?= "${BAZEL_DIR}/output_base"
-export BAZEL_ARGS="--output_user_root=${BAZEL_DIR}/user_root \
+export BAZEL_STARTUP_OPTIONS="--output_user_root=${BAZEL_DIR}/user_root \
--output_base=${BAZEL_OUTPUTBASE_DIR} \
--bazelrc=${S}/bazelrc \
--batch \
@@ -19,7 +19,7 @@ do_prepare_recipe_sysroot[postfuncs] += "do_install_bazel"
do_install_bazel() {
mkdir -p ${BAZEL_DIR}
install -m 0755 ${STAGING_BINDIR_NATIVE}/bazel ${BAZEL_DIR}
- create_cmdline_wrapper ${BAZEL} \$BAZEL_ARGS
+ create_cmdline_wrapper ${BAZEL} \$BAZEL_STARTUP_OPTIONS
zip -A ${BAZEL}.real
}

--
2.34.1


[meta-tensorflow][PATCH 1/3] tensorflow: do not fail on chmod failure

Julien STEPHAN
 

every recipe using tensorflow.inc will inherits the do_compile:append
task but sometimes, the chmod inside this task fails because the target
files are not generated, we can safely ignore the chmod exit code and
always return 0

Signed-off-by: Julien STEPHAN <jstephan@...>
---
recipes-framework/tensorflow/tensorflow.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-framework/tensorflow/tensorflow.inc b/recipes-framework/tensorflow/tensorflow.inc
index e30cca5..25d2ebf 100644
--- a/recipes-framework/tensorflow/tensorflow.inc
+++ b/recipes-framework/tensorflow/tensorflow.inc
@@ -39,6 +39,6 @@ TF_CONFIG ?= " \
inherit tensorflow_ver

do_compile:append() {
- chmod a+w ${BAZEL_DIR}/output_base/execroot/org_tensorflow/bazel-out/*/bin/tensorflow/lite/python/schema_py_srcs_no_include_all
- chmod a+w ${BAZEL_DIR}/output_base/execroot/org_tensorflow/bazel-out/*/bin/tensorflow/lite/python/schema_py_srcs_no_include_all/tflite
+ chmod a+w ${BAZEL_DIR}/output_base/execroot/org_tensorflow/bazel-out/*/bin/tensorflow/lite/python/schema_py_srcs_no_include_all || true
+ chmod a+w ${BAZEL_DIR}/output_base/execroot/org_tensorflow/bazel-out/*/bin/tensorflow/lite/python/schema_py_srcs_no_include_all/tflite || true
}
--
2.34.1

1741 - 1760 of 57347