Re: [yocto] [yocto-autobuilder2] config.py: add fedora36 to workers_prev_releases for kirkstone
On Thu, Dec 1, 2022 at 1:38 PM Richard Purdie wrote: > > On Thu, 2022-12-01 at 12:32 -1000, Steve Sakoman wrote: > > also remove obsolete fedora releases for kirkstone > > Please don't remove the obsolete ones, we leave the old ones here as a > record in case we do end up wanting to know which distros we did test. Understood, v2 sent. Steve -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58715): https://lists.yoctoproject.org/g/yocto/message/58715 Mute This Topic: https://lists.yoctoproject.org/mt/95394812/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder2][PATCH V2] config.py: add fedora36 to workers_prev_releases for kirkstone
Signed-off-by: Steve Sakoman
---
config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.py b/config.py
index de9356a..bf7126e 100644
--- a/config.py
+++ b/config.py
@@ -153,7 +153,7 @@ all_workers = workers + workers_bringup + workers_buildperf
+ workers_arm
# Worker filtering for older releases
workers_prev_releases = {
"langdale" : ("alma8", "alma9", "debian10", "debian11", "fedora35",
"fedora36", "opensuse153", "opensuse154", "ubuntu1804",
"ubuntu2004","ubuntu2204", "perf-"),
-"kirkstone" : ("alma8", "centos7", "centos8", "debian8", "debian9",
"debian10", "debian11", "fedora29", "fedora30", "fedora31", "fedora32",
"fedora33", "fedora34", "fedora35", "opensuse150", "opensuse151",
"opensuse152", "opensuse153", "ubuntu1604", "ubuntu1804", "ubuntu1904",
"ubuntu2004", "ubuntu2110", "ubuntu2204", "perf-"),
+"kirkstone" : ("alma8", "centos7", "centos8", "debian8", "debian9",
"debian10", "debian11", "fedora29", "fedora30", "fedora31", "fedora32",
"fedora33", "fedora34", "fedora35", "fedora36", "opensuse150", "opensuse151",
"opensuse152", "opensuse153", "ubuntu1604", "ubuntu1804", "ubuntu1904",
"ubuntu2004", "ubuntu2110", "ubuntu2204", "perf-"),
"honister" : ("alma8", "centos7", "centos8", "debian8", "debian9",
"debian10", "debian11", "fedora29", "fedora30", "fedora31", "fedora32",
"fedora33", "fedora34", "fedora35", "opensuse150", "opensuse151",
"opensuse152", "opensuse153", "ubuntu1604", "ubuntu1804", "ubuntu1904",
"ubuntu2004", "ubuntu2110", "ubuntu2204", "perf-"),
"hardknott" : ("centos7", "centos8", "debian8", "debian9", "debian10",
"debian11", "fedora31", "fedora32", "fedora33", "fedora34", "opensuse152",
"ubuntu1604", "ubuntu1804", "ubuntu2004", "perf-"),
"gatesgarth" : ("centos7", "centos8", "debian8", "debian9", "debian10",
"fedora30", "fedora31", "fedora32", "opensuse150", "opensuse151",
"opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58714): https://lists.yoctoproject.org/g/yocto/message/58714
Mute This Topic: https://lists.yoctoproject.org/mt/95399028/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder2] config.py: add fedora36 to workers_prev_releases for kirkstone
On Thu, 2022-12-01 at 12:32 -1000, Steve Sakoman wrote: > also remove obsolete fedora releases for kirkstone Please don't remove the obsolete ones, we leave the old ones here as a record in case we do end up wanting to know which distros we did test. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58713): https://lists.yoctoproject.org/g/yocto/message/58713 Mute This Topic: https://lists.yoctoproject.org/mt/95394812/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder2] config.py: add fedora36 to workers_prev_releases for kirkstone
also remove obsolete fedora releases for kirkstone
Signed-off-by: Steve Sakoman
---
config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.py b/config.py
index de9356a..082c853 100644
--- a/config.py
+++ b/config.py
@@ -153,7 +153,7 @@ all_workers = workers + workers_bringup + workers_buildperf
+ workers_arm
# Worker filtering for older releases
workers_prev_releases = {
"langdale" : ("alma8", "alma9", "debian10", "debian11", "fedora35",
"fedora36", "opensuse153", "opensuse154", "ubuntu1804",
"ubuntu2004","ubuntu2204", "perf-"),
-"kirkstone" : ("alma8", "centos7", "centos8", "debian8", "debian9",
"debian10", "debian11", "fedora29", "fedora30", "fedora31", "fedora32",
"fedora33", "fedora34", "fedora35", "opensuse150", "opensuse151",
"opensuse152", "opensuse153", "ubuntu1604", "ubuntu1804", "ubuntu1904",
"ubuntu2004", "ubuntu2110", "ubuntu2204", "perf-"),
+"kirkstone" : ("alma8", "centos7", "centos8", "debian8", "debian9",
"debian10", "debian11", "fedora35", "fedora36", "opensuse150", "opensuse151",
"opensuse152", "opensuse153", "ubuntu1604", "ubuntu1804", "ubuntu1904",
"ubuntu2004", "ubuntu2110", "ubuntu2204", "perf-"),
"honister" : ("alma8", "centos7", "centos8", "debian8", "debian9",
"debian10", "debian11", "fedora29", "fedora30", "fedora31", "fedora32",
"fedora33", "fedora34", "fedora35", "opensuse150", "opensuse151",
"opensuse152", "opensuse153", "ubuntu1604", "ubuntu1804", "ubuntu1904",
"ubuntu2004", "ubuntu2110", "ubuntu2204", "perf-"),
"hardknott" : ("centos7", "centos8", "debian8", "debian9", "debian10",
"debian11", "fedora31", "fedora32", "fedora33", "fedora34", "opensuse152",
"ubuntu1604", "ubuntu1804", "ubuntu2004", "perf-"),
"gatesgarth" : ("centos7", "centos8", "debian8", "debian9", "debian10",
"fedora30", "fedora31", "fedora32", "opensuse150", "opensuse151",
"opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58712): https://lists.yoctoproject.org/g/yocto/message/58712
Mute This Topic: https://lists.yoctoproject.org/mt/95394812/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [yocto-kernel-cache][yocto-5.15][PATCH 1/3] nxp-imx7: enable CONFIG_ARM_IMX_CPUFREQ_DT config
merged. Bruce In message: [yocto-kernel-cache][yocto-5.15][PATCH 1/3] nxp-imx7: enable CONFIG_ARM_IMX_CPUFREQ_DT config on 01/12/2022 Xiaolei Wang wrote: > enable CONFIG_ARM_IMX_CPUFREQ_DT config, this is supported > by imx7. Some places also rely on cpufreq, like imx_thermal. > > Signed-off-by: Xiaolei Wang > --- > bsp/nxp-imx7/nxp-imx7.cfg | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/bsp/nxp-imx7/nxp-imx7.cfg b/bsp/nxp-imx7/nxp-imx7.cfg > index 5db00dde..308c5c32 100644 > --- a/bsp/nxp-imx7/nxp-imx7.cfg > +++ b/bsp/nxp-imx7/nxp-imx7.cfg > @@ -17,6 +17,7 @@ CONFIG_CPU_FREQ_GOV_POWERSAVE=y > CONFIG_CPU_FREQ_GOV_USERSPACE=y > CONFIG_CPU_FREQ_GOV_ONDEMAND=y > CONFIG_CPUFREQ_DT=y > +CONFIG_ARM_IMX_CPUFREQ_DT=y > > CONFIG_CPU_IDLE=y > CONFIG_CPU_IDLE_GOV_MENU=y > -- > 2.25.1 > In message: [yocto-kernel-cache][yocto-5.15][PATCH 2/3] nxp-imx7: Delete duplicated config on 01/12/2022 Xiaolei Wang wrote: > Delete CONFIG_HIGHMEM and CONFIG_BACKLIGHT_PWM. > > Signed-off-by: Xiaolei Wang > --- > bsp/nxp-imx7/nxp-imx7.cfg | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/bsp/nxp-imx7/nxp-imx7.cfg b/bsp/nxp-imx7/nxp-imx7.cfg > index 308c5c32..db1b1944 100644 > --- a/bsp/nxp-imx7/nxp-imx7.cfg > +++ b/bsp/nxp-imx7/nxp-imx7.cfg > @@ -1,7 +1,6 @@ > CONFIG_ARCH_MXC=y > CONFIG_SOC_IMX7D=y > CONFIG_HAVE_ARM_ARCH_TIMER=y > -CONFIG_HIGHMEM=y > > CONFIG_SMP=y > CONFIG_VMSPLIT_2G=y > @@ -153,8 +152,6 @@ CONFIG_FB_MXC=y > CONFIG_FB_MXC_EDID=y > CONFIG_FB_MXS_SII902X=y > > -CONFIG_BACKLIGHT_PWM=y > - > CONFIG_FRAMEBUFFER_CONSOLE=y > CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y > > -- > 2.25.1 > In message: [yocto-kernel-cache][yocto-5.15][PATCH 3/3] nxp-imx7: Enable CONFIG_NOP_USB_XCEIV config on 01/12/2022 Xiaolei Wang wrote: > Enable CONFIG_NOP_USB_XCEIV config for nxp-imx7. > > Signed-off-by: Xiaolei Wang > --- > bsp/nxp-imx7/nxp-imx7.cfg | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/bsp/nxp-imx7/nxp-imx7.cfg b/bsp/nxp-imx7/nxp-imx7.cfg > index db1b1944..743acd76 100644 > --- a/bsp/nxp-imx7/nxp-imx7.cfg > +++ b/bsp/nxp-imx7/nxp-imx7.cfg > @@ -167,6 +167,7 @@ CONFIG_USB_ZERO=m > CONFIG_USB_ETH=m > CONFIG_USB_MASS_STORAGE=m > CONFIG_USB_G_SERIAL=m > +CONFIG_NOP_USB_XCEIV=y > > CONFIG_MMC=y > CONFIG_MMC_SDHCI=y > -- > 2.25.1 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11987): https://lists.yoctoproject.org/g/linux-yocto/message/11987 Mute This Topic: https://lists.yoctoproject.org/mt/95393689/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [yocto-kernel-cache]: bcm-2xxx-rpi: bcm-2xxx-rpi: enable kernel config ARCH_BCM for raspberry pi platform
In message: [yocto-kernel-cache]: bcm-2xxx-rpi: bcm-2xxx-rpi: enable kernel config ARCH_BCM for raspberry pi platform on 01/12/2022 Meng Li wrote: > From: Limeng > > Hi Bruce, > > Could you please help to merge this patch into yocto-kernel-cache, branch is > only master? merged to master. Bruce > > diffstat info ad below: > > bcm-2xxx-rpi.cfg |1 + > 1 file changed, 1 insertion(+) > > > thanks, > Limeng -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11986): https://lists.yoctoproject.org/g/linux-yocto/message/11986 Mute This Topic: https://lists.yoctoproject.org/mt/95374937/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [linux-yocto preempt-rt kernel v5.15]: nxp-s32g: update to align with NXP SDK BSP35 RC7
In message: [linux-yocto] [linux-yocto preempt-rt kernel v5.15]: nxp-s32g: update to align with NXP SDK BSP35 RC7 on 30/11/2022 Zhantao Tang wrote: > Hi Bruce, > > > There are 13 new patches from bsp35 internal share repo, would you please > help to > merge the patches into branch v5.15/standard/preempt-rt/nxp-sdk-5.10/nxp-s32g? > > > The patch infos as following: > > The following changes since commit 86387aca4861926ef4e21dafd461b2868741ed55: > > Merge branch 'v5.15/standard/base' into > v5.15/standard/preempt-rt/nxp-sdk-5.10/nxp-s32g (2022-11-28 14:32:03 -0500) > > are available in the Git repository at: > > https://github.com/zhantaotang/linux-yocto-std > v5.15/standard/preempt-rt/nxp-sdk-5.10/nxp-s32g merged. Bruce > > for you to fetch changes up to c23922ec8c218fd75a1855b575e8018c0ea9f67f: > > dts: s32gen1: Enable frequency scaling for A53 (2022-11-29 16:14:27 +0800) > > > Thanks, > Zhantao -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11985): https://lists.yoctoproject.org/g/linux-yocto/message/11985 Mute This Topic: https://lists.yoctoproject.org/mt/95353245/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [linux-yocto std kernel v5.15]: nxp-s32g: update to align with NXP SDK BSP35 RC7
In message: [linux-yocto] [linux-yocto std kernel v5.15]: nxp-s32g: update to align with NXP SDK BSP35 RC7 on 30/11/2022 Zhantao Tang wrote: > Hi Bruce, > > > There are 13 new patches from NXP SDK bsp35 internal share repo, would you > please help to merge the patches > into the v5.15/standard/nxp-sdk-5.10/nxp-s32g branch? > > > The patches info as following: > > The following changes since commit 6d764634466370804eec9d9e90f045c6c105f583: > > Merge branch 'v5.15/standard/base' into > v5.15/standard/nxp-sdk-5.10/nxp-s32g (2022-11-28 14:31:49 -0500) > > are available in the Git repository at: > > https://github.com/zhantaotang/linux-yocto-std > v5.15/standard/nxp-sdk-5.10/nxp-s32g merged. Bruce > > for you to fetch changes up to 151f13a497bfdd118fc12bd5779b63a4edbd1a19: > > dts: s32gen1: Enable frequency scaling for A53 (2022-11-29 16:10:51 +0800) > > > Thanks, > Zhantao -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11984): https://lists.yoctoproject.org/g/linux-yocto/message/11984 Mute This Topic: https://lists.yoctoproject.org/mt/95353244/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [yocto-kernel-cache yocto-5.15]: nxp-s32g: enable SCMI based cpufreq
In message: [linux-yocto] [yocto-kernel-cache yocto-5.15]: nxp-s32g: enable SCMI based cpufreq on 30/11/2022 Zhantao Tang wrote: > > Hi Bruce, > > There is an patch of yocto-kernel-cache to update kernel configs for nxp-s32g > bsp, > Would you please help to merge this patch into yocto-kernel-cache, branch > yocto-5.15? merged. Bruce > > > Thanks, > Zhantao -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11983): https://lists.yoctoproject.org/g/linux-yocto/message/11983 Mute This Topic: https://lists.yoctoproject.org/mt/95353237/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
Do not bother... This is a war between me and the entire YOCTO
community of founders... It has been going for a while. Lot of INTEL
guys and former INTEL guys against former INTEL guy. Me.
But, I came here with Peace. It seems some people could not overcome their EGOs.
I am trying to ask for a brainstorming. Now, I am trying to
understand, why the backpors took place from kirkstone... Once my
scripts were working for hardknott...
But they do not work anymore.
Well...
Not my fault. Just trying to push forward.
Zee
___
On Thu, Dec 1, 2022 at 6:01 PM Alexander Kanavin wrote:
>
> On Thu, 1 Dec 2022 at 17:41, Rudolf J Streif wrote:
> >
> >
> > > Recently I've also seen this:
> > > LAYERSERIES_COMPAT_phytec = "${LAYERSERIES_COMPAT_core}"
> > >
> > Oh no, now the entire Yocto Project world knows about this hack. Now we
> > need a sanity checker for this in the insane class. :)
>
> It's a slippery slope. We can also for example make bitbake forcibly
> not expand any variables in it, and write out an angry rant when
> someone tries, and then I'm sure determined people will find a way
> around that too.
>
> Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58711): https://lists.yoctoproject.org/g/yocto/message/58711
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] Use my own custom kernel source in yocto #zeus
Greetings !
I am working on NXP's i.MX6UL SoC . I have built yocto successfully for the
same . I want to use to my own custom linux kernel source which is cloned in my
local PC in some specific directory (suppose in Desktop) , without using
default kernel source installed during the yocto compilation .
I tried adding the below lines in "local.conf" file but it is not working .
Please help me out to achieve the same.
BRANCH_pn-linux-imx += "v5.0"
SRC_URI_pn-linux-imx += "git:///${HOME}/Desktop/linux;branch=${BRANCH}"
SRCREV_pn-linux-imx += "${AUTOREV}"
Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58710): https://lists.yoctoproject.org/g/yocto/message/58710
Mute This Topic: https://lists.yoctoproject.org/mt/95387628/21656
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
On Thu, 1 Dec 2022 at 17:41, Rudolf J Streif wrote:
>
>
> > Recently I've also seen this:
> > LAYERSERIES_COMPAT_phytec = "${LAYERSERIES_COMPAT_core}"
> >
> Oh no, now the entire Yocto Project world knows about this hack. Now we
> need a sanity checker for this in the insane class. :)
It's a slippery slope. We can also for example make bitbake forcibly
not expand any variables in it, and write out an angry rant when
someone tries, and then I'm sure determined people will find a way
around that too.
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58709): https://lists.yoctoproject.org/g/yocto/message/58709
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
Recently I've also seen this:
LAYERSERIES_COMPAT_phytec = "${LAYERSERIES_COMPAT_core}"
Oh no, now the entire Yocto Project world knows about this hack. Now we
need a sanity checker for this in the insane class. :)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58708): https://lists.yoctoproject.org/g/yocto/message/58708
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Get target machine
Hi Iggy,
On 12/1/22 13:55, Iggy via lists.yoctoproject.org wrote:
Hi,
I have a .inc file that contains this information:
# Set the MACHINE string, expected to eventually replace the long list of
# build settings below
EXTRA_OECMAKE += "-DRDK_MACHINE=${@d.getVar('MACHINE', False)} "
# Set the region and platform type (defaults to Xi6 and UK)
EXTRA_OECMAKE_append_xione-uk = " -DRDK_PLATFORM=XI1 -DREGION=UK "
EXTRA_OECMAKE_append_xione-us = " -DRDK_PLATFORM=XI1 -DREGION=UK "
EXTRA_OECMAKE_append_llama-uk = " -DRDK_PLATFORM=LLAMA -DREGION=UK "
EXTRA_OECMAKE_append_llama-us = " -DRDK_PLATFORM=LLAMA -DREGION=UK "
I understand that the append lines add extra parameters to the make call. How
does Yocto know which platform to use? I mean how does it choose xione-uk or
llama-us for instance?
You are building for a specific machine (MACHINE in your local.conf or
via command line argument for example), so Yocto definitely knows it.
Then your machine configuration file (the one in the form of
.conf contains multiple MACHINEOVERRIDES in .inc files
which define "families" under which your machine could be matched.
Since MACHINEOVERRIDES is part of OVERRIDES variable which is used to
filter some variables "overrides", it'll just work (e.g.
EXTRA_OECMAKE_append_).
Hope this helps,
Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58707): https://lists.yoctoproject.org/g/yocto/message/58707
Mute This Topic: https://lists.yoctoproject.org/mt/95380576/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Add user to group that's created in other recipe
Hi all, Thanks for the pointers. I'm actually on kirkstone-4.0. I'll try the work-arounds. Best regards, Sven -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58706): https://lists.yoctoproject.org/g/yocto/message/58706 Mute This Topic: https://lists.yoctoproject.org/mt/95359282/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
Agreed. Will revert. Zee ___ On Thu, Dec 1, 2022 at 1:48 PM Ross Burton wrote: > > On 1 Dec 2022, at 12:46, Zoran Stojsavljevic > wrote: > > But, could you, please, allow me to have my own original cannelloni > > recipe (yes, I developed it with some help from this community) on my > > own terms? I DID not copy it from anywhere. It is an ORIGINAL. > > As I explained in the bug I filed in your repository, the LICENSE statement > is the license of the contents of the packages, not the recipe itself. > > https://github.com/mguentner/cannelloni clearly says GPLv2. > > Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58705): https://lists.yoctoproject.org/g/yocto/message/58705 Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Get target machine
Hi,
I have a .inc file that contains this information:
# Set the MACHINE string, expected to eventually replace the long list of
# build settings below
EXTRA_OECMAKE += "-DRDK_MACHINE=${@d.getVar('MACHINE', False)} "
# Set the region and platform type (defaults to Xi6 and UK)
EXTRA_OECMAKE_append_xione-uk = " -DRDK_PLATFORM=XI1 -DREGION=UK "
EXTRA_OECMAKE_append_xione-us = " -DRDK_PLATFORM=XI1 -DREGION=UK "
EXTRA_OECMAKE_append_llama-uk = " -DRDK_PLATFORM=LLAMA -DREGION=UK "
EXTRA_OECMAKE_append_llama-us = " -DRDK_PLATFORM=LLAMA -DREGION=UK "
I understand that the append lines add extra parameters to the make call. How
does Yocto know which platform to use? I mean how does it choose xione-uk or
llama-us for instance?
Plus is there a variable that captures the target name, i.e. "xione-uk",
"xione-us", etc?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58704): https://lists.yoctoproject.org/g/yocto/message/58704
Mute This Topic: https://lists.yoctoproject.org/mt/95380576/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
On 1 Dec 2022, at 12:46, Zoran Stojsavljevic wrote: > But, could you, please, allow me to have my own original cannelloni > recipe (yes, I developed it with some help from this community) on my > own terms? I DID not copy it from anywhere. It is an ORIGINAL. As I explained in the bug I filed in your repository, the LICENSE statement is the license of the contents of the packages, not the recipe itself. https://github.com/mguentner/cannelloni clearly says GPLv2. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58703): https://lists.yoctoproject.org/g/yocto/message/58703 Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
Martin, U R too fast. Speedy Gonzales. ;-) I do agree that this is the bad practice to change licences for the known recipes. For the can-utils and socketcand. I'll revert this back to GPLv2. But, could you, please, allow me to have my own original cannelloni recipe (yes, I developed it with some help from this community) on my own terms? I DID not copy it from anywhere. It is an ORIGINAL. Please, check. Do NOT overspeed. Please. Thank you for your advice. Zee ___ On Thu, Dec 1, 2022 at 12:18 PM Martin Jansa wrote: > > On Thu, Dec 1, 2022 at 12:09 PM Ross Burton wrote: >> >> On 1 Dec 2022, at 04:27, Zoran via lists.yoctoproject.org >> wrote: >> > I do not understand why we need to explicitly name releases for such >> > simple generic layers?! >> >> The compatibility is because over time things change: override syntax has >> changed, classes get added or removed, functionality may appear in bitbake. >> Sometimes the breakage is subtle, and a layer may parse and appear to build >> fine, but be broken. >> >> Your meta-socketcan layer is broken in honister onwards despite claiming >> compatibility, for example. > > > And here is another example why nobody should be using meta-socketcan: > https://github.com/ZoranStojsavljevic/meta-socketcan/commit/cefd86cd1def9ad2e63be527f8ce36a076d7e17c# > > You cannot change the declared LICENSE of the components, just because you > wish them to use the same license as the layer metadata, especially when > those components clearly declare different LICENSE in the source code, e.g.: > https://github.com/linux-can/socketcand/commit/a7ab9878d11ac187b92dcf48b6331c228f4f4b92 > > Using COMMON_LICENSE_DIR in LIC_FILES_CHKSUM is another anti-pattern which > just disables whole purpose of LIC_FILES_CHKSUM and this is acceptable only > for "pure-metadata" recipes like packagegroups or image recipes. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58702): https://lists.yoctoproject.org/g/yocto/message/58702 Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
Ross,
It is now broken even in hardknott. I tried it, just as I tried it
before (it worked before).
I have no idea what the ERROR is:
zoran.s@NBK0005U:~/projects2/yocto/bbb-yocto/build$ bitbake -k
core-image-minimal
Loading cache: 100% |
| ETA:
--:--:--
Loaded 0 entries from dependency cache.
Parsing recipes: 100%
|#|
Time: 0:00:23
Parsing of 814 .bb files complete (0 cached, 814 parsed). 1438
targets, 41 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'cannelloni' (but
/home/zoran.s/projects2/yocto/bbb-yocto/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'cannelloni' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['cannelloni']
ERROR: Nothing RPROVIDES 'can-utils' (but
/home/zoran.s/projects2/yocto/bbb-yocto/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'can-utils' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['can-utils']
ERROR: Nothing RPROVIDES 'socketcand' (but
/home/zoran.s/projects2/yocto/bbb-yocto/poky/meta/recipes-core/images/core-image-minimal.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'socketcand' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['socketcand']
ERROR: Nothing RPROVIDES 'core-image-minimal'
No eligible RPROVIDERs exist for 'core-image-minimal'
NOTE: Runtime target 'core-image-minimal' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['core-image-minimal']
And my
/home/zoran.s/projects2/yocto/bbb-yocto/poky/meta/recipes-core/images/core-image-minimal.bb
is:
SUMMARY = "A small image just capable of allowing a device to boot."
IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"
IMAGE_LINGUAS = " "
LICENSE = "MIT"
nano meta/recipes-core/images/core-image-minimal.bb
## IMAGE_INSTALL_append = " kernel-modules"
IMAGE_INSTALL_append = " \
kernel-modules \
cannelloni \
can-utils \
socketcand \
"
IMAGE_ROOTFS_SIZE ?= "8192"
IMAGE_ROOTFS_EXTRA_SPACE_append =
"${@bb.utils.contains("DISTRO_FEATURES", "systemd", " + 4096", ""
,d)}"
Zee
On Thu, Dec 1, 2022 at 12:09 PM Ross Burton wrote:
>
> On 1 Dec 2022, at 04:27, Zoran via lists.yoctoproject.org
> wrote:
> > I do not understand why we need to explicitly name releases for such
> > simple generic layers?!
>
> The compatibility is because over time things change: override syntax has
> changed, classes get added or removed, functionality may appear in bitbake.
> Sometimes the breakage is subtle, and a layer may parse and appear to build
> fine, but be broken.
>
> Your meta-socketcan layer is broken in honister onwards despite claiming
> compatibility, for example.
>
> Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58701): https://lists.yoctoproject.org/g/yocto/message/58701
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
On Thu, Dec 1, 2022 at 12:09 PM Ross Burton wrote: > On 1 Dec 2022, at 04:27, Zoran via lists.yoctoproject.org > wrote: > > I do not understand why we need to explicitly name releases for such > > simple generic layers?! > > The compatibility is because over time things change: override syntax has > changed, classes get added or removed, functionality may appear in > bitbake. Sometimes the breakage is subtle, and a layer may parse and > appear to build fine, but be broken. > > Your meta-socketcan layer is broken in honister onwards despite claiming > compatibility, for example. > And here is another example why nobody should be using meta-socketcan: https://github.com/ZoranStojsavljevic/meta-socketcan/commit/cefd86cd1def9ad2e63be527f8ce36a076d7e17c# You cannot change the declared LICENSE of the components, just because you wish them to use the same license as the layer metadata, especially when those components clearly declare different LICENSE in the source code, e.g.: https://github.com/linux-can/socketcand/commit/a7ab9878d11ac187b92dcf48b6331c228f4f4b92 Using COMMON_LICENSE_DIR in LIC_FILES_CHKSUM is another anti-pattern which just disables whole purpose of LIC_FILES_CHKSUM and this is acceptable only for "pure-metadata" recipes like packagegroups or image recipes. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58700): https://lists.yoctoproject.org/g/yocto/message/58700 Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
On 1 Dec 2022, at 04:27, Zoran via lists.yoctoproject.org wrote: > I do not understand why we need to explicitly name releases for such > simple generic layers?! The compatibility is because over time things change: override syntax has changed, classes get added or removed, functionality may appear in bitbake. Sometimes the breakage is subtle, and a layer may parse and appear to build fine, but be broken. Your meta-socketcan layer is broken in honister onwards despite claiming compatibility, for example. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58699): https://lists.yoctoproject.org/g/yocto/message/58699 Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
On Thu, 2022-12-01 at 11:09 +0100, Alexander Kanavin wrote: > And this is the commit that did this: > https://git.phytec.de/meta-phytec/commit/conf/layer.conf?id=8261e896d2b43211e7377feb38e919336d47c39f > > Shame on you, phytec. Shame on you. What you do in your layers perhaps > doesn't matter so much, but you also give everyone a bad example to > follow. That commit really is not in the spirit of things and I'm not happy people are doing that. I'd not be surprised if that stopped working soon. We had a huge problem with unmaintained layers where it was unclear which releases a master branch worked or had been tested with. An actively maintained layer should have no problem with updating this a couple of times a year. If that is an issue, it isn't actively maintained and it makes that clear. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58698): https://lists.yoctoproject.org/g/yocto/message/58698 Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [Openembedded-architecture] Y2038 proposal
On Thu, 2022-12-01 at 11:27 +0100, Alexander Kanavin wrote:
> On Wed, 30 Nov 2022 at 14:15, Richard Purdie
> wrote:
> > * We need to have a 32 bit ptest run on the autobuilder (qemux86 should
> > work, not sure we can make qemuarm fast). Whether this is manually
> > triggered, not sure. We could have a smaller set of ptests to run for
> > it?
>
> I just ran qemux86 full ptest locally. It took 4h:10m (same as
> qemuarm64 ptest on an arm worker). The fails were:
>
> {'python3': ['test_deterministic_sets'],
> 'valgrind': ['gdbserver_tests/hgtls',
> 'gdbserver_tests/mcblocklistsearch',
> 'gdbserver_tests/mcbreak',
> 'gdbserver_tests/mcclean_after_fork',
> 'gdbserver_tests/mchelp',
> 'gdbserver_tests/mcinfcallRU',
> 'gdbserver_tests/mcinfcallWSRU',
> 'gdbserver_tests/mcinvokeRU',
> 'gdbserver_tests/mcinvokeWS',
> 'gdbserver_tests/mcleak',
> 'gdbserver_tests/mcmain_pic',
> 'gdbserver_tests/mcsignopass',
> 'gdbserver_tests/mcsigpass',
> 'gdbserver_tests/mcvabits',
> 'gdbserver_tests/mcwatchpoints',
> 'gdbserver_tests/mssnapshot',
> 'gdbserver_tests/nlcontrolc',
> 'gdbserver_tests/nlgone_abrt',
> 'gdbserver_tests/nlgone_exit',
> 'gdbserver_tests/nlgone_return',
> 'gdbserver_tests/nlpasssigalrm',
> 'gdbserver_tests/nlsigvgdb',
> 'gdbserver_tests/nlvgdbsigqueue',
> 'memcheck/tests/linux/memfd_create',
> 'memcheck/tests/linux/timerfd-syscall',
> 'memcheck/tests/origin5-bz2',
> 'massif/tests/mmapunmap']}
>
> So I think we could as well fix these, and add full qemux86 ptest to
> a-full? It is not heavy on the builder machine (mostly just runs a
> single qemu thread), it's just long.
I think we should fix those and we should add the target to the
autobuilder but I'm reluctant to add a long test to a-full. The fact it
is relatively clean suggests it doesn't regress that often. We could do
something like a once a month trigger for it?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58697): https://lists.yoctoproject.org/g/yocto/message/58697
Mute This Topic: https://lists.yoctoproject.org/mt/95357215/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [Openembedded-architecture] Y2038 proposal
On Wed, 30 Nov 2022 at 14:15, Richard Purdie
wrote:
> * We need to have a 32 bit ptest run on the autobuilder (qemux86 should
> work, not sure we can make qemuarm fast). Whether this is manually
> triggered, not sure. We could have a smaller set of ptests to run for
> it?
I just ran qemux86 full ptest locally. It took 4h:10m (same as
qemuarm64 ptest on an arm worker). The fails were:
{'python3': ['test_deterministic_sets'],
'valgrind': ['gdbserver_tests/hgtls',
'gdbserver_tests/mcblocklistsearch',
'gdbserver_tests/mcbreak',
'gdbserver_tests/mcclean_after_fork',
'gdbserver_tests/mchelp',
'gdbserver_tests/mcinfcallRU',
'gdbserver_tests/mcinfcallWSRU',
'gdbserver_tests/mcinvokeRU',
'gdbserver_tests/mcinvokeWS',
'gdbserver_tests/mcleak',
'gdbserver_tests/mcmain_pic',
'gdbserver_tests/mcsignopass',
'gdbserver_tests/mcsigpass',
'gdbserver_tests/mcvabits',
'gdbserver_tests/mcwatchpoints',
'gdbserver_tests/mssnapshot',
'gdbserver_tests/nlcontrolc',
'gdbserver_tests/nlgone_abrt',
'gdbserver_tests/nlgone_exit',
'gdbserver_tests/nlgone_return',
'gdbserver_tests/nlpasssigalrm',
'gdbserver_tests/nlsigvgdb',
'gdbserver_tests/nlvgdbsigqueue',
'memcheck/tests/linux/memfd_create',
'memcheck/tests/linux/timerfd-syscall',
'memcheck/tests/origin5-bz2',
'massif/tests/mmapunmap']}
So I think we could as well fix these, and add full qemux86 ptest to
a-full? It is not heavy on the builder machine (mostly just runs a
single qemu thread), it's just long.
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58696): https://lists.yoctoproject.org/g/yocto/message/58696
Mute This Topic: https://lists.yoctoproject.org/mt/95357215/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Add user to group that's created in other recipe
On Thu, 1 Dec 2022 at 08:51, Martin Jansa wrote: > >> I think there are some open bugs for useradd issues like this. It is >> supposed to work but sounds like there are races. If there isn't a bug >> open for it, there probably should be. > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13904 is one of the bugs I > think. This is another: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13419 Workarounds are not difficult, but the issue occurring for the first time must be very disorienting. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58695): https://lists.yoctoproject.org/g/yocto/message/58695 Mute This Topic: https://lists.yoctoproject.org/mt/95359282/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] LAYERSERIES_COMPAT_ variable in the layer's recipe
And this is the commit that did this:
https://git.phytec.de/meta-phytec/commit/conf/layer.conf?id=8261e896d2b43211e7377feb38e919336d47c39f
Shame on you, phytec. Shame on you. What you do in your layers perhaps
doesn't matter so much, but you also give everyone a bad example to
follow.
Alex
On Thu, 1 Dec 2022 at 08:47, Martin Jansa wrote:
>
> Agreed with Rudolf.
>
> If the layer maintainer didn't bother to do at least do one build with new
> release and adjust LAYERSERIES_COMPAT, then I don't consider that layer well
> maintained (it could be someone else who uses the layer, tests it with new
> release and sends PR to adjust LAYERSERIES_COMPAT).
>
> Recently I've also seen this:
> LAYERSERIES_COMPAT_phytec = "${LAYERSERIES_COMPAT_core}"
>
> which is also bad as it completely disables the check (seen in
> https://git.phytec.de/meta-phytec/tree/conf/layer.conf#n14).
>
> On Thu, Dec 1, 2022 at 7:06 AM Rudolf J Streif
> wrote:
>>
>>
>>
>> On Wed, Nov 30, 2022, 20:27 Zoran wrote:
>>>
>>> Hello to Yocto community,
>>>
>>> As I am much more passive yocto wise these few years ( working on
>>> Android build systems and around, this is also a nightmare, I should
>>> say ;-) ), I have one Yocto question which I never really understood.
>>>
>>> I will ask it by example. I have one layer for the CAN tools and apps
>>> which I have created 4 years ago:
>>> https://github.com/ZoranStojsavljevic/meta-socketcan
>>>
>>> In there, in conf/layer.conf:
>>> https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/conf/layer.conf
>>>
>>> I have the following line (layers' compatibility):
>>> LAYERSERIES_COMPAT_meta-socketcan = "sumo thud warrior zeus dunfell
>>> gatesgarth hardknott honister kirkstone"
>>>
>>> I do not understand why we need to explicitly name releases for such
>>> simple generic layers?!
>>
>>
>> To me this indicates that the maintainer of the layer has tested the
>> compatibility of his layer with all of these releases of the Yocto Project.
>>
>> A maintainer of a layer should make a deliberate decision of adding a
>> release or dropping one from the compatibility list. It should be an
>> attestation that the layer's compatibility with the releases in the list is
>> actually maintained and tested.
>>
>> There have been changes to the syntax to conditional variables. Your layer
>> might well be compatible with all of the releases and it's great if you
>> tested it. But it's not a given.
>>>
>>>
>>> Instead, for a virtual example:
>>> LAYERSERIES_COMPAT_meta-socketcan = "${AUTOLAYER x}"
>>>
>>> So all the layers might be included (or for at least lets say x = 4
>>> latest releases, where x = 0 would be include all)? I do understand
>>> that complex layers could NOT have such a definition (because of the
>>> dependencies), but for the generic layers (as such presented), this
>>> would be beneficial.
>>
>>
>> I never cared for ${AUTOREV}, which is similar, in the first place for the
>> very reason that it creates inconsistent behavior. This would do the same
>> thing. What would the last 4 releases even mean? What is the reference and
>> where is it obtained from?
>>>
>>>
>>> Thank you for the answers,
>>> Zee
>>>
>>> ___
>>
>>
>> Best,
>> :rjs
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58694): https://lists.yoctoproject.org/g/yocto/message/58694
Mute This Topic: https://lists.yoctoproject.org/mt/95375670/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Y2038 proposal
Hi Alexander, > On Wed, 30 Nov 2022 at 09:28, Lukasz Majewski wrote: > > 2. There are ptest available [2] to validate if the Y2038 problem > > works correctly. > > > > 3. Support for running ptests mentioned in point 2. is already > > available in the poky repository [3]. > > I just ran these tests in (32 bit) qemux86 on top of poky master (e.g. > no magic glibc flags), and they all passed. Do they need to be ran > after setting the date to the 'post-2038 future' to reveal the issues > and produce failures? Yes. You need to run them with adjusted date: date +'%Y-%m-%d %T' -s "2038-01-19 03:14:07" ptest-runner glibc-tests More info: https://github.com/lmajewski/meta-y2038/blob/master/README#L201 > > Alex Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpZZ7nYE2u3S.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58693): https://lists.yoctoproject.org/g/yocto/message/58693 Mute This Topic: https://lists.yoctoproject.org/mt/95354041/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
