[oe] [oe-core] kernel-devicetree.bbclass: DTBs with path components

2018-07-05 Thread Jonathan Haigh
Hi,


The recent oe-core commit 
https://github.com/openembedded/openembedded-core/commit/2e7f3b2b9318d1e5395ad58131eafb873f614326
 altered the normalize_dtb() function to always apply basename to the DTB (or 
DTS) passed in to convert a potentially full path to a DTB/DTS into a make 
target.


If I understand correctly, that's not the correct thing to do because the make 
targets can contain directory components - and some of the DTBs in 
meta-raspberrypi's KERNEL_DEVICETREE do contain directory components even 
though they're not full paths to the DTBs (e.g. overlays/at86rf233.dtbo from 
meta-raspberrypi:conf/machine/include/rpi-base.inc).


I think the normalize_dtb() function should just strip leading parts of 
DTB/DTSs to make them relative to the 'dts' directory. I have a patch to make 
this change that I will post shortly.


Regards,


Jonathan

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [oe-core] kernel-devicetree.bbclass: DTBs with path components

2018-07-06 Thread Jonathan Haigh
I've just noticed that my patch never actually made it to the mailing list. 
I'll try to send it again.

____
From: Jonathan Haigh
Sent: 06 July 2018 10:18:04
To: Khem Raj; openembedded-devel@lists.openembedded.org; ptsne...@gmail.com; 
richard.pur...@linuxfoundation.org
Cc: Jeremy Johnson
Subject: Re: [oe] [oe-core] kernel-devicetree.bbclass: DTBs with path components

Hi Khem,

Thanks for the response.

Reverting 2e7f3b2b9318d1e5395ad58131eafb873f614326 works for me (my 
KERNEL_DEVICETREEs don't actually contain any full paths to DTBs or DTSs).

In the case where the warning is emitted  (a full path to the DTB/DTS) the 
current code still may not handle some cases properly - when a DTB/DTS is given 
as a full path but that full path is to a subdirectory of dts/. In that case 
the current code will use basename to strip off all but the filename, but if I 
understand correctly, any path components after the dts/ directory shouldn't be 
stripped. That case comes with a BitBake warning though, so I guess maybe it's 
not supported and isn't important.


Paulo,

The scenario you've described is a bit different to what I was thinking about. 
Each element in KERNEL_DEVICETREE is translated by normalize_dtb() and then 
passed straight to oe_runmake in do_compile_append() in 
kernel-devicetree.bbclass. I'd guess that you need to do a bit more work to get 
your (translated) dtb path to be a valid make target than putting the DTS in 
${WORKDIR} (maybe putting your DTS in the kernel source's dts directory would 
do it).

The cases I was thinking about were where KERNEL_DEVICETREE has paths to DTS or 
DTB files that are already in the kernel's dts directory.

Thanks,

Jonathan

From: Khem Raj 
Sent: 05 July 2018 23:41
To: Jonathan Haigh; openembedded-devel@lists.openembedded.org; 
ptsne...@gmail.com; richard.pur...@linuxfoundation.org
Subject: Re: [oe] [oe-core] kernel-devicetree.bbclass: DTBs with path components


On 7/5/18 4:04 AM, Jonathan Haigh wrote:
> Hi,
>
>
> The recent oe-core commit  
> https://github.com/openembedded/openembedded-core/commit/2e7f3b2b9318d1e5395ad58131eafb873f614326
>  altered the normalize_dtb() function to always apply basename to the DTB (or 
> DTS) passed in to convert a potentially full path to a DTB/DTS into a make 
> target.
>
>
> If I understand correctly, that's not the correct thing to do because the 
> make targets can contain directory components - and some of the DTBs in 
> meta-raspberrypi's KERNEL_DEVICETREE do contain directory components even 
> though they're not full paths to the  DTBs (e.g. overlays/at86rf233.dtbo from 
> meta-raspberrypi:conf/machine/include/rpi-base.inc).
>
>
> I think the normalize_dtb() function should just strip leading parts of 
> DTB/DTSs to make them relative to the 'dts' directory. I have a patch to make 
> this change that I will post shortly.
>


it has already been reverted today.
see
http://git.openembedded.org/openembedded-core/commit/?id=0d725c76c113dec441a7319a6ee997e4ae8c4c88

please update to latest master.

>
> Regards,
>
>
> Jonathan
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any  purpose, or store or copy the 
> information in any medium. Thank you.
>



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [PATCH] kernel-devicetree.bbclass: DTB make targets may contain path components

2018-07-06 Thread Jonathan Haigh
normalize_dtb() turns DTS and DTB paths into values that can be used as
make targets. These make targets sometimes contain some directory components
so 'basename' is not suitable for turning the paths into make targets -
we should only strip off leading directory components of the path up to
and including the 'dts' directory (if it exists). For example:
* 'overlays/at86rf233.dtbo' should not be changed.
* 'some/directory/path/dts/overlays/at86rf233.dtbo' should be changed to
  'overlays/at86rf233.dtbo' rather than just 'at86rf233.dtbo'

Signed-off-by: Jonathan Haigh 
---
 meta/classes/kernel-devicetree.bbclass | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
index 9866d84..0ffa8e9 100644
--- a/meta/classes/kernel-devicetree.bbclass
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -12,9 +12,10 @@ KERNEL_DEVICETREE_BUNDLE ?= "0"
 normalize_dtb () {
 DTB="$1"
 if echo ${DTB} | grep -q '/dts/'; then
-   bbwarn "${DTB} contains the full path to the the dts file, but 
only the dtb name should be used."
+   bbwarn "${DTB} contains the full path to the the dts file, but 
the path should be relative to the dts directory."
+   DTB=`echo "${DTB}" | sed 's,^.*/dts/,,'`
 fi
-   DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
+   DTB=`echo "${DTB}" | sed 's,\.dts$,.dtb,g'`
 echo "${DTB}"
 }

--
2.7.4


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [oe-core] kernel-devicetree.bbclass: DTBs with path components

2018-07-07 Thread Jonathan Haigh
Hi Khem,

Thanks for the response.

Reverting 2e7f3b2b9318d1e5395ad58131eafb873f614326 works for me (my 
KERNEL_DEVICETREEs don't actually contain any full paths to DTBs or DTSs).

In the case where the warning is emitted  (a full path to the DTB/DTS) the 
current code still may not handle some cases properly - when a DTB/DTS is given 
as a full path but that full path is to a subdirectory of dts/. In that case 
the current code will use basename to strip off all but the filename, but if I 
understand correctly, any path components after the dts/ directory shouldn't be 
stripped. That case comes with a BitBake warning though, so I guess maybe it's 
not supported and isn't important.


Paulo,

The scenario you've described is a bit different to what I was thinking about. 
Each element in KERNEL_DEVICETREE is translated by normalize_dtb() and then 
passed straight to oe_runmake in do_compile_append() in 
kernel-devicetree.bbclass. I'd guess that you need to do a bit more work to get 
your (translated) dtb path to be a valid make target than putting the DTS in 
${WORKDIR} (maybe putting your DTS in the kernel source's dts directory would 
do it).

The cases I was thinking about were where KERNEL_DEVICETREE has paths to DTS or 
DTB files that are already in the kernel's dts directory.

Thanks,

Jonathan

From: Khem Raj 
Sent: 05 July 2018 23:41
To: Jonathan Haigh; openembedded-devel@lists.openembedded.org; 
ptsne...@gmail.com; richard.pur...@linuxfoundation.org
Subject: Re: [oe] [oe-core] kernel-devicetree.bbclass: DTBs with path components


On 7/5/18 4:04 AM, Jonathan Haigh wrote:
> Hi,
>
>
> The recent oe-core commit  
> https://github.com/openembedded/openembedded-core/commit/2e7f3b2b9318d1e5395ad58131eafb873f614326
>  altered the normalize_dtb() function to always apply basename to the DTB (or 
> DTS) passed in to convert a potentially full path to a DTB/DTS into a make 
> target.
>
>
> If I understand correctly, that's not the correct thing to do because the 
> make targets can contain directory components - and some of the DTBs in 
> meta-raspberrypi's KERNEL_DEVICETREE do contain directory components even 
> though they're not full paths to the  DTBs (e.g. overlays/at86rf233.dtbo from 
> meta-raspberrypi:conf/machine/include/rpi-base.inc).
>
>
> I think the normalize_dtb() function should just strip leading parts of 
> DTB/DTSs to make them relative to the 'dts' directory. I have a patch to make 
> this change that I will post shortly.
>


it has already been reverted today.
see
http://git.openembedded.org/openembedded-core/commit/?id=0d725c76c113dec441a7319a6ee997e4ae8c4c88

please update to latest master.

>
> Regards,
>
>
> Jonathan
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any  purpose, or store or copy the 
> information in any medium. Thank you.
>



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [PATCH] kernel-devicetree.bbclass: DTB make targets may contain path components

2018-07-10 Thread Jonathan Haigh
> This patch is fine however, you should rebase it on top of master as of today.
> secondly, this should be sent to oe-core mailing list since its
> changing that layer


Ah, okay, I'll do that. Thanks Khem.


From: Khem Raj 
Sent: 07 July 2018 03:38:48
To: akuster808
Cc: Jeremy Johnson; Jonathan Haigh; openembeded-devel
Subject: Re: [oe] [PATCH] kernel-devicetree.bbclass: DTB make targets may 
contain path components



On Fri, Jul 6, 2018 at 6:13 PM akuster808 
mailto:akuster...@gmail.com>> wrote:


On 07/06/2018 02:25 PM, Khem Raj wrote:
> On Fri, Jul 6, 2018 at 12:02 PM Jonathan Haigh 
> mailto:jonathan.ha...@arm.com>> wrote:
>> normalize_dtb() turns DTS and DTB paths into values that can be used as
>> make targets. These make targets sometimes contain some directory components
>> so 'basename' is not suitable for turning the paths into make targets -
>> we should only strip off leading directory components of the path up to
>> and including the 'dts' directory (if it exists). For example:
>> * 'overlays/at86rf233.dtbo' should not be changed.
>> * 'some/directory/path/dts/overlays/at86rf233.dtbo' should be changed to
>>   'overlays/at86rf233.dtbo' rather than just 'at86rf233.dtbo'
>>
>> Signed-off-by: Jonathan Haigh 
>> mailto:jonathan.ha...@arm.com>>
>> ---
>>  meta/classes/kernel-devicetree.bbclass | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/kernel-devicetree.bbclass 
>> b/meta/classes/kernel-devicetree.bbclass
>> index 9866d84..0ffa8e9 100644
>> --- a/meta/classes/kernel-devicetree.bbclass
>> +++ b/meta/classes/kernel-devicetree.bbclass
>> @@ -12,9 +12,10 @@ KERNEL_DEVICETREE_BUNDLE ?= "0"
>>  normalize_dtb () {
>>  DTB="$1"
>>  if echo ${DTB} | grep -q '/dts/'; then
>> -   bbwarn "${DTB} contains the full path to the the dts file, 
>> but only the dtb name should be used."
>> +   bbwarn "${DTB} contains the full path to the the dts file, 
>> but the path should be relative to the dts directory."
>> +   DTB=`echo "${DTB}" | sed 's,^.*/dts/,,'`
>>  fi
>> -   DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
>> +   DTB=`echo "${DTB}" | sed 's,\.dts$,.dtb,g'`
> This patch is fine however, you should rebase it on top of master as of today.
> secondly, this should be sent to oe-core mailing list since its
> changing that layer

this landed in master already. patch was posted earlier this week.

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8b9264824689e99fb257901be3c0f91f79f920ef
>

They are different patches

>>  echo "${DTB}"
>>  }
>>
>> --
>> 2.7.4
>>
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are 
>> confidential and may also be privileged. If you are not the intended 
>> recipient, please notify the sender immediately and do not disclose the 
>> contents to any other person, use it for any purpose, or store or copy the 
>> information in any medium. Thank you.
>> --
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org<mailto:Openembedded-devel@lists.openembedded.org>
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


[oe] [meta-python] broken python-asn1crypto-native dependency

2017-11-20 Thread Jonathan Haigh
Hi,


Recent changes to add the python-asn1crypto dependency to python-cryptography 
(commit 74985f286eadd35f7e726c60a0616f423ae45000) has broken 
python-cryptography-native builds because there's no recipe providing 
python-asn1crypto-native.


I have a patch for this - adding BBCLASSEXTEND = "native" to 
python-asn1crypto's recipe - which I will send with git send-email, although 
most of the other python recipes also include nativesdk in BBCLASSEXTEND so 
maybe that should be added too (I don't know much about the SDK stuff).


Kind Regards,


Jonathan Haigh

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


[oe] [meta-python][PATCH] Allow native builds of python-asyn1crypto

2017-11-20 Thread Jonathan Haigh
Add "native" to BBCLASSEXTEND to allow native builds.

Signed-off-by: Jonathan Haigh 
---
 meta-python/recipes-devtools/python/python-asn1crypto.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta-python/recipes-devtools/python/python-asn1crypto.inc 
b/meta-python/recipes-devtools/python/python-asn1crypto.inc
index 3bdb4b2..41b7342 100644
--- a/meta-python/recipes-devtools/python/python-asn1crypto.inc
+++ b/meta-python/recipes-devtools/python/python-asn1crypto.inc
@@ -10,3 +10,4 @@ SRC_URI[md5sum] = "97d54665c397b72b165768398dfdd876"
 SRC_URI[sha256sum] = 
"0874981329cfebb366d6584c3d16e913f2a0eb026c9463efcc4aaf42a9d94d70"

 inherit pypi
+BBCLASSEXTEND = "native"
--
2.7.4
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [meta-python] broken python-asn1crypto-native dependency

2017-11-21 Thread Jonathan Haigh
Great, thanks Otavio.


From: Otavio Salvador 
Sent: 20 November 2017 18:08:47
To: Jonathan Haigh
Cc: openembedded-devel@lists.openembedded.org; Simon Hughes
Subject: Re: [oe] [meta-python] broken python-asn1crypto-native dependency

Hello Jonathan,

On Mon, Nov 20, 2017 at 9:33 AM, Jonathan Haigh  wrote:
> I have a patch for this - adding BBCLASSEXTEND = "native" to 
> python-asn1crypto's recipe - which I will send with git send-email, although 
> most of the other python recipes also include nativesdk in BBCLASSEXTEND so 
> maybe that should be added too (I don't know much about the SDK stuff).

I had it in my queue, so I sent it.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel