Date   

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

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.4_M1.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 Thursday, June 17.

Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Saturday, 12 June, 2021 7:49 PM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.4_M1.rc1)


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


https://autobuilder.yocto.io/pub/releases/yocto-3.4_M1.rc1


Build hash information:

bitbake: 398a1686176c695d103591089a36e25173f9fd6e
meta-arm: 6c3d62c776fc45b4bae47d178899e84b17248b31
meta-gplv2: 1ee1a73070d91e0c727f9d0db11943a61765c8d9
meta-intel: 0937728bcd98dd13d2c6829e1cd604ea2e53e5cd
meta-mingw: bfd22a248c0db4c57d5a72d675979d8341a7e9c1
oecore: 3b2903ccc791d5dedd84c75227f38ae4c8d29251
poky: 59d93693bf24e02ca0f05fe06d96a46f4f0f1bf8



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







Re: [poky] [PATCH] local.conf.sample: disable prelink

Khem Raj
 

On 6/15/21 8:21 AM, Alexander Kanavin wrote:
On Tue, 15 Jun 2021 at 10:55, Alexander Kanavin <alex.kanavin@... <mailto:alex.kanavin@...>> wrote:
On Tue, 15 Jun 2021 at 10:48, Richard Purdie
<richard.purdie@...
<mailto:richard.purdie@...>> wrote:
I appreciate the desire simply to delete/disable anything that
causes issues
but in this case I draw the line and my answer is no. It works
fine in the
vast majority of usage.
But where are the benchmarks that show it's actually beneficial? And
commitment from someone to maintain it and address open issues
(there are more than just this one)?
I went ahead and ran some quick benchmarks myself. Specifically:
1. Running 'free' after things have settled down at boot:
a) without prelink
core-image-sato-sdk
               total        used        free      shared  buff/cache available
Mem:          489352      152104      236284         472      100964  323824
core-image-ptest-fast
              total        used        free      shared  buff/cache available
Mem:        1004680       43456      927688         256       33536  941156
b) with prelink
core-image-sato-sdk
               total        used        free      shared  buff/cache available
Mem:          489352      153048      235544         468      100760  322900
core-image-ptest-fast
              total        used        free      shared  buff/cache available
Mem:        1004680       44444      928128         256       32108  940168
2. Running -c testimage
a) without prelink
core-image-sato-sdk () - Ran 66 tests in 96.693s
core-image-sato-sdk () - Ran 66 tests in 96.469s
core-image-sato-sdk () - Ran 66 tests in 94.994s
core-image-ptest-fast () - Ran 66 tests in 583.767s
core-image-ptest-fast () - Ran 66 tests in 576.564s
core-image-ptest-fast () - Ran 66 tests in 576.797s
b) with prelink
core-image-sato-sdk () - Ran 66 tests in 96.390s
core-image-sato-sdk () - Ran 66 tests in 96.615s
core-image-sato-sdk () - Ran 66 tests in 95.596s
core-image-ptest-fast () - Ran 66 tests in 576.248s
core-image-ptest-fast () - Ran 66 tests in 574.618s
core-image-ptest-fast () - Ran 66 tests in 576.760s
I think the advantage is not on high end CPUs but more on less powerful ones, so perhaps trying it on something like rpi0 or lower would be good


So the memory usage is actually *better* without prelink. And any timing benefits are lost in statistical noise, in these tests at least.
So I do not think it is wrong to question the usefulness of this feature. I'd like to hear Mark's take on this, as prelink-cross is primarily his work, he's put a lot of effort into it, and I would want to know where the benefits are. Note that Red Hat abandoned prelink in 2013, and prelink-cross likewise hasn't seen any commits for two years.


Alex


Re: [poky] [PATCH] local.conf.sample: disable prelink

Alexander Kanavin
 



On Tue, 15 Jun 2021 at 10:55, Alexander Kanavin <alex.kanavin@...> wrote:
On Tue, 15 Jun 2021 at 10:48, Richard Purdie <richard.purdie@...> wrote:
I appreciate the desire simply to delete/disable anything that causes issues
but in this case I draw the line and my answer is no. It works fine in the
vast majority of usage.

But where are the benchmarks that show it's actually beneficial? And commitment from someone to maintain it and address open issues (there are more than just this one)?

I went ahead and ran some quick benchmarks myself. Specifically:

1. Running 'free' after things have settled down at boot:

a) without prelink
core-image-sato-sdk
               total        used        free      shared  buff/cache   available
Mem:          489352      152104      236284         472      100964      323824
core-image-ptest-fast
              total        used        free      shared  buff/cache   available
Mem:        1004680       43456      927688         256       33536      941156

b) with prelink
core-image-sato-sdk
               total        used        free      shared  buff/cache   available
Mem:          489352      153048      235544         468      100760      322900
core-image-ptest-fast
              total        used        free      shared  buff/cache   available
Mem:        1004680       44444      928128         256       32108      940168

2. Running -c testimage

a) without prelink
core-image-sato-sdk () - Ran 66 tests in 96.693s
core-image-sato-sdk () - Ran 66 tests in 96.469s
core-image-sato-sdk () - Ran 66 tests in 94.994s
core-image-ptest-fast () - Ran 66 tests in 583.767s
core-image-ptest-fast () - Ran 66 tests in 576.564s
core-image-ptest-fast () - Ran 66 tests in 576.797s

b) with prelink
core-image-sato-sdk () - Ran 66 tests in 96.390s
core-image-sato-sdk () - Ran 66 tests in 96.615s
core-image-sato-sdk () - Ran 66 tests in 95.596s
core-image-ptest-fast () - Ran 66 tests in 576.248s
core-image-ptest-fast () - Ran 66 tests in 574.618s
core-image-ptest-fast () - Ran 66 tests in 576.760s

So the memory usage is actually *better* without prelink. And any timing benefits are lost in statistical noise, in these tests at least.

So I do not think it is wrong to question the usefulness of this feature. I'd like to hear Mark's take on this, as prelink-cross is primarily his work, he's put a lot of effort into it, and I would want to know where the benefits are. Note that Red Hat abandoned prelink in 2013, and prelink-cross likewise hasn't seen any commits for two years.

Alex


Yocto Project Status WW24`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M2

Next Deadline: 12th July 2021 YP 3.4 M2 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.4 M1 was built and is in the QA process.
  • The intermittent ltp hanging issue is continuing to be tracked down, currently thought to be a kernel bug introduced around the 5.0 -> 5.1 kernel version window. We ended up unblocking M1 since it is clear the LTP issue will take longer to unravel. Whilst aufs was initially thought to be a possible cause, it wasn’t the issue.
  • We are working around the autobuilder centos8 issue which is an issue with the upstream centos kernel where syscalls were backported in the latest version and don’t work properly.
  • We have a 10th anniversary T-shirt and some other Yocto Project items (hoody, stickers, mugs etc.) now available at https://yoctoproject.org/shop (EU and Americas sources)
  • The multiconfig changes in bitbake continue to cause problems, we still need simpler test cases to reproduce issues rather than huge builds. The existing patches seem to fix some workloads and break others. Richard is trying to fix but trying to fix autobuilder issues and other problems and these are slow builds to debug.
  • Intermittent autobuilder issues continue to occur and continue to be at record high levels. 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

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 is in QA
  • YP 3.4 M1 Release date 2021/06/18
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23 (Feature Freeze)
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.1.9 build date 2021/06/21
  • YP 3.1.9 release date 2021/07/02
  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

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

 


[meta-rockchip][PATCH v3] Rock64: add machine

Yann Dirson
 

From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE=3D"mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.

Changes in v3:
- add board to README
- use rock-pi-e.wks rather than rock-pi-4.wks (identical contents today)
- put copyright info straight

Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

README | 1 +
conf/machine/include/rk3328.inc | 25 +++++++++++++++
conf/machine/rock64.conf | 31 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 ++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
5 files changed, 90 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-ad=
d-mmc0-mmc1-aliases.patch

diff --git a/README b/README
index b825eba..cec1b53 100644
--- a/README
+++ b/README
@@ -24,6 +24,7 @@ Status of supported boards:
rock-pi-4a
rock-pi-4b
rock-pi-4c
+ rock64
tinker-board
tinker-board-s
vyasa-rk3288
diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk332=
8.inc
new file mode 100644
index 0000000..a4bbc5d
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2021 Blade SAS
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY =3D "rk3328"
+
+DEFAULTTUNE ?=3D "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?=3D "defconfig"
+KERNEL_CLASSES =3D "kernel-fitimage"
+KERNEL_IMAGETYPE =3D "fitImage"
+
+TFA_PLATFORM =3D "rk3328"
+TFA_BUILD_TARGET =3D "bl31"
+
+UBOOT_SUFFIX ?=3D "itb"
+UBOOT_ENTRYPOINT ?=3D "0x06000000"
+
+SERIAL_CONSOLES =3D "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?=3D "u-boot"
+SPL_BINARY ?=3D "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..acda018
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,31 @@
+# Copyright (C) 2021 Blade SAS
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES +=3D "usbhost serial"
+
+UBOOT_MACHINE =3D "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE =3D "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?=3D "mmcblk1"
+
+WKS_FILE ?=3D "rock-pi-e.wks"
+IMAGE_FSTYPES +=3D "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?=3D " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?=3D "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+KBUILD_DEFCONFIG =3D "defconfig"
diff --git a/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-=
mmc1-aliases.patch b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-a=
dd-mmc0-mmc1-aliases.patch
new file mode 100644
index 0000000..1ad3b9e
--- /dev/null
+++ b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-al=
iases.patch
@@ -0,0 +1,27 @@
+From f10cfe01f753348d346374008b8e8f5f26ed94ab Mon Sep 17 00:00:00 2001
+From: Kamil Trzcinski <ayufan@...>
+Date: Mon, 28 Aug 2017 11:24:37 +0200
+Subject: [PATCH] ayufan: dtsi: rk3328: add mmc0/mmc1 aliases
+Upstream-Status: Pending [https://github.com/ayufan-rock64/linux-mainlin=
e-kernel/commit/f10cfe01f753348d346374008b8e8f5f26ed94ab]
+
+Change-Id: I82a5394df8a505f7d1496393621c1198895c88b0
+---
+ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/=
dts/rockchip/rk3328.dtsi
+index 0afed15bc7ff..800f1c796882 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+@@ -27,6 +27,8 @@
+ i2c1 =3D &i2c1;
+ i2c2 =3D &i2c2;
+ i2c3 =3D &i2c3;
++ mmc0 =3D &emmc;
++ mmc1 =3D &sdmmc;
+ ethernet0 =3D &gmac2io;
+ ethernet1 =3D &gmac2phy;
+ };
+--=20
+2.30.2
+
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 7702e3f..3789c72 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -8,3 +8,9 @@ COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
+COMPATIBLE_MACHINE_rock64 =3D "rock64"
+
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
+
+# indeed applicable to all rk3328 boards
+SRC_URI_append_rock64 =3D " file://0001-ayufan-dtsi-rk3328-add-mmc0-mmc1=
-aliases.patch"
--=20
2.30.2


Re: [meta-rockchip][PATCH v2] Rock64: add machine

Yann Dirson
 

Le mar. 15 juin 2021 à 10:16, Trevor Woerner <twoerner@...> a écrit :

On Tue 2021-06-15 @ 10:03:31 AM, Yann Dirson wrote:
Le lun. 14 juin 2021 à 18:19, Trevor Woerner <twoerner@...> a écrit :

Hi Yann,

Thanks for the contribution!

On Mon 2021-05-31 @ 04:00:58 PM, yann.dirson@... wrote:
From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.
Sounds good. I prefer the rockchip default of 1,500,000 anyway.


Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

conf/machine/include/rk3328.inc | 25 ++++++++++++++++
conf/machine/rock64.conf | 30 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 +++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
4 files changed, 88 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries
Odd that you'd be assigning the copyright to Garmin ;-)
Oh, right, copypaste rules around here, so Garmin does have a role but
something may be missing :)


+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3328"
+
+DEFAULTTUNE ?= "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
+SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..38bc9fa
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,30 @@
+# Copyright (C) 2021 Blade SAS
Can you also specify an OSS-friendly licence too?

+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES += "usbhost serial"
+
+UBOOT_MACHINE = "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?= "mmcblk1"
+
+WKS_FILE ?= "rock-pi-4.wks"
Personally I'd prefer to see a rock64 wic file which includes an rk3328
default, even if it is a copy of the rock-pi-4 layout.
In fact we already have rock-pi-e.wks doing this.


Right that was something I wondered how to deal with and forgot (and note that
for the nanopi-m4 I used the same file).

My reading of [1] is that all rockchip APs are using the same
partition table. I see
that the existing {rk3288,rk3399}-boot.wks only differ in the choice
of u-boot image,
and I'm wondering if using the SoC to distinguish between them is the
right choice,
as eg. upstream RK is not using the .itb format, and I suspect we
could use it as well
for rk3288 (I'm sure I have one in a drawer and could check that some day). Now
maybe the sate of things is different for 32bit SoCs, and I thought it
could make sense to
distinguish rockchip-32bit-boot.wks and rockchip-64bit-boot.wks, or maybe even
name them using the format, as something like rockchip-legacy-boot.wks
(well there
is probably a more descriptive name for that format) and rockchip-itb-boot.wks ?

Similarly, the .wks for 3288-based boards and for 3399-based ones only
differ by the
console baudrate, and the 3288-based .wks are all identical except for
some whitespace.
And in fact, it is not unthinkable for a given project to use
something else than a
single-partition layout, so those files are indeed closer to a
"default wks". Maybe we
could use more generic filenames there too (until we implement a way to avoid
hardcoding the baudrate here)

[1] http://opensource.rock-chips.com/wiki_Boot_option
True. We could definitely use some cleanup in this area. If you want to
propose something that's going to work, I'll add it.

Also, when adding a new board, please update the top-level README.
Let's do the minimum for now for this to get merged, and we'll improve
incrementally.
Eg. only now I realize, through the presence of rk3328-boot.wks, that
rock-pi-e is
indeed also based on that soc, and its machine def would benefit from
including the
same rk3328.inc.

--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech


[meta-security][PATCH] sssd: set pid path with /run

kai
 

From: Kai Kang <kai.kang@...>

/var/run is deprecated and set pid path with /run to store pid files for
the SSSD.

Signed-off-by: Kai Kang <kai.kang@...>
---
recipes-security/sssd/sssd_2.5.0.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/recipes-security/sssd/sssd_2.5.0.bb b/recipes-security/sssd/sssd_2.5.0.bb
index 4c92519..c699527 100644
--- a/recipes-security/sssd/sssd_2.5.0.bb
+++ b/recipes-security/sssd/sssd_2.5.0.bb
@@ -63,6 +63,7 @@ EXTRA_OECONF += " \
--without-python2-bindings \
--without-secrets \
--with-xml-catalog-path=${STAGING_ETCDIR_NATIVE}/xml/catalog \
+ --with-pid-path=/run \
"

do_configure_prepend() {
@@ -88,8 +89,8 @@ do_install () {
echo "d /var/log/sssd 0750 - - - -" > ${D}${sysconfdir}/tmpfiles.d/sss.conf
fi

- # Remove /var/run as it is created on startup
- rm -rf ${D}${localstatedir}/run
+ # Remove /run as it is created on startup
+ rm -rf ${D}/run

rm -f ${D}${systemd_system_unitdir}/sssd-secrets.*
}
--
2.17.1


Re: [meta-rockchip][PATCH v2] Rock64: add machine

Trevor Woerner
 

On Tue 2021-06-15 @ 10:03:31 AM, Yann Dirson wrote:
Le lun. 14 juin 2021 à 18:19, Trevor Woerner <twoerner@...> a écrit :

Hi Yann,

Thanks for the contribution!

On Mon 2021-05-31 @ 04:00:58 PM, yann.dirson@... wrote:
From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.
Sounds good. I prefer the rockchip default of 1,500,000 anyway.


Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

conf/machine/include/rk3328.inc | 25 ++++++++++++++++
conf/machine/rock64.conf | 30 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 +++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
4 files changed, 88 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries
Odd that you'd be assigning the copyright to Garmin ;-)
Oh, right, copypaste rules around here, so Garmin does have a role but
something may be missing :)


+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3328"
+
+DEFAULTTUNE ?= "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
+SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..38bc9fa
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,30 @@
+# Copyright (C) 2021 Blade SAS
Can you also specify an OSS-friendly licence too?

+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES += "usbhost serial"
+
+UBOOT_MACHINE = "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?= "mmcblk1"
+
+WKS_FILE ?= "rock-pi-4.wks"
Personally I'd prefer to see a rock64 wic file which includes an rk3328
default, even if it is a copy of the rock-pi-4 layout.
Right that was something I wondered how to deal with and forgot (and note that
for the nanopi-m4 I used the same file).

My reading of [1] is that all rockchip APs are using the same
partition table. I see
that the existing {rk3288,rk3399}-boot.wks only differ in the choice
of u-boot image,
and I'm wondering if using the SoC to distinguish between them is the
right choice,
as eg. upstream RK is not using the .itb format, and I suspect we
could use it as well
for rk3288 (I'm sure I have one in a drawer and could check that some day). Now
maybe the sate of things is different for 32bit SoCs, and I thought it
could make sense to
distinguish rockchip-32bit-boot.wks and rockchip-64bit-boot.wks, or maybe even
name them using the format, as something like rockchip-legacy-boot.wks
(well there
is probably a more descriptive name for that format) and rockchip-itb-boot.wks ?

Similarly, the .wks for 3288-based boards and for 3399-based ones only
differ by the
console baudrate, and the 3288-based .wks are all identical except for
some whitespace.
And in fact, it is not unthinkable for a given project to use
something else than a
single-partition layout, so those files are indeed closer to a
"default wks". Maybe we
could use more generic filenames there too (until we implement a way to avoid
hardcoding the baudrate here)

[1] http://opensource.rock-chips.com/wiki_Boot_option
True. We could definitely use some cleanup in this area. If you want to
propose something that's going to work, I'll add it.

Also, when adding a new board, please update the top-level README.

Thanks!


Re: [meta-rockchip][PATCH v2] Rock64: add machine

Yann Dirson
 

Le lun. 14 juin 2021 à 18:19, Trevor Woerner <twoerner@...> a écrit :

Hi Yann,

Thanks for the contribution!

On Mon 2021-05-31 @ 04:00:58 PM, yann.dirson@... wrote:
From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.
Sounds good. I prefer the rockchip default of 1,500,000 anyway.


Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

conf/machine/include/rk3328.inc | 25 ++++++++++++++++
conf/machine/rock64.conf | 30 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 +++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
4 files changed, 88 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries
Odd that you'd be assigning the copyright to Garmin ;-)
Oh, right, copypaste rules around here, so Garmin does have a role but
something may be missing :)


+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3328"
+
+DEFAULTTUNE ?= "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
+SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..38bc9fa
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,30 @@
+# Copyright (C) 2021 Blade SAS
Can you also specify an OSS-friendly licence too?

+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES += "usbhost serial"
+
+UBOOT_MACHINE = "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?= "mmcblk1"
+
+WKS_FILE ?= "rock-pi-4.wks"
Personally I'd prefer to see a rock64 wic file which includes an rk3328
default, even if it is a copy of the rock-pi-4 layout.
Right that was something I wondered how to deal with and forgot (and note that
for the nanopi-m4 I used the same file).

My reading of [1] is that all rockchip APs are using the same
partition table. I see
that the existing {rk3288,rk3399}-boot.wks only differ in the choice
of u-boot image,
and I'm wondering if using the SoC to distinguish between them is the
right choice,
as eg. upstream RK is not using the .itb format, and I suspect we
could use it as well
for rk3288 (I'm sure I have one in a drawer and could check that some day). Now
maybe the sate of things is different for 32bit SoCs, and I thought it
could make sense to
distinguish rockchip-32bit-boot.wks and rockchip-64bit-boot.wks, or maybe even
name them using the format, as something like rockchip-legacy-boot.wks
(well there
is probably a more descriptive name for that format) and rockchip-itb-boot.wks ?

Similarly, the .wks for 3288-based boards and for 3399-based ones only
differ by the
console baudrate, and the 3288-based .wks are all identical except for
some whitespace.
And in fact, it is not unthinkable for a given project to use
something else than a
single-partition layout, so those files are indeed closer to a
"default wks". Maybe we
could use more generic filenames there too (until we implement a way to avoid
hardcoding the baudrate here)

[1] http://opensource.rock-chips.com/wiki_Boot_option

+IMAGE_FSTYPES += "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+KBUILD_DEFCONFIG = "defconfig"
diff --git a/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
new file mode 100644
index 0000000..1ad3b9e
--- /dev/null
+++ b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
@@ -0,0 +1,27 @@
+From f10cfe01f753348d346374008b8e8f5f26ed94ab Mon Sep 17 00:00:00 2001
+From: Kamil Trzcinski <ayufan@...>
+Date: Mon, 28 Aug 2017 11:24:37 +0200
+Subject: [PATCH] ayufan: dtsi: rk3328: add mmc0/mmc1 aliases
+Upstream-Status: Pending [https://github.com/ayufan-rock64/linux-mainline-kernel/commit/f10cfe01f753348d346374008b8e8f5f26ed94ab]
+
+Change-Id: I82a5394df8a505f7d1496393621c1198895c88b0
+---
+ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+index 0afed15bc7ff..800f1c796882 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+@@ -27,6 +27,8 @@
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
++ mmc0 = &emmc;
++ mmc1 = &sdmmc;
+ ethernet0 = &gmac2io;
+ ethernet1 = &gmac2phy;
+ };
+--
+2.30.2
+
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/linux/linux-yocto%.bbappend
index 7702e3f..3789c72 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -8,3 +8,9 @@ COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb"
+COMPATIBLE_MACHINE_rock64 = "rock64"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+# indeed applicable to all rk3328 boards
I have a roc-rk3328-cc ("renegade") board I should investigate adding. Then I
can see if this applies there as well.

+SRC_URI_append_rock64 = " file://0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch"
--
2.30.2


--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech


Re: [meta-java] icedtea7 fetching error

Alexander Kanavin
 

On Mon, 14 Jun 2021 at 23:31, Richard Leitner - SKIDATA <Richard.Leitner@...> wrote:
Thank you very much Richard!
The openjdk8 tarballs are now hosted at https://downloads.yoctoproject.org/mirror/sources/
with their local download names.

Unfortunately I currently don't have the time and resources to provide a
patch for fixing the URLs and adding the mirror.
So help is greatly appreciated!

Unfortunately I think you mirrored the wrong tarballs. The problematic ones are specifically the six tarballs coming from http://icedtea.classpath.org/hg/
and I am not seeing them mirrored. See the original error at the start of this thread:

--2021-06-07 17:24:33--  http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/archive/f89009ada191.tar.bz2
Resolving icedtea.classpath.org (icedtea.classpath.org)... 172.104.137.120
Connecting to icedtea.classpath.org (icedtea.classpath.org)|172.104.137.120|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-06-07 16:21:05 ERROR 404: Not Found.

Alex



[meta-rockchip][PATCH] qtbase: Add needed bbappend for rk3399 SOCs

Khem Raj
 

This ensures that DISTRO_FEATURES can translates correctly
for qtbate packageconfigs and we can get right platforms enabled

Signed-off-by: Khem Raj <raj.khem@...>
---
conf/layer.conf | 5 +++++
.../qt5-layer/recipes-qt/qt5/qtbase_%.bbappend | 9 +++++++++
2 files changed, 14 insertions(+)
create mode 100644 dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend

diff --git a/conf/layer.conf b/conf/layer.conf
index b263b6f..f97fb69 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -16,3 +16,8 @@ BBFILE_PRIORITY_rockchip = "1"
LAYERVERSION_rockchip = "1"
LAYERSERIES_COMPAT_rockchip = "hardknott"
LAYERDEPENDS_rockchip = "core meta-arm"
+
+BBFILES_DYNAMIC += " \
+ qt5-layer:${LAYERDIR}/dynamic-layers/qt5-layer/*/*/*.bb \
+ qt5-layer:${LAYERDIR}/dynamic-layers/qt5-layer/*/*/*.bbappend \
+"
diff --git a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
new file mode 100644
index 0000000..a977229
--- /dev/null
+++ b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
@@ -0,0 +1,9 @@
+PACKAGECONFIG_GL_rk3399 = "${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'gl', \
+ bb.utils.contains('DISTRO_FEATURES', 'opengl', 'eglfs gles2', \
+ '', d), d)}"
+PACKAGECONFIG_GL_append_rk3399 = " kms gbm"
+
+PACKAGECONFIG_FONTS_rk3399 = "fontconfig"
+
+PACKAGECONFIG_append_rk3399 = " libinput examples tslib xkbcommon"
+PACKAGECONFIG_remove_rk3399 = "tests"
--
2.32.0


M+ & H bugs with Milestone Movements WW24

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

3362

Improve dependency analysis tools

richard.purdie@...

newcomer@...

Future

3.99

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW23!

Stephen Jolley
 

All,

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

Who

Count

randy.macleod@...

2

ross@...

1

JPEWhacker@...

1

liezhi.yang@...

1

richard.purdie@...

1

Grand Total

6

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

32

ross@...

31

michael.opdenacker@...

22

david.reyna@...

22

bruce.ashfield@...

21

bluelightning@...

12

akuster808@...

12

timothy.t.orling@...

11

trevor.gamblin@...

11

JPEWhacker@...

11

sakib.sajal@...

10

kai.kang@...

9

randy.macleod@...

9

hongxu.jia@...

6

Qi.Chen@...

6

mingli.yu@...

6

chee.yang.lee@...

5

raj.khem@...

5

tony.tascioglu@...

5

yi.zhao@...

4

alexandre.belloni@...

3

mostthingsweb@...

3

yf3yu@...

2

mshah@...

2

pokylinux@...

2

ydirson@...

2

jaewon@...

2

alejandro@...

2

yoctoproject@...

1

naveen.kumar.saini@...

1

kergoth@...

1

Martin.Jansa@...

1

stacygaikovaia@...

1

dl9pf@...

1

liezhi.yang@...

1

open.source@...

1

weaverjs@...

1

nicolas.dechesne@...

1

kexin.hao@...

1

mark.hatle@...

1

mister_rs@...

1

jon.mason@...

1

john.kaldas.enpj@...

1

jeanmarie.lemetayer@...

1

devendra.tewari@...

1

aehs29@...

1

diego.sueiro@...

1

matthewzmd@...

1

thomas.perrot@...

1

saul.wold@...

1

douglas.royds@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 347 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Re: [meta-java] icedtea7 fetching error

Richard Purdie
 

On Mon, 2021-06-14 at 21:31 +0000, Richard Leitner - SKIDATA wrote:
On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote:
On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:
On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:
I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?
Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?
If someone points me at the tarballs I can probably sort something out with
our source mirrors.
Thank you very much Richard!
The openjdk8 tarballs are now hosted at https://downloads.yoctoproject.org/mirror/sources/
with their local download names.

Unfortunately I currently don't have the time and resources to provide a
patch for fixing the URLs and adding the mirror.
So help is greatly appreciated!
In theory if these are the names the metadata was using and you have the standard
OE/Yocto source mirrors, this should "just work"...

Cheers,

Richard


Re: [meta-java] icedtea7 fetching error

Richard Leitner
 

On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote:
On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:
On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:
I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?
Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?
If someone points me at the tarballs I can probably sort something out with
our source mirrors.
Thank you very much Richard!
The openjdk8 tarballs are now hosted at https://downloads.yoctoproject.org/mirror/sources/
with their local download names.

Unfortunately I currently don't have the time and resources to provide a
patch for fixing the URLs and adding the mirror.
So help is greatly appreciated!

regards;rl


Cheers,

Richard


Re: [meta-java] icedtea7 fetching error

Richard Leitner
 

On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote:
On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:
On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:
I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?
Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?
If someone points me at the tarballs I can probably sort something out with
our source mirrors.
Thanks for that!

I'm currently uploading the tarballs and provide you the link as soon as
it's finished (sorry, really crappy uplink here 😕)

It's about 1GiB with following files affected:

openjdk8-242-corba-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-corba-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-corba-jdk8u242-ga.tar.bz2
openjdk8-242-hotspot-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-hotspot-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-hotspot-jdk8u242-ga.tar.bz2
openjdk8-242-jaxp-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jaxp-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jaxp-jdk8u242-ga.tar.bz2
openjdk8-242-jaxws-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jaxws-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jaxws-jdk8u242-ga.tar.bz2
openjdk8-242-jdk8u-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jdk8u-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jdk8u-jdk8u242-ga.tar.bz2
openjdk8-242-jdk-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jdk-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jdk-jdk8u242-ga.tar.bz2
openjdk8-242-langtools-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-langtools-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-langtools-jdk8u242-ga.tar.bz2
openjdk8-242-nashorn-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-nashorn-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-nashorn-jdk8u242-ga.tar.bz2
openjdk8-252-corba-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-corba-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-corba-jdk8u252-ga.tar.bz2
openjdk8-252-hotspot-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-hotspot-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-hotspot-jdk8u252-ga.tar.bz2
openjdk8-252-jaxp-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jaxp-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jaxp-jdk8u252-ga.tar.bz2
openjdk8-252-jaxws-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jaxws-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jaxws-jdk8u252-ga.tar.bz2
openjdk8-252-jdk8u-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jdk8u-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jdk8u-jdk8u252-ga.tar.bz2
openjdk8-252-jdk-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jdk-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jdk-jdk8u252-ga.tar.bz2
openjdk8-252-langtools-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-langtools-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-langtools-jdk8u252-ga.tar.bz2
openjdk8-252-nashorn-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-nashorn-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-nashorn-jdk8u252-ga.tar.bz2
openjdk8-265-corba-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-corba-jdk8u265-ga.tar.bz2
openjdk8-265-hotspot-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-hotspot-jdk8u265-ga.tar.bz2
openjdk8-265-jaxp-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jaxp-jdk8u265-ga.tar.bz2
openjdk8-265-jaxws-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jaxws-jdk8u265-ga.tar.bz2
openjdk8-265-jdk8u-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jdk8u-jdk8u265-ga.tar.bz2
openjdk8-265-jdk-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jdk-jdk8u265-ga.tar.bz2
openjdk8-265-langtools-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-langtools-jdk8u265-ga.tar.bz2
openjdk8-265-nashorn-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-nashorn-jdk8u265-ga.tar.bz2
openjdk8-272-corba-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-corba-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-corba-jdk8u272-ga.tar.bz2
openjdk8-272-hotspot-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-hotspot-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-hotspot-jdk8u272-ga.tar.bz2
openjdk8-272-jaxp-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jaxp-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jaxp-jdk8u272-ga.tar.bz2
openjdk8-272-jaxws-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jaxws-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jaxws-jdk8u272-ga.tar.bz2
openjdk8-272-jdk8u-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jdk8u-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jdk8u-jdk8u272-ga.tar.bz2
openjdk8-272-jdk-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jdk-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jdk-jdk8u272-ga.tar.bz2
openjdk8-272-langtools-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-langtools-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-langtools-jdk8u272-ga.tar.bz2
openjdk8-272-nashorn-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-nashorn-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-nashorn-jdk8u272-ga.tar.bz2
openjdk8-292-corba-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-corba-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-corba-jdk8u292-ga.tar.bz2
openjdk8-292-hotspot-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-hotspot-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-hotspot-jdk8u292-ga.tar.bz2
openjdk8-292-jaxp-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jaxp-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jaxp-jdk8u292-ga.tar.bz2
openjdk8-292-jaxws-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jaxws-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jaxws-jdk8u292-ga.tar.bz2
openjdk8-292-jdk8u-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jdk8u-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jdk8u-jdk8u292-ga.tar.bz2
openjdk8-292-jdk-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jdk-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jdk-jdk8u292-ga.tar.bz2
openjdk8-292-langtools-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-langtools-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-langtools-jdk8u292-ga.tar.bz2
openjdk8-292-nashorn-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-nashorn-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-nashorn-jdk8u292-ga.tar.bz2
icedtea-2.1.3.tar.gz



Cheers,

Richard
regards;rl


Re: [meta-java] icedtea7 fetching error

Richard Purdie
 

On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:
On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:
I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?
Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?
If someone points me at the tarballs I can probably sort something out with
our source mirrors.

Cheers,

Richard


Re: [meta-java] icedtea7 fetching error

Richard Leitner
 

On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:
I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?
Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?

regards;rl


Alex

On Tue, 8 Jun 2021 at 08:10, <George.Mocanu@...> wrote:

Hello,


I am trying to build something that relies on meta-java, but it fails on
do_fetch for the icedtea7 recipe:

--2021-06-07 17:24:33-- http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/archive/f89009ada191.tar.bz2
Resolving icedtea.classpath.org (icedtea.classpath.org)... 172.104.137.120
Connecting to icedtea.classpath.org (icedtea.classpath.org)|172.104.137.120|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-06-07 16:21:05 ERROR 404: Not Found.

ERROR: icedtea7-native-2.1.3-r1.0 do_fetch: Fetcher failure for URL: 'http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/archive/f89009ada191.tar.bz2;name=openjdk;unpack=false;downloadfilename=openjdk-f89009ada191.tar.bz2'. Unable to fetch URL from any source.


Following this link, seems like the webserver is down. Do you know any
mirror that I can use in the meantime?

Thanks,
George



3541 - 3560 of 57387