[yocto] pseudo issue in kirkstone

2022-11-21 Thread Marek Belisko 
Hi,

I have a class where I create a custom image with cryptsetup and for
that purpose I'm using sudo. AFAIK using sudo in image creation should
be OK as it runs in pseudo. sudo calls works fine in dunfell releases
but while on kirkstone I'm getting:

| sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"
| sudo: /usr/lib/sudo/sudoers.so must be owned by uid 0
| sudo: fatal error, unable to load plugins

Is there any workaround available or it's a pseudo issue?

Thanks and BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58615): https://lists.yoctoproject.org/g/yocto/message/58615
Mute This Topic: https://lists.yoctoproject.org/mt/95191553/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [linux-yocto v5.15 v2] tgpio: Fix compilation errors for PSE TGPIO

2022-11-21 Thread Kevin Hao 
From: Hao Li 

commit f02a736e8a95690894cac88cda7dc3d8f22babb6 from
https://github.com/intel/linux-intel-lts.git

Signed-off-by: Hao Li 
Signed-off-by: Kevin Hao 
---
Hi Bruce,

Please help me merge this into the following two branches:
  v5.15/standard/preempt-rt/x86
  v5.15/standard/x86


v2: Cherry-pick the fix patch from SDK kernel.

 drivers/gpio/gpio-ehl-pse-plat.c | 8 
 drivers/mfd/intel-ehl-gpio.c | 6 ++
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpio/gpio-ehl-pse-plat.c b/drivers/gpio/gpio-ehl-pse-plat.c
index 514a726a8cef..dd47f9efe369 100644
--- a/drivers/gpio/gpio-ehl-pse-plat.c
+++ b/drivers/gpio/gpio-ehl-pse-plat.c
@@ -169,10 +169,11 @@ static int ehl_pse_gpio_get_direction(struct gpio_chip 
*chip,
 {
struct ehl_pse_gpio *priv = gpiochip_get_data(chip);
int direction = 0;
+   u32 reg_gpdr;
 
pm_runtime_get_sync(priv->dev->parent);
 
-   u32 reg_gpdr = intel_gpio_readl(priv->reg_base, GPDR);
+   reg_gpdr = intel_gpio_readl(priv->reg_base, GPDR);
 
direction = !(reg_gpdr & BIT(offset));
 
@@ -362,7 +363,6 @@ static int ehl_pse_gpio_probe(struct platform_device *pdev)
struct ehl_pse_gpio *priv;
struct resource *res;
u32 irq;
-   void __iomem *base;
int ret;
 
priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
@@ -375,11 +375,11 @@ static int ehl_pse_gpio_probe(struct platform_device 
*pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
-   return NULL;
+   return -EINVAL;
 
irq = platform_get_irq(pdev, 0);
if (irq < 0)
-   return NULL;
+   return irq ? irq : -EINVAL;
 
priv->dev = >dev;
priv->reg_base = devm_ioremap_resource(>dev, res);
diff --git a/drivers/mfd/intel-ehl-gpio.c b/drivers/mfd/intel-ehl-gpio.c
index 6aa5a6cfc9ad..e0c248337635 100644
--- a/drivers/mfd/intel-ehl-gpio.c
+++ b/drivers/mfd/intel-ehl-gpio.c
@@ -132,7 +132,6 @@ static int intel_ehl_pse_gpio_mfd_suspend(struct device 
*dev)
 {
struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
struct intel_ehl_pse_gpio_data  *pdata = pci_get_drvdata(pdev);
-   int i = 0;
u32 d0i3c_reg, cgsr_reg = 0;
 
d0i3c_reg = readl(pdata->priv + PSE_GPIO_D0I3C);
@@ -181,7 +180,6 @@ static int intel_ehl_pse_gpio_mfd_runtime_suspend(struct 
device *dev)
 {
struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
struct intel_ehl_pse_gpio_data  *pdata = pci_get_drvdata(pdev);
-   int i = 0;
u32 d0i3c_reg, cgsr_reg = 0;
 
d0i3c_reg = readl(pdata->priv + PSE_GPIO_D0I3C);
@@ -233,8 +231,8 @@ static const struct dev_pm_ops 
intel_ehl_pse_gpio_mfd_pm_ops = {
 };
 
 static const struct pci_device_id intel_ehl_pse_gpio_mfd_ids[] = {
-   { PCI_VDEVICE(INTEL, 0x4b88), NULL},
-   { PCI_VDEVICE(INTEL, 0x4b89), NULL},
+   { PCI_VDEVICE(INTEL, 0x4b88), },
+   { PCI_VDEVICE(INTEL, 0x4b89), },
{ },
 };
 MODULE_DEVICE_TABLE(pci, intel_ehl_pse_gpio_mfd_ids);
-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11934): 
https://lists.yoctoproject.org/g/linux-yocto/message/11934
Mute This Topic: https://lists.yoctoproject.org/mt/95189605/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 0/4] Fix the build errors for intel-ehl-gpio driver

2022-11-21 Thread Kevin Hao 
On Mon, Nov 21, 2022 at 11:05:36AM -0500, Bruce Ashfield wrote:
> On Mon, Nov 21, 2022 at 8:09 AM Kevin Hao  wrote:
> >
> > From: Kevin Hao 
> >
> > Hi Bruce,
> >
> > This patch series fixes serveal build errors when intel-ehl-gpio driver
> > is enabled. Please help merge them into the following two branches:
> >   v5.15/standard/preempt-rt/x86
> >   v5.15/standard/x86
> 
> Thanks Kevin.
> 
> Quick question.  I recall that the drivers in question came from an
> intel SDK (correct me if I'm wrong).

Yes.

> 
> Did we introduce the breakage in a -stable merge ?

No.

> or is this
> something that can also be sent to the upstream SDK for fixing there
> as well ?

I managed to forget to check the SDK git tree for a fix. It seems there
already have been a patch for these build issues. So please ignore this
patch series and I will send a v2 to backport that fix.

Thanks,
Kevin


signature.asc
Description: PGP signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11933): 
https://lists.yoctoproject.org/g/linux-yocto/message/11933
Mute This Topic: https://lists.yoctoproject.org/mt/95171186/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] M+ & H bugs with Milestone Movements WW47

2022-11-21 Thread Stephen Jolley 
All,

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


Priority

Bug ID

Short Description

Changer

Owner

Was

Became


Medium+

  14896

Current autobuilder code incompatible with buildbot 3.5.0

richard.pur...@linuxfoundation.org

richard.pur...@linuxfoundation.org

4.2

4.2 M3

Thanks, 

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com  

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58614): https://lists.yoctoproject.org/g/yocto/message/58614
Mute This Topic: https://lists.yoctoproject.org/mt/95184039/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Enhancements/Bugs closed WW47!

2022-11-21 Thread Stephen Jolley 
All,

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


Who

Count


randy.macl...@windriver.com

2


ross.bur...@arm.com

2


sundeep.kokko...@gmail.com

1


wei.qing...@gmail.com

1


pa...@zhukoff.net

1


Grand Total

7

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58613): https://lists.yoctoproject.org/g/yocto/message/58613
Mute This Topic: https://lists.yoctoproject.org/mt/95184026/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Current high bug count owners for Yocto Project 4.2

2022-11-21 Thread Stephen Jolley 
All,

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


Who

Count


michael.opdenac...@bootlin.com

35


ross.bur...@arm.com

32


randy.macl...@windriver.com

26


bruce.ashfi...@gmail.com

24


david.re...@windriver.com

23


richard.pur...@linuxfoundation.org

22


sakib.sa...@windriver.com

11


jpewhac...@gmail.com

10


saul.w...@windriver.com

9


zheng@windriver.com

4


sundeep.kokko...@gmail.com

4


pa...@zhukoff.net

4


tim.orl...@konsulko.com

4


akuster...@gmail.com

2


s...@bigsur.com

2


jon.ma...@arm.com

2


naveen.go...@windriver.com

2


aeh...@gmail.com

2


hongxu@windriver.com

2


rybczyn...@gmail.com

1


ptsne...@gmail.com

1


tvgamb...@gmail.com

1


sundeep.kokko...@windriver.com

1


thomas.per...@bootlin.com

1


qi.c...@windriver.com

1


hummerbl...@gmail.com

1


alexandre.bell...@bootlin.com

1


anton.anto...@arm.com

1


martin.ja...@gmail.com

1


martin.bee...@online.de

1


mhalst...@linuxfoundation.org

1


Grand Total

232

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58612): https://lists.yoctoproject.org/g/yocto/message/58612
Mute This Topic: https://lists.yoctoproject.org/mt/95183978/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2022-11-21 Thread Stephen Jolley 
All,

 

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

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

https://bugzilla.yoctoproject.org/createaccount.cgi

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58611): https://lists.yoctoproject.org/g/yocto/message/58611
Mute This Topic: https://lists.yoctoproject.org/mt/95183956/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] build 2 sdk toolchain

2022-11-21 Thread Johann Obermayr via lists.yoctoproject.org 
Hello,

build mingw sdk get follow error:

configure: error: linux/capability.h is required in order to build libcap-ng

$ SDKMACHINE=x86_64-mingw” bitbake my-image -c populate_sdk

We use kernel 5.15
Any idea ?

Best regards
  Johann

> -Ursprüngliche Nachricht-
> Von: Alexander Kanavin 
> Gesendet: Dienstag, 15. November 2022 13:06
> An: Johann Obermayr 
> Cc: yocto@lists.yoctoproject.org
> Betreff: Re: [yocto] build 2 sdk toolchain
> 
> CAUTION: External E-Mail !
> 
> This is the correct way, yes. You can put SDKMACHINE into local.conf (default
> is 'linux sdk'), or you can specify it on command line (in which case it will
> override the local.conf setting).
> 
> Alex
> 
> On Tue, 15 Nov 2022 at 13:02, Johann Obermayr via lists.yoctoproject.org
>  wrote:
> >
> > Hello,
> >
> >
> >
> > we use kirkstone.
> >
> > We will build
> >
> > Image
> > Toolchain for linux
> > Toolchain for windows
> >
> >
> >
> > Now we can build a image + linux sdk toolchain.
> >
> > That work correct.
> >
> >
> >
> > $ bitbake my-image
> >
> > $ bitbake my-image -c populate_sdk
> >
> >
> >
> > Now we will build a Toolchain for windows
> >
> > We have add meta-mingw
> >
> >
> >
> > $ SDKMACHINE=x86_64-mingw” bitbake my-image -c populate_sdk
> >
> >
> >
> > Is this the correct way ?
> >
> > Or what is a better solution for this.
> >
> >
> >
> > Best regards
> >
> >   Johann
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58610): https://lists.yoctoproject.org/g/yocto/message/58610
Mute This Topic: https://lists.yoctoproject.org/mt/95040911/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] rockchip-defaults: remove xf86-input-keyboard

2022-11-21 Thread Trevor Woerner 
On Sat 2022-11-19 @ 08:45:18 AM, Trevor Woerner via lists.yoctoproject.org 
wrote:
> xf86-input-keyboard was removed from openembedded-core at its commit:
> f1d7c33b64 (xf86-input-keyboard: remove the recipe, 2022-07-20). Therefore
> remove it from the XSERVER definition.
> 
> Signed-off-by: Trevor Woerner 
> ---
>  conf/machine/include/rockchip-defaults.inc | 1 -
>  1 file changed, 1 deletion(-)

Applied to meta-rockchip master (with Quentin's Reviewed-by).
Thanks!

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58609): https://lists.yoctoproject.org/g/yocto/message/58609
Mute This Topic: https://lists.yoctoproject.org/mt/95132799/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [PATCH][meta-rockchip][master][kirkstone][honister] rockchip.wic.inc: let wic update fstab again

2022-11-21 Thread Trevor Woerner 
On Wed 2022-11-09 @ 02:24:05 PM, Quentin Schulz wrote:
> From: Quentin Schulz 
> 
> The commit ed3a97f7b2e4 ("rockchip-wic.inc: don't let wic edit fstab")
> removing this ability was introduced to fix an issue in the wic tool in
> OE-Core in which wic partitions whose "mountpoint" is not a valid path
> are still added to fstab.
> This was eventually fixed in OE-Core in commit 7aa678ce804c
> ("wic:direct.py: ignore invalid mountpoints during fstab update") which
> is part of release Honister (3.4) and later.
> 
> Therefore, it should be safe to now let wic update fstab again for
> partitions with a valid mountpoint path. The benefit being that the wic
> partitions with a mountpoint are now automounted at boot.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
> restore fstab update by wic
> 
> Since wic now correctly handles partitions without a valid mountpoint path and
> does not add them to fstab, we can let wic update fstab again so let's do it.
> 
> This makes partition automounting work again.
> 
> This was tested on a Kirkstone (4.0.4) poky-based core-image-minimal on a
> PX30-uQ7 (Ringneck) SoM on Haikou devkit
> (https://git.theobroma-systems.com/yocto-layers/meta-theobroma-systems-bsp.git/)
> 
> This should be safe to backport to kirkstone and honister too.
> 
> Cc: Markus Volk 
> Cc: Trevor Woerner 
> ---
>  conf/machine/include/rockchip-wic.inc | 3 ---
>  1 file changed, 3 deletions(-)

Applied to meta-rockchip master, kirkstone, and honister.
Thanks!

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58608): https://lists.yoctoproject.org/g/yocto/message/58608
Mute This Topic: https://lists.yoctoproject.org/mt/94912272/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #kirkstone: boot script section not added in the fitimage

2022-11-21 Thread Quentin Schulz via lists.yoctoproject.org 

Hi Sébastien,

On 11/14/22 14:50, sebastien.fabr...@gmail.com wrote:

Hello,

I am working on kirkstone. If UBOOT_ENV is specified and kernel-fitimage is in 
KERNEL_CLASSES, boot script section is not added in the fitimage.

In fitimage_assemble (kernel-fitimage.bbclass), the 3 rd step is not performed 
because boot directory is not in STAGING_DIR_HOST. Indeed, u-boot.inc installs 
UBOOT_ENV_BINARY in boot directory but boot is not in SYSROOT_DIRS so it is not 
present in kernel STAGING_DIR_HOST.

Should we add the following line in u-boot.inc ?

SYSROOT_DIRS:append = "${@' /boot' if d.getVar('UBOOT_ENV') else ''}"



The logic seems reasonable to me, yes. We could have used the deploy 
directory instead and depend on the do_deploy task instead of the 
do_populate_sysroot but I think it is actually safer to use the sysroot 
(because it is cleaned if a dependency changes, as opposed to the deploy 
directory that might be providing an old version, e.g. think one build 
with UBOOT_ENV set followed by one it isn't, the deployed artifact will 
still be present).


Though, please use += instead of :append.

I'm wondering also if we cannot just always have /boot in SYSROOT_DIRS 
for U-Boot recipe? I guess it's fine like this :)


Please send a patch,
Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58607): https://lists.yoctoproject.org/g/yocto/message/58607
Mute This Topic: https://lists.yoctoproject.org/mt/95018923/21656
Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Apply Patching #dunfell #patch #yocto #raspberrypi #linux

2022-11-21 Thread Alexander Kanavin 
In this case I have no idea unfortunately. Does a regular kernel work?

Alex

On Mon 21. Nov 2022 at 16.38, Nikita Gupta 
wrote:

> Hello Alex,
> Sorry for late reply. Actually i madert- image by setting the preferred
> virtual/kernel type.
> PREFERRED_PROVIDER_virtual/kernel = "linux-raspberrypi-rt"
>
> and bake the recipe for following target.
> bitbake core-image-base
>
> I got my image successfully and it is booting up, but it is not taking
> user input from my keyboard. Why is it happening?
>
> Thanks in Advance
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58606): https://lists.yoctoproject.org/g/yocto/message/58606
Mute This Topic: https://lists.yoctoproject.org/mt/94645313/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Mute #patch:https://lists.yoctoproject.org/g/yocto/mutehashtag/patch
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #raspberrypi:https://lists.yoctoproject.org/g/yocto/mutehashtag/raspberrypi
Mute #linux:https://lists.yoctoproject.org/g/yocto/mutehashtag/linux
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Reproducible builds not working with musl?

2022-11-21 Thread Alexander Kanavin 
You have to find them yourself with gut bisect I would say. Too many things
have changed.

Alex

On Mon 21. Nov 2022 at 17.07, Kenth Eriksson 
wrote:

> I see. Any particular fixes you can point me to that may be relevant also
> for musl?
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58605): https://lists.yoctoproject.org/g/yocto/message/58605
Mute This Topic: https://lists.yoctoproject.org/mt/95172718/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Reproducible builds not working with musl?

2022-11-21 Thread Kenth Eriksson 
I see. Any particular fixes you can point me to that may be relevant also for 
musl?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58604): https://lists.yoctoproject.org/g/yocto/message/58604
Mute This Topic: https://lists.yoctoproject.org/mt/95172718/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [linux-yocto 0/4] Fix the build errors for intel-ehl-gpio driver

2022-11-21 Thread Bruce Ashfield 
On Mon, Nov 21, 2022 at 8:09 AM Kevin Hao  wrote:
>
> From: Kevin Hao 
>
> Hi Bruce,
>
> This patch series fixes serveal build errors when intel-ehl-gpio driver
> is enabled. Please help merge them into the following two branches:
>   v5.15/standard/preempt-rt/x86
>   v5.15/standard/x86

Thanks Kevin.

Quick question.  I recall that the drivers in question came from an
intel SDK (correct me if I'm wrong).

Did we introduce the breakage in a -stable merge ? or is this
something that can also be sent to the upstream SDK for fixing there
as well ?

Bruce



>
> Kevin Hao (4):
>   gpio: intel-ehl-gpio: Fix the declaration after statement error
>   gpio: intel-ehl-gpio: Fix the wrong return type in
> ehl_pse_gpio_probe()
>   mfd: intel-ehl-gpio: Drop the unused variables
>   mfd: intel-ehl-gpio: Fix the int conversion error
>
>  drivers/gpio/gpio-ehl-pse-plat.c | 8 
>  drivers/mfd/intel-ehl-gpio.c | 6 ++
>  2 files changed, 6 insertions(+), 8 deletions(-)
>
> --
> 2.38.1
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11932): 
https://lists.yoctoproject.org/g/linux-yocto/message/11932
Mute This Topic: https://lists.yoctoproject.org/mt/95171186/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Reproducible builds not working with musl?

2022-11-21 Thread Joshua Watt 


On 11/21/22 08:38, Alexander Kanavin wrote:

On Mon, 21 Nov 2022 at 15:31, Kenth Eriksson
 wrote:

Having trouble with reproducible builds in yocto on dunfell release with musl 
as libc. E.g. I can see that the build path for musl crti assembler file is 
leaking through and becomes visible when I do strings on libraries and binaries.

$ strings 
/opt/infn-xr/1.0/sysroots/aarch64-xr-linux-musl/usr/lib64/.debug/libcrypto.so.1.1
 | grep crt[a-z]\.o
/data/jenkins/workspace/XR_yocto-xr_master/build/build/infn-xr/gmcu/tmp/work/aarch64-xr-linux-musl/openssl/1.1.1l-r0/recipe-sysroot/usr/lib64/crti.o
/data/jenkins/workspace/XR_yocto-xr_master/build/build/infn-xr/gmcu/tmp/work/aarch64-xr-linux-musl/openssl/1.1.1l-r0/recipe-sysroot/usr/lib64/crtn.o
$

Is this a known issue? Yocto passes -fmacro-prefix-map and -fdebug-prefix-map 
as part of DEBUG_PREFIX_MAP to eliminate paths to WORKDIR. But it looks as that 
fails for the musl assembler file?

Testing reproducibility properly is a heavy exercise (you need to
build everything from scratch, then compare), and so we do it only for
glibc.

There have been recent fixes and tests to check that host paths do not
leak into target files, but dunfell probably has neither the fix nor
the test.


This is correct; it's hard for upstream to test every possible 
combination for reproducibility. We do try to get some decent coverage, 
but ultimately if you really care about reproducible builds, you should 
setup a reproducible build test for your exact combination. We've tried 
to make this pretty easy, see https://youtu.be/zXEdqGS62Wc?t=1021




Alex




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58602): https://lists.yoctoproject.org/g/yocto/message/58602
Mute This Topic: https://lists.yoctoproject.org/mt/95172718/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Reproducible builds not working with musl?

2022-11-21 Thread Alexander Kanavin 
On Mon, 21 Nov 2022 at 15:31, Kenth Eriksson
 wrote:
>
> Having trouble with reproducible builds in yocto on dunfell release with musl 
> as libc. E.g. I can see that the build path for musl crti assembler file is 
> leaking through and becomes visible when I do strings on libraries and 
> binaries.
>
> $ strings 
> /opt/infn-xr/1.0/sysroots/aarch64-xr-linux-musl/usr/lib64/.debug/libcrypto.so.1.1
>  | grep crt[a-z]\.o
> /data/jenkins/workspace/XR_yocto-xr_master/build/build/infn-xr/gmcu/tmp/work/aarch64-xr-linux-musl/openssl/1.1.1l-r0/recipe-sysroot/usr/lib64/crti.o
> /data/jenkins/workspace/XR_yocto-xr_master/build/build/infn-xr/gmcu/tmp/work/aarch64-xr-linux-musl/openssl/1.1.1l-r0/recipe-sysroot/usr/lib64/crtn.o
> $
>
> Is this a known issue? Yocto passes -fmacro-prefix-map and -fdebug-prefix-map 
> as part of DEBUG_PREFIX_MAP to eliminate paths to WORKDIR. But it looks as 
> that fails for the musl assembler file?

Testing reproducibility properly is a heavy exercise (you need to
build everything from scratch, then compare), and so we do it only for
glibc.

There have been recent fixes and tests to check that host paths do not
leak into target files, but dunfell probably has neither the fix nor
the test.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58601): https://lists.yoctoproject.org/g/yocto/message/58601
Mute This Topic: https://lists.yoctoproject.org/mt/95172718/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Reproducible builds not working with musl?

2022-11-21 Thread Kenth Eriksson 
Having trouble with reproducible builds in yocto on dunfell release with musl 
as libc. E.g. I can see that the build path for musl crti assembler file is 
leaking through and becomes visible when I do strings on libraries and binaries.

$ strings 
/opt/infn-xr/1.0/sysroots/aarch64-xr-linux-musl/usr/lib64/.debug/libcrypto.so.1.1
 | grep crt[a-z]\.o
/data/jenkins/workspace/XR_yocto-xr_master/build/build/infn-xr/gmcu/tmp/work/aarch64-xr-linux-musl/openssl/1.1.1l-r0/recipe-sysroot/usr/lib64/crti.o
/data/jenkins/workspace/XR_yocto-xr_master/build/build/infn-xr/gmcu/tmp/work/aarch64-xr-linux-musl/openssl/1.1.1l-r0/recipe-sysroot/usr/lib64/crtn.o
$

Is this a known issue? Yocto passes -fmacro-prefix-map and -fdebug-prefix-map 
as part of DEBUG_PREFIX_MAP to eliminate paths to WORKDIR. But it looks as that 
fails for the musl assembler file?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58600): https://lists.yoctoproject.org/g/yocto/message/58600
Mute This Topic: https://lists.yoctoproject.org/mt/95172718/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 4/4] mfd: intel-ehl-gpio: Fix the int conversion error

2022-11-21 Thread Kevin Hao 
From: Kevin Hao 

Fix the following int conversion errors introduced by commit
f6c5e7b6e801 ("mfd: intel-ehl-gpio: Introduce MFD framework to
PSE GPIO/TGPIO").
  include/linux/stddef.h:8:14: error: initialization of ‘long unsigned int’ 
from ‘void *’ makes integer from pointer without a cast [-Werror=int-conversion]
  8 | #define NULL ((void *)0)
|  ^
  drivers/mfd/intel-ehl-gpio.c:234:39: note: in expansion of macro ‘NULL’
234 | { PCI_VDEVICE(INTEL, 0x4b88), NULL},
|   ^~~~

Signed-off-by: Kevin Hao 
---
 drivers/mfd/intel-ehl-gpio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/intel-ehl-gpio.c b/drivers/mfd/intel-ehl-gpio.c
index 4c1c808ce190..e0c248337635 100644
--- a/drivers/mfd/intel-ehl-gpio.c
+++ b/drivers/mfd/intel-ehl-gpio.c
@@ -231,8 +231,8 @@ static const struct dev_pm_ops 
intel_ehl_pse_gpio_mfd_pm_ops = {
 };
 
 static const struct pci_device_id intel_ehl_pse_gpio_mfd_ids[] = {
-   { PCI_VDEVICE(INTEL, 0x4b88), NULL},
-   { PCI_VDEVICE(INTEL, 0x4b89), NULL},
+   { PCI_VDEVICE(INTEL, 0x4b88), },
+   { PCI_VDEVICE(INTEL, 0x4b89), },
{ },
 };
 MODULE_DEVICE_TABLE(pci, intel_ehl_pse_gpio_mfd_ids);
-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11931): 
https://lists.yoctoproject.org/g/linux-yocto/message/11931
Mute This Topic: https://lists.yoctoproject.org/mt/95171193/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 3/4] mfd: intel-ehl-gpio: Drop the unused variables

2022-11-21 Thread Kevin Hao 
From: Kevin Hao 

Fix the unused variable errors introduced by commit f6c5e7b6e801 ("mfd:
intel-ehl-gpio: Introduce MFD framework to PSE GPIO/TGPIO").
  drivers/gpio/gpio-ehl-pse-plat.c: In function ‘ehl_pse_gpio_probe’:
  drivers/gpio/gpio-ehl-pse-plat.c:366:23: error: unused variable ‘base’ 
[-Werror=unused-variable]
366 | void __iomem *base;
|   ^~~~
  drivers/mfd/intel-ehl-gpio.c: In function ‘intel_ehl_pse_gpio_mfd_suspend’:
  drivers/mfd/intel-ehl-gpio.c:135:13: error: unused variable ‘i’ 
[-Werror=unused-variable]
135 | int i = 0;
| ^
  drivers/mfd/intel-ehl-gpio.c: In function 
‘intel_ehl_pse_gpio_mfd_runtime_suspend’:
  drivers/mfd/intel-ehl-gpio.c:184:13: error: unused variable ‘i’ 
[-Werror=unused-variable]
184 | int i = 0;
| ^

Signed-off-by: Kevin Hao 
---
 drivers/gpio/gpio-ehl-pse-plat.c | 1 -
 drivers/mfd/intel-ehl-gpio.c | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpio/gpio-ehl-pse-plat.c b/drivers/gpio/gpio-ehl-pse-plat.c
index 1b24dcd60dfe..23a2deed6fa5 100644
--- a/drivers/gpio/gpio-ehl-pse-plat.c
+++ b/drivers/gpio/gpio-ehl-pse-plat.c
@@ -363,7 +363,6 @@ static int ehl_pse_gpio_probe(struct platform_device *pdev)
struct ehl_pse_gpio *priv;
struct resource *res;
u32 irq;
-   void __iomem *base;
int ret;
 
priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
diff --git a/drivers/mfd/intel-ehl-gpio.c b/drivers/mfd/intel-ehl-gpio.c
index 6aa5a6cfc9ad..4c1c808ce190 100644
--- a/drivers/mfd/intel-ehl-gpio.c
+++ b/drivers/mfd/intel-ehl-gpio.c
@@ -132,7 +132,6 @@ static int intel_ehl_pse_gpio_mfd_suspend(struct device 
*dev)
 {
struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
struct intel_ehl_pse_gpio_data  *pdata = pci_get_drvdata(pdev);
-   int i = 0;
u32 d0i3c_reg, cgsr_reg = 0;
 
d0i3c_reg = readl(pdata->priv + PSE_GPIO_D0I3C);
@@ -181,7 +180,6 @@ static int intel_ehl_pse_gpio_mfd_runtime_suspend(struct 
device *dev)
 {
struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
struct intel_ehl_pse_gpio_data  *pdata = pci_get_drvdata(pdev);
-   int i = 0;
u32 d0i3c_reg, cgsr_reg = 0;
 
d0i3c_reg = readl(pdata->priv + PSE_GPIO_D0I3C);
-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11930): 
https://lists.yoctoproject.org/g/linux-yocto/message/11930
Mute This Topic: https://lists.yoctoproject.org/mt/95171191/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 2/4] gpio: intel-ehl-gpio: Fix the wrong return type in ehl_pse_gpio_probe()

2022-11-21 Thread Kevin Hao 
From: Kevin Hao 

The commit f6c5e7b6e801 ("mfd: intel-ehl-gpio: Introduce MFD framework
to PSE GPIO/TGPIO") introduced the following wrong return type errors:
  drivers/gpio/gpio-ehl-pse-plat.c: In function ‘ehl_pse_gpio_probe’:
  include/linux/stddef.h:8:14: error: returning ‘void *’ from a function with 
return type ‘int’ makes integer from pointer without a cast 
[-Werror=int-conversion]
  8 | #define NULL ((void *)0)
|  ^
  drivers/gpio/gpio-ehl-pse-plat.c:378:24: note: in expansion of macro ‘NULL’
378 | return NULL;
|^~~~
  include/linux/stddef.h:8:14: error: returning ‘void *’ from a function with 
return type ‘int’ makes integer from pointer without a cast 
[-Werror=int-conversion]
  8 | #define NULL ((void *)0)
|  ^
  drivers/gpio/gpio-ehl-pse-plat.c:382:24: note: in expansion of macro ‘NULL’
382 | return NULL;
|^~~~

Fix them by returning the -EINVAL for the platform_get_{resource,irt}()
failure.

Signed-off-by: Kevin Hao 
---
 drivers/gpio/gpio-ehl-pse-plat.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-ehl-pse-plat.c b/drivers/gpio/gpio-ehl-pse-plat.c
index c3d640a06c36..1b24dcd60dfe 100644
--- a/drivers/gpio/gpio-ehl-pse-plat.c
+++ b/drivers/gpio/gpio-ehl-pse-plat.c
@@ -376,11 +376,11 @@ static int ehl_pse_gpio_probe(struct platform_device 
*pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
-   return NULL;
+   return -EINVAL;
 
irq = platform_get_irq(pdev, 0);
if (irq < 0)
-   return NULL;
+   return -EINVAL;
 
priv->dev = >dev;
priv->reg_base = devm_ioremap_resource(>dev, res);
-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11929): 
https://lists.yoctoproject.org/g/linux-yocto/message/11929
Mute This Topic: https://lists.yoctoproject.org/mt/95171190/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 1/4] gpio: intel-ehl-gpio: Fix the declaration after statement error

2022-11-21 Thread Kevin Hao 
From: Kevin Hao 

The commit f6c5e7b6e801 ("mfd: intel-ehl-gpio: Introduce MFD framework
to PSE GPIO/TGPIO") introduced the following build error:
  driverr/gpio/gpio-ehl-pse-plat.c: In function ‘ehl_pse_gpio_get_direction’:
  drivers/gpio/gpio-ehl-pse-plat.c:175:9: error: ISO C90 forbids mixed 
declarations and code [-Werror=declaration-after-statement]
175 | u32 reg_gpdr = intel_gpio_readl(priv->reg_base, GPDR);
| ^~~

Move up the declaration to fix it.

Signed-off-by: Kevin Hao 
---
 drivers/gpio/gpio-ehl-pse-plat.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-ehl-pse-plat.c b/drivers/gpio/gpio-ehl-pse-plat.c
index 514a726a8cef..c3d640a06c36 100644
--- a/drivers/gpio/gpio-ehl-pse-plat.c
+++ b/drivers/gpio/gpio-ehl-pse-plat.c
@@ -169,10 +169,11 @@ static int ehl_pse_gpio_get_direction(struct gpio_chip 
*chip,
 {
struct ehl_pse_gpio *priv = gpiochip_get_data(chip);
int direction = 0;
+   u32 reg_gpdr;
 
pm_runtime_get_sync(priv->dev->parent);
 
-   u32 reg_gpdr = intel_gpio_readl(priv->reg_base, GPDR);
+   reg_gpdr = intel_gpio_readl(priv->reg_base, GPDR);
 
direction = !(reg_gpdr & BIT(offset));
 
-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11928): 
https://lists.yoctoproject.org/g/linux-yocto/message/11928
Mute This Topic: https://lists.yoctoproject.org/mt/95171187/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [linux-yocto 0/4] Fix the build errors for intel-ehl-gpio driver

2022-11-21 Thread Kevin Hao 
From: Kevin Hao 

Hi Bruce,

This patch series fixes serveal build errors when intel-ehl-gpio driver
is enabled. Please help merge them into the following two branches:
  v5.15/standard/preempt-rt/x86
  v5.15/standard/x86

Kevin Hao (4):
  gpio: intel-ehl-gpio: Fix the declaration after statement error
  gpio: intel-ehl-gpio: Fix the wrong return type in
ehl_pse_gpio_probe()
  mfd: intel-ehl-gpio: Drop the unused variables
  mfd: intel-ehl-gpio: Fix the int conversion error

 drivers/gpio/gpio-ehl-pse-plat.c | 8 
 drivers/mfd/intel-ehl-gpio.c | 6 ++
 2 files changed, 6 insertions(+), 8 deletions(-)

-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11927): 
https://lists.yoctoproject.org/g/linux-yocto/message/11927
Mute This Topic: https://lists.yoctoproject.org/mt/95171186/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] rust issue for armv6 in mainline poky

2022-11-21 Thread Alexander Kanavin 
Can you try the tip of master please?

Alex

On Mon, 21 Nov 2022 at 13:32, Marek Belisko  wrote:
>
> Hi,
>
> on kirkstone branch when trying to build rust for raspberrypi machine
> I'm getting:
>
> ERROR: rust-cross-arm1176jzfshf-vfp-glibc-1.59.0-r0
> do_rust_gen_targets: Error executing a python function in
> exec_func_python() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_func_python() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:do_rust_gen_targets(d)
>  0003:
> File: 
> '/data/projects/test-build/.build-rpi/../sources/poky/meta/recipes-devtools/rust/rust-cross.inc',
> lineno: 19, function: do_rust_gen_targets
>  0015:if arch == "arm" and target_is_armv7(d):
>  0016:arch = 'armv7'
>  0017:features = d.getVar('TARGET_LLVM_FEATURES') or ""
>  0018:cpu = d.getVar('TARGET_LLVM_CPU')
>  *** 0019:rust_gen_target(d, thing, wd, features, cpu, arch, abi)
>  0020:}
>  0021:
>  0022:# Otherwise we'll depend on what we provide
>  0023:INHIBIT_DEFAULT_RUST_DEPS = "1"
> File: 
> '/data/projects/test-build/.build-rpi/../sources/poky/meta/recipes-devtools/rust/rust-common.inc',
> lineno: 314, function: rust_gen_target
>  0310:# build tspec
>  0311:tspec = {}
>  0312:tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi)
>  0313:tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
>  *** 0314:tspec['max-atomic-width'] =
> int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
>  0315:tspec['target-pointer-width'] =
> d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
>  0316:tspec['target-c-int-width'] =
> d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
>  0317:tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN', arch_abi)
>  0318:tspec['arch'] = arch_to_rust_target_arch(rust_arch)
> Exception: TypeError: int() argument must be a string, a bytes-like
> object or a number, not 'NoneType'
>
> by adding below it seems to fix an issue (copied from meta-rust):
> diff --git a/meta/recipes-devtools/rust/rust-common.inc
> b/meta/recipes-devtools/rust/rust-common.inc
> index ef70c48d0f..389c75d2f7 100644
> --- a/meta/recipes-devtools/rust/rust-common.inc
> +++ b/meta/recipes-devtools/rust/rust-common.inc
> @@ -118,6 +118,15 @@ def llvm_features(d):
>  llvm_features_from_target_fpu(d))
>
>
> +
> +DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
> +LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
> +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"
> +
>  ## arm-unknown-linux-gnueabihf
>
> Thanks and BR,
>
> marek
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
>
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58599): https://lists.yoctoproject.org/g/yocto/message/58599
Mute This Topic: https://lists.yoctoproject.org/mt/95170677/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] rust issue for armv6 in mainline poky

2022-11-21 Thread Marek Belisko 
Hi,

on kirkstone branch when trying to build rust for raspberrypi machine
I'm getting:

ERROR: rust-cross-arm1176jzfshf-vfp-glibc-1.59.0-r0
do_rust_gen_targets: Error executing a python function in
exec_func_python() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_rust_gen_targets(d)
 0003:
File: 
'/data/projects/test-build/.build-rpi/../sources/poky/meta/recipes-devtools/rust/rust-cross.inc',
lineno: 19, function: do_rust_gen_targets
 0015:if arch == "arm" and target_is_armv7(d):
 0016:arch = 'armv7'
 0017:features = d.getVar('TARGET_LLVM_FEATURES') or ""
 0018:cpu = d.getVar('TARGET_LLVM_CPU')
 *** 0019:rust_gen_target(d, thing, wd, features, cpu, arch, abi)
 0020:}
 0021:
 0022:# Otherwise we'll depend on what we provide
 0023:INHIBIT_DEFAULT_RUST_DEPS = "1"
File: 
'/data/projects/test-build/.build-rpi/../sources/poky/meta/recipes-devtools/rust/rust-common.inc',
lineno: 314, function: rust_gen_target
 0310:# build tspec
 0311:tspec = {}
 0312:tspec['llvm-target'] = d.getVar('RUST_TARGET_SYS', arch_abi)
 0313:tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
 *** 0314:tspec['max-atomic-width'] =
int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
 0315:tspec['target-pointer-width'] =
d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
 0316:tspec['target-c-int-width'] =
d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
 0317:tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN', arch_abi)
 0318:tspec['arch'] = arch_to_rust_target_arch(rust_arch)
Exception: TypeError: int() argument must be a string, a bytes-like
object or a number, not 'NoneType'

by adding below it seems to fix an issue (copied from meta-rust):
diff --git a/meta/recipes-devtools/rust/rust-common.inc
b/meta/recipes-devtools/rust/rust-common.inc
index ef70c48d0f..389c75d2f7 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -118,6 +118,15 @@ def llvm_features(d):
 llvm_features_from_target_fpu(d))


+
+DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
+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"
+
 ## arm-unknown-linux-gnueabihf

Thanks and BR,

marek

--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58598): https://lists.yoctoproject.org/g/yocto/message/58598
Mute This Topic: https://lists.yoctoproject.org/mt/95170677/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] rockchip-defaults: remove xf86-input-keyboard

2022-11-21 Thread Quentin Schulz via lists.yoctoproject.org 

Hi Trevor,

On 11/19/22 14:45, Trevor Woerner wrote:

xf86-input-keyboard was removed from openembedded-core at its commit:
f1d7c33b64 (xf86-input-keyboard: remove the recipe, 2022-07-20). Therefore > 
remove it from the XSERVER definition.

Signed-off-by: Trevor Woerner 


Reviewed-by: Quentin Schulz 

Thanks,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58597): https://lists.yoctoproject.org/g/yocto/message/58597
Mute This Topic: https://lists.yoctoproject.org/mt/95132799/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-