Re: [PATCH v3] rockchip: rv1108: Convert to OF_UPSTREAM
Reviewed-by: Otavio Salvador
Tested-by: Otavio Salvador
Em qua., 24 de abr. de 2024 às 11:18, Fabio Estevam
escreveu:
> Instead of using the local rv1108 devicetree copies from U-Boot,
> let's convert the rv1108 boards to OF_UPSTREAM so that the upstream kernel
> devicetrees can be used instead.
>
> Tested on a rv1108-elgin-r1 board.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v2:
> - Also removed the arch/arm/dts/Makefile entries.
>
> arch/arm/dts/Makefile| 4 -
> arch/arm/dts/rv1108-elgin-r1.dts | 59
> arch/arm/dts/rv1108-evb.dts | 79 -
> arch/arm/dts/rv1108.dtsi | 581 ---
> arch/arm/mach-rockchip/Kconfig | 1 +
> configs/elgin-rv1108_defconfig | 2 +-
> configs/evb-rv1108_defconfig | 2 +-
> 7 files changed, 3 insertions(+), 725 deletions(-)
> delete mode 100644 arch/arm/dts/rv1108-elgin-r1.dts
> delete mode 100644 arch/arm/dts/rv1108-evb.dts
> delete mode 100644 arch/arm/dts/rv1108.dtsi
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index b1c9c6222e5d..e600f9c6ed25 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -182,10 +182,6 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
> rk3588-rock-5b.dtb \
> rk3588-turing-rk1.dtb
>
> -dtb-$(CONFIG_ROCKCHIP_RV1108) += \
> - rv1108-elgin-r1.dtb \
> - rv1108-evb.dtb
> -
> dtb-$(CONFIG_ROCKCHIP_RV1126) += \
> rv1126-edgeble-neu2-io.dtb
>
> diff --git a/arch/arm/dts/rv1108-elgin-r1.dts
> b/arch/arm/dts/rv1108-elgin-r1.dts
> deleted file mode 100644
> index 83e8b3183847..
> --- a/arch/arm/dts/rv1108-elgin-r1.dts
> +++ /dev/null
> @@ -1,59 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * (C) Copyright 2016 Rockchip Electronics Co., Ltd
> - */
> -
> -/dts-v1/;
> -
> -#include "rv1108.dtsi"
> -
> -/ {
> - model = "Elgin RV1108 R1 board";
> - compatible = "elgin,rv1108-elgin", "rockchip,rv1108";
> -
> - memory@6000 {
> - device_type = "memory";
> - reg = <0x6000 0x0800>;
> - };
> -
> - chosen {
> - stdout-path = "serial2:150n8";
> - };
> -};
> -
> - {
> - pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _bus8>;
> - bus-width = <8>;
> - cap-mmc-highspeed;
> - disable-wp;
> - non-removable;
> - status = "okay";
> -};
> -
> - {
> - status = "okay";
> -
> - u2phy_otg: otg-port {
> - status = "okay";
> - };
> -};
> -
> - {
> - pinctrl-names = "default";
> - pinctrl-0 = <_xfer_pullup>;
> - status = "okay";
> -};
> -
> -_otg {
> - status = "okay";
> -};
> -
> - {
> - uart2m0 {
> - uart2m0_xfer_pullup: uart2m0-xfer-pullup {
> - rockchip,pins = <2 RK_PD2 RK_FUNC_1
> _pull_up_drv_8ma>,
> - <2 RK_PD1 RK_FUNC_1
> _pull_up_drv_8ma>;
> - };
> - };
> -};
> diff --git a/arch/arm/dts/rv1108-evb.dts b/arch/arm/dts/rv1108-evb.dts
> deleted file mode 100644
> index c91776bc106e..
> --- a/arch/arm/dts/rv1108-evb.dts
> +++ /dev/null
> @@ -1,79 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * (C) Copyright 2016 Rockchip Electronics Co., Ltd
> - */
> -
> -/dts-v1/;
> -
> -#include "rv1108.dtsi"
> -
> -/ {
> - model = "Rockchip RV1108 Evaluation board";
> - compatible = "rockchip,rv1108-evb", "rockchip,rv1108";
> -
> - memory@6000 {
> - device_type = "memory";
> - reg = <0x6000 0x0800>;
> - };
> -
> - chosen {
> - stdout-path = "serial2:150n8";
> - };
> -
> - vcc5v0_otg: vcc5v0-otg-drv {
> - compatible = "regulator-fixed";
> - enable-active-high;
> - regulator-name = "vcc5v0_otg";
> - gpio = < RK_PB0 GPIO_ACTIVE_HIGH>;
> - regulator-min-microvolt = <500>;
> - regulator-max-microvolt = <500>;
> - };
> -};
> -
> - {
> - status = "okay";
> - clock_in_out = <0>;
> - snps,reset-active-low;
> - snps,reset-delays-us = <0 1 100>;
> - snp
Re: [OE-core] [PATCH v2] bmaptool: Add bmap-tools runtime alias for compatibility
Em qui., 7 de mar. de 2024 às 13:14, Alexander Kanavin <
alex.kana...@gmail.com> escreveu:
> On Thu, 7 Mar 2024 at 14:43, Tom Hochstein wrote:
> > +# For compatibility with layers before scarthgap
> > +RPROVIDES:${PN} = "bmap-tools"
> > +RREPLACES:${PN} = "bmap-tools"
> > +RCONFLICTS:${PN} = "bmap-tools"
>
> Only RREPLACES/RCONFLICTS please. Do not add the obsolete RPROVIDES.
>
For package feed upgrade it is required.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196805):
https://lists.openembedded.org/g/openembedded-core/message/196805
Mute This Topic: https://lists.openembedded.org/mt/104787184/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility
Em qua., 6 de mar. de 2024 às 09:55, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > Put another way, if I were to merge the PROVIDES, when would it ever be > acceptable to remove it? > I'd do it in next release; so it keeps a time for upgrade. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196676): https://lists.openembedded.org/g/openembedded-core/message/196676 Mute This Topic: https://lists.openembedded.org/mt/104753355/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility
Em qua., 6 de mar. de 2024 às 09:36, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > On Wed, 2024-03-06 at 09:13 -0300, Otavio Salvador wrote: > > Em ter., 5 de mar. de 2024 às 21:06, Richard Purdie > > escreveu: > > > On Tue, 2024-03-05 at 14:36 -0600, Tom Hochstein wrote: > > > > The rename of bmap-tools to bmaptool creates an incompatibility > > > > for > > > > pre-scarthgap layers. Restore compatibility by adding bmap-tools > > > > as > > > > an alias. > > > > > > > > Acked-by: Otavio Salvador > > > > Signed-off-by: Tom Hochstein > > > > --- > > > > meta/recipes-support/bmaptool/bmaptool_git.bb | 8 > > > > 1 file changed, 8 insertions(+) > > > > > > Perhaps we should just drop nanbield from the layer series instead > > > as > > > we're about to do that anyway? > > > > > > I'm worried this will just mask things and stop people renaming :/. > > > > > > > I understand your point of view, but it is a must for package feeds, > > or it will break them. > > You need the R* changes for that which is fair enough but you do not > the PROVIDES... > Sure, but since we're late on release, it would be helpful to maintain compatibility. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196674): https://lists.openembedded.org/g/openembedded-core/message/196674 Mute This Topic: https://lists.openembedded.org/mt/104753355/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility
Em ter., 5 de mar. de 2024 às 21:06, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > On Tue, 2024-03-05 at 14:36 -0600, Tom Hochstein wrote: > > The rename of bmap-tools to bmaptool creates an incompatibility for > > pre-scarthgap layers. Restore compatibility by adding bmap-tools as > > an alias. > > > > Acked-by: Otavio Salvador > > Signed-off-by: Tom Hochstein > > --- > > meta/recipes-support/bmaptool/bmaptool_git.bb | 8 > > 1 file changed, 8 insertions(+) > > Perhaps we should just drop nanbield from the layer series instead as > we're about to do that anyway? > > I'm worried this will just mask things and stop people renaming :/. > I understand your point of view, but it is a must for package feeds, or it will break them. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196669): https://lists.openembedded.org/g/openembedded-core/message/196669 Mute This Topic: https://lists.openembedded.org/mt/104753355/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] linux-firmware: Fix the linux-firmware-bcm4373 FILES variable
Em seg., 8 de jan. de 2024 às 11:17, escreveu: > From: "Rodrigo M. Duarte" > > This commit includes the 'cyfmac4373-sdio.clm_blob' file in > the list of files for the linux-firmware-bcm4373 package. > Without this file, the linux-firmware package adds all > firmware packages to the image. > > Signed-off-by: Rodrigo M. Duarte > Signed-off-by: Otavio Salvador > -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193437): https://lists.openembedded.org/g/openembedded-core/message/193437 Mute This Topic: https://lists.openembedded.org/mt/103597527/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 4/4] weston: Add sysconfdir to FILES:${PN}
From: Luan Rafael Carneiro
When enabling the vnc feature as backend, the weston-remote-access is
installed from meson inside the /etc/pam.d directory.
Signed-off-by: Luan Rafael Carneiro
Signed-off-by: Otavio Salvador
---
meta/recipes-graphics/wayland/weston_12.0.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/wayland/weston_12.0.2.bb
b/meta/recipes-graphics/wayland/weston_12.0.2.bb
index cc7f95eea8..5a179e6770 100644
--- a/meta/recipes-graphics/wayland/weston_12.0.2.bb
+++ b/meta/recipes-graphics/wayland/weston_12.0.2.bb
@@ -132,7 +132,7 @@ PACKAGES += "${@bb.utils.contains('PACKAGECONFIG',
'xwayland', '${PN}-xwayland',
libweston-${WESTON_MAJOR_VERSION} ${PN}-examples"
FILES:${PN}-dev += "${libdir}/${BPN}/libexec_weston.so"
-FILES:${PN} = "${bindir}/weston ${bindir}/weston-terminal
${bindir}/weston-info ${bindir}/weston-launch ${bindir}/wcap-decode
${libexecdir} ${libdir}/${BPN}/*.so* ${datadir}"
+FILES:${PN} = "${sysconfdir} ${bindir}/weston ${bindir}/weston-terminal
${bindir}/weston-info ${bindir}/weston-launch ${bindir}/wcap-decode
${libexecdir} ${libdir}/${BPN}/*.so* ${datadir}"
FILES:libweston-${WESTON_MAJOR_VERSION} = "${libdir}/lib*${SOLIBS}
${libdir}/libweston-${WESTON_MAJOR_VERSION}/*.so"
SUMMARY:libweston-${WESTON_MAJOR_VERSION} = "Helper library for implementing
'wayland window managers'."
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187450):
https://lists.openembedded.org/g/openembedded-core/message/187450
Mute This Topic: https://lists.openembedded.org/mt/101255453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/4] weston: Upgrade version 12.0.1 -> 12.0.2
From: Luan Rafael Carneiro
This is a bug fix release for 12.0 version. Full commit history bellow:
Derek Foreman (1):
data-device: Don't make a weston_coord with no valid space
Leandro Ribeiro (3):
drm: drop disable_planes being false as a condition to support writeback
drm: do not pull writeback task if KMS atomic API is not supported
tests: assert that capture info was received before trying screenshot
Liu, Kai1 (1):
xwm: WM_TRANSIENT_FOR should not point to override-redirect window
Marius Vlad (3):
backend-drm: Make DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP inert
backend-drm/meson.build: Require at least mesa 21.1.1
build: bump to version 12.0.2 for the point release
Michael Olbrich (1):
backend-wayland: fix --fullscreen
Pekka Paalanen (1):
man: make --wait-for-debugger findable
Philipp Zabel (2):
backend-rdp: extract weston_output_set_single_mode()
backend-vnc: use weston_output_set_single_mode()
Signed-off-by: Luan Rafael Carneiro
Signed-off-by: Otavio Salvador
---
.../wayland/{weston_12.0.1.bb => weston_12.0.2.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/wayland/{weston_12.0.1.bb => weston_12.0.2.bb}
(98%)
diff --git a/meta/recipes-graphics/wayland/weston_12.0.1.bb
b/meta/recipes-graphics/wayland/weston_12.0.2.bb
similarity index 98%
rename from meta/recipes-graphics/wayland/weston_12.0.1.bb
rename to meta/recipes-graphics/wayland/weston_12.0.2.bb
index 8c2438cdaa..cc7f95eea8 100644
--- a/meta/recipes-graphics/wayland/weston_12.0.1.bb
+++ b/meta/recipes-graphics/wayland/weston_12.0.2.bb
@@ -13,7 +13,7 @@ SRC_URI =
"https://gitlab.freedesktop.org/wayland/weston/-/releases/${PV}/downlo
file://systemd-notify.weston-start \
"
-SRC_URI[sha256sum] =
"b18591eab278bc191720f6c09158040b795e7118af1d5ddca6acd9a8e2039535"
+SRC_URI[sha256sum] =
"eb686a7cf00992a23b17f192fca9a887313e92c346ee35d8575196983d656b4a"
UPSTREAM_CHECK_URI = "https://wayland.freedesktop.org/releases.html;
UPSTREAM_CHECK_REGEX = "weston-(?P\d+\.\d+\.(?!9\d+)\d+)"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187449):
https://lists.openembedded.org/g/openembedded-core/message/187449
Mute This Topic: https://lists.openembedded.org/mt/101255452/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/4] weston-init: fix init code indentation
Tested-by: Tom Hochstein Signed-off-by: Otavio Salvador --- meta/recipes-graphics/wayland/weston-init/init | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/wayland/weston-init/init b/meta/recipes-graphics/wayland/weston-init/init index d3b0d1873e..a5c54e001e 100644 --- a/meta/recipes-graphics/wayland/weston-init/init +++ b/meta/recipes-graphics/wayland/weston-init/init @@ -30,7 +30,7 @@ done case "$1" in start) . /etc/profile - export HOME=ROOTHOME + export HOME=ROOTHOME WESTON_USER=weston weston-start $OPTARGS & ;; -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187448): https://lists.openembedded.org/g/openembedded-core/message/187448 Mute This Topic: https://lists.openembedded.org/mt/101255451/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/4] weston-init: remove misleading comment about udev rule
The udev rule has been removed but the comment has kept, by
mistake. Remove it.
Fixes: dd83fb40f7 ("weston-init: Stop running weston as root")
Tested-by: Tom Hochstein
Signed-off-by: Otavio Salvador
---
meta/recipes-graphics/wayland/weston-init.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index 1884b5d440..024e400665 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -36,7 +36,7 @@ do_install() {
sed -i 's#ROOTHOME#${ROOT_HOME}#'
${D}/${sysconfdir}/init.d/weston
fi
- # Install Weston systemd service and accompanying udev rule
+ # Install Weston systemd service
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
then
install -D -p -m0644 ${WORKDIR}/weston.service
${D}${systemd_system_unitdir}/weston.service
install -D -p -m0644 ${WORKDIR}/weston.socket
${D}${systemd_system_unitdir}/weston.socket
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187447):
https://lists.openembedded.org/g/openembedded-core/message/187447
Mute This Topic: https://lists.openembedded.org/mt/101255450/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Keep scripts/create-pull-request and send-pull-request ?
Hi Michael, Em qui., 10 de ago. de 2023 às 11:04, Michael Opdenacker via lists.openembedded.org escreveu: > > Greetings, > > I'm reviewing > https://docs.yoctoproject.org/next/contributor-guide/submit-change.html#using-scripts-to-push-a-change-upstream-and-request-a-pull > and trying to simplify it. > > Do people still use scripts/create-pull-request and send-pull-request? I > see some obsolete URLs in the first script, and mostly old commits to > their code. > > I'm also asking because I'm wondering whether it's better to document > how to create and send pull requests from standard git tools. This way, > people also learn how to submit pull requests to other upstreams. > > What do you think? I completely agree that documenting standard git tools is a great idea. This way, people will learn how to submit pull requests to other upstreams, which is always a valuable skill to have. Best regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185749): https://lists.openembedded.org/g/openembedded-core/message/185749 Mute This Topic: https://lists.openembedded.org/mt/100663724/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 3/3] weston-init: mimic systemd behavior when running in sysvinit
Hello Alexandre, Em seg., 7 de ago. de 2023 às 05:56, Alexandre Belloni via lists.openembedded.org escreveu: > I believe this change causes this QA failure: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/7576/steps/12/logs/stdio I'll check this. @Purdie, Richard please hold this patch until I check the error. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185594): https://lists.openembedded.org/g/openembedded-core/message/185594 Mute This Topic: https://lists.openembedded.org/mt/100553774/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe-core][PATCHv2] systemd: add less to RRECOMMENDS
Em sáb., 5 de ago. de 2023 às 04:03, Markus Volk escreveu: > journald uses less to display logs. less.busybox can do the > job, but it rips out support for color/highlighting. > > So I would highly recommend to use the real 'less' > > Signed-off-by: Markus Volk I think this should be added depending on a PACKAGECONFIG. Adding it by default seems overkill. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185556): https://lists.openembedded.org/g/openembedded-core/message/185556 Mute This Topic: https://lists.openembedded.org/mt/100561087/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] systemd: add usrmerge to REQUIRED_DISTRO_FEATURES
Em sáb., 5 de ago. de 2023 às 08:06, Luca Bocassi escreveu: > From: Luca Boccassi > > Support for unmerged-usr is deprecated upstream, taints the system and > has been removed for v255 (next release). > Enforce building merged-usr images when using systemd. This allows one > release cycle where it can be tested for any remaining issue, and can > still be overridden, before it stops working completely. > > Signed-off-by: Luca Boccassi This makes sense. I also prefer to add this sooner than later. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185553): https://lists.openembedded.org/g/openembedded-core/message/185553 Mute This Topic: https://lists.openembedded.org/mt/100562757/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 3/3] weston-init: mimic systemd behavior when running in sysvinit
Em sex., 4 de ago. de 2023 às 20:54, Khem Raj escreveu:
> On Fri, Aug 4, 2023 at 1:05 PM Otavio Salvador
> wrote:
> > -su -c "XDG_RUNTIME_DIR=/run/user/`id -u ${WESTON_USER}` weston
> > $weston_args --log=/tmp/weston.log" $WESTON_USER
> > +if [ -z "$WAYLAND_DISPLAY" ]; then
> > + WAYLAND_DISPLAY=/run/wayland-0
>
> This can be set automatically by something like
> WAYLAND_DISPLAY=`basename /run/user/1000/wayland-[0-9]`
>
> That way it can cover more e.g. my variscite/imx8 SOM I have wayland-1
This uses the same as systemd, so it has the same behavior. However,
it supports users to override it using /etc/default/weston. So it sets
this only if unset.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185552):
https://lists.openembedded.org/g/openembedded-core/message/185552
Mute This Topic: https://lists.openembedded.org/mt/100553774/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/3] weston-init: mimic systemd behavior when running in sysvinit
The systemd uses /run/wayland-0 as global socket and it is important to
align the behavior so it avoids diverging when using sysvinit. Another
change is installing the ${sysconfdir}/profile.d/weston-socket.sh script
also aligning the behaviors.
The commit modifies the behavior of the weston-init script when running
in sysvinit. It mimics the behavior of systemd by exporting the
WAYLAND_DISPLAY variable and using it as the socket for the weston
command.
The changes include:
- The installation of the weston-socket.sh script in the /etc/profile.d
directory, which sets the WAYLAND_DISPLAY variable to /run/wayland-0 if
it is not already set.
- Modifying the weston-start script to check if the WAYLAND_DISPLAY
variable is set. If not, it sets it to /run/wayland-0.
These changes ensure that the weston command uses the same socket
defined in the WAYLAND_DISPLAY variable, allowing compatibility with
systems using sysvinit and systemd.
Fixes: 2818cbc730 ("weston-init: add profile to point users to global socket")
Tested-by: Tom Hochstein
Signed-off-by: Otavio Salvador
---
meta/recipes-graphics/wayland/weston-init.bb | 4 +++-
meta/recipes-graphics/wayland/weston-init/weston-start | 6 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index 024e400665..6c8dc36467 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -40,13 +40,15 @@ do_install() {
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
then
install -D -p -m0644 ${WORKDIR}/weston.service
${D}${systemd_system_unitdir}/weston.service
install -D -p -m0644 ${WORKDIR}/weston.socket
${D}${systemd_system_unitdir}/weston.socket
- install -D -p -m0644 ${WORKDIR}/weston-socket.sh
${D}${sysconfdir}/profile.d/weston-socket.sh
sed -i -e s:/etc:${sysconfdir}:g \
-e s:/usr/bin:${bindir}:g \
-e s:/var:${localstatedir}:g \
${D}${systemd_system_unitdir}/weston.service
fi
+ # Export the WAYLAND_DISPLAY in case it is using the global socket
+ install -D -p -m0644 ${WORKDIR}/weston-socket.sh
${D}${sysconfdir}/profile.d/weston-socket.sh
+
if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then
install -D -p -m0644 ${WORKDIR}/weston-autologin
${D}${sysconfdir}/pam.d/weston-autologin
fi
diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start
b/meta/recipes-graphics/wayland/weston-init/weston-start
index 01670cd4f5..7b898bb436 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -68,4 +68,8 @@ if test -z "$XDG_RUNTIME_DIR"; then
fi
fi
-su -c "XDG_RUNTIME_DIR=/run/user/`id -u ${WESTON_USER}` weston $weston_args
--log=/tmp/weston.log" $WESTON_USER
+if [ -z "$WAYLAND_DISPLAY" ]; then
+ WAYLAND_DISPLAY=/run/wayland-0
+fi
+
+su -c "XDG_RUNTIME_DIR=/run/user/`id -u ${WESTON_USER}` weston $weston_args
--socket=$WAYLAND_DISPLAY --log=/tmp/weston.log" $WESTON_USER
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185541):
https://lists.openembedded.org/g/openembedded-core/message/185541
Mute This Topic: https://lists.openembedded.org/mt/100553774/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/3] weston-init: fix init code indentation
Tested-by: Tom Hochstein Signed-off-by: Otavio Salvador --- meta/recipes-graphics/wayland/weston-init/init | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/wayland/weston-init/init b/meta/recipes-graphics/wayland/weston-init/init index d3b0d1873e..a5c54e001e 100644 --- a/meta/recipes-graphics/wayland/weston-init/init +++ b/meta/recipes-graphics/wayland/weston-init/init @@ -30,7 +30,7 @@ done case "$1" in start) . /etc/profile - export HOME=ROOTHOME + export HOME=ROOTHOME WESTON_USER=weston weston-start $OPTARGS & ;; -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185540): https://lists.openembedded.org/g/openembedded-core/message/185540 Mute This Topic: https://lists.openembedded.org/mt/100553772/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/3] weston-init: remove misleading comment about udev rule
The udev rule has been removed but the comment has kept, by
mistake. Remove it.
Fixes: dd83fb40f7 ("weston-init: Stop running weston as root")
Tested-by: Tom Hochstein
Signed-off-by: Otavio Salvador
---
meta/recipes-graphics/wayland/weston-init.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index 1884b5d440..024e400665 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -36,7 +36,7 @@ do_install() {
sed -i 's#ROOTHOME#${ROOT_HOME}#'
${D}/${sysconfdir}/init.d/weston
fi
- # Install Weston systemd service and accompanying udev rule
+ # Install Weston systemd service
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
then
install -D -p -m0644 ${WORKDIR}/weston.service
${D}${systemd_system_unitdir}/weston.service
install -D -p -m0644 ${WORKDIR}/weston.socket
${D}${systemd_system_unitdir}/weston.socket
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185539):
https://lists.openembedded.org/g/openembedded-core/message/185539
Mute This Topic: https://lists.openembedded.org/mt/100553771/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] cmake: Upgrade to 3.26.3
Em qua., 3 de mai. de 2023 às 23:51, Khem Raj escreveu: > License-Update: Copyright year changed from 2022 -> 2023 > > - Copyright 2000-2022 Kitware, Inc. and Contributors > + Copyright 2000-2023 Kitware, Inc. and Contributors > > Call bootstrap directly without wrapping it with configure > since all it does it find the sourcedir > > Signed-off-by: Khem Raj > Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180863): https://lists.openembedded.org/g/openembedded-core/message/180863 Mute This Topic: https://lists.openembedded.org/mt/98676913/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: 23.0.2 -> 23.0.3
Hello Richard, Em qua., 3 de mai. de 2023 às 05:17, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > On Wed, 2023-05-03 at 09:14 +0100, Richard Purdie via > lists.openembedded.org wrote: > > On Tue, 2023-05-02 at 17:12 -0300, Otavio Salvador wrote: > > > Update to 23.0.3 stable release. Release notes in: > > > > > > - https://docs.mesa3d.org/relnotes/23.0.3.html > > > > > > Signed-off-by: Otavio Salvador > > > --- > > > > Unfortunately I isolated this change to be causing qemuppc xorg sanity > > check failures: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/7010 > > https://autobuilder.yoctoproject.org/typhoon/#/builders/107/builds/4517 > > > > I've not looked into why, just isolated it to this change. > > Sorry, I was about to remove the patch and I'm not sure I have isolated > it to that :(. > > I'll do some further checks as whilst I meant to isolate it to this, > I'm not sure I did. > An error occurred due to an invalid instruction. Have you removed the QEMU upgrade that was previously installed? The upgrade version was 8.0.0, replacing the older version, 7.2.0. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180812): https://lists.openembedded.org/g/openembedded-core/message/180812 Mute This Topic: https://lists.openembedded.org/mt/98647584/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] mesa: 23.0.2 -> 23.0.3
Update to 23.0.3 stable release. Release notes in:
- https://docs.mesa3d.org/relnotes/23.0.3.html
Signed-off-by: Otavio Salvador
---
.../mesa/{mesa-gl_23.0.2.bb => mesa-gl_23.0.3.bb} | 0
meta/recipes-graphics/mesa/mesa.inc | 2 +-
meta/recipes-graphics/mesa/{mesa_23.0.2.bb => mesa_23.0.3.bb} | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/mesa/{mesa-gl_23.0.2.bb => mesa-gl_23.0.3.bb}
(100%)
rename meta/recipes-graphics/mesa/{mesa_23.0.2.bb => mesa_23.0.3.bb} (100%)
diff --git a/meta/recipes-graphics/mesa/mesa-gl_23.0.2.bb
b/meta/recipes-graphics/mesa/mesa-gl_23.0.3.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_23.0.2.bb
rename to meta/recipes-graphics/mesa/mesa-gl_23.0.3.bb
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index babd10a855..10efff96f0 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -19,7 +19,7 @@ SRC_URI =
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
"
-SRC_URI[sha256sum] =
"1b7d3399fc6f16f030361f925d33ebc7600cbf98094582f54775b6a1180529e7"
+SRC_URI[sha256sum] =
"386362a5d80df3b096636b67f340e1ce67b705b44767d5bdd11d2ed1037192d5"
UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"
diff --git a/meta/recipes-graphics/mesa/mesa_23.0.2.bb
b/meta/recipes-graphics/mesa/mesa_23.0.3.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa_23.0.2.bb
rename to meta/recipes-graphics/mesa/mesa_23.0.3.bb
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180770):
https://lists.openembedded.org/g/openembedded-core/message/180770
Mute This Topic: https://lists.openembedded.org/mt/98647584/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] glide: remove as 'go mod' has become standard
Signed-off-by: Otavio Salvador
---
meta/classes-recipe/glide.bbclass | 15 ---
meta/conf/distro/include/maintainers.inc| 1 -
meta/recipes-devtools/glide/glide_0.13.3.bb | 43 -
3 files changed, 59 deletions(-)
delete mode 100644 meta/classes-recipe/glide.bbclass
delete mode 100644 meta/recipes-devtools/glide/glide_0.13.3.bb
diff --git a/meta/classes-recipe/glide.bbclass
b/meta/classes-recipe/glide.bbclass
deleted file mode 100644
index 21b48fa4e0..00
--- a/meta/classes-recipe/glide.bbclass
+++ /dev/null
@@ -1,15 +0,0 @@
-#
-# Copyright OpenEmbedded Contributors
-#
-# SPDX-License-Identifier: MIT
-#
-
-# Handle Glide Vendor Package Management use
-#
-# Copyright 2018 (C) O.S. Systems Software LTDA.
-
-DEPENDS:append = " glide-native"
-
-do_compile:prepend() {
-( cd ${B}/src/${GO_IMPORT} && glide install )
-}
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 682ec2cfdf..6902019f3a 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -211,7 +211,6 @@ RECIPE_MAINTAINER:pn-glibc-mtrace = "Khem Raj
"
RECIPE_MAINTAINER:pn-glibc-scripts = "Khem Raj "
RECIPE_MAINTAINER:pn-glibc-tests = "Lukasz Majewski "
RECIPE_MAINTAINER:pn-glibc-testsuite = "Khem Raj "
-RECIPE_MAINTAINER:pn-glide = "Otavio Salvador
"
RECIPE_MAINTAINER:pn-gmp = "Khem Raj "
RECIPE_MAINTAINER:pn-glslang = "Jose Quaresma "
RECIPE_MAINTAINER:pn-gnome-desktop-testing = "Ross Burton
"
diff --git a/meta/recipes-devtools/glide/glide_0.13.3.bb
b/meta/recipes-devtools/glide/glide_0.13.3.bb
deleted file mode 100644
index db703c2d21..00
--- a/meta/recipes-devtools/glide/glide_0.13.3.bb
+++ /dev/null
@@ -1,43 +0,0 @@
-SUMMARY = "Vendor Package Management for Golang"
-HOMEPAGE = "https://github.com/Masterminds/glide;
-DESCRIPTION = "Glide is a Vendor Package Management for Golang"
-LICENSE = "MIT"
-LIC_FILES_CHKSUM =
"file://src/${GO_IMPORT}/LICENSE;md5=54905cf894f8cc416a92f4fc350c35b2"
-
-GO_IMPORT = "github.com/Masterminds/glide"
-SRC_URI = "git://${GO_IMPORT};branch=master;protocol=https"
-SRCREV = "8ed5b9292379d86c39592a7e6a58eb9c903877cf"
-
-inherit go
-
-# New Go versions has Go modules support enabled by default and cause the Glide
-# tool build to fail.
-export GO111MODULE = "off"
-
-RDEPENDS:${PN}-dev += "bash"
-RDEPENDS:${PN}-ptest += "bash"
-
-BBCLASSEXTEND = "native nativesdk"
-
-# for x86 ends with textrel in ${PN}
-# http://errors.yoctoproject.org/Errors/Details/185631/
-# ERROR: QA Issue: ELF binary
'/work/i586-oe-linux/glide/0.13.1-r0/packages-split/glide/usr/bin/glide' has
relocations in .text [textrel]
-INSANE_SKIP:${PN} += "textrel"
-
-# for aarch64 ends with textrel in ${PN}-ptest
-# http://errors.yoctoproject.org/Errors/Details/185633/
-# ERROR: QA Issue: ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/glide.test'
has relocations in .text
-# ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/dependency/dependency.test'
has relocations in .text
-# ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/repo/repo.test'
has relocations in .text
-# ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/mirrors/mirrors.test'
has relocations in .text
-# ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/cfg/cfg.test'
has relocations in .text
-# ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/godep/strip/strip.test'
has relocations in .text
-# ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/path/path.test'
has relocations in .text
-# ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/tree/tree.test'
has relocations in .text
-# ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/util/util.test'
has relocations in .text
-# ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/action/action.test'
has relocations in .text
-# ELF binary
'/work/aarch64-oe-linux/glide/0.13.1-r0/packages-split/glide-ptest/usr/lib/glide/ptest/github.com/Masterminds/glide/cache/cache.test'
has relocations i
Re: [OE-core] [PATCH v3 3/3] mesa: Add PACKAGECONFIG "rusticl"
Em seg., 6 de mar. de 2023 às 06:11, Zoltan Boszormenyi
escreveu:
>
> In the anonymous python function that creates packages based
> on PACKAGECONFIG, use a single synthetic "opencl" setting
> that is added when either "clover" or "rusticl" are present.
>
> Without this, creating variables for two "libopencl-mesa" will
> confuse the packaging code, resulting in subsequent packages
> (like mesa-megadriver and others) being renamed incorrectly.
>
> This also makes sense from a packaging standpoint: currently
> both clover and rusticl can be enabled, in which case both CL
> frontends should go into the same libopencl-mesa subpackage.
>
> Signed-off-by: Zoltán Böszörményi
Please name the PACKAGECONFIG as opencl-rusticl
> inherit meson pkgconfig python3native gettext features_check
> +inherit ${@bb.utils.contains('PACKAGECONFIG', 'rusticl', 'rust', '', d)}
Here.
> BBCLASSEXTEND = "native nativesdk"
>
> @@ -136,6 +137,9 @@ PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
> OPENCL_NATIVE = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno',
> '-Dopencl-native=true', '', d)}"
> PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true
> ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
> spirv-tools"
>
> +# "rusticl" requires libclc, spirv-llvm-translator and bindgen-cli-native
> from meta-clang and spirv-tools from OE-Core
> +PACKAGECONFIG[rusticl] = "-Dgallium-rusticl=true
> -Drust_std=2021,-Dgallium-rusticl=false,bindgen-cli-native libclc spirv-tools
> spirv-llvm-translator,libclc spirv-tools spirv-llvm-translator"
Here.
> RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'clover',
> 'libclc spirv-tools', '', d)}"
> +RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'rusticl',
> 'libclc spirv-tools spirv-llvm-translator', '', d)}"
Here.
>
> PACKAGES =+ "libegl-mesa libegl-mesa-dev \
> libosmesa libosmesa-dev \
> @@ -250,6 +255,11 @@ do_install:append () {
> # RPROVIDEs/RCONFLICTs on the generic libgl name.
> python __anonymous() {
> pkgconfig = (d.getVar('PACKAGECONFIG') or "").split()
> +# Add the synthetic "opencl" string to pkgconfig because
> +# both "clover" and "rusticl" would create libopencl-mesa.
> + # Both CL frontends should go into the same package.
> +if "clover" in pkgconfig or "rusticl" in pkgconfig:
> +pkgconfig.append("opencl")
Here.
Also, we need to add RREPLACES, RRECOMMENDS and RCONFLICTS to old
clover package so we support package feed upgrades.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178079):
https://lists.openembedded.org/g/openembedded-core/message/178079
Mute This Topic: https://lists.openembedded.org/mt/97421292/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3 2/3] mesa: Rename PACKAGECONFIG "opencl" to "clover"
Em seg., 6 de mar. de 2023 às 06:11, Zoltan Boszormenyi
escreveu:
>
> There is another OpenCL frontend called "rusticl" now.
>
> Signed-off-by: Zoltán Böszörményi
...
> +PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true
> ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
> spirv-tools"
PACKAGECONFIG[opencl-clover]
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178078):
https://lists.openembedded.org/g/openembedded-core/message/178078
Mute This Topic: https://lists.openembedded.org/mt/97421291/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3 1/3] mesa, mesa-gl: 23.0.0
Em seg., 6 de mar. de 2023 às 06:11, Zoltan Boszormenyi escreveu: > > Signed-off-by: Zoltán Böszörményi Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#178077): https://lists.openembedded.org/g/openembedded-core/message/178077 Mute This Topic: https://lists.openembedded.org/mt/97421290/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [PATCH 1/2] barebox: add initial support
Em qua., 15 de fev. de 2023 às 11:11, Alexander Kanavin escreveu: > > On Wed, 15 Feb 2023 at 14:53, Otavio Salvador > wrote: > > I think the Barebox inside OE-Core allows a bigger integration and > > reuse of existing tooling for signing and other classes currently well > > integrated with U-Boot. For me, a critical point for decision is if > > Pengutronix will commit to support it. > > You should be well aware there's a history of people contributing > stuff to core and even assigning themselves as maintainers, then > disappearing. And then it falls (largely) on me to keep things > (barely) going. What happens if ptx withdraws its commitment? Can I > then send a commit that removes barebox from core? Imagine the angry > lynch mob that will show up after my head. Yes. If no one maintains, it should be removed. People will get mad but then we'll see more commitment in future. > Adding things to core is a decision that cannot be easily reversed, so > I'd rather have barebox in meta-barebox for a while, with any needed > fixing to classes and infra in core. Sure but adding things to the core should still be possible and it is a place to foster work sharing and contribution. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
Re: [yocto] [OE-core] [PATCH 1/2] barebox: add initial support
Em qua., 15 de fev. de 2023 às 11:11, Alexander Kanavin escreveu: > > On Wed, 15 Feb 2023 at 14:53, Otavio Salvador > wrote: > > I think the Barebox inside OE-Core allows a bigger integration and > > reuse of existing tooling for signing and other classes currently well > > integrated with U-Boot. For me, a critical point for decision is if > > Pengutronix will commit to support it. > > You should be well aware there's a history of people contributing > stuff to core and even assigning themselves as maintainers, then > disappearing. And then it falls (largely) on me to keep things > (barely) going. What happens if ptx withdraws its commitment? Can I > then send a commit that removes barebox from core? Imagine the angry > lynch mob that will show up after my head. Yes. If no one maintains, it should be removed. People will get mad but then we'll see more commitment in future. > Adding things to core is a decision that cannot be easily reversed, so > I'd rather have barebox in meta-barebox for a while, with any needed > fixing to classes and infra in core. Sure but adding things to the core should still be possible and it is a place to foster work sharing and contribution. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177200): https://lists.openembedded.org/g/openembedded-core/message/177200 Mute This Topic: https://lists.openembedded.org/mt/96956667/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [PATCH 1/2] barebox: add initial support
Em qua., 15 de fev. de 2023 às 10:44, Alexander Kanavin escreveu: > On Wed, 15 Feb 2023 at 12:22, Otavio Salvador > wrote: > >> Fair enough, I'm open to the idea. It would be interesting/useful to > >> see if anyone else in the community is in favour of this or not. I'm > >> sure you appreciate why we need to ask the question and why we can't > >> just add everything! :) > >> > >> The community usage does appear to be primarily phytec/ptx. > > > > I have used barebox in some projects in the past for multiple customers. It > > is a solid and commonly used bootloader. I consider U-Boot the industry > > standard, but Barebox is also widely used, and it makes sense to be part of > > OE-Core. > > I do not quite understand why barebox needs to be specifically in > oe-core. There's a well maintained layer for it: > https://github.com/menschel-d/meta-barebox > so once all those meta-phytec recipes are phased out in favour of > using that layer, there's no fragmentation. I think the Barebox inside OE-Core allows a bigger integration and reuse of existing tooling for signing and other classes currently well integrated with U-Boot. For me, a critical point for decision is if Pengutronix will commit to support it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
Re: [yocto] [OE-core] [PATCH 1/2] barebox: add initial support
Em qua., 15 de fev. de 2023 às 10:44, Alexander Kanavin escreveu: > On Wed, 15 Feb 2023 at 12:22, Otavio Salvador > wrote: > >> Fair enough, I'm open to the idea. It would be interesting/useful to > >> see if anyone else in the community is in favour of this or not. I'm > >> sure you appreciate why we need to ask the question and why we can't > >> just add everything! :) > >> > >> The community usage does appear to be primarily phytec/ptx. > > > > I have used barebox in some projects in the past for multiple customers. It > > is a solid and commonly used bootloader. I consider U-Boot the industry > > standard, but Barebox is also widely used, and it makes sense to be part of > > OE-Core. > > I do not quite understand why barebox needs to be specifically in > oe-core. There's a well maintained layer for it: > https://github.com/menschel-d/meta-barebox > so once all those meta-phytec recipes are phased out in favour of > using that layer, there's no fragmentation. I think the Barebox inside OE-Core allows a bigger integration and reuse of existing tooling for signing and other classes currently well integrated with U-Boot. For me, a critical point for decision is if Pengutronix will commit to support it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177193): https://lists.openembedded.org/g/openembedded-core/message/177193 Mute This Topic: https://lists.openembedded.org/mt/96956667/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 1/2] kernel-module-split: make autoload and probeconf distribution specific
Em qua., 15 de fev. de 2023 às 10:01, Jose Quaresma escreveu: > > The modules-load.d [1] - Configure kernel modules to load at boot > should install their configuration files in /usr/lib/modules-load.d. > > The modprobe.d [2] - Configuration directory for modprobe > should install their configuration files in /lib/modprobe.d > > [1] https://www.freedesktop.org/software/systemd/man/modules-load.d.html > [2] https://www.man7.org/linux/man-pages//man5/modprobe.d.5.html > > Signed-off-by: Jose Quaresma Did you validate this using busybox only? Using sysv and busybox need to be validated as well. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177189): https://lists.openembedded.org/g/openembedded-core/message/177189 Mute This Topic: https://lists.openembedded.org/mt/96981851/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [PATCH 1/2] barebox: add initial support
Hello Richard, Em ter., 14 de fev. de 2023 às 10:56, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > Fair enough, I'm open to the idea. It would be interesting/useful to > see if anyone else in the community is in favour of this or not. I'm > sure you appreciate why we need to ask the question and why we can't > just add everything! :) > > The community usage does appear to be primarily phytec/ptx. > I have used barebox in some projects in the past for multiple customers. It is a solid and commonly used bootloader. I consider U-Boot the industry standard, but Barebox is also widely used, and it makes sense to be part of OE-Core. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177184): https://lists.openembedded.org/g/openembedded-core/message/177184 Mute This Topic: https://lists.openembedded.org/mt/96956667/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3] u-boot: Upgrade to 2023.01
Em qui., 19 de jan. de 2023 às 15:26, Fabio Estevam escreveu: > +++ b/meta/recipes-bsp/u-boot/u-boot_2023.01.bb > @@ -0,0 +1,5 @@ > +require u-boot-common.inc > +require u-boot.inc > + > +DEPENDS += "bc-native dtc-native python3-setuptools-native" > + > python3-setuptools-native has been included in the common.inc so this depends can be removed. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176162): https://lists.openembedded.org/g/openembedded-core/message/176162 Mute This Topic: https://lists.openembedded.org/mt/96383492/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [regression] 2023.01 breaks u-boot-initial-env for aarch64
Thanks!
Em sáb., 7 de jan. de 2023 às 10:44, Fabio Estevam
escreveu:
> Hi Otavio,
>
> On Sat, Jan 7, 2023 at 10:22 AM Otavio Salvador
> wrote:
>
> > I didn't enable it explicitly.
>
> I enable LTO in this commit:
>
> https://source.denx.de/u-boot/u-boot/-/commit/750d7ddf2c514949228d991e6dd4f7982bfb27f6
>
> > > Does 486aef08de ("u-boot-initial-env: rework make target") fix things?
> > >
> >
> > Yes, this fixed it. @Tom Rini please add this to
> > v2023.01 release.
>
> Adding the correct Tom's email.
>
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
Re: [regression] 2023.01 breaks u-boot-initial-env for aarch64
Hello Sean,
Em sex., 6 de jan. de 2023 às 22:59, Sean Anderson
escreveu:
> On 1/6/23 19:44, Otavio Salvador wrote:
> > The very same works just fine with 2022.10 it works. I didn't investigate
> > more yet.
> >
>
> Do you have LTO enabled?
>
I didn't enable it explicitly.
> Does 486aef08de ("u-boot-initial-env: rework make target") fix things?
>
Yes, this fixed it. @Tom Rini please add this to
v2023.01 release.
Thanks for the quick response.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
[regression] 2023.01 breaks u-boot-initial-env for aarch64
Hello, When using v2023.01-rc4-49-g582e3c9fb23 for aarch64 (technically imx8mm-lpddr4-evk) I get following error: | /bin/false) | cat u-boot-nodtb.bin dts/dt.dtb > u-boot-dtb.bin | cp u-boot-dtb.bin u-boot.bin | aarch64-oel-linux-objcopy --dump-section .rodata.default_environment=u-boot-initial-env env/common.o; sed --in-place -e 's/\x00/\x0A/g' u-boot-initial-env; sed --in-place -e '/^\s*$/d' u-boot-initial-env; sort --field-separator== -k1,1 --stable u-boot-initial-env -o u-boot-initial-env | aarch64-oel-linux-objcopy: env/common.o: can't dump section '.rodata.default_environment' - it does not exist: file format not recognized | sed: can't read u-boot-initial-env: No such file or directory The very same works just fine with 2022.10 it works. I didn't investigate more yet. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
Re: [oe-core][PATCH] mesa: update 22.2.3 -> 22.3.0
Em seg., 5 de dez. de 2022 às 02:52, Markus Volk escreveu: > Am So, 4. Dez 2022 um 09:23:49 -0800 schrieb Khem Raj >: > > Not sure if this is related but I think its somewhere in egl headers > provided by mesa. > > > This is related to an update of the egl headers in Mesa, just as you > thought: > https://github.com/meta-qt5/meta-qt5/pull/491 > It looks fine for me. @Martin Jansa could you check the PR above and merge if fine with it? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#174288): https://lists.openembedded.org/g/openembedded-core/message/174288 Mute This Topic: https://lists.openembedded.org/mt/95388063/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] How is 'devtool sdk-install' supposed to work?
Em seg., 10 de out. de 2022 às 07:35, Ross Burton escreveu: > Copying in Paul as he was involved in this code so might have some > thoughts… > > On 9 Oct 2022, at 20:57, Otavio Salvador via lists.openembedded.org > wrote: > > > > Hello all, > > > > Daiane and I are working on the 3rd edition of our Yocto Project book > and now working on the chapter where we'd like to cover the eSDK use > better. We are likely missing something obvious, but it is better to ask if > we can't figure it out. > > > > How is 'devtool sdk-install' supposed to work? > > > > We used the 'devtool sdk-install -s libpng' command, and the build > succeeded, but the package didn't install. The error is: > > > > ERROR: Failed to install libpng - unavailable > > Yeah, I just hit that too. > > I wonder if the hash equiv broke something… > It does; setting it to use OEBasicHash did the trick. > Interestingly, the eSDK tests use that, so either they’re doing something > special, or they’re not actually running. It may be the latter. > Or it doesn't use same schema. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171588): https://lists.openembedded.org/g/openembedded-core/message/171588 Mute This Topic: https://lists.openembedded.org/mt/94223146/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] How is 'devtool sdk-install' supposed to work?
Hello all, Daiane and I are working on the 3rd edition of our Yocto Project book and now working on the chapter where we'd like to cover the eSDK use better. We are likely missing something obvious, but it is better to ask if we can't figure it out. How is 'devtool sdk-install' supposed to work? We used the 'devtool sdk-install -s libpng' command, and the build succeeded, but the package didn't install. The error is: ERROR: Failed to install libpng - unavailable Thanks in advance, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171555): https://lists.openembedded.org/g/openembedded-core/message/171555 Mute This Topic: https://lists.openembedded.org/mt/94223146/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-Core][PATCH 2/2] u-boot: Add savedefconfig task
Em sex., 7 de out. de 2022 às 13:47, Alex Kiernan escreveu: > Add savedefconfig task which U-Boot supports (unfortunately not all > consumers of cml1 support this). > > Signed-off-by: Alex Kiernan > Kernel also does, so might be nice to add it to a specific class and reuse. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171535): https://lists.openembedded.org/g/openembedded-core/message/171535 Mute This Topic: https://lists.openembedded.org/mt/94183781/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v3] rust-hello-world: move to recipes-extended
There is no need to have a single recipe in recipes-example; moving it
to recipes-extended put it with other recipes.
Signed-off-by: Otavio Salvador
---
Changes in v3:
- rework commit log
Changes in v2:
- move from recipes-example to recipes-extended
.../rust-example}/rust-hello-world/0001-enable-LTO.patch | 0
.../rust-example}/rust-hello-world_git.bb | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename meta/{recipes-example/rust-hello-world =>
recipes-extended/rust-example}/rust-hello-world/0001-enable-LTO.patch (100%)
rename meta/{recipes-example/rust-hello-world =>
recipes-extended/rust-example}/rust-hello-world_git.bb (100%)
diff --git
a/meta/recipes-example/rust-hello-world/rust-hello-world/0001-enable-LTO.patch
b/meta/recipes-extended/rust-example/rust-hello-world/0001-enable-LTO.patch
similarity index 100%
rename from
meta/recipes-example/rust-hello-world/rust-hello-world/0001-enable-LTO.patch
rename to
meta/recipes-extended/rust-example/rust-hello-world/0001-enable-LTO.patch
diff --git a/meta/recipes-example/rust-hello-world/rust-hello-world_git.bb
b/meta/recipes-extended/rust-example/rust-hello-world_git.bb
similarity index 100%
rename from meta/recipes-example/rust-hello-world/rust-hello-world_git.bb
rename to meta/recipes-extended/rust-example/rust-hello-world_git.bb
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170513):
https://lists.openembedded.org/g/openembedded-core/message/170513
Mute This Topic: https://lists.openembedded.org/mt/93600921/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] rust-hello-world: move to recipes-extended
Em sex., 9 de set. de 2022 às 13:49, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > On Fri, 2022-09-09 at 13:14 -0300, Otavio Salvador wrote: > > Em sex., 9 de set. de 2022 às 12:16, Richard Purdie > > escreveu: > > > On Fri, 2022-09-09 at 12:12 -0300, Otavio Salvador wrote: > > > > There is no need to have a single recipe in recipes-example; > > > > moving it > > > > to recipes-extended allow it being use inside QA tests. > > > > > > I'm a bit puzzled why it doesn't work from it's current location? > > > > > > > > > It does but recipes-example only has this recipe. > > > That makes the commit message a bit misleading then as it doesn't fix > any QA test. > I'll send a v3. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#170501): https://lists.openembedded.org/g/openembedded-core/message/170501 Mute This Topic: https://lists.openembedded.org/mt/93574973/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] rust-hello-world: move to recipes-extended
Em sex., 9 de set. de 2022 às 12:16, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > On Fri, 2022-09-09 at 12:12 -0300, Otavio Salvador wrote: > > There is no need to have a single recipe in recipes-example; moving it > > to recipes-extended allow it being use inside QA tests. > > I'm a bit puzzled why it doesn't work from it's current location? > It does but recipes-example only has this recipe. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#170494): https://lists.openembedded.org/g/openembedded-core/message/170494 Mute This Topic: https://lists.openembedded.org/mt/93574973/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2] rust-hello-world: move to recipes-extended
There is no need to have a single recipe in recipes-example; moving it
to recipes-extended allow it being use inside QA tests.
Signed-off-by: Otavio Salvador
---
Changes in v2:
- move from recipes-example to recipes-extended
.../rust-example}/rust-hello-world/0001-enable-LTO.patch | 0
.../rust-example}/rust-hello-world_git.bb | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename meta/{recipes-example/rust-hello-world =>
recipes-extended/rust-example}/rust-hello-world/0001-enable-LTO.patch (100%)
rename meta/{recipes-example/rust-hello-world =>
recipes-extended/rust-example}/rust-hello-world_git.bb (100%)
diff --git
a/meta/recipes-example/rust-hello-world/rust-hello-world/0001-enable-LTO.patch
b/meta/recipes-extended/rust-example/rust-hello-world/0001-enable-LTO.patch
similarity index 100%
rename from
meta/recipes-example/rust-hello-world/rust-hello-world/0001-enable-LTO.patch
rename to
meta/recipes-extended/rust-example/rust-hello-world/0001-enable-LTO.patch
diff --git a/meta/recipes-example/rust-hello-world/rust-hello-world_git.bb
b/meta/recipes-extended/rust-example/rust-hello-world_git.bb
similarity index 100%
rename from meta/recipes-example/rust-hello-world/rust-hello-world_git.bb
rename to meta/recipes-extended/rust-example/rust-hello-world_git.bb
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170491):
https://lists.openembedded.org/g/openembedded-core/message/170491
Mute This Topic: https://lists.openembedded.org/mt/93574973/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] rust: Use variable to specify extra tools to install
Em qui., 8 de set. de 2022 às 12:13, Khem Raj escreveu:
> All architectures may not support same set of tools, therefore use a
> variable to specify this. E.g. on riscv32 only cargo-clippy is buildable
> right now.
>
> Signed-off-by: Khem Raj
> ---
> meta/recipes-devtools/rust/rust_1.63.0.bb | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/rust/rust_1.63.0.bb
> b/meta/recipes-devtools/rust/rust_1.63.0.bb
> index cf6468d212..2f70b33c29 100644
> --- a/meta/recipes-devtools/rust/rust_1.63.0.bb
> +++ b/meta/recipes-devtools/rust/rust_1.63.0.bb
> @@ -62,13 +62,15 @@ rust_do_install:class-nativesdk() {
> rm ${D}${libdir}/rustlib/manifest*
> }
>
> +EXTRA_TOOLS ?= "cargo-clippy clippy-driver rustfmt"
> +EXTRA_TOOLS:remove:riscv32 = "cargo-driver rustfmt"
>
clippy driver is spelled wrong.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170464):
https://lists.openembedded.org/g/openembedded-core/message/170464
Mute This Topic: https://lists.openembedded.org/mt/93550831/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] rust-hello-world: move to meta-skeleton
Signed-off-by: Otavio Salvador
---
.../hello-rust}/rust-hello-world/0001-enable-LTO.patch| 0
.../recipes-skeleton/hello-rust}/rust-hello-world_git.bb | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename {meta/recipes-example/rust-hello-world =>
meta-skeleton/recipes-skeleton/hello-rust}/rust-hello-world/0001-enable-LTO.patch
(100%)
rename {meta/recipes-example/rust-hello-world =>
meta-skeleton/recipes-skeleton/hello-rust}/rust-hello-world_git.bb (100%)
diff --git
a/meta/recipes-example/rust-hello-world/rust-hello-world/0001-enable-LTO.patch
b/meta-skeleton/recipes-skeleton/hello-rust/rust-hello-world/0001-enable-LTO.patch
similarity index 100%
rename from
meta/recipes-example/rust-hello-world/rust-hello-world/0001-enable-LTO.patch
rename to
meta-skeleton/recipes-skeleton/hello-rust/rust-hello-world/0001-enable-LTO.patch
diff --git a/meta/recipes-example/rust-hello-world/rust-hello-world_git.bb
b/meta-skeleton/recipes-skeleton/hello-rust/rust-hello-world_git.bb
similarity index 100%
rename from meta/recipes-example/rust-hello-world/rust-hello-world_git.bb
rename to meta-skeleton/recipes-skeleton/hello-rust/rust-hello-world_git.bb
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170463):
https://lists.openembedded.org/g/openembedded-core/message/170463
Mute This Topic: https://lists.openembedded.org/mt/93553025/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] rust-cross-canadian: rename shell variables for easier appends
Em ter., 23 de ago. de 2022 às 17:38, Peter Bergin escreveu: > In my particular case the rust application I'm building against the SDK is > using the crate prost-build (https://crates.io/crates/prost-build) that > is used to generate code from .proto files. It is using the tool protoc > from protobuf and in order to get it working the variable PROTOC needs to > be set. Then my solution was to add that variable to > environment-setup.d/rust.sh in the SDK as I thought that was an easy > solution and rust.sh is in some way connected to the variable setting. Then > looking in to do_install of rust-cross-canadian I saw that the variable > ENV_SETUP_SH is first used for rust.sh then for cargo.sh so I could not use > it to point out rust.sh. Then I had the idea that it would be better to > have one variable for rust.sh and one for cargo.sh. > The protoc could have this set in environment-setup.d so it doesn't need change in rust and avoids rebuilds. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169729): https://lists.openembedded.org/g/openembedded-core/message/169729 Mute This Topic: https://lists.openembedded.org/mt/93201518/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] rust-cross-canadian: rename shell variables for easier appends
Em ter., 23 de ago. de 2022 às 08:02, Peter Bergin escreveu: > Make unique shell variable names for cargo and rust > setup scripts. This change will make it easier to append to the > scripts in a bbappend file by using the variable for the script. > Before this change it was only possible for the last script as > they shared the same variable name. > > Signed-off-by: Peter Bergin > Why do you want to append them? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169705): https://lists.openembedded.org/g/openembedded-core/message/169705 Mute This Topic: https://lists.openembedded.org/mt/93201518/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] packagegroup-rust-cross-canadian: add native compiler environment
Em ter., 23 de ago. de 2022 às 05:57, Peter Bergin escreveu: > When building rust crates it is quite common to have a build script [1] > that is compiled for the host machine and then used during build for > target. > Currently when adding packagegroup-rust-cross-canadian this does not work > without having the native compiler and linker added to the SDK. > Add those packages to the packagegroup to make it easier to handle. > > The reason for having glibc-dev and libgcc-dev is to have version match > with the used tools. Otherwise it will work on hosts that have compatible > gcc and glibc versions but not on all. > This should be in a comment inside the packagegroup. > [1] https://doc.rust-lang.org/cargo/reference/build-scripts.html > > Signed-off-by: Peter Bergin > -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169704): https://lists.openembedded.org/g/openembedded-core/message/169704 Mute This Topic: https://lists.openembedded.org/mt/93200331/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] module.bbclass: rebuild the modules when kernel change
Em qui., 11 de ago. de 2022 às 14:06, Bruce Ashfield < bruce.ashfi...@gmail.com> escreveu: > On Thu, Aug 11, 2022 at 12:18 PM Jose Quaresma > wrote: > > > > When the kernel is rebuild or some of they tasks change the > > kernel modules is not rebuild as well and will comes from > > the sstate-cache. > > > > [YOCTO #14885] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14885 > > > > Signed-off-by: Jose Quaresma > > --- > > meta/classes/module.bbclass | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass > > index a09ec3ed1e..d377a08bc6 100644 > > --- a/meta/classes/module.bbclass > > +++ b/meta/classes/module.bbclass > > @@ -1,5 +1,7 @@ > > inherit module-base kernel-module-split pkgconfig > > > > +DEPENDS += "virtual/kernel" > > There's already a dependency on virtual/kernel:do_shared_workdir() through > module-base.bbclass and the make-mod-scripts dependency. > > And that dependency was a change to this: > > -# This is instead of DEPENDS = "virtual/kernel" > -do_configure[depends] += "virtual/kernel:do_compile_kernelmodules" > > i.e. we've always had a finer grained dependency than what is being > proposed here. > > We need to understand why that shared_workdir() dependency isn't > doing the job any more, and if there's no way to fix it .. then going back > to the older compile dependency is still lighter weight than depending > on virtual/kernel (and the default of do_prepare_recipe_sysroot). > > It must (could?) be something with the shared workdir changing the > interactions. > Good catch; this really seems strange. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169261): https://lists.openembedded.org/g/openembedded-core/message/169261 Mute This Topic: https://lists.openembedded.org/mt/92962048/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] module.bbclass: rebuild the modules when kernel change
Em qui., 11 de ago. de 2022 às 13:18, Jose Quaresma escreveu: > When the kernel is rebuild or some of they tasks change the > kernel modules is not rebuild as well and will comes from > the sstate-cache. > > [YOCTO #14885] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14885 > > Signed-off-by: Jose Quaresma > Issue: https://github.com/Freescale/meta-freescale/pull/1168 Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169255): https://lists.openembedded.org/g/openembedded-core/message/169255 Mute This Topic: https://lists.openembedded.org/mt/92962048/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?
Em seg., 1 de ago. de 2022 às 19:41, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > I do feel that whilst well intentioned, there are too many ways it can > go wrong in ways that will cause bad feelings towards the project. > What about security flaws that aren't fixed and could lead to a compromised device and people not knowing they were using an EOL release? That will cause bad feelings towards the project as well. I see a warning isn't perfect but is a better option than users not knowing it is EOL. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1611): https://lists.openembedded.org/g/openembedded-architecture/message/1611 Mute This Topic: https://lists.openembedded.org/mt/92611044/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?
Em seg., 1 de ago. de 2022 às 14:30, Alexander Kanavin <
alex.kana...@gmail.com> escreveu:
> On Mon, 1 Aug 2022 at 13:22, Ross Burton wrote:
> > Would this be something done in oe-core, or something that distros (such
> as Poky) can opt in to? We don’t want to start warning when oe-core is EOL
> if the user is using a commercial Yocto release which still has support for
> many years.
> >
> > Would this be done with a variable (be it a EOL date, or a marker) in
> the git repository itself, or something that if fetched periodically? A
> variable in the git repository would need to be kept up to date, and
> there’s potentially a significant delay between a change landing in oe-core
> and reaching a user (oe-core release -> OSV release -> BSP release) which
> could result in inappropriate warnings. The same information being online
> and fetched on builds would solve that problem but instead add phone-home
> issues and the usual network complications (caching, no-network use cases,
> etc).
> >
> > Whilst we can see that there are definite value propositions in alerting
> users that a release is approaching EOL, there are considerable
> complications to be thought though.
>
> I think this could work the following way:
>
> - EOL date defined in a variable in meta/conf/distro/end-of-life.inc,
> for stable branches only, and with ?=, so it can be easily overriden
> by commercial distros or users who know what they are doing.
> - if the EOL date is less than (say) 1 month away, bitbake prints a
> note. If the EOL date is in the past, it becomes a warning.
> - the note or the warning uses guarded language ('may', 'possibly',
> etc.) and points to the Releases wiki page and LTS policy pages
>
> Any particular problems with this approach?
>
I don't see problems with this and whoever wishes to support it, can easily
override it.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1609):
https://lists.openembedded.org/g/openembedded-architecture/message/1609
Mute This Topic: https://lists.openembedded.org/mt/92611044/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] uboot-config.bbclass: Raise error for bad key
Em qui., 28 de jul. de 2022 às 15:44, Tom Hochstein escreveu: > If an invalid key is used, the class ignores the error, with an > indeterminate result. In my case, the problem surfaced in do_deploy: > > ``` > | cp: cannot stat > '/.../build/tmp/work/imx6qdlsabresd-fsl-linux-gnueabi/u-boot-imx-mfgtool/2022.04-r0/deploy-u-boot-imx-mfgtool/u-boot.imx': > No such file or > | directory > ``` > > The root cause of this was that the uboot config key did not match > a valid option. With the fix, the error is caught by the class: > > ``` > ERROR: Nothing PROVIDES 'u-boot-imx-mfgtool' > u-boot-imx-mfgtool was skipped: The selected UBOOT_CONFIG key ['mfgtool'] > has no match in dict_keys(['sd-fslc', 'sd-imx', 'sd-optee-imx', 'sata-imx', > 'mfgtool-imx']). > ``` > > Signed-off-by: Tom Hochstein > Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168616): https://lists.openembedded.org/g/openembedded-core/message/168616 Mute This Topic: https://lists.openembedded.org/mt/92676883/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 2/3] oeqa/sdk: Add basic rust cargo test
Em qua., 27 de jul. de 2022 às 13:48, Luca Ceresoli via lists.openembedded.org escreveu: > On Tue, 26 Jul 2022 15:24:12 +0100 > "Richard Purdie" wrote: > > > From: Otavio Salvador > > > > Add a QA test to the SDK to test that a basic cargo build works. > > > > [RP: Tweaked to work for multilibs and updated to match toolchain > changes] > > > > Signed-off-by: Otavio Salvador > > Signed-off-by: Richard Purdie > > We have a build failure with this series applied: > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5615/steps/26/logs/stdio > > Attached is the do_testsdk log. > It seems the SDK test directory is being reused, so it failed as file already exists. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168583): https://lists.openembedded.org/g/openembedded-core/message/168583 Mute This Topic: https://lists.openembedded.org/mt/92628459/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins
Sent :-) Em qua., 27 de jul. de 2022 às 13:45, Khem Raj escreveu: > > > On 7/27/22 12:41 PM, Otavio Salvador wrote: > > > > > > Em qua., 27 de jul. de 2022 às 13:35, Ross Burton > <mailto:ross.bur...@arm.com>> escreveu: > > > > Whoever adds the patch needs to add their S-o-b. > > > > > > The patch sanity check should warn about it as it does for the status > > header. I said, RP can add it. > > RP can do, but he can only do so much :) lets try to help him. > Its not something that can be added during applying patch which could be > done, this needs to change the libusb1 patch and then final patch > regenerated, its better if it can be done by you and resend a v2. > > > -- > > Otavio Salvador O.S. Systems > > http://www.ossystems.com.br <http://www.ossystems.com.br> > > http://code.ossystems.com.br <http://code.ossystems.com.br> > > Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 > > > > > > > > > > > > -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168580): https://lists.openembedded.org/g/openembedded-core/message/168580 Mute This Topic: https://lists.openembedded.org/mt/92647443/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2] libusb1: Link with -latomic only if no atomic builtins
Backport a fix from 1.0.27 so we only link atomic if no atomic builtins
are available.
Signed-off-by: Otavio Salvador
---
Changes in v2:
- add signed-off-by
...k-with-latomic-only-if-no-atomic-bui.patch | 53 +++
meta/recipes-support/libusb/libusb1_1.0.26.bb | 1 +
2 files changed, 54 insertions(+)
create mode 100644
meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
diff --git
a/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
b/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
new file mode 100644
index 00..5c49cbb8a7
--- /dev/null
+++
b/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
@@ -0,0 +1,53 @@
+From a6890a6a9a8f88b567631874e209aaadc79e28e5 Mon Sep 17 00:00:00 2001
+From: Lonnie Abelbeck
+Date: Sun, 8 May 2022 14:05:56 -0500
+Subject: [PATCH] configure.ac: Link with -latomic only if no atomic builtins
+
+Follow-up to 561dbda, a check of GCC atomic builtins needs to be done
+first.
+
+I'm no autoconf guru, but using this:
+https://github.com/mesa3d/mesa/blob/0df485c285b73c34ba9062f0c27e55c3c702930d/configure.ac#L469
+as inspiration, I created a pre-check before calling AC_SEARCH_LIBS(...)
+
+Upstream-Status: Backport [1.0.27]
+
+Fixes #1135
+Closes #1139
+(cherry picked from commit 95e601ce116dd46ea7915c171976b85ea0905d58)
+
+Signed-off-by: Otavio Salvador
+---
+ configure.ac | 16 +++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index d4f12510..96787500 100644
+--- a/configure.ac
b/configure.ac
+@@ -153,7 +153,21 @@ if test "x$platform" = xposix; then
+ AC_SEARCH_LIBS([pthread_create], [pthread],
+ [test "x$ac_cv_search_pthread_create" != "xnone required" &&
AC_SUBST(THREAD_LIBS, [-lpthread])],
+ [], [])
+- AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
++ dnl Check for new-style atomic builtins. We first check without linking
to -latomic.
++ AC_MSG_CHECKING(whether __atomic_load_n is supported)
++ AC_LINK_IFELSE([AC_LANG_SOURCE([[
++ #include
++ int main() {
++ struct {
++ uint64_t *v;
++ } x;
++ return (int)__atomic_load_n(x.v, __ATOMIC_ACQUIRE) &
++ (int)__atomic_add_fetch(x.v, (uint64_t)1,
__ATOMIC_ACQ_REL);
++ }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=yes,
GCC_ATOMIC_BUILTINS_SUPPORTED=no)
++ AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_SUPPORTED)
++ if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" != xyes; then
++ AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
++ fi
+ elif test "x$platform" = xwindows; then
+ AC_DEFINE([PLATFORM_WINDOWS], [1], [Define to 1 if compiling for a
Windows platform.])
+ else
+--
+2.37.0
+
diff --git a/meta/recipes-support/libusb/libusb1_1.0.26.bb
b/meta/recipes-support/libusb/libusb1_1.0.26.bb
index fd63e7adc2..ff3f0be7a5 100644
--- a/meta/recipes-support/libusb/libusb1_1.0.26.bb
+++ b/meta/recipes-support/libusb/libusb1_1.0.26.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=fbc093901857fcd118f065f900982c24"
BBCLASSEXTEND = "native nativesdk"
SRC_URI =
"https://github.com/libusb/libusb/releases/download/v${PV}/libusb-${PV}.tar.bz2
\
+
file://0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch \
file://run-ptest \
"
--
2.37.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168579):
https://lists.openembedded.org/g/openembedded-core/message/168579
Mute This Topic: https://lists.openembedded.org/mt/92653354/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins
Em qua., 27 de jul. de 2022 às 13:35, Ross Burton escreveu: > Whoever adds the patch needs to add their S-o-b. > The patch sanity check should warn about it as it does for the status header. I said, RP can add it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168576): https://lists.openembedded.org/g/openembedded-core/message/168576 Mute This Topic: https://lists.openembedded.org/mt/92647443/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins
Em qua., 27 de jul. de 2022 às 12:28, Ross Burton escreveu: > The patch is missing your S-o-b. > The patch isn't mine but a backport. Richard can add it when adding it to MUT, though. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168573): https://lists.openembedded.org/g/openembedded-core/message/168573 Mute This Topic: https://lists.openembedded.org/mt/92647443/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins
Backport a fix from 1.0.27 so we only link atomic if no atomic builtins
are available.
Signed-off-by: Otavio Salvador
---
...k-with-latomic-only-if-no-atomic-bui.patch | 51 +++
meta/recipes-support/libusb/libusb1_1.0.26.bb | 1 +
2 files changed, 52 insertions(+)
create mode 100644
meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
diff --git
a/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
b/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
new file mode 100644
index 00..7c20dc0478
--- /dev/null
+++
b/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
@@ -0,0 +1,51 @@
+From a6890a6a9a8f88b567631874e209aaadc79e28e5 Mon Sep 17 00:00:00 2001
+From: Lonnie Abelbeck
+Date: Sun, 8 May 2022 14:05:56 -0500
+Subject: [PATCH] configure.ac: Link with -latomic only if no atomic builtins
+
+Follow-up to 561dbda, a check of GCC atomic builtins needs to be done
+first.
+
+I'm no autoconf guru, but using this:
+https://github.com/mesa3d/mesa/blob/0df485c285b73c34ba9062f0c27e55c3c702930d/configure.ac#L469
+as inspiration, I created a pre-check before calling AC_SEARCH_LIBS(...)
+
+Upstream-Status: Backport [1.0.27]
+
+Fixes #1135
+Closes #1139
+(cherry picked from commit 95e601ce116dd46ea7915c171976b85ea0905d58)
+---
+ configure.ac | 16 +++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index d4f12510..96787500 100644
+--- a/configure.ac
b/configure.ac
+@@ -153,7 +153,21 @@ if test "x$platform" = xposix; then
+ AC_SEARCH_LIBS([pthread_create], [pthread],
+ [test "x$ac_cv_search_pthread_create" != "xnone required" &&
AC_SUBST(THREAD_LIBS, [-lpthread])],
+ [], [])
+- AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
++ dnl Check for new-style atomic builtins. We first check without linking
to -latomic.
++ AC_MSG_CHECKING(whether __atomic_load_n is supported)
++ AC_LINK_IFELSE([AC_LANG_SOURCE([[
++ #include
++ int main() {
++ struct {
++ uint64_t *v;
++ } x;
++ return (int)__atomic_load_n(x.v, __ATOMIC_ACQUIRE) &
++ (int)__atomic_add_fetch(x.v, (uint64_t)1,
__ATOMIC_ACQ_REL);
++ }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=yes,
GCC_ATOMIC_BUILTINS_SUPPORTED=no)
++ AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_SUPPORTED)
++ if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" != xyes; then
++ AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
++ fi
+ elif test "x$platform" = xwindows; then
+ AC_DEFINE([PLATFORM_WINDOWS], [1], [Define to 1 if compiling for a
Windows platform.])
+ else
+--
+2.37.0
+
diff --git a/meta/recipes-support/libusb/libusb1_1.0.26.bb
b/meta/recipes-support/libusb/libusb1_1.0.26.bb
index fd63e7adc2..ff3f0be7a5 100644
--- a/meta/recipes-support/libusb/libusb1_1.0.26.bb
+++ b/meta/recipes-support/libusb/libusb1_1.0.26.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=fbc093901857fcd118f065f900982c24"
BBCLASSEXTEND = "native nativesdk"
SRC_URI =
"https://github.com/libusb/libusb/releases/download/v${PV}/libusb-${PV}.tar.bz2
\
+
file://0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch \
file://run-ptest \
"
--
2.37.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168559):
https://lists.openembedded.org/g/openembedded-core/message/168559
Mute This Topic: https://lists.openembedded.org/mt/92647443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?
Em seg., 25 de jul. de 2022 às 15:13, Alexander Kanavin < alex.kana...@gmail.com> escreveu: > an idea just popped into my head that I don't remember having been > discussed: > > Should stable-branch oe-core issue a warning via bitbake when it is > close to EOL and perhaps a stronger warning when it has crossed it? > > I feel that this page: > https://wiki.yoctoproject.org/wiki/Releases > is not enough to ensure the message (of not using EOL yocto) reaches > the users, and we need something better and directly seen by anyone > invoking bitbake. > > Is it a terrible idea? Awesome idea? Ok-ish idea? > I like the idea so users are aware of it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1594): https://lists.openembedded.org/g/openembedded-architecture/message/1594 Mute This Topic: https://lists.openembedded.org/mt/92611044/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
Hello Richard,
Em qua., 20 de jul. de 2022 às 15:11, Otavio Salvador <
ota...@ossystems.com.br> escreveu:
> Em qua., 20 de jul. de 2022 às 14:21, Richard Purdie <
> richard.pur...@linuxfoundation.org> escreveu:
>
>> I've done a bit more work on this and the more I dig, the more I think
>> we have some issues we need to sort with taking a step back and
>> checking some assumptions.
>>
>> What I'm lacking is a good way to test the resulting rust toolchain.
>> Would someone with some rust knowledge be able to add something to
>> meta/lib/oeqa/sdk/cases/ which tested rust in the SDK?
>>
>> If someone can add some rust tests in the SDK, I think I might have an
>> idea of what the patches look like to properly fix the rust toolchain
>> there.
>>
>
> Ok, I will send you a test case shortly.
>
As promised. See attached.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
From d62112db3e4bc9ec9e3c7ca480ebf2f3a207e4a6 Mon Sep 17 00:00:00 2001
From: Otavio Salvador
Date: Wed, 20 Jul 2022 16:06:01 -0300
Subject: [PATCH] oeqa: sdk: rust: add basic cargo test
Signed-off-by: Otavio Salvador
---
meta/lib/oeqa/sdk/cases/rust.py | 31 +++
meta/lib/oeqa/sdk/files/rust/hello/Cargo.toml | 6
.../lib/oeqa/sdk/files/rust/hello/src/main.rs | 3 ++
3 files changed, 40 insertions(+)
create mode 100644 meta/lib/oeqa/sdk/cases/rust.py
create mode 100644 meta/lib/oeqa/sdk/files/rust/hello/Cargo.toml
create mode 100644 meta/lib/oeqa/sdk/files/rust/hello/src/main.rs
diff --git a/meta/lib/oeqa/sdk/cases/rust.py b/meta/lib/oeqa/sdk/cases/rust.py
new file mode 100644
index 00..c29b06223b
--- /dev/null
+++ b/meta/lib/oeqa/sdk/cases/rust.py
@@ -0,0 +1,31 @@
+#
+# SPDX-License-Identifier: MIT
+#
+
+import os
+import shutil
+import unittest
+
+from oeqa.core.utils.path import remove_safe
+from oeqa.sdk.case import OESDKTestCase
+
+from oeqa.utils.subprocesstweak import errors_have_output
+errors_have_output()
+
+class RustCompileTest(OESDKTestCase):
+td_vars = ['MACHINE']
+
+@classmethod
+def setUpClass(self):
+shutil.copytree(os.path.join(self.tc.sdk_files_dir, "rust/hello"),
+os.path.join(self.tc.sdk_dir, "hello"))
+
+def setUp(self):
+machine = self.td.get("MACHINE")
+if not (self.tc.hasHostPackage("packagegroup-rust-cross-canadian-%s" % machine) or
+self.tc.hasHostPackage("^rust-cross-canadian-", regex=True) or
+self.tc.hasHostPackage("^cargo-cross-canadian-", regex=True)):
+raise unittest.SkipTest("RustCompileTest class: SDK doesn't contain a Rust cross-canadian toolchain")
+
+def test_cargo_build(self):
+self._run('cd %s/hello; cargo build' % self.tc.sdk_dir)
diff --git a/meta/lib/oeqa/sdk/files/rust/hello/Cargo.toml b/meta/lib/oeqa/sdk/files/rust/hello/Cargo.toml
new file mode 100644
index 00..fe619478a6
--- /dev/null
+++ b/meta/lib/oeqa/sdk/files/rust/hello/Cargo.toml
@@ -0,0 +1,6 @@
+[package]
+name = "hello"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
diff --git a/meta/lib/oeqa/sdk/files/rust/hello/src/main.rs b/meta/lib/oeqa/sdk/files/rust/hello/src/main.rs
new file mode 100644
index 00..a06c03f82a
--- /dev/null
+++ b/meta/lib/oeqa/sdk/files/rust/hello/src/main.rs
@@ -0,0 +1,3 @@
+fn main() {
+println!("Hello, OpenEmbedded world!");
+}
--
2.36.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168373):
https://lists.openembedded.org/g/openembedded-core/message/168373
Mute This Topic: https://lists.openembedded.org/mt/92292892/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
Em qua., 20 de jul. de 2022 às 14:21, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > I've done a bit more work on this and the more I dig, the more I think > we have some issues we need to sort with taking a step back and > checking some assumptions. > > What I'm lacking is a good way to test the resulting rust toolchain. > Would someone with some rust knowledge be able to add something to > meta/lib/oeqa/sdk/cases/ which tested rust in the SDK? > > If someone can add some rust tests in the SDK, I think I might have an > idea of what the patches look like to properly fix the rust toolchain > there. > Ok, I will send you a test case shortly. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168371): https://lists.openembedded.org/g/openembedded-core/message/168371 Mute This Topic: https://lists.openembedded.org/mt/92292892/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
Em seg., 18 de jul. de 2022 às 19:54, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > On Mon, 2022-07-18 at 18:41 -0300, Otavio Salvador wrote: > > Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie > > escreveu: > > > > It does, indeed, but it doesn't seem related to this PR. > > > > > > > > Do you know if this has worked? > > > > > > > > I am asking as I did all development and testing using SDKMACHINE > > > > ?= > > > > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. > > > > However, > > > > looking at some of the logs above, it seems it is using an > > > > SDKMACHINE > > > > as i686, so this appears as a different issue for me. > > > > > > > > > > rust-cross-canadian hasn't officially worked properly or been > > > supported. In assessing whether a patch is better or worse, it is > > > useful to know which cases regress and which improve. I had hoped > > > this > > > list of failures would be smaller. I will admit I don't know > > > whether > > > this is better or worse than before so I guess that is the next > > > thing I > > > need to determine. > > > > > > > > > I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and this > > worked. > > > > > What we don't know right now is which combinations work and which > > > don't > > > so we can't even tell people what is expected to work and what > > > isn't/doesn't :( > > > > > > > > > See above. > > > > > I mentioned this report in case someone can work out the pattern, > > > or > > > even better, understand what a fix looks like... > > > > > > > > > I am not familiar enough to Rust boostrap to help here but we spent a > > lot of time to get the SDK working and I think this is a step on the > > right direction, at least. > > Thanks, I do appreciate the patches. I think we've talked cross > purposes as I did report my aarch64 test case issue previously and I > thought this series was to attempt to fix things so the recipe did work > generically. > I had it fixed to SDKMACHINE as x86_64 on a x86_64. I didn't realise it was using a different SDKMACHINE. If I merge this to fix x86_64, I think people will then just ignore the > other cases and things will remain broken there which worries me a lot > and means we can't generically enable rust SDKs for the project and > gain autobuilder testing to spot future regressions. > I understand. > Obviously you want your use case fixed though. I will try and evaluate > things a bit more tomorrow. What I don't want to do is merge a fix > which then makes it harder to get things correctly done in future > though, particularly when I know there will be an instant backport > request to an LTS as soon as I accept it for master. > In fact I need patch 1/2 as this fixes our use case. We worked on 2/2 (this patch) for completeness. > We never should have accepted these rust cross-canadian recipes at all > as they are just broken :(. > Agreed. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168265): https://lists.openembedded.org/g/openembedded-core/message/168265 Mute This Topic: https://lists.openembedded.org/mt/92292892/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > > It does, indeed, but it doesn't seem related to this PR. > > > > Do you know if this has worked? > > > > I am asking as I did all development and testing using SDKMACHINE ?= > > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. However, > > looking at some of the logs above, it seems it is using an SDKMACHINE > > as i686, so this appears as a different issue for me. > > > > rust-cross-canadian hasn't officially worked properly or been > supported. In assessing whether a patch is better or worse, it is > useful to know which cases regress and which improve. I had hoped this > list of failures would be smaller. I will admit I don't know whether > this is better or worse than before so I guess that is the next thing I > need to determine. > I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and this worked. What we don't know right now is which combinations work and which don't > so we can't even tell people what is expected to work and what > isn't/doesn't :( > See above. > I mentioned this report in case someone can work out the pattern, or > even better, understand what a fix looks like... > I am not familiar enough to Rust boostrap to help here but we spent a lot of time to get the SDK working and I think this is a step on the right direction, at least. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168259): https://lists.openembedded.org/g/openembedded-core/message/168259 Mute This Topic: https://lists.openembedded.org/mt/92292892/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
Hello Richard and Khem
Em seg., 18 de jul. de 2022 às 12:59, Richard Purdie <
richard.pur...@linuxfoundation.org> escreveu:
> On Mon, 2022-07-18 at 12:49 -0300, Otavio Salvador wrote:
> > Em seg., 18 de jul. de 2022 às 09:45, Richard Purdie
> > escreveu:
> > > On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote:
> > > > Signed-off-by: Otavio Salvador
> > > SDKAMCHINE = "aarch64"
> > > MACHINE = "qemuarm64"
> > >
> > > bitbake rust-cross-canadian-aarch64
> > >
> > > still fails so there is still something wrong with the SDK builds
> > > :/
> > >
> >
> >
> > I'll check this. I didn't check this combination.
>
> I tried an experiment to see which combinations worked. To do that I
> added:
>
> TOOLCHAIN_HOST_TASK:append = ' packagegroup-rust-cross-canadian-${MACHINE}'
>
> to the autobuilder config. This resulted in:
>
> qemux86:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/5491
>
> buildtools:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5885
>
> beaglebone:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5563
>
> edgerouter:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/5533
>
> genericx86:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5548
>
> genericx86-64:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5533
>
> multilib:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5554
>
> pkgman-deb-non-deb:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/5554
>
> qemumips:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/5498
>
> qemux86-64:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/5487
>
> qemuarm64:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/5510
>
> qemuarm:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/5525
>
> so there is something rather wrong :(
>
It does, indeed, but it doesn't seem related to this PR.
Do you know if this has worked?
I am asking as I did all development and testing using SDKMACHINE ?=
'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. However, looking
at some of the logs above, it seems it is using an SDKMACHINE as i686, so
this appears as a different issue for me.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168253):
https://lists.openembedded.org/g/openembedded-core/message/168253
Mute This Topic: https://lists.openembedded.org/mt/92292892/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
Em seg., 18 de jul. de 2022 às 09:45, Richard Purdie < richard.pur...@linuxfoundation.org> escreveu: > On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote: > > Signed-off-by: Otavio Salvador > > --- > > > > (no changes since v1) > > > > .../cargo/cargo-cross-canadian.inc| 20 ++- > > 1 file changed, 19 insertions(+), 1 deletion(-) > > I did look into this with some local testing. With: > > SDKAMCHINE = "aarch64" > MACHINE = "qemuarm64" > > bitbake rust-cross-canadian-aarch64 > > still fails so there is still something wrong with the SDK builds :/ > I'll check this. I didn't check this combination. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168238): https://lists.openembedded.org/g/openembedded-core/message/168238 Mute This Topic: https://lists.openembedded.org/mt/92292892/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation
Hello Alejandro, Em qua., 13 de jul. de 2022 às 21:08, Alejandro Hernandez Samaniego < a...@linux.microsoft.com> escreveu: > These look okay to me, could we backport these to Kirkstone? > This is my goal as well; kirkstone is broken for me at this moment. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#168031): https://lists.openembedded.org/g/openembedded-core/message/168031 Mute This Topic: https://lists.openembedded.org/mt/92292890/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] rng-tools: Only install one set of init scripts
Em sáb., 9 de jul. de 2022 às 17:26, An?bal Lim?n escreveu: > From: Aníbal Limón > > Check if systemd is enabled to install .service file only instead of > service and sysvinit files because it will to rngd service twice by > systemd compatibility. > > One called rng-tools.service (sysv compat) and another rngd.service. > I think renaming the init script to use the same name as the .service file should fix it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167850): https://lists.openembedded.org/g/openembedded-core/message/167850 Mute This Topic: https://lists.openembedded.org/mt/92278770/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 2/2] cargo-cross-canadian: Use SDK's flags during target linking
Signed-off-by: Otavio Salvador
---
(no changes since v1)
.../cargo/cargo-cross-canadian.inc| 20 ++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
b/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
index 7fc22a4128..01ba151d0a 100644
--- a/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
+++ b/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
@@ -39,6 +39,18 @@ do_compile:prepend () {
PKG_CONFIG_PATH="${RECIPE_SYSROOT_NATIVE}/usr/lib/pkgconfig:${PKG_CONFIG_PATH}"
}
+create_sdk_wrapper () {
+file="$1"
+shift
+
+cat <<- EOF > "${file}"
+ #!/bin/sh
+ \$$1 \$@
+ EOF
+
+chmod +x "$file"
+}
+
do_install () {
SYS_BINDIR=$(dirname ${D}${bindir})
install -d "${SYS_BINDIR}"
@@ -47,6 +59,9 @@ do_install () {
chrpath -r "\$ORIGIN/../lib" ${i}
done
+# Uses SDK's CC as linker so linked binaries works out of box.
+create_sdk_wrapper "${SYS_BINDIR}/target-rust-ccld" "CC"
+
ENV_SETUP_DIR=${D}${base_prefix}/environment-setup.d
mkdir "${ENV_SETUP_DIR}"
ENV_SETUP_SH="${ENV_SETUP_DIR}/cargo.sh"
@@ -58,7 +73,10 @@ do_install () {
touch "\$CARGO_HOME/config"
echo "[build]" >> "\$CARGO_HOME/config"
echo 'target = "'${TARGET_SYS}'"' >> "\$CARGO_HOME/config"
-fi
+ echo '# TARGET_SYS' >> "\$CARGO_HOME/config"
+ echo '[target.'${TARGET_SYS}']' >> "\$CARGO_HOME/config"
+ echo 'linker = "target-rust-ccld"' >> "\$CARGO_HOME/config"
+fi
# Keep the below off as long as HTTP/2 is disabled.
export CARGO_HTTP_MULTIPLEXING=false
--
2.36.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167849):
https://lists.openembedded.org/g/openembedded-core/message/167849
Mute This Topic: https://lists.openembedded.org/mt/92292892/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 1/2] rust-common: Fix use of target definitions for SDK generation
We need full target passed for build so we changed the
rust-cross-canadian to use same code used in regular rust recipes and
added support to use specific llvm-target for the building host.
Fixes: ef566af964 ("rust: fix issue building cross-canadian tools for aarch64
on x86_64")
Fixes: bd36593ba3 ("rust-common: Drop LLVM_TARGET and simplify")
Fixes: 8ed000debb ("rust-common: Fix for target definitions returning
'NoneType' for arm")
Signed-off-by: Otavio Salvador
---
Changes in v2:
- Fix syntax for newer Python
meta/recipes-devtools/rust/rust-common.inc| 21 --
.../rust/rust-cross-canadian-common.inc | 22 ---
2 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-devtools/rust/rust-common.inc
b/meta/recipes-devtools/rust/rust-common.inc
index ef70c48d0f..a937d58a37 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,12 +119,12 @@ def llvm_features(d):
## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-TARGET_ENDIAN[arm] = "little"
-TARGET_POINTER_WIDTH[arm] = "32"
-TARGET_C_INT_WIDTH[arm] = "32"
-MAX_ATOMIC_WIDTH[arm] = "64"
-FEATURES[arm] = "+v6,+vfp2"
+DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+TARGET_ENDIAN[arm-eabi] = "little"
+TARGET_POINTER_WIDTH[arm-eabi] = "32"
+TARGET_C_INT_WIDTH[arm-eabi] = "32"
+MAX_ATOMIC_WIDTH[arm-eabi] = "64"
+FEATURES[arm-eabi] = "+v6,+vfp2"
## armv7-unknown-linux-gnueabihf
DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
@@ -304,12 +304,19 @@ def rust_gen_target(d, thing, wd, features, cpu, arch,
abi=""):
else:
arch_abi = rust_arch
+# When building for the building system we need to return the HOST target
+# or wrong flags are used.
+if thing == "BUILD":
+llvm_target = d.getVar('RUST_HOST_SYS', arch_abi)
+else:
+llvm_target = d.getVar('RUST_TARGET_SYS', arch_abi)
+
features = features or d.getVarFlag('FEATURES', arch_abi) or ""
features = features.strip()
# build tspec
tspec = {}
-tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi)
+tspec['llvm-target'] = llvm_target
tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
tspec['max-atomic-width'] = int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH',
arch_abi)
diff --git a/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
b/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
index 1f21c8af26..eff9212648 100644
--- a/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
+++ b/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
@@ -27,9 +27,23 @@ DEBUG_PREFIX_MAP =
"-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDP
python do_rust_gen_targets () {
wd = d.getVar('WORKDIR') + '/targets/'
-rust_gen_target(d, 'TARGET', wd, d.getVar('TARGET_LLVM_FEATURES') or "",
d.getVar('TARGET_LLVM_CPU'), d.getVar('TARGET_ARCH'))
-rust_gen_target(d, 'HOST', wd, "", "generic", d.getVar('HOST_ARCH'))
-rust_gen_target(d, 'BUILD', wd, "", "generic", d.getVar('BUILD_ARCH'))
+# It is important 'TARGET' is last here so that it overrides our less
+# informed choices for BUILD & HOST if TARGET happens to be the same as
+# either of them.
+for thing in ['BUILD', 'HOST', 'TARGET']:
+bb.debug(1, "rust_gen_target for " + thing)
+features = ""
+cpu = "generic"
+arch = d.getVar('{}_ARCH'.format(thing))
+abi = ""
+if thing is "TARGET":
+abi = d.getVar('ABIEXTENSION')
+# arm and armv7 have different targets in llvm
+if arch == "arm" and target_is_armv7(d):
+arch = 'armv7'
+features = d.getVar('TARGET_LLVM_FEATURES') or ""
+cpu = d.getVar('TARGET_LLVM_CPU')
+rust_gen_target(d, thing, wd, features, cpu, arch, abi)
}
INHIBIT_DEFAULT_RUST_DEPS = "1"
@@ -45,6 +59,8 @@ python do_configure:prepend() {
hosts = ["{}-unknown-linux-gnu".format(d.getVar("HOST_ARCH", True))]
}
+INSANE_SKIP:${PN} = "libdir"
+
INSANE_SKIP:${RUSTLIB_TARGET_PN} = "file-rdeps arch ldflags"
SKIP_FILEDEPS:${RUSTLIB_TARGET_PN} = "1"
--
2.36.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167848):
https://lists.openembedded.org/g/openembedded-core/message/167848
Mute This Topic: https://lists.openembedded.org/mt/92292890/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] rust-common: Fix use of target definitions for SDK generation
Em sáb., 9 de jul. de 2022 às 10:14, Richard Purdie <
richard.pur...@linuxfoundation.org> escreveu:
> On Thu, 2022-07-07 at 14:19 -0300, Otavio Salvador wrote:
> > We need full target passed for build so we changed the
> > rust-cross-canadian to use same code used in regular rust recipes and
> > added support to use specific llvm-target for the building host.
> >
> > Fixes: ef566af964 ("rust: fix issue building cross-canadian tools for
> aarch64 on x86_64")
> > Fixes: bd36593ba3 ("rust-common: Drop LLVM_TARGET and simplify")
> > Fixes: 8ed000debb ("rust-common: Fix for target definitions returning
> 'NoneType' for arm")
> > Signed-off-by: Otavio Salvador
> > ---
> >
> > meta/recipes-devtools/rust/rust-common.inc| 21 --
> > .../rust/rust-cross-canadian-common.inc | 22 ---
> > 2 files changed, 33 insertions(+), 10 deletions(-)
>
> I ran these through the autobuilder:
>
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/3809/steps/14/logs/stdio
>
> seems there is some syntax that recent python doesn't like. I do need
> to look at the patches in more detail but wanted to share the
> autobuilder results.
>
I will fix and send a v2.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167840):
https://lists.openembedded.org/g/openembedded-core/message/167840
Mute This Topic: https://lists.openembedded.org/mt/92233379/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Linux 5.4.202
My mistake, sorry. Em qui., 7 de jul. de 2022 às 14:19, Otavio Salvador via lists.openembedded.org escreveu: > From: Greg Kroah-Hartman > > Link: > https://lore.kernel.org/r/20220627111927.641837...@linuxfoundation.org > Tested-by: Jon Hunter > Tested-by: Florian Fainelli > Tested-by: Shuah Khan > Tested-by: Guenter Roeck > Tested-by: Sudip Mukherjee > Tested-by: Hulk Robot > Signed-off-by: Greg Kroah-Hartman > --- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index ae9156f804e5..021878dc23f9 100644 > --- a/Makefile > +++ b/Makefile > @@ -1,7 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0 > VERSION = 5 > PATCHLEVEL = 4 > -SUBLEVEL = 201 > +SUBLEVEL = 202 > EXTRAVERSION = > NAME = Kleptomaniac Octopus > > -- > 2.36.1 > > > > > -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167797): https://lists.openembedded.org/g/openembedded-core/message/167797 Mute This Topic: https://lists.openembedded.org/mt/92233428/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] Linux 5.4.202
From: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20220627111927.641837...@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Sudip Mukherjee Tested-by: Hulk Robot Signed-off-by: Greg Kroah-Hartman --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ae9156f804e5..021878dc23f9 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 5 PATCHLEVEL = 4 -SUBLEVEL = 201 +SUBLEVEL = 202 EXTRAVERSION = NAME = Kleptomaniac Octopus -- 2.36.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167796): https://lists.openembedded.org/g/openembedded-core/message/167796 Mute This Topic: https://lists.openembedded.org/mt/92233382/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/2] cargo-cross-canadian: Use SDK's flags during target linking
Signed-off-by: Otavio Salvador
---
.../cargo/cargo-cross-canadian.inc| 20 ++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
b/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
index 7fc22a4128..01ba151d0a 100644
--- a/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
+++ b/meta/recipes-devtools/cargo/cargo-cross-canadian.inc
@@ -39,6 +39,18 @@ do_compile:prepend () {
PKG_CONFIG_PATH="${RECIPE_SYSROOT_NATIVE}/usr/lib/pkgconfig:${PKG_CONFIG_PATH}"
}
+create_sdk_wrapper () {
+file="$1"
+shift
+
+cat <<- EOF > "${file}"
+ #!/bin/sh
+ \$$1 \$@
+ EOF
+
+chmod +x "$file"
+}
+
do_install () {
SYS_BINDIR=$(dirname ${D}${bindir})
install -d "${SYS_BINDIR}"
@@ -47,6 +59,9 @@ do_install () {
chrpath -r "\$ORIGIN/../lib" ${i}
done
+# Uses SDK's CC as linker so linked binaries works out of box.
+create_sdk_wrapper "${SYS_BINDIR}/target-rust-ccld" "CC"
+
ENV_SETUP_DIR=${D}${base_prefix}/environment-setup.d
mkdir "${ENV_SETUP_DIR}"
ENV_SETUP_SH="${ENV_SETUP_DIR}/cargo.sh"
@@ -58,7 +73,10 @@ do_install () {
touch "\$CARGO_HOME/config"
echo "[build]" >> "\$CARGO_HOME/config"
echo 'target = "'${TARGET_SYS}'"' >> "\$CARGO_HOME/config"
-fi
+ echo '# TARGET_SYS' >> "\$CARGO_HOME/config"
+ echo '[target.'${TARGET_SYS}']' >> "\$CARGO_HOME/config"
+ echo 'linker = "target-rust-ccld"' >> "\$CARGO_HOME/config"
+fi
# Keep the below off as long as HTTP/2 is disabled.
export CARGO_HTTP_MULTIPLEXING=false
--
2.36.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167795):
https://lists.openembedded.org/g/openembedded-core/message/167795
Mute This Topic: https://lists.openembedded.org/mt/92233381/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/2] rust-common: Fix use of target definitions for SDK generation
We need full target passed for build so we changed the
rust-cross-canadian to use same code used in regular rust recipes and
added support to use specific llvm-target for the building host.
Fixes: ef566af964 ("rust: fix issue building cross-canadian tools for aarch64
on x86_64")
Fixes: bd36593ba3 ("rust-common: Drop LLVM_TARGET and simplify")
Fixes: 8ed000debb ("rust-common: Fix for target definitions returning
'NoneType' for arm")
Signed-off-by: Otavio Salvador
---
meta/recipes-devtools/rust/rust-common.inc| 21 --
.../rust/rust-cross-canadian-common.inc | 22 ---
2 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-devtools/rust/rust-common.inc
b/meta/recipes-devtools/rust/rust-common.inc
index ef70c48d0f..f8d365ecf8 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,12 +119,12 @@ def llvm_features(d):
## arm-unknown-linux-gnueabihf
-DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-TARGET_ENDIAN[arm] = "little"
-TARGET_POINTER_WIDTH[arm] = "32"
-TARGET_C_INT_WIDTH[arm] = "32"
-MAX_ATOMIC_WIDTH[arm] = "64"
-FEATURES[arm] = "+v6,+vfp2"
+DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+TARGET_ENDIAN[arm-eabi] = "little"
+TARGET_POINTER_WIDTH[arm-eabi] = "32"
+TARGET_C_INT_WIDTH[arm-eabi] = "32"
+MAX_ATOMIC_WIDTH[arm-eabi] = "64"
+FEATURES[arm-eabi] = "+v6,+vfp2"
## armv7-unknown-linux-gnueabihf
DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
@@ -304,12 +304,19 @@ def rust_gen_target(d, thing, wd, features, cpu, arch,
abi=""):
else:
arch_abi = rust_arch
+# When building for the building system we need to return the HOST target
+# or wrong flags are used.
+if thing is "BUILD":
+llvm_target = d.getVar('RUST_HOST_SYS', arch_abi)
+else:
+llvm_target = d.getVar('RUST_TARGET_SYS', arch_abi)
+
features = features or d.getVarFlag('FEATURES', arch_abi) or ""
features = features.strip()
# build tspec
tspec = {}
-tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi)
+tspec['llvm-target'] = llvm_target
tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
tspec['max-atomic-width'] = int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
tspec['target-pointer-width'] = d.getVarFlag('TARGET_POINTER_WIDTH',
arch_abi)
diff --git a/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
b/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
index 1f21c8af26..eff9212648 100644
--- a/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
+++ b/meta/recipes-devtools/rust/rust-cross-canadian-common.inc
@@ -27,9 +27,23 @@ DEBUG_PREFIX_MAP =
"-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDP
python do_rust_gen_targets () {
wd = d.getVar('WORKDIR') + '/targets/'
-rust_gen_target(d, 'TARGET', wd, d.getVar('TARGET_LLVM_FEATURES') or "",
d.getVar('TARGET_LLVM_CPU'), d.getVar('TARGET_ARCH'))
-rust_gen_target(d, 'HOST', wd, "", "generic", d.getVar('HOST_ARCH'))
-rust_gen_target(d, 'BUILD', wd, "", "generic", d.getVar('BUILD_ARCH'))
+# It is important 'TARGET' is last here so that it overrides our less
+# informed choices for BUILD & HOST if TARGET happens to be the same as
+# either of them.
+for thing in ['BUILD', 'HOST', 'TARGET']:
+bb.debug(1, "rust_gen_target for " + thing)
+features = ""
+cpu = "generic"
+arch = d.getVar('{}_ARCH'.format(thing))
+abi = ""
+if thing is "TARGET":
+abi = d.getVar('ABIEXTENSION')
+# arm and armv7 have different targets in llvm
+if arch == "arm" and target_is_armv7(d):
+arch = 'armv7'
+features = d.getVar('TARGET_LLVM_FEATURES') or ""
+cpu = d.getVar('TARGET_LLVM_CPU')
+rust_gen_target(d, thing, wd, features, cpu, arch, abi)
}
INHIBIT_DEFAULT_RUST_DEPS = "1"
@@ -45,6 +59,8 @@ python do_configure:prepend() {
hosts = ["{}-unknown-linux-gnu".format(d.getVar("HOST_ARCH", True))]
}
+INSANE_SKIP:${PN} = "libdir"
+
INSANE_SKIP:${RUSTLIB_TARGET_PN} = "file-rdeps arch ldflags"
SKIP_FILEDEPS:${RUSTLIB_TARGET_PN} = "1"
--
2.36.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167794):
https://lists.openembedded.org/g/openembedded-core/message/167794
Mute This Topic: https://lists.openembedded.org/mt/92233379/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][kirkstone][PATCH] networkmanager: fix build with enabled ppp
Em seg., 27 de jun. de 2022 às 10:39, Javier Viguera via lists.openembedded.org escreveu: > If 'ppp' packageconfig option is enabled, but the build system does NOT > have pppd binary installed, the build fails with: > > | Has header "pppd/pppd.h" : YES > | Program pppd /sbin/pppd /usr/sbin/pppd found: NO > | > | ../NetworkManager-1.36.2/meson.build:570:4: ERROR: Assert failed: pppd > required but not found, please provide a valid pppd path or use -Dppp=false > to disable it > > This is due to meson trying to look for the 'pppd' binary in the build > system when it should not. If the build system does not contain pppd, > the build fails. > > Signed-off-by: Javier Viguera > Please send it against master, first, then we can ask for backports. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#97663): https://lists.openembedded.org/g/openembedded-devel/message/97663 Mute This Topic: https://lists.openembedded.org/mt/92020681/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] Announcing pkgexp
Em ter., 28 de jun. de 2022 às 11:26, Michael Opdenacker via lists.openembedded.org escreveu: > > On 6/28/22 16:24, Ross Burton wrote: > > > >> On 28 Jun 2022, at 15:11, Michael Opdenacker < > michael.opdenac...@bootlin.com> wrote: > >> Hey, this looks very nice and very easy to use! > >> One minor complaint, though: the "What Depends on" button didn't > immediately catch my eye. > >> Would it be possible to show such reverse dependencies in the same way > you show RDEPENDS? The result may look better and everything would be on > the same page. > > The immediate problem with that is that for some packages, like libc, > the reverse depends list can be hge. If the page is redesigned to have > scrollable regions then sure. That would likely involve someone more > skilled in web design than me getting involved ;) > Ross, take a look on ye (https://github.com/OSSystemsEmbeddedLinux/ye) it does have some things worth adding as well. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57414): https://lists.yoctoproject.org/g/yocto/message/57414 Mute This Topic: https://lists.yoctoproject.org/mt/92044621/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [OE-core] Announcing pkgexp
Em ter., 28 de jun. de 2022 às 11:26, Michael Opdenacker via lists.openembedded.org escreveu: > > On 6/28/22 16:24, Ross Burton wrote: > > > >> On 28 Jun 2022, at 15:11, Michael Opdenacker < > michael.opdenac...@bootlin.com> wrote: > >> Hey, this looks very nice and very easy to use! > >> One minor complaint, though: the "What Depends on" button didn't > immediately catch my eye. > >> Would it be possible to show such reverse dependencies in the same way > you show RDEPENDS? The result may look better and everything would be on > the same page. > > The immediate problem with that is that for some packages, like libc, > the reverse depends list can be hge. If the page is redesigned to have > scrollable regions then sure. That would likely involve someone more > skilled in web design than me getting involved ;) > Ross, take a look on ye (https://github.com/OSSystemsEmbeddedLinux/ye) it does have some things worth adding as well. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#97611): https://lists.openembedded.org/g/openembedded-devel/message/97611 Mute This Topic: https://lists.openembedded.org/mt/92044622/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Announcing pkgexp
Em ter., 28 de jun. de 2022 às 11:26, Michael Opdenacker via lists.openembedded.org escreveu: > > On 6/28/22 16:24, Ross Burton wrote: > > > >> On 28 Jun 2022, at 15:11, Michael Opdenacker < > michael.opdenac...@bootlin.com> wrote: > >> Hey, this looks very nice and very easy to use! > >> One minor complaint, though: the "What Depends on" button didn't > immediately catch my eye. > >> Would it be possible to show such reverse dependencies in the same way > you show RDEPENDS? The result may look better and everything would be on > the same page. > > The immediate problem with that is that for some packages, like libc, > the reverse depends list can be hge. If the page is redesigned to have > scrollable regions then sure. That would likely involve someone more > skilled in web design than me getting involved ;) > Ross, take a look on ye (https://github.com/OSSystemsEmbeddedLinux/ye) it does have some things worth adding as well. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167358): https://lists.openembedded.org/g/openembedded-core/message/167358 Mute This Topic: https://lists.openembedded.org/mt/92043861/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: Allow building Mesa's OpenCL through PACKAGECONFIG
Awesome!
Acked-by: Otavio Salvador
Em qua., 16 de mar. de 2022 às 10:47, Zoltan Boszormenyi via
lists.openembedded.org escreveu:
> From: Zoltán Böszörményi
>
> Signed-off-by: Zoltán Böszörményi
> ---
> meta/recipes-graphics/mesa/mesa.inc | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index 2a89b8e8f0..4ce69a78f8 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -74,7 +74,6 @@ MESON_BUILDTYPE = "${@check_buildtype(d)}"
>
> EXTRA_OEMESON = " \
> -Dshared-glapi=enabled \
> --Dgallium-opencl=disabled \
> -Dglx-read-only-text=true \
> -Dplatforms='${@",".join("${PLATFORMS}".split())}' \
> "
> @@ -122,6 +121,9 @@ PACKAGECONFIG[gles] = "-Dgles1=enabled
> -Dgles2=enabled, -Dgles1=disabled -Dgles2
> # "egl" requires "opengl"
> PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
>
> +# "opencl" requires libclc from meta-clang and spirv-tools from OE-Core
> +PACKAGECONFIG[opencl] = "-Dgallium-opencl=icd
> -Dopencl-spirv=true,-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
> spirv-tools"
> +
> PACKAGECONFIG[broadcom] = ""
> PACKAGECONFIG[etnaviv] = ""
> PACKAGECONFIG[freedreno] = ""
> @@ -190,6 +192,8 @@ RDEPENDS:${PN}-dev = ""
> # development package of libgles3.
> RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"
>
> +RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG',
> 'opencl', 'libclc spirv-tools', '', d)}"
> +
> PACKAGES =+ "libegl-mesa libegl-mesa-dev \
> libosmesa libosmesa-dev \
> libgl-mesa libgl-mesa-dev \
> @@ -198,6 +202,7 @@ PACKAGES =+ "libegl-mesa libegl-mesa-dev \
> libgles1-mesa libgles1-mesa-dev \
> libgles2-mesa libgles2-mesa-dev \
> libgles3-mesa libgles3-mesa-dev \
> + libopencl-mesa libopencl-mesa-dev \
> libxatracker libxatracker-dev \
> mesa-megadriver mesa-vulkan-drivers \
> mesa-vdpau-drivers \
> @@ -230,7 +235,8 @@ python __anonymous() {
>("opengl", "libgl", "libgl1"),
>("gles", "libgles1", "libglesv1-cm1"),
>("gles", "libgles2", "libglesv2-2"),
> - ("gles", "libgles3",)):
> + ("gles", "libgles3",),
> + ("opencl", "libopencl",)):
> if not p[0] in pkgconfig:
> continue
> mlprefix = d.getVar("MLPREFIX")
> @@ -290,6 +296,7 @@ FILES:libgbm = "${libdir}/libgbm.so.*"
> FILES:libgles1-mesa = "${libdir}/libGLESv1*.so.*"
> FILES:libgles2-mesa = "${libdir}/libGLESv2.so.*"
> FILES:libgl-mesa = "${libdir}/libGL.so.*"
> +FILES:libopencl-mesa = "${libdir}/libMesaOpenCL.so.*
> ${sysconfdir}/OpenCL/vendors/mesa.icd"
> FILES:libglapi = "${libdir}/libglapi.so.*"
> FILES:libosmesa = "${libdir}/libOSMesa.so.*"
> FILES:libxatracker = "${libdir}/libxatracker.so.*"
> --
> 2.35.1
>
>
>
>
>
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163366):
https://lists.openembedded.org/g/openembedded-core/message/163366
Mute This Topic: https://lists.openembedded.org/mt/89821896/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [AUH] rust-llvm: upgrading to 1.59.0 FAILED
Em sex., 4 de mar. de 2022 às 15:04, Alexander Kanavin < alex.kana...@gmail.com> escreveu: > Rust is a low-risk item from feature freeze perspective, so I already > queued a patch. If a-full is ok with it, there's no reason not to > merge it in my opinion. > I agree; it makes sense to upgrade it (even during the LTS lifetime) especially because Rust compiler isn't long term maintained so we should consider it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#162757): https://lists.openembedded.org/g/openembedded-core/message/162757 Mute This Topic: https://lists.openembedded.org/mt/89530593/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] classes: add setuptools3_legacy
Em sex., 4 de mar. de 2022 às 13:56, Khem Raj escreveu: > There are recipes in meta-oe and meta-python which would need this > and both layer only list core as sole dependency, if we put it in either of > these layers, then one will depend on other which is not nice, so I rather > would prefer it in core. Couldn't those recipes (depending on Python) go to meta-python? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#162750): https://lists.openembedded.org/g/openembedded-core/message/162750 Mute This Topic: https://lists.openembedded.org/mt/89547022/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] waffle: add wayland-protocols when building with wayland
Em qui., 17 de fev. de 2022 às 11:17, Andrey Zhizhikin escreveu: > When 'wayland is selected in ' DISTRO_FEATURES, following build error > occurs during do_configure: > > | Run-time dependency wayland-protocols found: NO (tried pkgconfig) > | > | ../git/meson.build:120:2: ERROR: Dependency "wayland-protocols" not > found, tried pkgconfig > > Add "wayland-protocols" to PACKAGECONFIG to resolve missing dependency. > > Signed-off-by: Andrey Zhizhikin > Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161851): https://lists.openembedded.org/g/openembedded-core/message/161851 Mute This Topic: https://lists.openembedded.org/mt/89209700/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [PATCH v4 meta-oe] rtc-tools: Add a recipe
Em sex., 28 de jan. de 2022 às 16:54, Fabio Estevam escreveu: > > From: Fabio Estevam > > rtc-tools is a useful utility developed by Alexandre Belloni > for testing RTC kernel drivers, such as y2038 support. > > Based on the initial recipe from Heiko Schocher . > > Signed-off-by: Fabio Estevam Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#95164): https://lists.openembedded.org/g/openembedded-devel/message/95164 Mute This Topic: https://lists.openembedded.org/mt/88753075/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [PATCH v2 meta-oe] rtc-tools: Add a recipe
Em qua., 26 de jan. de 2022 às 15:32, Khem Raj escreveu:
> > +do_install() {
> > + oe_runmake install
> > +}
IIRC this is the default so EXTRA_OEMAKE (removing this task) would just work.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#95108):
https://lists.openembedded.org/g/openembedded-devel/message/95108
Mute This Topic: https://lists.openembedded.org/mt/88703575/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [PATCH] patman: Support absolute and ~user-relative alias files
Em qua., 12 de jan. de 2022 às 18:22, Simon Glass escreveu: > On Fri, 7 Jan 2022 at 16:16, Brian Norris wrote: > > > > Python doesn't naturally support tilde (~) as a user-home marker in > > paths, but git-config does. So we need to resolve it before continuing. > > > > We also shouldn't blindly join the top-level tree with the aliasesfile > > path, because it might be an absolute path. > > > > This resolves warnings like the following: > > > > Warning: Cannot find alias file '/path/to/source/tree/~/.git-email' > > > > Seen when git-config is like: > > > > $ git config sendemail.aliasesfile > > ~/.git-email > > > > Signed-off-by: Brian Norris > > --- > > > > tools/patman/gitutil.py | 11 --- > > 1 file changed, 8 insertions(+), 3 deletions(-) > > +Otavio Salvador to check this one > > Reviewed-by: Simon Glass Some use-case of mine. Reviewed-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
Re: [OE-core] [PATCH 3/6] go: correctly set debug-prefix-map and build directory
Em qua., 12 de jan. de 2022 às 12:01, Alexander Kanavin escreveu: > I'm not immediately sure how to solve this though. We do want to keep those > flags when they're defined. > > Ideas? Perhaps they could be defined empty in some place which is present in > all distributions? I believe it does make sense; it ought to have a default. https://github.com/openembedded/openembedded-core/blob/master/meta/conf/distro/include/default-distrovars.inc sounds like the right place. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160488): https://lists.openembedded.org/g/openembedded-core/message/160488 Mute This Topic: https://lists.openembedded.org/mt/88071320/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/3] [DNM] e2fsprogs: upgrade 1.46.4 -> 1.46.5
Signed-off-by: Otavio Salvador
---
The ptest is failing[1]; I didn't spot anything obvious and couldn't
reproduce the error in my NixOS host (ended sending the update so it
also runs on their CI - https://github.com/NixOS/nixpkgs/pull/153660).
1.
https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/2963/steps/12/logs/stdio
I need someone to help on this so I'd like to ask for the patch to not
be merged as it has known issues.
Changes in v2:
- remove patch headers
- avoid changing not required patches
...ct_io-expect-correct-expected-output.patch | 69 ---
...2fsprogs_1.46.4.bb => e2fsprogs_1.46.5.bb} | 9 +--
2 files changed, 3 insertions(+), 75 deletions(-)
delete mode 100644
meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-tests-u_direct_io-expect-correct-expected-output.patch
rename meta/recipes-devtools/e2fsprogs/{e2fsprogs_1.46.4.bb =>
e2fsprogs_1.46.5.bb} (94%)
diff --git
a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-tests-u_direct_io-expect-correct-expected-output.patch
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-tests-u_direct_io-expect-correct-expected-output.patch
deleted file mode 100644
index f198df83eb..00
---
a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-tests-u_direct_io-expect-correct-expected-output.patch
+++ /dev/null
@@ -1,69 +0,0 @@
-From ea5adf259e01c790f9ba69d6fe88d691de410b6f Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin
-Date: Sun, 22 Aug 2021 14:37:32 +0200
-Subject: [PATCH] tests/u_direct_io/expect: correct expected output
-
-This is likely the right fix, but upstream needs to confirm.
-
-Upstream-Status: Inappropriate [issue reported
https://github.com/tytso/e2fsprogs/issues/80]
-Signed-off-by: Alexander Kanavin
- tests/u_direct_io/expect | 16 +---
- 1 file changed, 9 insertions(+), 7 deletions(-)
-
-diff --git a/tests/u_direct_io/expect b/tests/u_direct_io/expect
-index b0cdc730..830cbd75 100644
a/tests/u_direct_io/expect
-+++ b/tests/u_direct_io/expect
-@@ -19,8 +19,8 @@ Filesystem OS type: Linux
- Inode count: 32768
- Block count: 32768
- Reserved block count: 1638
--Overhead clusters:5131
--Free blocks: 27631
-+Overhead clusters:6155
-+Free blocks: 26607
- Free inodes: 32757
- First block: 0
- Block size: 4096
-@@ -29,27 +29,29 @@ Reserved GDT blocks: 7
- Blocks per group: 32768
- Fragments per group: 32768
- Inodes per group: 32768
--Inode blocks per group: 1024
-+Inode blocks per group: 2048
- Flex block group size:16
- Mount count: 0
- Check interval: 15552000 (6 months)
- Reserved blocks uid: 0
- Reserved blocks gid: 0
- First inode: 11
--Inode size: 128
-+Inode size: 256
-+Required extra isize: 32
-+Desired extra isize: 32
- Journal inode:8
- Default directory hash: half_md4
- Journal backup: inode blocks
- Directories: 2
- Group 0: block bitmap at 9, inode bitmap at 25, inode table at 41
-- 27631 free blocks, 32757 free inodes, 2 used directories
-+ 26607 free blocks, 32757 free inodes, 2 used directories
- e2fsck -fn -N test_filesys $LOOP
- Pass 1: Checking inodes, blocks, and sizes
- Pass 2: Checking directory structure
- Pass 3: Checking directory connectivity
- Pass 4: Checking reference counts
- Pass 5: Checking group summary information
--test_filesys: 11/32768 files (9.1% non-contiguous), 5137/32768 blocks
-+test_filesys: 11/32768 files (9.1% non-contiguous), 6161/32768 blocks
- Exit status is 0
- e2fsck -fn -N test_filesys $TMPFILE
- Pass 1: Checking inodes, blocks, and sizes
-@@ -57,5 +59,5 @@ Pass 2: Checking directory structure
- Pass 3: Checking directory connectivity
- Pass 4: Checking reference counts
- Pass 5: Checking group summary information
--test_filesys: 11/32768 files (9.1% non-contiguous), 5137/32768 blocks
-+test_filesys: 11/32768 files (9.1% non-contiguous), 6161/32768 blocks
- Exit status is 0
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.46.4.bb
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.46.5.bb
similarity index 94%
rename from meta/recipes-devtools/e2fsprogs/e2fsprogs_1.46.4.bb
rename to meta/recipes-devtools/e2fsprogs/e2fsprogs_1.46.5.bb
index f42cefcaf9..68b8531565 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.46.4.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.46.5.bb
@@ -4,14 +4,11 @@ SRC_URI += "file://remove.ldconfig.call.patch \
file://run-ptest \
file://ptest.patch \
file://mkdir_p.patch \
- file://0001-tests-u_direct_io-expect-correct-expected-output.patch \
+ file://e2fsprogs-fix-missing-check-for-permission-denied.patch \
+ file://quiet-debugfs.patch \
"
-SRC_URI:append:class-native = "
file://e2fsprogs-fix-missing
[OE-core] [PATCH 2/3] [DNM] python3-setuptools: upgrade 59.5.0 -> 60.2.0
Signed-off-by: Otavio Salvador
---
The patch seems to break some native package building due do host
contamination; I faced it at btrfs-progs, for example.
I need someone which has more intimacy in Python to help on this so I'd
like to ask for the patch to not be merged as it has known issues.
Changes in v2:
- remove wrong patch header
...01-conditionally-do-not-fetch-code-by-easy_install.patch | 6 +++---
...n3-setuptools_59.5.0.bb => python3-setuptools_60.2.0.bb} | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
rename meta/recipes-devtools/python/{python3-setuptools_59.5.0.bb =>
python3-setuptools_60.2.0.bb} (94%)
diff --git
a/meta/recipes-devtools/python/files/0001-conditionally-do-not-fetch-code-by-easy_install.patch
b/meta/recipes-devtools/python/files/0001-conditionally-do-not-fetch-code-by-easy_install.patch
index 5e2ee454da..5d508f759f 100644
---
a/meta/recipes-devtools/python/files/0001-conditionally-do-not-fetch-code-by-easy_install.patch
+++
b/meta/recipes-devtools/python/files/0001-conditionally-do-not-fetch-code-by-easy_install.patch
@@ -1,4 +1,4 @@
-From da88c57fe03e4474ba20325edacf519e80c1d7a8 Mon Sep 17 00:00:00 2001
+From 74abf3fae060c87b04e5fb8c382ecc835afc3a50 Mon Sep 17 00:00:00 2001
From: Hongxu Jia
Date: Tue, 17 Jul 2018 10:13:38 +0800
Subject: [PATCH] conditionally do not fetch code by easy_install
@@ -15,10 +15,10 @@ Signed-off-by: Hongxu Jia
1 file changed, 5 insertions(+)
diff --git a/setuptools/command/easy_install.py
b/setuptools/command/easy_install.py
-index fc848d0..c04a5de 100644
+index fb34d10..217fce1 100644
--- a/setuptools/command/easy_install.py
+++ b/setuptools/command/easy_install.py
-@@ -642,6 +642,11 @@ class easy_install(Command):
+@@ -649,6 +649,11 @@ class easy_install(Command):
os.path.exists(tmpdir) and rmtree(tmpdir)
def easy_install(self, spec, deps=False):
diff --git a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
b/meta/recipes-devtools/python/python3-setuptools_60.2.0.bb
similarity index 94%
rename from meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
rename to meta/recipes-devtools/python/python3-setuptools_60.2.0.bb
index 878fa08404..8748f91388 100644
--- a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_60.2.0.bb
@@ -13,7 +13,7 @@ SRC_URI += "\
file://0001-_distutils-sysconfig-append-STAGING_LIBDIR-python-sy.patch \
"
-SRC_URI[sha256sum] =
"d144f85102f999444d06f9c0e8c737fd0194f10f2f7e5fdb77573f6e2fa4fad0"
+SRC_URI[sha256sum] =
"675fcebecb43c32eb930481abf907619137547f4336206e4d673180242e1a278"
DEPENDS += "${PYTHON_PN}"
--
2.34.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160220):
https://lists.openembedded.org/g/openembedded-core/message/160220
Mute This Topic: https://lists.openembedded.org/mt/88227970/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/3] libxcrypt, libxcrypt-compat: upgrade 4.4.26 -> 4.4.27
License-Update: build-aux files updated.
Signed-off-by: Otavio Salvador
---
Changes in v2:
- fix license checksum error
- update libxcrypt too
.../libxcrypt/files/fix_cflags_handling.patch | 10 +-
...ypt-compat_4.4.26.bb => libxcrypt-compat_4.4.27.bb} | 0
meta/recipes-core/libxcrypt/libxcrypt.inc | 4 ++--
.../{libxcrypt_4.4.26.bb => libxcrypt_4.4.27.bb} | 0
4 files changed, 7 insertions(+), 7 deletions(-)
rename meta/recipes-core/libxcrypt/{libxcrypt-compat_4.4.26.bb =>
libxcrypt-compat_4.4.27.bb} (100%)
rename meta/recipes-core/libxcrypt/{libxcrypt_4.4.26.bb =>
libxcrypt_4.4.27.bb} (100%)
diff --git a/meta/recipes-core/libxcrypt/files/fix_cflags_handling.patch
b/meta/recipes-core/libxcrypt/files/fix_cflags_handling.patch
index 0772998c72..94aa3fed49 100644
--- a/meta/recipes-core/libxcrypt/files/fix_cflags_handling.patch
+++ b/meta/recipes-core/libxcrypt/files/fix_cflags_handling.patch
@@ -1,4 +1,4 @@
-From fd9a46695594c3cd836ecb7d959f03f605e69a2f Mon Sep 17 00:00:00 2001
+From 7b2a0cdc281d94a5782c37ef87040c341447b4b4 Mon Sep 17 00:00:00 2001
From: Richard Purdie
Date: Fri, 30 Apr 2021 10:35:02 +0100
Subject: [PATCH] libxcrypt: Update to 4.4.19 release and fix symbol version
@@ -15,13 +15,13 @@ Upstream-Status: Submitted
[https://github.com/besser82/libxcrypt/pull/126]
Signed-off-by: Richard Purdie
---
- build-aux/compute-symver-floor | 2 ++
+ build-aux/scripts/compute-symver-floor | 2 ++
1 file changed, 2 insertions(+)
-diff --git a/build-aux/compute-symver-floor b/build-aux/compute-symver-floor
+diff --git a/build-aux/scripts/compute-symver-floor
b/build-aux/scripts/compute-symver-floor
index 4ec82e1..8117342 100644
a/build-aux/compute-symver-floor
-+++ b/build-aux/compute-symver-floor
+--- a/build-aux/scripts/compute-symver-floor
b/build-aux/scripts/compute-symver-floor
@@ -36,6 +36,8 @@ sub preprocessor_check {
die "C compiler not available\n" unless @CC;
diff --git a/meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.26.bb
b/meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.27.bb
similarity index 100%
rename from meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.26.bb
rename to meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.27.bb
diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc
b/meta/recipes-core/libxcrypt/libxcrypt.inc
index 9186c45e18..725965e535 100644
--- a/meta/recipes-core/libxcrypt/libxcrypt.inc
+++ b/meta/recipes-core/libxcrypt/libxcrypt.inc
@@ -3,14 +3,14 @@ DESCRIPTION = "Forked code from glibc libary to extract only
crypto part."
HOMEPAGE = "https://github.com/besser82/libxcrypt;
SECTION = "libs"
LICENSE = "LGPLv2.1"
-LIC_FILES_CHKSUM = "file://LICENSING;md5=29c5f9af198623cdce52a77f85695164 \
+LIC_FILES_CHKSUM = "file://LICENSING;md5=c0a30e2b1502c55a7f37e412cd6c6a4b \
file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c \
"
inherit autotools pkgconfig
SRC_URI =
"git://github.com/besser82/libxcrypt.git;branch=${SRCBRANCH};protocol=https"
-SRCREV = "8ff7a8c5019cbd50419f7d0a8cd691eb99d6b086"
+SRCREV = "814e715dd8580ff00344112d7d8383a6a5a5b83d"
SRCBRANCH ?= "develop"
SRC_URI += "file://fix_cflags_handling.patch"
diff --git a/meta/recipes-core/libxcrypt/libxcrypt_4.4.26.bb
b/meta/recipes-core/libxcrypt/libxcrypt_4.4.27.bb
similarity index 100%
rename from meta/recipes-core/libxcrypt/libxcrypt_4.4.26.bb
rename to meta/recipes-core/libxcrypt/libxcrypt_4.4.27.bb
--
2.34.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160219):
https://lists.openembedded.org/g/openembedded-core/message/160219
Mute This Topic: https://lists.openembedded.org/mt/88227962/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][PATCH v2] ifupdown-ng: Add recipe
Hello Ross, Em ter., 4 de jan. de 2022 às 07:28, Ross Burton escreveu: > On Mon, 3 Jan 2022 at 16:40, Alex Kiernan wrote: > > ifupdown-ng is a network device manager that is largely compatible with > > Debian ifupdown, BusyBox ifupdown and Cumulus Networks' ifupdown2. > > If this is a superior alternative, should this be merged into oe-core > as the replacement for the existing ifupdown scripts? I think we could consider it but it'd be interesting to check the size difference between both so we can have a clear idea on the impact of it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#94659): https://lists.openembedded.org/g/openembedded-devel/message/94659 Mute This Topic: https://lists.openembedded.org/mt/88115930/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][PATCH v2] ifupdown-ng: Add recipe
Em seg., 3 de jan. de 2022 às 13:37, Alex Kiernan
escreveu:
>
> ifupdown-ng is a network device manager that is largely compatible with
> Debian ifupdown, BusyBox ifupdown and Cumulus Networks' ifupdown2.
>
> Signed-off-by: Alex Kiernan
> Signed-off-by: Alex Kiernan
> ---
> Changes in v2:
> - drop merged upstream SBINDIR patch
>
> .../ifupdown-ng/ifupdown-ng_0.11.3.bb | 45 +++
> 1 file changed, 45 insertions(+)
> create mode 100644
> meta-networking/recipes-support/ifupdown-ng/ifupdown-ng_0.11.3.bb
>
> diff --git
> a/meta-networking/recipes-support/ifupdown-ng/ifupdown-ng_0.11.3.bb
> b/meta-networking/recipes-support/ifupdown-ng/ifupdown-ng_0.11.3.bb
> new file mode 100644
...
> +do_compile () {
> + oe_runmake
> +}
> +
> +do_install () {
> + oe_runmake 'DESTDIR=${D}' install
> +}
The do_compile and do_install could be dropped as this is the default.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#94658):
https://lists.openembedded.org/g/openembedded-devel/message/94658
Mute This Topic: https://lists.openembedded.org/mt/88115930/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[PATCH] patman: expand user home when looking for the alias file
This allows the use of git aliases files relative to the user home,
without using the full path to the file.
Signed-off-by: Otavio Salvador
---
tools/patman/gitutil.py | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 5e4c1128dcb..172de4aae59 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -616,8 +616,13 @@ def GetAliasFile():
"""
fname = command.OutputOneLine('git', 'config', 'sendemail.aliasesfile',
raise_on_error=False)
+
if fname:
-fname = os.path.join(GetTopLevel(), fname.strip())
+fname = fname.strip()
+if fname.startswith("~/"):
+fname = fname.replace("~", os.path.expanduser('~'), 1)
+fname = os.path.join(GetTopLevel(), fname)
+
return fname
def GetDefaultUserName():
--
2.34.1
Re: [OE-core] [PATCH 05/24] e2fsprogs: upgrade 1.46.4 -> 1.46.5
Em seg., 3 de jan. de 2022 às 14:42, Richard Purdie
escreveu:
> On Mon, 2022-01-03 at 13:18 -0300, Otavio Salvador wrote:
> > Signed-off-by: Otavio Salvador
> > ---
> > ...ct_io-expect-correct-expected-output.patch | 69 ---
> > ...-missing-check-for-permission-denied.patch | 3 +-
> > .../e2fsprogs/e2fsprogs/quiet-debugfs.patch | 3 +-
> > ...2fsprogs_1.46.4.bb => e2fsprogs_1.46.5.bb} | 9 +--
> > 4 files changed, 7 insertions(+), 77 deletions(-)
> > delete mode 100644
> > meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-tests-u_direct_io-expect-correct-expected-output.patch
> > rename meta/recipes-devtools/e2fsprogs/{e2fsprogs_1.46.4.bb =>
> > e2fsprogs_1.46.5.bb} (94%)
> >
> > diff --git
> > a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-tests-u_direct_io-expect-correct-expected-output.patch
> >
> > b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-tests-u_direct_io-expect-correct-expected-output.patch
> > deleted file mode 100644
> > index f198df83eb..00
> > ---
> > a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-tests-u_direct_io-expect-correct-expected-output.patch
> > +++ /dev/null
> > @@ -1,69 +0,0 @@
> > -From ea5adf259e01c790f9ba69d6fe88d691de410b6f Mon Sep 17 00:00:00 2001
> > -From: Alexander Kanavin
> > -Date: Sun, 22 Aug 2021 14:37:32 +0200
> > -Subject: [PATCH] tests/u_direct_io/expect: correct expected output
> > -
> > -This is likely the right fix, but upstream needs to confirm.
> > -
> > -Upstream-Status: Inappropriate [issue reported
> > https://github.com/tytso/e2fsprogs/issues/80]
> > -Signed-off-by: Alexander Kanavin
> >
> > - tests/u_direct_io/expect | 16 +---
> > - 1 file changed, 9 insertions(+), 7 deletions(-)
> > -
> > -diff --git a/tests/u_direct_io/expect b/tests/u_direct_io/expect
> > -index b0cdc730..830cbd75 100644
> > a/tests/u_direct_io/expect
> > -+++ b/tests/u_direct_io/expect
> > -@@ -19,8 +19,8 @@ Filesystem OS type: Linux
> > - Inode count: 32768
> > - Block count: 32768
> > - Reserved block count: 1638
> > --Overhead clusters:5131
> > --Free blocks: 27631
> > -+Overhead clusters:6155
> > -+Free blocks: 26607
> > - Free inodes: 32757
> > - First block: 0
> > - Block size: 4096
> > -@@ -29,27 +29,29 @@ Reserved GDT blocks: 7
> > - Blocks per group: 32768
> > - Fragments per group: 32768
> > - Inodes per group: 32768
> > --Inode blocks per group: 1024
> > -+Inode blocks per group: 2048
> > - Flex block group size:16
> > - Mount count: 0
> > - Check interval: 15552000 (6 months)
> > - Reserved blocks uid: 0
> > - Reserved blocks gid: 0
> > - First inode: 11
> > --Inode size: 128
> > -+Inode size: 256
> > -+Required extra isize: 32
> > -+Desired extra isize: 32
> > - Journal inode:8
> > - Default directory hash: half_md4
> > - Journal backup: inode blocks
> > - Directories: 2
> > - Group 0: block bitmap at 9, inode bitmap at 25, inode table at 41
> > -- 27631 free blocks, 32757 free inodes, 2 used directories
> > -+ 26607 free blocks, 32757 free inodes, 2 used directories
> > - e2fsck -fn -N test_filesys $LOOP
> > - Pass 1: Checking inodes, blocks, and sizes
> > - Pass 2: Checking directory structure
> > - Pass 3: Checking directory connectivity
> > - Pass 4: Checking reference counts
> > - Pass 5: Checking group summary information
> > --test_filesys: 11/32768 files (9.1% non-contiguous), 5137/32768 blocks
> > -+test_filesys: 11/32768 files (9.1% non-contiguous), 6161/32768 blocks
> > - Exit status is 0
> > - e2fsck -fn -N test_filesys $TMPFILE
> > - Pass 1: Checking inodes, blocks, and sizes
> > -@@ -57,5 +59,5 @@ Pass 2: Checking directory structure
> > - Pass 3: Checking directory connectivity
> > - Pass 4: Checking reference counts
> > - Pass 5: Checking group summary information
> > --test_filesys: 11/32768 files (9.1% non-contiguous), 5137/32768 blocks
> > -+test_filesys: 11/32768 files (9.1% non-contiguous), 6161/32768 blocks
> > - Exit status is 0
> > diff --git
> > a/meta/recipes-devtools/e2fsprogs/e2fsprogs/e2fsprogs-fix-missing-check-for-permission-denied.patch
> >
> > b/meta/recipes-devtools/e2fsprogs/e2fsprogs/e2fsprogs-fix-mi
[OE-core] [PATCH 24/24] stress-ng: upgrade 0.13.08 -> 0.13.09
Signed-off-by: Otavio Salvador
---
.../stress-ng/{stress-ng_0.13.08.bb => stress-ng_0.13.09.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-extended/stress-ng/{stress-ng_0.13.08.bb =>
stress-ng_0.13.09.bb} (93%)
diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.13.08.bb
b/meta/recipes-extended/stress-ng/stress-ng_0.13.09.bb
similarity index 93%
rename from meta/recipes-extended/stress-ng/stress-ng_0.13.08.bb
rename to meta/recipes-extended/stress-ng/stress-ng_0.13.09.bb
index f7197a27fa..482fdd2df5 100644
--- a/meta/recipes-extended/stress-ng/stress-ng_0.13.08.bb
+++ b/meta/recipes-extended/stress-ng/stress-ng_0.13.09.bb
@@ -6,7 +6,7 @@ LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
SRC_URI =
"git://github.com/ColinIanKing/stress-ng.git;protocol=https;branch=master"
-SRCREV = "0af163e0e378e5c62abb9328a27b653289c05679"
+SRCREV = "757b66b49e4b3d7d008ef7054b34d791c742e869"
S = "${WORKDIR}/git"
DEPENDS = "coreutils-native"
--
2.34.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160141):
https://lists.openembedded.org/g/openembedded-core/message/160141
Mute This Topic: https://lists.openembedded.org/mt/88115453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 23/24] sqlite3: upgrade 3.37.0 -> 3.37.1
Signed-off-by: Otavio Salvador
---
.../sqlite/{sqlite3_3.37.0.bb => sqlite3_3.37.1.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-support/sqlite/{sqlite3_3.37.0.bb => sqlite3_3.37.1.bb}
(86%)
diff --git a/meta/recipes-support/sqlite/sqlite3_3.37.0.bb
b/meta/recipes-support/sqlite/sqlite3_3.37.1.bb
similarity index 86%
rename from meta/recipes-support/sqlite/sqlite3_3.37.0.bb
rename to meta/recipes-support/sqlite/sqlite3_3.37.1.bb
index 68394c88b0..a13cca633a 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.37.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.37.1.bb
@@ -4,7 +4,7 @@ LICENSE = "PD"
LIC_FILES_CHKSUM =
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66"
SRC_URI = "http://www.sqlite.org/2021/sqlite-autoconf-${SQLITE_PV}.tar.gz;
-SRC_URI[sha256sum] =
"731a4651d4d4b36fc7d21db586b2de4dd00af31fd54fb5a9a4b7f492057479f7"
+SRC_URI[sha256sum] =
"40f22a13bf38bbcd4c7ac79bcfb42a72d5aa40930c1f3f822e30ccce295f0f2e"
# -19242 is only an issue in specific development branch commits
CVE_CHECK_WHITELIST += "CVE-2019-19242"
--
2.34.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160140):
https://lists.openembedded.org/g/openembedded-core/message/160140
Mute This Topic: https://lists.openembedded.org/mt/88115452/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 22/24] python3-zipp: upgrade 3.6.0 -> 3.7.0
Signed-off-by: Otavio Salvador
---
.../python/{python3-zipp_3.6.0.bb => python3-zipp_3.7.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/python/{python3-zipp_3.6.0.bb =>
python3-zipp_3.7.0.bb} (84%)
diff --git a/meta/recipes-devtools/python/python3-zipp_3.6.0.bb
b/meta/recipes-devtools/python/python3-zipp_3.7.0.bb
similarity index 84%
rename from meta/recipes-devtools/python/python3-zipp_3.6.0.bb
rename to meta/recipes-devtools/python/python3-zipp_3.7.0.bb
index c98bc7a3a4..9ce987c870 100644
--- a/meta/recipes-devtools/python/python3-zipp_3.6.0.bb
+++ b/meta/recipes-devtools/python/python3-zipp_3.7.0.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "https://github.com/jaraco/zipp;
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=7a7126e068206290f3fe9f8d6c713ea6"
-SRC_URI[sha256sum] =
"71c644c5369f4a6e07636f0aa966270449561fcea2e3d6747b8d23efaa9d7832"
+SRC_URI[sha256sum] =
"9f50f446828eb9d45b267433fd3e9da8d801f614129124863f9c51ebceafb87d"
DEPENDS += "${PYTHON_PN}-setuptools-scm-native"
--
2.34.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160139):
https://lists.openembedded.org/g/openembedded-core/message/160139
Mute This Topic: https://lists.openembedded.org/mt/88115450/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 21/24] python3-tomli: upgrade 1.2.2 -> 2.0.0
Signed-off-by: Otavio Salvador
---
.../python/{python3-tomli_1.2.2.bb => python3-tomli_2.0.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/python/{python3-tomli_1.2.2.bb =>
python3-tomli_2.0.0.bb} (86%)
diff --git a/meta/recipes-devtools/python/python3-tomli_1.2.2.bb
b/meta/recipes-devtools/python/python3-tomli_2.0.0.bb
similarity index 86%
rename from meta/recipes-devtools/python/python3-tomli_1.2.2.bb
rename to meta/recipes-devtools/python/python3-tomli_2.0.0.bb
index 39030ed218..aa23ad856d 100644
--- a/meta/recipes-devtools/python/python3-tomli_1.2.2.bb
+++ b/meta/recipes-devtools/python/python3-tomli_2.0.0.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=f0879d17df0110d1aa8c8c9f46f5"
inherit pypi setuptools3
-SRC_URI[sha256sum] =
"c6ce0015eb38820eaf32b5db832dbc26deb3dd427bd5f6556cf0acac2c214fee"
+SRC_URI[sha256sum] =
"c292c34f58502a1eb2bbb9f5bbc9a5ebc37bee10ffb8c2d6bbdfa8eb13cc14e1"
do_configure:prepend() {
cat > ${S}/setup.py <<-EOF
--
2.34.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160138):
https://lists.openembedded.org/g/openembedded-core/message/160138
Mute This Topic: https://lists.openembedded.org/mt/88115448/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 20/24] python3-setuptools: upgrade 59.5.0 -> 60.2.0
Signed-off-by: Otavio Salvador
---
...1-conditionally-do-not-fetch-code-by-easy_install.patch | 7 ---
...3-setuptools_59.5.0.bb => python3-setuptools_60.2.0.bb} | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
rename meta/recipes-devtools/python/{python3-setuptools_59.5.0.bb =>
python3-setuptools_60.2.0.bb} (94%)
diff --git
a/meta/recipes-devtools/python/files/0001-conditionally-do-not-fetch-code-by-easy_install.patch
b/meta/recipes-devtools/python/files/0001-conditionally-do-not-fetch-code-by-easy_install.patch
index 5e2ee454da..290188ebae 100644
---
a/meta/recipes-devtools/python/files/0001-conditionally-do-not-fetch-code-by-easy_install.patch
+++
b/meta/recipes-devtools/python/files/0001-conditionally-do-not-fetch-code-by-easy_install.patch
@@ -1,7 +1,8 @@
-From da88c57fe03e4474ba20325edacf519e80c1d7a8 Mon Sep 17 00:00:00 2001
+From 74abf3fae060c87b04e5fb8c382ecc835afc3a50 Mon Sep 17 00:00:00 2001
From: Hongxu Jia
Date: Tue, 17 Jul 2018 10:13:38 +0800
Subject: [PATCH] conditionally do not fetch code by easy_install
+Organization: O.S. Systems Software LTDA.
If var-NO_FETCH_BUILD is set, do not allow to fetch code from
internet by easy_install.
@@ -15,10 +16,10 @@ Signed-off-by: Hongxu Jia
1 file changed, 5 insertions(+)
diff --git a/setuptools/command/easy_install.py
b/setuptools/command/easy_install.py
-index fc848d0..c04a5de 100644
+index fb34d10..217fce1 100644
--- a/setuptools/command/easy_install.py
+++ b/setuptools/command/easy_install.py
-@@ -642,6 +642,11 @@ class easy_install(Command):
+@@ -649,6 +649,11 @@ class easy_install(Command):
os.path.exists(tmpdir) and rmtree(tmpdir)
def easy_install(self, spec, deps=False):
diff --git a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
b/meta/recipes-devtools/python/python3-setuptools_60.2.0.bb
similarity index 94%
rename from meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
rename to meta/recipes-devtools/python/python3-setuptools_60.2.0.bb
index 878fa08404..8748f91388 100644
--- a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_60.2.0.bb
@@ -13,7 +13,7 @@ SRC_URI += "\
file://0001-_distutils-sysconfig-append-STAGING_LIBDIR-python-sy.patch \
"
-SRC_URI[sha256sum] =
"d144f85102f999444d06f9c0e8c737fd0194f10f2f7e5fdb77573f6e2fa4fad0"
+SRC_URI[sha256sum] =
"675fcebecb43c32eb930481abf907619137547f4336206e4d673180242e1a278"
DEPENDS += "${PYTHON_PN}"
--
2.34.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160137):
https://lists.openembedded.org/g/openembedded-core/message/160137
Mute This Topic: https://lists.openembedded.org/mt/88115444/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 19/24] python3-ruamel-yaml: upgrade 0.17.17 -> 0.17.19
Signed-off-by: Otavio Salvador
---
...n3-ruamel-yaml_0.17.17.bb => python3-ruamel-yaml_0.17.19.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/python/{python3-ruamel-yaml_0.17.17.bb =>
python3-ruamel-yaml_0.17.19.bb} (86%)
diff --git a/meta/recipes-devtools/python/python3-ruamel-yaml_0.17.17.bb
b/meta/recipes-devtools/python/python3-ruamel-yaml_0.17.19.bb
similarity index 86%
rename from meta/recipes-devtools/python/python3-ruamel-yaml_0.17.17.bb
rename to meta/recipes-devtools/python/python3-ruamel-yaml_0.17.19.bb
index 4eb0274166..a0f5c89846 100644
--- a/meta/recipes-devtools/python/python3-ruamel-yaml_0.17.17.bb
+++ b/meta/recipes-devtools/python/python3-ruamel-yaml_0.17.19.bb
@@ -9,7 +9,7 @@ PYPI_PACKAGE = "ruamel.yaml"
inherit pypi setuptools3
-SRC_URI[sha256sum] =
"9751de4cbb57d4bfbf8fc394e125ed4a2f170fbff3dc3d78abf50be85924f8be"
+SRC_URI[sha256sum] =
"b9ce9a925d0f0c35a1dbba56b40f253c53cd526b0fa81cf7b1d24996f28fb1d7"
RDEPENDS:${PN} += "\
${PYTHON_PN}-shell \
--
2.34.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160136):
https://lists.openembedded.org/g/openembedded-core/message/160136
Mute This Topic: https://lists.openembedded.org/mt/88115443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
