Re: [OE-core] [PATCH 0/4] Recipes for Open Source Verilog and Lattice iCE40 FPGAs tools

[Khem Raj]

On Tue, Sep 12, 2017 at 4:42 PM, Trevor Woerner  wrote:
> On Tue, Sep 12, 2017 at 4:21 PM, Khem Raj  wrote:
>> On Mon, Sep 11, 2017 at 1:58 AM, Burton, Ross  wrote:
>>> On 10 September 2017 at 14:14, Nathan Rossi  wrote:

 Please note whilst this series is sent for oe-core it may be better
 located in another layer? (e.g. meta-oe). However since the recipes and
 the tools they build are not specific to a single BSP it did not make
 sense to keep in a BSP specific layer.
>>>
>>>
>>> Sounds like a dedicated FPGA layer would be ideal.
>>>
>>
>> I think a layer for 2 recipes might be too much. Put it under 
>> recipes-devtools
>> in meta-oe for now.
>
> 5?
>
> Am I reading this patch correctly? There are 5 recipes?

2 or 5 doesnt matter I just meant "too few to be a layer of its own"
engineers minds :)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] python*native.bbclass: suppress user site dirs

[Martin Kelly]

Currently, $HOME/.local is being added into sys.path for the native
Python, causing subtle host contamination. Suppress this by exporting
PYTHONNOUSERSITE = "1" as documented in PEP 370.

Signed-off-by: Martin Kelly 
---
 meta/classes/python3native.bbclass | 3 +++
 meta/classes/pythonnative.bbclass  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/meta/classes/python3native.bbclass 
b/meta/classes/python3native.bbclass
index ef468b3fde..89665efee8 100644
--- a/meta/classes/python3native.bbclass
+++ b/meta/classes/python3native.bbclass
@@ -9,5 +9,8 @@ DEPENDS_append = " ${PYTHON_PN}-native "
 export STAGING_INCDIR
 export STAGING_LIBDIR
 
+# suppress host user's site-packages dirs.
+export PYTHONNOUSERSITE = "1"
+
 # autoconf macros will use their internal default preference otherwise
 export PYTHON
diff --git a/meta/classes/pythonnative.bbclass 
b/meta/classes/pythonnative.bbclass
index 4e0381b568..4cc8b2769c 100644
--- a/meta/classes/pythonnative.bbclass
+++ b/meta/classes/pythonnative.bbclass
@@ -12,5 +12,8 @@ DEPENDS_append = " ${PYTHON_PN}-native "
 export STAGING_INCDIR
 export STAGING_LIBDIR
 
+# suppress host user's site-packages dirs.
+export PYTHONNOUSERSITE = "1"
+
 # autoconf macros will use their internal default preference otherwise
 export PYTHON
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] linux-firmware: bump to latest linux-firmware git revision

[Stefan Agner]

From: Stefan Agner 

This requires MD5 sum updates for
- LICENSE.QualcommAtheros_ath10k: year change
- WHENCE: various version updates and addition of new firmwares

The new firmware for Qualcom Venus causes a QA error:
  QA Issue: linux-firmware: Recipe inherits the allarch class, but has packaged 
architecture-specific binaries

Since firmware typically do not run on the CPU, the architecture of
the firmware file is independent from the CPU architecture the image
will be running on. Disable the QA check for the linux-firmware
package by default.

Signed-off-by: Stefan Agner 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 20d140c..ea77d65 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -1,6 +1,8 @@
 SUMMARY = "Firmware files for use with Linux kernel"
 SECTION = "kernel"
 
+ERROR_QA_remove = "arch"
+
 LICENSE = "\
 Firmware-Abilis \
 & Firmware-adsp_sst \
@@ -98,7 +100,7 @@ LIC_FILES_CHKSUM = "\
 file://LICENCE.qla1280;md5=d6895732e622d950609093223a2c4f5d \
 file://LICENCE.qla2xxx;md5=505855e921b75f1be4a437ad9b79dff0 \
 file://LICENSE.QualcommAtheros_ar3k;md5=b5fe244fb2b532311de1472a3bc06da5 \
-file://LICENSE.QualcommAtheros_ath10k;md5=b5fe244fb2b532311de1472a3bc06da5 
\
+file://LICENSE.QualcommAtheros_ath10k;md5=cb42b686ee5f5cb890275e4321db60a8 
\
 file://LICENCE.r8a779x_usb3;md5=4c1671656153025d7076105a5da7e498 \
 file://LICENSE.radeon;md5=68ec28bacb3613200bca44f404c69b16 \
 
file://LICENCE.ralink_a_mediatek_company_firmware;md5=728f1a85fd53fd67fa8d7afb080bc435
 \
@@ -114,7 +116,7 @@ LIC_FILES_CHKSUM = "\
 file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 \
 file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
 file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \
-file://WHENCE;md5=ad12d0618287e8c10ae3da05fa0edcfb \
+file://WHENCE;md5=08f6d4371353cac5f6fc271d5407c63e \
 "
 
 # These are not common licenses, set NO_GENERIC_LICENSE for them
@@ -175,7 +177,7 @@ NO_GENERIC_LICENSE[Firmware-xc5000] = "LICENCE.xc5000"
 NO_GENERIC_LICENSE[Firmware-xc5000c] = "LICENCE.xc5000c"
 NO_GENERIC_LICENSE[WHENCE] = "WHENCE"
 
-SRCREV = "b14134583c2a15d4404695f72cb523daedb877ab"
+SRCREV = "a61ac5cf8374edbfe692d12f805a1b194f7fead2"
 PE = "1"
 PV = "0.0+git${SRCPV}"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] linux-firmware: package Marvell PCIe WiFi firmwares

[Stefan Agner]

From: Stefan Agner 

Add packages for Marvell Avastar 88W8897 and 88W8997 PCIe WiFi
chips.

Signed-off-by: Stefan Agner 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 396bd4e..20d140c 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -229,7 +229,8 @@ do_install() {
 PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-mt7601u-license ${PN}-mt7601u \
  ${PN}-radeon-license ${PN}-radeon \
- ${PN}-marvell-license ${PN}-sd8686 ${PN}-sd8688 ${PN}-sd8787 
${PN}-sd8797 ${PN}-sd8801 ${PN}-sd8887 ${PN}-sd8897 \
+ ${PN}-marvell-license ${PN}-pcie8897 ${PN}-pcie8997 \
+ ${PN}-sd8686 ${PN}-sd8688 ${PN}-sd8787 ${PN}-sd8797 ${PN}-sd8801 
${PN}-sd8887 ${PN}-sd8897 \
  ${PN}-ti-connectivity-license ${PN}-wl12xx ${PN}-wl18xx \
  ${PN}-vt6656-license ${PN}-vt6656 \
  ${PN}-rtl-license ${PN}-rtl8188 ${PN}-rtl8192cu ${PN}-rtl8192ce 
${PN}-rtl8192su ${PN}-rtl8723 ${PN}-rtl8821 \
@@ -356,6 +357,8 @@ FILES_${PN}-radeon = " \
 RDEPENDS_${PN}-radeon += "${PN}-radeon-license"
 
 # For marvell
+LICENSE_${PN}-pcie8897 = "Firmware-Marvell"
+LICENSE_${PN}-pcie8997 = "Firmware-Marvell"
 LICENSE_${PN}-sd8686 = "Firmware-Marvell"
 LICENSE_${PN}-sd8688 = "Firmware-Marvell"
 LICENSE_${PN}-sd8787 = "Firmware-Marvell"
@@ -366,6 +369,14 @@ LICENSE_${PN}-sd8897 = "Firmware-Marvell"
 LICENSE_${PN}-marvell-license = "Firmware-Marvell"
 
 FILES_${PN}-marvell-license = "${nonarch_base_libdir}/firmware/LICENCE.Marvell"
+FILES_${PN}-pcie8897 = " \
+  ${nonarch_base_libdir}/firmware/mrvl/pcie8897_uapsta.bin \
+"
+FILES_${PN}-pcie8997 = " \
+  ${nonarch_base_libdir}/firmware/mrvl/pcie8997_wlan_v4.bin \
+  ${nonarch_base_libdir}/firmware/mrvl/pcieuart8997_combo_v4.bin \
+  ${nonarch_base_libdir}/firmware/mrvl/pcieusb8997_combo_v4.bin \
+"
 FILES_${PN}-sd8686 = " \
   ${nonarch_base_libdir}/firmware/libertas/sd8686_v9* \
   ${nonarch_base_libdir}/firmware/sd8686* \
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/4] Recipes for Open Source Verilog and Lattice iCE40 FPGAs tools

[Trevor Woerner]

On Tue, Sep 12, 2017 at 4:21 PM, Khem Raj  wrote:
> On Mon, Sep 11, 2017 at 1:58 AM, Burton, Ross  wrote:
>> On 10 September 2017 at 14:14, Nathan Rossi  wrote:
>>>
>>> Please note whilst this series is sent for oe-core it may be better
>>> located in another layer? (e.g. meta-oe). However since the recipes and
>>> the tools they build are not specific to a single BSP it did not make
>>> sense to keep in a BSP specific layer.
>>
>>
>> Sounds like a dedicated FPGA layer would be ideal.
>>
>
> I think a layer for 2 recipes might be too much. Put it under recipes-devtools
> in meta-oe for now.

5?

Am I reading this patch correctly? There are 5 recipes?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/4] Recipes for Open Source Verilog and Lattice iCE40 FPGAs tools

[Alistair Francis]

On Tue, Sep 12, 2017 at 3:56 PM, Trevor Woerner  wrote:
> Nathan, this is awesome!
>
> (haven't tested it yet, but it's great to see this effort!!)
>
> On Mon, Sep 11, 2017 at 1:58 AM, Burton, Ross  wrote:
>> On 10 September 2017 at 14:14, Nathan Rossi  wrote:
>>>
>>> Please note whilst this series is sent for oe-core it may be better
>>> located in another layer? (e.g. meta-oe). However since the recipes and
>>> the tools they build are not specific to a single BSP it did not make
>>> sense to keep in a BSP specific layer.
>>
>>
>> Sounds like a dedicated FPGA layer would be ideal.
>
> We already have meta-xilinx (and friends) and meta-altera, looks like
> a meta-lattice is in order?

For open tools like these I think a meta-fpga layer makes sense.
Hopefully then others can build off it.

Thanks,
Alistair

> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/4] Recipes for Open Source Verilog and Lattice iCE40 FPGAs tools

[Khem Raj]

On Mon, Sep 11, 2017 at 1:58 AM, Burton, Ross  wrote:
> On 10 September 2017 at 14:14, Nathan Rossi  wrote:
>>
>> Please note whilst this series is sent for oe-core it may be better
>> located in another layer? (e.g. meta-oe). However since the recipes and
>> the tools they build are not specific to a single BSP it did not make
>> sense to keep in a BSP specific layer.
>
>
> Sounds like a dedicated FPGA layer would be ideal.
>

I think a layer for 2 recipes might be too much. Put it under recipes-devtools
in meta-oe for now.

> Ross
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] initramfs-framework: bump PR and fix install-efi and setup-live modules

[Trevor Woerner]

On Tue, Sep 12, 2017 at 3:58 PM, Otavio Salvador
 wrote:
> On Tue, Sep 12, 2017 at 7:51 PM, Trevor Woerner  wrote:
>> On Mon, Sep 11, 2017 at 6:40 PM, Paul Eggleton
>>  wrote:
>>> Is someone documenting all of this? I'm pretty sure this isn't the only one.
>>
>> Better still: an automated test (with comments including this
>> information, so the test doesn't get removed under the assumption the
>> thing it's testing is buggy)
>
> What kind of test do you imagine?

This would be bitbake?

Isn't there already a test suite for bitbake (if my previous statement
is correct)?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] initramfs-framework: bump PR and fix install-efi and setup-live modules

[Otavio Salvador]

On Tue, Sep 12, 2017 at 7:51 PM, Trevor Woerner  wrote:
> On Mon, Sep 11, 2017 at 6:40 PM, Paul Eggleton
>  wrote:
>> Is someone documenting all of this? I'm pretty sure this isn't the only one.
>
> Better still: an automated test (with comments including this
> information, so the test doesn't get removed under the assumption the
> thing it's testing is buggy)

What kind of test do you imagine?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/4] Recipes for Open Source Verilog and Lattice iCE40 FPGAs tools

[Trevor Woerner]

Nathan, this is awesome!

(haven't tested it yet, but it's great to see this effort!!)

On Mon, Sep 11, 2017 at 1:58 AM, Burton, Ross  wrote:
> On 10 September 2017 at 14:14, Nathan Rossi  wrote:
>>
>> Please note whilst this series is sent for oe-core it may be better
>> located in another layer? (e.g. meta-oe). However since the recipes and
>> the tools they build are not specific to a single BSP it did not make
>> sense to keep in a BSP specific layer.
>
>
> Sounds like a dedicated FPGA layer would be ideal.

We already have meta-xilinx (and friends) and meta-altera, looks like
a meta-lattice is in order?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] initramfs-framework: bump PR and fix install-efi and setup-live modules

[Trevor Woerner]

On Mon, Sep 11, 2017 at 6:40 PM, Paul Eggleton
 wrote:
> Is someone documenting all of this? I'm pretty sure this isn't the only one.

Better still: an automated test (with comments including this
information, so the test doesn't get removed under the assumption the
thing it's testing is buggy)

:-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v8 00/13] Revamp the Go support

[Bruce Ashfield]

On Tue, Sep 12, 2017 at 5:53 PM, Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:

> On Tue, Sep 12, 2017 at 6:41 PM, Bruce Ashfield
>  wrote:
> > On Tue, Sep 12, 2017 at 8:50 AM, Otavio Salvador <
> ota...@ossystems.com.br>
> > wrote:
> >>
> >> This improves the Go support on OE-Core.
> >>
> >> We are trying to port as much as possible work done by Matt on
> >> meta-golang back to OE-Core and also to avoid carrying old releases as
> >> there is no need to support more versions of Go toolchain.
> >>
> >> This fixes issues in existing support as well as add support for SDK
> >> generation which supports Go.
> >
> >
> > Testing against what has merged, and what are in these series is showing
> > that large
> > parts of the go applications that are used in meta-virt no longer work.
> Was
> > it the
> > intention of the re-work to not be compatible with existing users of the
> > language support ?
> >
> > Just curious, since I haven't seen this flagged in this context
> > (compatibility), but now we
> > have to fixup the layers before I branch to match the release .. and that
> > was unexpected.
>
> It does change things which can potentially break old recipes. That
> said, it is straightforward to fix for most recipes as they end being
> simpler.
>

ok, cool. I just didn't notice this went it first went in (that doesn't
mean it wasn't stated .. just that I missed it :)


>
> I volunteer to help if there is the need.
>

Right now some of the fixes are in flight, if the fixes get stuck, I'll
make sure to ping.

Thanks,

Bruce


>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v8 00/13] Revamp the Go support

[Otavio Salvador]

On Tue, Sep 12, 2017 at 6:41 PM, Bruce Ashfield
 wrote:
> On Tue, Sep 12, 2017 at 8:50 AM, Otavio Salvador 
> wrote:
>>
>> This improves the Go support on OE-Core.
>>
>> We are trying to port as much as possible work done by Matt on
>> meta-golang back to OE-Core and also to avoid carrying old releases as
>> there is no need to support more versions of Go toolchain.
>>
>> This fixes issues in existing support as well as add support for SDK
>> generation which supports Go.
>
>
> Testing against what has merged, and what are in these series is showing
> that large
> parts of the go applications that are used in meta-virt no longer work. Was
> it the
> intention of the re-work to not be compatible with existing users of the
> language support ?
>
> Just curious, since I haven't seen this flagged in this context
> (compatibility), but now we
> have to fixup the layers before I branch to match the release .. and that
> was unexpected.

It does change things which can potentially break old recipes. That
said, it is straightforward to fix for most recipes as they end being
simpler.

I volunteer to help if there is the need.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] python*native.bbclass: suppress user site dirs

[Khem Raj]

On Tue, Sep 12, 2017 at 2:03 PM Martin Kelly  wrote:

> Currently, $HOME/.local is being added into sys.path for the native
> Python, causing subtle host contamination. Suppress this by exporting
> PYTHONNOUSERSITE = "1" as documented in PEP 370.
>

LGTM

>
> Signed-off-by: Martin Kelly 
> ---
>  meta/classes/python3native.bbclass | 3 +++
>  meta/classes/pythonnative.bbclass  | 3 +++
>  2 files changed, 6 insertions(+)
>
> diff --git a/meta/classes/python3native.bbclass
> b/meta/classes/python3native.bbclass
> index ef468b3fde..89665efee8 100644
> --- a/meta/classes/python3native.bbclass
> +++ b/meta/classes/python3native.bbclass
> @@ -9,5 +9,8 @@ DEPENDS_append = " ${PYTHON_PN}-native "
>  export STAGING_INCDIR
>  export STAGING_LIBDIR
>
> +# suppress host user's site-packages dirs.
> +export PYTHONNOUSERSITE = "1"
> +
>  # autoconf macros will use their internal default preference otherwise
>  export PYTHON
> diff --git a/meta/classes/pythonnative.bbclass
> b/meta/classes/pythonnative.bbclass
> index 4e0381b568..4cc8b2769c 100644
> --- a/meta/classes/pythonnative.bbclass
> +++ b/meta/classes/pythonnative.bbclass
> @@ -12,5 +12,8 @@ DEPENDS_append = " ${PYTHON_PN}-native "
>  export STAGING_INCDIR
>  export STAGING_LIBDIR
>
> +# suppress host user's site-packages dirs.
> +export PYTHONNOUSERSITE = "1"
> +
>  # autoconf macros will use their internal default preference otherwise
>  export PYTHON
> --
> 2.11.0
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v8 00/13] Revamp the Go support

[Bruce Ashfield]

On Tue, Sep 12, 2017 at 8:50 AM, Otavio Salvador 
wrote:

> This improves the Go support on OE-Core.
>
> We are trying to port as much as possible work done by Matt on
> meta-golang back to OE-Core and also to avoid carrying old releases as
> there is no need to support more versions of Go toolchain.
>
> This fixes issues in existing support as well as add support for SDK
> generation which supports Go.
>

Testing against what has merged, and what are in these series is showing
that large
parts of the go applications that are used in meta-virt no longer work. Was
it the
intention of the re-work to not be compatible with existing users of the
language support ?

Just curious, since I haven't seen this flagged in this context
(compatibility), but now we
have to fixup the layers before I branch to match the release .. and that
was unexpected.

Bruce


>
> Changes in v8:
> - new patch
> - Fix patch header
>
> Changes in v7:
> - Fix Upstream-Status header typo
> - Add patch header
>
> Changes in v6:
> - new patch
> - new patch
> - new patch
> - new patch
> - new patch
> - new patch
> - new patch
> - new patch
> - new patch
> - new patch
> - new patch
> - new patch
>
> Matt Madison (12):
>   go-native: remove dependency on go-bootstrap-native
>   go-bootstrap-native: remove recipe
>   go: split out go-runtime into separate recipe
>   go.bbclass: remove GO_GCFLAGS nad GO_LDFLAGS
>   go.bbclass: remove some xxx_FINAL variables
>   go.bbclass: clean up CGO_xxx settings
>   go: rename go.inc -> go-target.inc
>   go-cross: take GOARM environment setting
>   go: enable nativesdk builds for the toolchain
>   go-crosssdk: add recipe
>   go.bbclass: enable nativesdk builds for Go packages
>   go-cross-canadian: add recipe
>
> Otavio Salvador (1):
>   go-dep: Move bash dependency to -dev package
>
>  meta/classes/go.bbclass|  54 +++--
>  meta/recipes-devtools/go/go-1.4.inc|  16 --
>  ...alignment-for-the-.rel.plt-section-on-32-.patch |  33 ---
>  .../go/go-1.4/016-armhf-elf-header.patch   |  24 ---
>  ...ckport-cmd-link-support-new-386-amd64-rel.patch | 225
> -
>  meta/recipes-devtools/go/go-1.4/syslog.patch   |  62 --
>  meta/recipes-devtools/go/go-1.8.inc|   6 +-
>  .../go/go-1.8/make-goroot-precious.patch   |  21 ++
>  .../go/go-1.8/set-gotooldir-during-bootstrap.patch |  22 ++
>  .../recipes-devtools/go/go-bootstrap-native_1.4.bb |   3 -
>  meta/recipes-devtools/go/go-common.inc |   2 +-
>  meta/recipes-devtools/go/go-cross-canadian.inc |  64 ++
>  meta/recipes-devtools/go/go-cross-canadian_1.8.bb  |   2 +
>  meta/recipes-devtools/go/go-cross.inc  |  61 +-
>  meta/recipes-devtools/go/go-cross_1.8.bb   |   5 +-
>  meta/recipes-devtools/go/go-crosssdk.inc   |  55 +
>  meta/recipes-devtools/go/go-crosssdk_1.8.bb|   2 +
>  meta/recipes-devtools/go/go-dep_0.3.0.bb   |   2 +-
>  meta/recipes-devtools/go/go-native.inc |  48 +++--
>  meta/recipes-devtools/go/go-native_1.8.bb  |   1 -
>  meta/recipes-devtools/go/go-runtime.inc|  58 ++
>  meta/recipes-devtools/go/go-runtime_1.8.bb |   2 +
>  meta/recipes-devtools/go/go-target.inc |  54 +
>  meta/recipes-devtools/go/go.inc|  81 
>  meta/recipes-devtools/go/go_1.8.bb |   2 +-
>  25 files changed, 394 insertions(+), 511 deletions(-)
>  delete mode 100644 meta/recipes-devtools/go/go-1.4.inc
>  delete mode 100644 meta/recipes-devtools/go/go-1.
> 4/0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch
>  delete mode 100644 meta/recipes-devtools/go/go-1.
> 4/016-armhf-elf-header.patch
>  delete mode 100644 meta/recipes-devtools/go/go-1.
> 4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch
>  delete mode 100644 meta/recipes-devtools/go/go-1.4/syslog.patch
>  create mode 100644 meta/recipes-devtools/go/go-1.
> 8/make-goroot-precious.patch
>  create mode 100644 meta/recipes-devtools/go/go-1.8/set-gotooldir-during-
> bootstrap.patch
>  delete mode 100644 meta/recipes-devtools/go/go-bootstrap-native_1.4.bb
>  create mode 100644 meta/recipes-devtools/go/go-cross-canadian.inc
>  create mode 100644 meta/recipes-devtools/go/go-cross-canadian_1.8.bb
>  create mode 100644 meta/recipes-devtools/go/go-crosssdk.inc
>  create mode 100644 meta/recipes-devtools/go/go-crosssdk_1.8.bb
>  create mode 100644 meta/recipes-devtools/go/go-runtime.inc
>  create mode 100644 meta/recipes-devtools/go/go-runtime_1.8.bb
>  create mode 100644 meta/recipes-devtools/go/go-target.inc
>  delete mode 100644 meta/recipes-devtools/go/go.inc
>
> --
> 2.14.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, 

[OE-core] [PATCH v8 3/3] kernel-devicetree.bbclass: Add support to generate append to kernel

[Otavio Salvador]

The are use cases where the Device Tree appended to the kernel is
convinient, so we generate the bundle concatenating the kernel (and
potentionally the initramfs) and the Device Tree binaries.

To enable it, set KERNEL_DEVICETREE_BUNDLE variable to '1'

Signed-off-by: Otavio Salvador 
---

Changes in v8:
- rework append support to support ARM and MIPS (obi)

Changes in v7:
- simplified code
- rename bundle to use .bin extension

Changes in v6: None
Changes in v5:
- add support for initramfs bundle

Changes in v4:
- new patch

Changes in v3: None
Changes in v2: None

 meta/classes/kernel-devicetree.bbclass | 62 +-
 1 file changed, 61 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
index 8723f24212..c618594c96 100644
--- a/meta/classes/kernel-devicetree.bbclass
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -1,6 +1,13 @@
 # Support for device tree generation
-PACKAGES_append = " kernel-devicetree"
+PACKAGES_append = " \
+kernel-devicetree \
+${@['kernel-image-zimage-bundle', ''][d.getVar('KERNEL_DEVICETREE_BUNDLE') 
!= '1']} \
+"
 FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb 
/${KERNEL_IMAGEDEST}/*.dtbo"
+FILES_kernel-image-zimage-bundle = "/${KERNEL_IMAGEDEST}/zImage-*.dtb.bin"
+
+# Generate kernel+devicetree bundle
+KERNEL_DEVICETREE_BUNDLE ?= "0"
 
 normalize_dtb () {
DTB="$1"
@@ -20,6 +27,38 @@ get_real_dtb_path_in_kernel () {
echo "${DTB_PATH}"
 }
 
+
+do_configure_devicetree() {
+   if [ "${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+   if echo ${KERNEL_IMAGETYPE_FOR_MAKE} | grep -q 'zImage'; then
+   case "${ARCH}" in
+   "arm")
+   config="${B}/.config"
+   if ! grep -q 'CONFIG_ARM_APPENDED_DTB=y' 
$config; then
+   bbwarn 'CONFIG_ARM_APPENDED_DTB is NOT 
enabled in the kernel. Enabling it to allow the kernel to boot with the Device 
Tree appended!'
+   sed -i "/CONFIG_ARM_APPENDED_DTB[ =]/d" 
$config
+   echo "CONFIG_ARM_APPENDED_DTB=y" >> 
$config
+   echo "# CONFIG_ARM_ATAG_DTB_COMPAT is 
not set" >> $config
+   fi
+   ;;
+   "mips")
+   config="${B}/.config"
+   if ! grep -q 'CONFIG_MIPS_APPENDED_DTB=y' 
$config; then
+   bbwarn 'CONFIG_MIPS_APPENDED_DTB is NOT 
enabled in the kernel. Enabling it to allow the kernel to boot with the Device 
Tree appended!'
+   sed -i "/CONFIG_MIPS_APPENDED_DTB[ 
=]/d" $config
+   echo "CONFIG_MIPS_APPENDED_DTB=y" >> 
$config
+   fi
+   ;;
+   *)
+   bberror "KERNEL_DEVICETREE_BUNDLE is not 
supported for ${ARCH}. Currently it is only supported for 'arm' and 'mips'."
+   esac
+   else
+   bberror 'The KERNEL_DEVICETREE_BUNDLE requires the 
KERNEL_IMAGETYPE to contain zImage.'
+   fi
+   fi
+}
+addtask configure_devicetree after do_configure before do_compile
+
 do_compile_devicetree() {
DTBS=""
for dtb in ${KERNEL_DEVICETREE}; do
@@ -43,6 +82,12 @@ fakeroot do_install_devicetree() {
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
ln -sf ${DTB_BASE_NAME}.${DTB_EXT} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
+
+   if [ "$type" = "zImage" ] && [ 
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+   cat ${D}/${KERNEL_IMAGEDEST}/$type \
+   
${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} \
+   > 
${D}/${KERNEL_IMAGEDEST}/$type-${DTB_BASE_NAME}.${DTB_EXT}.bin
+   fi
done
done
 }
@@ -63,6 +108,21 @@ do_deploy_append() {
install -m 0644 ${DTB_PATH} 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_BASE_NAME}.${DTB_EXT}
+
+   if [ "$type" = "zImage" ] && [ 
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+   cat ${DEPLOYDIR}/$type \
+   ${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT} \
+   > 

[OE-core] [PATCH v8 2/3] kernel-devicetree.bbclass: Rework to use tasks

[Otavio Salvador]

This reworks the compile and install in tasks as well as run the build
of the Device Tree files in parallel, if possible.

Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7:
- Split tasks change from linux-dtb rework
- Run do_compile_devicetree before do_compile_kernelmodules

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 meta/classes/kernel-devicetree.bbclass | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
index 72814ca224..8723f24212 100644
--- a/meta/classes/kernel-devicetree.bbclass
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -20,14 +20,19 @@ get_real_dtb_path_in_kernel () {
echo "${DTB_PATH}"
 }
 
-do_compile_append() {
-   for DTB in ${KERNEL_DEVICETREE}; do
-   DTB=`normalize_dtb "${DTB}"`
-   oe_runmake ${DTB}
+do_compile_devicetree() {
+   DTBS=""
+   for dtb in ${KERNEL_DEVICETREE}; do
+   dtb=`normalize_dtb "${dtb}"`
+   DTBS="$DTBS $dtb"
done
+   oe_runmake -C ${B} ${PARALLEL_MAKE} ${DTBS}
 }
+addtask compile_devicetree after do_compile before do_compile_kernelmodules 
do_install
 
-do_install_append() {
+do_install_devicetree[dirs] = "${B}"
+do_install_devicetree[umask] = "022"
+fakeroot do_install_devicetree() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
DTB_EXT=${DTB##*.}
@@ -41,6 +46,7 @@ do_install_append() {
done
done
 }
+addtask install_devicetree after do_install before do_deploy
 
 do_deploy_append() {
for DTB in ${KERNEL_DEVICETREE}; do
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 1/3] kernel: Move Device Tree support to kernel.bbclass

[Otavio Salvador]

The Device Tree is commonly used but it is still kept as a .inc file
instead of a proper class. Instead now we move the Device Tree code to
a kernel-devicetree class and automatically enable it when the
KERNEL_DEVICETREE variable is set.

To avoid breakage in existing layers, we kept a linux-dtb.inc file
which raises a warning telling the user about the change so in next
release this can be removed.

Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7:
- Avoid changing logic when reworking to a class

Changes in v6:
- Remove linux-dtb.inc from linux-yocto recipes
- Always inherit kernel-devicetree class

Changes in v5: None
Changes in v4:
- Rebase on top of 1/3

Changes in v3:
- rework compile and install to tasks
- improve commit log

Changes in v2:
- Wrong version as the changes were not staged. Sorry!

 meta/classes/kernel-devicetree.bbclass| 62 +
 meta/classes/kernel.bbclass   |  3 ++
 meta/recipes-kernel/linux/linux-dtb.inc   | 66 +--
 meta/recipes-kernel/linux/linux-yocto.inc |  1 -
 4 files changed, 67 insertions(+), 65 deletions(-)
 create mode 100644 meta/classes/kernel-devicetree.bbclass

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
new file mode 100644
index 00..72814ca224
--- /dev/null
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -0,0 +1,62 @@
+# Support for device tree generation
+PACKAGES_append = " kernel-devicetree"
+FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb 
/${KERNEL_IMAGEDEST}/*.dtbo"
+
+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."
+   DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
+   fi
+   echo "${DTB}"
+}
+
+get_real_dtb_path_in_kernel () {
+   DTB="$1"
+   DTB_PATH="${B}/arch/${ARCH}/boot/dts/${DTB}"
+   if [ ! -e "${DTB_PATH}" ]; then
+   DTB_PATH="${B}/arch/${ARCH}/boot/${DTB}"
+   fi
+   echo "${DTB_PATH}"
+}
+
+do_compile_append() {
+   for DTB in ${KERNEL_DEVICETREE}; do
+   DTB=`normalize_dtb "${DTB}"`
+   oe_runmake ${DTB}
+   done
+}
+
+do_install_append() {
+   for DTB in ${KERNEL_DEVICETREE}; do
+   DTB=`normalize_dtb "${DTB}"`
+   DTB_EXT=${DTB##*.}
+   DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
+   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT}
+   for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
+   symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
+   ln -sf ${DTB_BASE_NAME}.${DTB_EXT} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
+   done
+   done
+}
+
+do_deploy_append() {
+   for DTB in ${KERNEL_DEVICETREE}; do
+   DTB=`normalize_dtb "${DTB}"`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
+   for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
+   base_name=${type}"-"${KERNEL_IMAGE_BASE_NAME}
+   symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_NAME=`echo ${base_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
+   DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
+   DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
+   install -d ${DEPLOYDIR}
+   install -m 0644 ${DTB_PATH} 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_BASE_NAME}.${DTB_EXT}
+   done
+   done
+}
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 02a5e961cb..0ad522d167 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -662,3 +662,6 @@ do_deploy[prefuncs] += "package_get_auto_pr"
 addtask deploy after do_populate_sysroot do_packagedata
 
 EXPORT_FUNCTIONS do_deploy
+
+# Add using Device Tree support
+inherit kernel-devicetree
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc 
b/meta/recipes-kernel/linux/linux-dtb.inc
index ca92822d25..f1912775ca 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -1,65 +1,3 @@
-# Support for device tree generation
-FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb 
/${KERNEL_IMAGEDEST}/*.dtbo"
-
-python __anonymous () {
-d.appendVar("PACKAGES", " kernel-devicetree")
-}
-

Re: [OE-core] [PATCH v8 3/3] kernel-devicetree.bbclass: Add support to generate append to kernel

[Otavio Salvador]

Andreas,

On Tue, Sep 12, 2017 at 4:10 PM, Andreas Oberritter
 wrote:
> On Tue, 12 Sep 2017 14:00:43 -0300
> Otavio Salvador  wrote:
>> On Tue, Sep 12, 2017 at 11:45 AM, Andreas Oberritter
>>  wrote:
>> > Hi Otavio,
>> >
>> > On Tue, 12 Sep 2017 10:45:51 -0300
>> > Otavio Salvador  wrote:
>> >
>> >> +do_configure_devicetree() {
>> >> + if [ "${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
>> >> + if echo ${KERNEL_IMAGETYPE_FOR_MAKE} | grep -q 'zImage'; 
>> >> then
>> >> + config="${B}/.config"
>> >> + if ! grep -q 'CONFIG_ARM_APPENDED_DTB=y' $config; 
>> >> then
>> >> + bbwarn 'CONFIG_ARM_APPENDED_DTB is NOT 
>> >> enabled in the kernel. Enabling it to allow the kernel to boot with the 
>> >> Device Tree appended!'
>> >> + sed -i "/CONFIG_ARM_APPENDED_DTB[ =]/d" 
>> >> $config
>> >> + echo "CONFIG_ARM_APPENDED_DTB=y" >> $config
>> >> + echo "# CONFIG_ARM_ATAG_DTB_COMPAT is not 
>> >> set" >> $config
>> >
>> > what about CONFIG_MIPS_APPENDED_DTB?
>> >
>> > Can we ever make sure to cover all relevant architectures?
>>
>> I don't know the details about the MIPS and its appended DTB support.
>> Do you know what we need?
>
> Just the symbol already mentioned above, see [1].
>
> However, I'd argue that the verification of configuration options specific to 
> one
> or two architectures shouldn't be done here at all. Users are responsible to 
> choose
> suitable kernel options.

Ok; I will prepare the patch to support both.

I prefer to mangle the config here so we provide a turn-key support
for it. I am preparing a new patch revision adding it. I've added you
to Cc for the new patchset revision.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] qemurunner.py: wait for PID to appear in procfs

[Juro Bystricky]

We need QEMU PID in order to access "/proc//cmdline"
Having a valid QEMU PID does not mean we can access the proc entry
immediately, we need to wait for the /proc/ to appear
before we can access it.

Signed-off-by: Juro Bystricky 
---
 meta/lib/oeqa/utils/qemurunner.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 9073315..427ae23 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -394,9 +394,10 @@ class QemuRunner:
 f = open(self.qemu_pidfile, 'r')
 qemu_pid = f.read()
 f.close()
-#logger.info("qemu_pid: %s" % qemu_pid)
-self.qemupid = int(qemu_pid)
-return True
+qemupid = int(qemu_pid)
+if os.path.exists("/proc/" + str(qemupid)):
+self.qemupid = qemupid
+return True
 return False
 
 def run_serial(self, command, raw=False, timeout=5):
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v8 06/13] go-dep: Move bash dependency to -dev package

[Khem Raj]

On Tue, Sep 12, 2017 at 12:20 PM, Otavio Salvador
 wrote:
> On Tue, Sep 12, 2017 at 3:58 PM, Martin Jansa  wrote:
>> Seems like this version was already picked to master-next, so probably
>> better to leave as standalone change now.
>>
>> The version currently in master fails to build for arm with thumb enabled:
>> http://errors.yoctoproject.org/Errors/Details/155765/
>>
>> Is it fixed somewhere in this new patchset?
>>
>> # github.com/golang/dep/cmd/dep
>> TOPDIR/tmp-glibc/work/armv5te-oe-linux-gnueabi/go-dep/0.3.0-r0/recipe-sysroot-native/usr/lib/arm-oe-linux-gnueabi/go/pkg/tool/linux_amd64/link:
>> R_ARM_THM_CALL, are you using -marm?
>> WARNING: exit code 2 from a shell command.
>> ERROR: Function failed: do_compile (log file is located at
>> TOPDIR/tmp-glibc/work/armv5te-oe-linux-gnueabi/go-dep/0.3.0-r0/temp/log.do_compile.13531)
>
> No, it is not.
>
> It seems that Go, when using CGO, does not play nice with Thumb. Matt,
> do you know if there is a known fix for it?

Disable CGO for thumb, we have a variable to select cgo
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v8 06/13] go-dep: Move bash dependency to -dev package

[Otavio Salvador]

On Tue, Sep 12, 2017 at 3:58 PM, Martin Jansa  wrote:
> Seems like this version was already picked to master-next, so probably
> better to leave as standalone change now.
>
> The version currently in master fails to build for arm with thumb enabled:
> http://errors.yoctoproject.org/Errors/Details/155765/
>
> Is it fixed somewhere in this new patchset?
>
> # github.com/golang/dep/cmd/dep
> TOPDIR/tmp-glibc/work/armv5te-oe-linux-gnueabi/go-dep/0.3.0-r0/recipe-sysroot-native/usr/lib/arm-oe-linux-gnueabi/go/pkg/tool/linux_amd64/link:
> R_ARM_THM_CALL, are you using -marm?
> WARNING: exit code 2 from a shell command.
> ERROR: Function failed: do_compile (log file is located at
> TOPDIR/tmp-glibc/work/armv5te-oe-linux-gnueabi/go-dep/0.3.0-r0/temp/log.do_compile.13531)

No, it is not.

It seems that Go, when using CGO, does not play nice with Thumb. Matt,
do you know if there is a known fix for it?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v8 3/3] kernel-devicetree.bbclass: Add support to generate append to kernel

[Andreas Oberritter]

On Tue, 12 Sep 2017 14:00:43 -0300
Otavio Salvador  wrote:

> Hello Andreas,
> 
> On Tue, Sep 12, 2017 at 11:45 AM, Andreas Oberritter
>  wrote:
> > Hi Otavio,
> >
> > On Tue, 12 Sep 2017 10:45:51 -0300
> > Otavio Salvador  wrote:
> >  
> >> +do_configure_devicetree() {
> >> + if [ "${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
> >> + if echo ${KERNEL_IMAGETYPE_FOR_MAKE} | grep -q 'zImage'; then
> >> + config="${B}/.config"
> >> + if ! grep -q 'CONFIG_ARM_APPENDED_DTB=y' $config; 
> >> then
> >> + bbwarn 'CONFIG_ARM_APPENDED_DTB is NOT 
> >> enabled in the kernel. Enabling it to allow the kernel to boot with the 
> >> Device Tree appended!'
> >> + sed -i "/CONFIG_ARM_APPENDED_DTB[ =]/d" 
> >> $config
> >> + echo "CONFIG_ARM_APPENDED_DTB=y" >> $config
> >> + echo "# CONFIG_ARM_ATAG_DTB_COMPAT is not 
> >> set" >> $config  
> >
> > what about CONFIG_MIPS_APPENDED_DTB?
> >
> > Can we ever make sure to cover all relevant architectures?  
> 
> I don't know the details about the MIPS and its appended DTB support.
> Do you know what we need?
 
Just the symbol already mentioned above, see [1].

However, I'd argue that the verification of configuration options specific to 
one
or two architectures shouldn't be done here at all. Users are responsible to 
choose
suitable kernel options.

Regards,
Andreas

[1]: 
https://dev.openwrt.org/browser/trunk/target/linux/brcm63xx/patches-4.1/366-MIPS-add-support-for-vmlinux.bin-appended-DTB.patch?rev=46113
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v8 06/13] go-dep: Move bash dependency to -dev package

[Martin Jansa]

Seems like this version was already picked to master-next, so probably
better to leave as standalone change now.

The version currently in master fails to build for arm with thumb enabled:
http://errors.yoctoproject.org/Errors/Details/155765/

Is it fixed somewhere in this new patchset?

# github.com/golang/dep/cmd/dep
TOPDIR/tmp-glibc/work/armv5te-oe-linux-gnueabi/go-dep/0.3.0-r0/recipe-sysroot-native/usr/lib/arm-oe-linux-gnueabi/go/pkg/tool/linux_amd64/link:
R_ARM_THM_CALL, are you using -marm?
WARNING: exit code 2 from a shell command.
ERROR: Function failed: do_compile (log file is located at
TOPDIR/tmp-glibc/work/armv5te-oe-linux-gnueabi/go-dep/0.3.0-r0/temp/log.do_compile.13531)


On Tue, Sep 12, 2017 at 3:32 PM, Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:

> On Tue, Sep 12, 2017 at 10:15 AM, Martin Jansa 
> wrote:
> > Doesn't this belong into:
> > [OE-core] [PATCH v8 03/13] go: split out go-runtime into separate recipe
> > where it packaging change was probably introduced?
>
> I can squash it; in fact the change was introduced on "[v8,05/13]
> go.bbclass: remove some xxx_FINAL variables". Not sure if it is better
> or worse in this case. What do you think?
>
> > Also just RFC question, would it make sense to use:
> >
> > VIRTUAL-RUNTIME_bash ?= "bash"
> > RDEPENDS_${PN}-dev += "${VIRTUAL-RUNTIME_bash}"
> >
> > instead of the bash dependency directly? If it's acceptable for oe-core
> I'll
> > create change to do it for all recipe (I don't mind waiting after 2.4 is
> > released).
> >
> > Because right now for reasons described in
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=9217 I need to do the
> > above +
> > RDEPENDS_${PN}-dev_remove = "bash"
> > for many recipes with many bbappends, for our distro where we RPROVIDE
> bash
> > by busybox, which is good enough for package manager, but QA error is
> still
> > shown in cases where the real bash is built before the component
> rdpenending
> > on it.
>
> I'd be fine with this. It does make sense to allow the replacement of bash.
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] allarch: don't reset baselib

[Mark Hatle]

On 9/12/17 11:34 AM, Burton, Ross wrote:
> On 12 September 2017 at 17:28, Mark Hatle  > wrote:
> 
> On 9/12/17 10:59 AM, Ross Burton wrote:
> > allarch currently resets baselib to "lib" in an attempt to keep allarch 
> recipes
> > uniform.  However if the real value for $baselib is actually needed, 
> for example
> > in a multilib environment where $baselib is lib64 for standard binaries 
> and the
> > allarch package is using postinst intercepts which need to know the 
> real value
> > of $libdir, then a non-existant or incorrect $libdir will be used.
> >
> > Real world example: liberation-fonts is allarch and inherits fontcache, 
> which
> > uses a postinst intercept to run fc-cache inside qemu-user.  In a 
> multilib
> > configuration where normal libdir=/usr/lib64 and lib32 libdir=/usr/lib 
> qemu will
> > try running a 64-bit fc-cache with a 32-bit ld-linux, and predicatably 
> the
> > binary crashes.
> 
> This still won't work right.  If we put an allarch package in a 
> configuration
> that can be either 32-bit or 64-bit (which is the point of allarch), then 
> how
> will it know which arch this magic script is running on?
> 
> It sounds to me like the way the script is running needs to be fixed 
> (and/or
> qemu needs to be fixed).   Calls to QEMU should inherit the matching 
> system
> envrionment, not assume an environment from the post-install scripts.
> 
> 
> There's several problems, yes.  qemu needs to handle this more gracefully, but
> it's clearly being told by the postinst-intercept framework to run a binary in
> rootfs/usr/bin (64-bit) using libraries in rootfs/usr/lib (32-bit).  By not
> resetting baselib at least allarch packages think libdir is the "native" 
> libdir,
> not whatever /usr/lib happens to be.

The call to qemu really should not be embedded into the postinst-intercept
script.  The framework itself is what should 'know' what it is doing and deal
with it.  The package can provide hints.. perhaps something like:

call-qemu  

Then the postinst stuff would implement the call-qemu 'function' (wrapper or
whatever) that would do the right thing for a given arch specified.

> I guess the true solution is for the recipes to not need to know the library
> path.  Not sure how to do that yet though...
> 
> Also its interesting that nobody else noticed this: multilib images that
> installed fonts were segfaulting in rootfs...

If the segfault is causing the postinst to exit w/ an error (non-0) then it's
likely re-running on the target itself (and thus working).  If not, ugh.

I don't have a good answer how to resolve this 'right now' with the time we 
have.

--Mark
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v8 3/3] kernel-devicetree.bbclass: Add support to generate append to kernel

[Otavio Salvador]

Hello Andreas,

On Tue, Sep 12, 2017 at 11:45 AM, Andreas Oberritter
 wrote:
> Hi Otavio,
>
> On Tue, 12 Sep 2017 10:45:51 -0300
> Otavio Salvador  wrote:
>
>> +do_configure_devicetree() {
>> + if [ "${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
>> + if echo ${KERNEL_IMAGETYPE_FOR_MAKE} | grep -q 'zImage'; then
>> + config="${B}/.config"
>> + if ! grep -q 'CONFIG_ARM_APPENDED_DTB=y' $config; then
>> + bbwarn 'CONFIG_ARM_APPENDED_DTB is NOT enabled 
>> in the kernel. Enabling it to allow the kernel to boot with the Device Tree 
>> appended!'
>> + sed -i "/CONFIG_ARM_APPENDED_DTB[ =]/d" $config
>> + echo "CONFIG_ARM_APPENDED_DTB=y" >> $config
>> + echo "# CONFIG_ARM_ATAG_DTB_COMPAT is not set" 
>> >> $config
>
> what about CONFIG_MIPS_APPENDED_DTB?
>
> Can we ever make sure to cover all relevant architectures?

I don't know the details about the MIPS and its appended DTB support.
Do you know what we need?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] allarch: don't reset baselib

[Burton, Ross]

On 12 September 2017 at 17:28, Mark Hatle  wrote:

> On 9/12/17 10:59 AM, Ross Burton wrote:
> > allarch currently resets baselib to "lib" in an attempt to keep allarch
> recipes
> > uniform.  However if the real value for $baselib is actually needed, for
> example
> > in a multilib environment where $baselib is lib64 for standard binaries
> and the
> > allarch package is using postinst intercepts which need to know the real
> value
> > of $libdir, then a non-existant or incorrect $libdir will be used.
> >
> > Real world example: liberation-fonts is allarch and inherits fontcache,
> which
> > uses a postinst intercept to run fc-cache inside qemu-user.  In a
> multilib
> > configuration where normal libdir=/usr/lib64 and lib32 libdir=/usr/lib
> qemu will
> > try running a 64-bit fc-cache with a 32-bit ld-linux, and predicatably
> the
> > binary crashes.
>
> This still won't work right.  If we put an allarch package in a
> configuration
> that can be either 32-bit or 64-bit (which is the point of allarch), then
> how
> will it know which arch this magic script is running on?
>
> It sounds to me like the way the script is running needs to be fixed
> (and/or
> qemu needs to be fixed).   Calls to QEMU should inherit the matching system
> envrionment, not assume an environment from the post-install scripts.
>

There's several problems, yes.  qemu needs to handle this more gracefully,
but it's clearly being told by the postinst-intercept framework to run a
binary in rootfs/usr/bin (64-bit) using libraries in rootfs/usr/lib
(32-bit).  By not resetting baselib at least allarch packages think libdir
is the "native" libdir, not whatever /usr/lib happens to be.

I guess the true solution is for the recipes to not need to know the
library path.  Not sure how to do that yet though...

Also its interesting that nobody else noticed this: multilib images that
installed fonts were segfaulting in rootfs...

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] allarch: don't reset baselib

[Mark Hatle]

On 9/12/17 10:59 AM, Ross Burton wrote:
> allarch currently resets baselib to "lib" in an attempt to keep allarch 
> recipes
> uniform.  However if the real value for $baselib is actually needed, for 
> example
> in a multilib environment where $baselib is lib64 for standard binaries and 
> the
> allarch package is using postinst intercepts which need to know the real value
> of $libdir, then a non-existant or incorrect $libdir will be used.
> 
> Real world example: liberation-fonts is allarch and inherits fontcache, which
> uses a postinst intercept to run fc-cache inside qemu-user.  In a multilib
> configuration where normal libdir=/usr/lib64 and lib32 libdir=/usr/lib qemu 
> will
> try running a 64-bit fc-cache with a 32-bit ld-linux, and predicatably the
> binary crashes.

This still won't work right.  If we put an allarch package in a configuration
that can be either 32-bit or 64-bit (which is the point of allarch), then how
will it know which arch this magic script is running on?

It sounds to me like the way the script is running needs to be fixed (and/or
qemu needs to be fixed).   Calls to QEMU should inherit the matching system
envrionment, not assume an environment from the post-install scripts.

--Mark

> Signed-off-by: Ross Burton 
> ---
>  meta/classes/allarch.bbclass | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
> index 51ba509cd0a..e0326039d0c 100644
> --- a/meta/classes/allarch.bbclass
> +++ b/meta/classes/allarch.bbclass
> @@ -13,7 +13,7 @@ python () {
>  
>  # Set these to a common set of values, we shouldn't be using them 
> other that for WORKDIR directory
>  # naming anyway
> -d.setVar("baselib", "lib")
> +#d.setVar("baselib", "lib")
>  d.setVar("TARGET_ARCH", "allarch")
>  d.setVar("TARGET_OS", "linux")
>  d.setVar("TARGET_CC_ARCH", "none")
> @@ -48,4 +48,3 @@ python () {
>  elif bb.data.inherits_class('packagegroup', d) and not 
> bb.data.inherits_class('nativesdk', d):
>  bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit 
> packagegroup" % d.getVar("FILE"))
>  }
> -
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] allarch: don't reset baselib

[Ross Burton]

allarch currently resets baselib to "lib" in an attempt to keep allarch recipes
uniform.  However if the real value for $baselib is actually needed, for example
in a multilib environment where $baselib is lib64 for standard binaries and the
allarch package is using postinst intercepts which need to know the real value
of $libdir, then a non-existant or incorrect $libdir will be used.

Real world example: liberation-fonts is allarch and inherits fontcache, which
uses a postinst intercept to run fc-cache inside qemu-user.  In a multilib
configuration where normal libdir=/usr/lib64 and lib32 libdir=/usr/lib qemu will
try running a 64-bit fc-cache with a 32-bit ld-linux, and predicatably the
binary crashes.

Signed-off-by: Ross Burton 
---
 meta/classes/allarch.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 51ba509cd0a..e0326039d0c 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -13,7 +13,7 @@ python () {
 
 # Set these to a common set of values, we shouldn't be using them 
other that for WORKDIR directory
 # naming anyway
-d.setVar("baselib", "lib")
+#d.setVar("baselib", "lib")
 d.setVar("TARGET_ARCH", "allarch")
 d.setVar("TARGET_OS", "linux")
 d.setVar("TARGET_CC_ARCH", "none")
@@ -48,4 +48,3 @@ python () {
 elif bb.data.inherits_class('packagegroup', d) and not 
bb.data.inherits_class('nativesdk', d):
 bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit 
packagegroup" % d.getVar("FILE"))
 }
-
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v8 3/3] kernel-devicetree.bbclass: Add support to generate append to kernel

[Andreas Oberritter]

Hi Otavio,

On Tue, 12 Sep 2017 10:45:51 -0300
Otavio Salvador  wrote:

> +do_configure_devicetree() {
> + if [ "${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
> + if echo ${KERNEL_IMAGETYPE_FOR_MAKE} | grep -q 'zImage'; then
> + config="${B}/.config"
> + if ! grep -q 'CONFIG_ARM_APPENDED_DTB=y' $config; then
> + bbwarn 'CONFIG_ARM_APPENDED_DTB is NOT enabled 
> in the kernel. Enabling it to allow the kernel to boot with the Device Tree 
> appended!'
> + sed -i "/CONFIG_ARM_APPENDED_DTB[ =]/d" $config
> + echo "CONFIG_ARM_APPENDED_DTB=y" >> $config
> + echo "# CONFIG_ARM_ATAG_DTB_COMPAT is not set" 
> >> $config

what about CONFIG_MIPS_APPENDED_DTB?

Can we ever make sure to cover all relevant architectures?

Regards,
Andreas

> + fi
> + else
> + bberror 'The KERNEL_DEVICETREE_BUNDLE requires the 
> KERNEL_IMAGETYPE to contain zImage.'
> + fi
> + fi
> +}

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 3/3] kernel-devicetree.bbclass: Add support to generate append to kernel

[Otavio Salvador]

The are use cases where the Device Tree appended to the kernel is
convinient, so we generate the bundle concatenating the kernel (and
potentionally the initramfs) and the Device Tree binaries.

To enable it, set KERNEL_DEVICETREE_BUNDLE variable to '1'

Signed-off-by: Otavio Salvador 
---

Changes in v7:
- simplified code
- rename bundle to use .bin extension

Changes in v6: None
Changes in v5:
- add support for initramfs bundle

Changes in v4:
- new patch

Changes in v3: None
Changes in v2: None

 meta/classes/kernel-devicetree.bbclass | 48 +-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
index 8723f24212..54bed5b4c4 100644
--- a/meta/classes/kernel-devicetree.bbclass
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -1,6 +1,13 @@
 # Support for device tree generation
-PACKAGES_append = " kernel-devicetree"
+PACKAGES_append = " \
+kernel-devicetree \
+${@['kernel-image-zimage-bundle', ''][d.getVar('KERNEL_DEVICETREE_BUNDLE') 
!= '1']} \
+"
 FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb 
/${KERNEL_IMAGEDEST}/*.dtbo"
+FILES_kernel-image-zimage-bundle = "/${KERNEL_IMAGEDEST}/zImage-*.dtb.bin"
+
+# Generate kernel+devicetree bundle
+KERNEL_DEVICETREE_BUNDLE ?= "0"
 
 normalize_dtb () {
DTB="$1"
@@ -20,6 +27,24 @@ get_real_dtb_path_in_kernel () {
echo "${DTB_PATH}"
 }
 
+
+do_configure_devicetree() {
+   if [ "${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+   if echo ${KERNEL_IMAGETYPE_FOR_MAKE} | grep -q 'zImage'; then
+   config="${B}/.config"
+   if ! grep -q 'CONFIG_ARM_APPENDED_DTB=y' $config; then
+   bbwarn 'CONFIG_ARM_APPENDED_DTB is NOT enabled 
in the kernel. Enabling it to allow the kernel to boot with the Device Tree 
appended!'
+   sed -i "/CONFIG_ARM_APPENDED_DTB[ =]/d" $config
+   echo "CONFIG_ARM_APPENDED_DTB=y" >> $config
+   echo "# CONFIG_ARM_ATAG_DTB_COMPAT is not set" 
>> $config
+   fi
+   else
+   bberror 'The KERNEL_DEVICETREE_BUNDLE requires the 
KERNEL_IMAGETYPE to contain zImage.'
+   fi
+   fi
+}
+addtask configure_devicetree after do_configure before do_compile
+
 do_compile_devicetree() {
DTBS=""
for dtb in ${KERNEL_DEVICETREE}; do
@@ -43,6 +68,12 @@ fakeroot do_install_devicetree() {
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
ln -sf ${DTB_BASE_NAME}.${DTB_EXT} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
+
+   if [ "$type" = "zImage" ] && [ 
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+   cat ${D}/${KERNEL_IMAGEDEST}/$type \
+   
${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} \
+   > 
${D}/${KERNEL_IMAGEDEST}/$type-${DTB_BASE_NAME}.${DTB_EXT}.bin
+   fi
done
done
 }
@@ -63,6 +94,21 @@ do_deploy_append() {
install -m 0644 ${DTB_PATH} 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_BASE_NAME}.${DTB_EXT}
+
+   if [ "$type" = "zImage" ] && [ 
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+   cat ${DEPLOYDIR}/$type \
+   ${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT} \
+   > 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}.bin
+   ln -sf ${DTB_NAME}.${DTB_EXT}.bin 
${DEPLOYDIR}/$type-${DTB_BASE_NAME}.${DTB_EXT}.bin
+
+   if [ -e 
"${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
+   cat 
${KERNEL_OUTPUT_DIR}/${type}.initramfs \
+   
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT} \
+   > 
${DEPLOYDIR}/${type}-${INITRAMFS_BASE_NAME}-${DTB_BASE_NAME}.${DTB_EXT}.bin
+   ln -sf 
${type}-${INITRAMFS_BASE_NAME}-${DTB_BASE_NAME}.${DTB_EXT}.bin \
+  
${DEPLOYDIR}/${type}-initramfs-${DTB_BASE_NAME}.${DTB_EXT}-${MACHINE}.bin
+   fi
+   fi
done
done
 }
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

[OE-core] [PATCH v8 2/3] kernel-devicetree.bbclass: Rework to use tasks

[Otavio Salvador]

This reworks the compile and install in tasks as well as run the build
of the Device Tree files in parallel, if possible.

Signed-off-by: Otavio Salvador 
---

Changes in v7:
- Split tasks change from linux-dtb rework
- Run do_compile_devicetree before do_compile_kernelmodules

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 meta/classes/kernel-devicetree.bbclass | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
index 72814ca224..8723f24212 100644
--- a/meta/classes/kernel-devicetree.bbclass
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -20,14 +20,19 @@ get_real_dtb_path_in_kernel () {
echo "${DTB_PATH}"
 }
 
-do_compile_append() {
-   for DTB in ${KERNEL_DEVICETREE}; do
-   DTB=`normalize_dtb "${DTB}"`
-   oe_runmake ${DTB}
+do_compile_devicetree() {
+   DTBS=""
+   for dtb in ${KERNEL_DEVICETREE}; do
+   dtb=`normalize_dtb "${dtb}"`
+   DTBS="$DTBS $dtb"
done
+   oe_runmake -C ${B} ${PARALLEL_MAKE} ${DTBS}
 }
+addtask compile_devicetree after do_compile before do_compile_kernelmodules 
do_install
 
-do_install_append() {
+do_install_devicetree[dirs] = "${B}"
+do_install_devicetree[umask] = "022"
+fakeroot do_install_devicetree() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
DTB_EXT=${DTB##*.}
@@ -41,6 +46,7 @@ do_install_append() {
done
done
 }
+addtask install_devicetree after do_install before do_deploy
 
 do_deploy_append() {
for DTB in ${KERNEL_DEVICETREE}; do
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 1/3] kernel: Move Device Tree support to kernel.bbclass

[Otavio Salvador]

The Device Tree is commonly used but it is still kept as a .inc file
instead of a proper class. Instead now we move the Device Tree code to
a kernel-devicetree class and automatically enable it when the
KERNEL_DEVICETREE variable is set.

To avoid breakage in existing layers, we kept a linux-dtb.inc file
which raises a warning telling the user about the change so in next
release this can be removed.

Signed-off-by: Otavio Salvador 
---

Changes in v7:
- Avoid changing logic when reworking to a class

Changes in v6:
- Remove linux-dtb.inc from linux-yocto recipes
- Always inherit kernel-devicetree class

Changes in v5: None
Changes in v4:
- Rebase on top of 1/3

Changes in v3:
- rework compile and install to tasks
- improve commit log

Changes in v2:
- Wrong version as the changes were not staged. Sorry!

 meta/classes/kernel-devicetree.bbclass| 62 +
 meta/classes/kernel.bbclass   |  3 ++
 meta/recipes-kernel/linux/linux-dtb.inc   | 66 +--
 meta/recipes-kernel/linux/linux-yocto.inc |  1 -
 4 files changed, 67 insertions(+), 65 deletions(-)
 create mode 100644 meta/classes/kernel-devicetree.bbclass

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
new file mode 100644
index 00..72814ca224
--- /dev/null
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -0,0 +1,62 @@
+# Support for device tree generation
+PACKAGES_append = " kernel-devicetree"
+FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb 
/${KERNEL_IMAGEDEST}/*.dtbo"
+
+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."
+   DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
+   fi
+   echo "${DTB}"
+}
+
+get_real_dtb_path_in_kernel () {
+   DTB="$1"
+   DTB_PATH="${B}/arch/${ARCH}/boot/dts/${DTB}"
+   if [ ! -e "${DTB_PATH}" ]; then
+   DTB_PATH="${B}/arch/${ARCH}/boot/${DTB}"
+   fi
+   echo "${DTB_PATH}"
+}
+
+do_compile_append() {
+   for DTB in ${KERNEL_DEVICETREE}; do
+   DTB=`normalize_dtb "${DTB}"`
+   oe_runmake ${DTB}
+   done
+}
+
+do_install_append() {
+   for DTB in ${KERNEL_DEVICETREE}; do
+   DTB=`normalize_dtb "${DTB}"`
+   DTB_EXT=${DTB##*.}
+   DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
+   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT}
+   for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
+   symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
+   ln -sf ${DTB_BASE_NAME}.${DTB_EXT} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
+   done
+   done
+}
+
+do_deploy_append() {
+   for DTB in ${KERNEL_DEVICETREE}; do
+   DTB=`normalize_dtb "${DTB}"`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
+   for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
+   base_name=${type}"-"${KERNEL_IMAGE_BASE_NAME}
+   symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_NAME=`echo ${base_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
+   DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
+   DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
+   install -d ${DEPLOYDIR}
+   install -m 0644 ${DTB_PATH} 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_BASE_NAME}.${DTB_EXT}
+   done
+   done
+}
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 02a5e961cb..0ad522d167 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -662,3 +662,6 @@ do_deploy[prefuncs] += "package_get_auto_pr"
 addtask deploy after do_populate_sysroot do_packagedata
 
 EXPORT_FUNCTIONS do_deploy
+
+# Add using Device Tree support
+inherit kernel-devicetree
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc 
b/meta/recipes-kernel/linux/linux-dtb.inc
index ca92822d25..f1912775ca 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -1,65 +1,3 @@
-# Support for device tree generation
-FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb 
/${KERNEL_IMAGEDEST}/*.dtbo"
-
-python __anonymous () {
-d.appendVar("PACKAGES", " kernel-devicetree")
-}
-
-normalize_dtb () {
-

Re: [OE-core] [PATCH v8 06/13] go-dep: Move bash dependency to -dev package

[Otavio Salvador]

On Tue, Sep 12, 2017 at 10:15 AM, Martin Jansa  wrote:
> Doesn't this belong into:
> [OE-core] [PATCH v8 03/13] go: split out go-runtime into separate recipe
> where it packaging change was probably introduced?

I can squash it; in fact the change was introduced on "[v8,05/13]
go.bbclass: remove some xxx_FINAL variables". Not sure if it is better
or worse in this case. What do you think?

> Also just RFC question, would it make sense to use:
>
> VIRTUAL-RUNTIME_bash ?= "bash"
> RDEPENDS_${PN}-dev += "${VIRTUAL-RUNTIME_bash}"
>
> instead of the bash dependency directly? If it's acceptable for oe-core I'll
> create change to do it for all recipe (I don't mind waiting after 2.4 is
> released).
>
> Because right now for reasons described in
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9217 I need to do the
> above +
> RDEPENDS_${PN}-dev_remove = "bash"
> for many recipes with many bbappends, for our distro where we RPROVIDE bash
> by busybox, which is good enough for package manager, but QA error is still
> shown in cases where the real bash is built before the component rdpenending
> on it.

I'd be fine with this. It does make sense to allow the replacement of bash.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] image_types: support lz4 compressed squashfs

[Enrico Scholz]

Signed-off-by: Enrico Scholz 
---
 meta/classes/image_types.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 9b646e9..61dca62 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -107,6 +107,7 @@ IMAGE_CMD_btrfs () {
 IMAGE_CMD_squashfs = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs ${EXTRA_IMAGECMD} 
-noappend"
 IMAGE_CMD_squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-xz ${EXTRA_IMAGECMD} 
-noappend -comp xz"
 IMAGE_CMD_squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo 
${EXTRA_IMAGECMD} -noappend -comp lzo"
+IMAGE_CMD_squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lz4 
${EXTRA_IMAGECMD} -noappend -comp lz4"
 
 # By default, tar from the host is used, which can be quite old. If
 # you need special parameters (like --xattrs) which are only supported
@@ -236,6 +237,7 @@ do_image_btrfs[depends] += 
"btrfs-tools-native:do_populate_sysroot"
 do_image_squashfs[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_xz[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_squashfs_lzo[depends] += "squashfs-tools-native:do_populate_sysroot"
+do_image_squashfs_lz4[depends] += "squashfs-tools-native:do_populate_sysroot"
 do_image_elf[depends] += "virtual/kernel:do_populate_sysroot 
mkelfimage-native:do_populate_sysroot"
 do_image_ubi[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_ubifs[depends] += "mtd-utils-native:do_populate_sysroot"
@@ -251,7 +253,7 @@ IMAGE_TYPES = " \
 btrfs \
 iso \
 hddimg \
-squashfs squashfs-xz squashfs-lzo \
+squashfs squashfs-xz squashfs-lzo squashfs-lz4 \
 ubi ubifs multiubi \
 tar tar.gz tar.bz2 tar.xz tar.lz4 \
 cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
-- 
2.9.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] wic: apply --extra-space + --overhead to squashfs

[Enrico Scholz]

Ed Bartosh  writes:

> I agree. --size is less suitable for your needs than extra space and
> overhead factor. I still don't like the idea of using them to reserve
> non-formatted space.

Btw, exactly this is done for extX already.


> Any other ideas how to do it?

Perhaps, Logic can be moved into the disk_size() method:

|def disk_size(self):
|method = getattr(self, "_get_disk_size_" + prefix, None)
|if method:
|return method(self.size)
|elif self.fixed_size:
|return self.fixed_size
|else:
|return self.size
|
|def _get_disk_size_squashfs(size):
|return self.get_rootfs_size(size)

But I did not checked whether this really works.


Enrico
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v8 06/13] go-dep: Move bash dependency to -dev package

[Martin Jansa]

Doesn't this belong into:
[OE-core] [PATCH v8 03/13] go: split out go-runtime into separate recipe
where it packaging change was probably introduced?

Also just RFC question, would it make sense to use:

VIRTUAL-RUNTIME_bash ?= "bash"
RDEPENDS_${PN}-dev += "${VIRTUAL-RUNTIME_bash}"

instead of the bash dependency directly? If it's acceptable for oe-core
I'll create change to do it for all recipe (I don't mind waiting after 2.4
is released).

Because right now for reasons described in
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9217 I need to do the
above +
RDEPENDS_${PN}-dev_remove = "bash"
for many recipes with many bbappends, for our distro where we RPROVIDE bash
by busybox, which is good enough for package manager, but QA error is still
shown in cases where the real bash is built before the component
rdpenending on it.

Regards,


On Tue, Sep 12, 2017 at 2:50 PM, Otavio Salvador 
wrote:

> The src content has been moved to -dev package, so does the test
> routines. Fix the runtime dependency accordingly.
>
> Signed-off-by: Otavio Salvador 
> ---
>
> Changes in v8:
> - new patch
>
> Changes in v7: None
> Changes in v6: None
>
>  meta/recipes-devtools/go/go-dep_0.3.0.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/go/go-dep_0.3.0.bb
> b/meta/recipes-devtools/go/go-dep_0.3.0.bb
> index c65b4f7cb5..5e4544a104 100644
> --- a/meta/recipes-devtools/go/go-dep_0.3.0.bb
> +++ b/meta/recipes-devtools/go/go-dep_0.3.0.bb
> @@ -15,4 +15,4 @@ GO_INSTALL = "${GO_IMPORT}/cmd/dep"
>
>  INSANE_SKIP_${PN} += "ldflags"
>
> -RDEPENDS_${PN}-staticdev += "bash"
> +RDEPENDS_${PN}-dev += "bash"
> --
> 2.14.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] wic: apply --extra-space + --overhead to squashfs

[Ed Bartosh]

On Tue, Sep 12, 2017 at 02:18:41PM +0200, Enrico Scholz wrote:
> Ed Bartosh  writes:
> 
> >> >> >> The --extra-space and --overhead option did not had an effect to 
> >> >> >> squashfs
> >> >> >> partitions.  Although squashfs is read-only, it can be useful to 
> >> >> >> allocate
> >> >> >> more space for the on-disk partition to avoid repartitioning of the 
> >> >> >> whole
> >> >> >> disk when a new (and larger) squashfs image is written on later 
> >> >> >> updates.
> >> >> >
> >> >> > Is it possible to just use --size or --fixed-size in .wks to allocate
> >> >> > partition of certain size?
> >> >> 
> >> >> --fixed-size works with this patch (tested); --size should work.
> >> >
> >> > Sorry for not being clear. Why do we need this if we can use --size to
> >> > explicity specify partition size?
> >> 
> >> --size and --fixed-size did not had an effect for squashfs with the old
> >> code.
> >>
> >
> > I'd propose to fix this instead of applying extra space and overhead
> > factor to the filesystems that don't support this by design.
> >
> > The idea is to make size and fixed-size parameters to set partition size
> > and use extra-space and overhead-factor to extend filesystem size as
> > they're currently used.
> 
> For what is this overhead to be used?  In most cases, to allow future
> updates.  And this is required for squashfs too.
> 

It depends on the usage scenario. Additional space may be required
for other purposes too. It may me needed for the system to be able to
boot and perform what it was built for.

> Only difference is, that updates for squashfs are to be applied on
> partition level and these for other file systems on file system level.
> But the need for extra space exists in both cases.
> 
> 
> >> I want/need it to allow updates of the running system without complete
> >> repartitioning.  E.g. at wic creation time, the squashfs has a certain
> >> size.  Sometime in the future, there are needed e.g. 5 MiB more because
> >> a new package was added or so.
> >>
> >
> > Yep, I understood what you want. I think it's better achieved by setting
> > partition size with --size option than artificially apply extra-space and
> > overhead factor to the filesystem that doesn't support this.
> 
> It really does not matter for me whether the filesystem itself can be
> extended or whether I need a larger partition to apply future updates.
> 

It matters for me. I think I explained why.

> I just need a partition which provides an absolute or relative amount of
> additional space.
> 
> 
> >> I need to reserve space in the partition so that I can 'dd' the new
> >> image without a complete repartitioning.
> >> 
> >> --extra-space/--overhead has the meaning which I want (e.g. to say
> >> "reserve +20% for changes in the future").
> >
> > So far extra-space and overhead factor were used to allocate additional
> > space on the file system. This is different from the way you want to
> > use them. You're not allocating space on squashfs, you're allocating
> > unformatted space on the partition. It's better to use --size for this.
> 
> No; --size is not what I want. --size (or --fixed-size) assume that I
> know the absolute size.
> 
> Of course, I can get this size empirically.  But it is highly inflexible
> and requires different wks files for different image types.
> 
> I want to reserve an extra percentage for future updates.  And these
> percentages can be in the range of 1 - 5 MB (for small images with
> only test tools) or several hundred MB (for large image types with
> e.g. desktop environments).
> 
> --size or --fixed-size for these image types would be in completely
> different ranges while --extra-space/--overhead fits to all.
> 

I agree. --size is less suitable for your needs than extra space and
overhead factor. I still don't like the idea of using them to reserve
non-formatted space. Any other ideas how to do it?

--
Regards,
Ed
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 13/13] go-cross-canadian: add recipe

[Otavio Salvador]

From: Matt Madison 

Enable cross-canadian builds of the Go toolchain.  This
requires an additional patch to the Go source to allow us
to use the native GOTOOLDIR during the bootstrap phase.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8:
- Fix patch header

Changes in v7:
- Add patch header

Changes in v6:
- new patch

 meta/recipes-devtools/go/go-1.8.inc|  1 +
 .../go/go-1.8/set-gotooldir-during-bootstrap.patch | 22 
 meta/recipes-devtools/go/go-cross-canadian.inc | 64 ++
 meta/recipes-devtools/go/go-cross-canadian_1.8.bb  |  2 +
 4 files changed, 89 insertions(+)
 create mode 100644 
meta/recipes-devtools/go/go-1.8/set-gotooldir-during-bootstrap.patch
 create mode 100644 meta/recipes-devtools/go/go-cross-canadian.inc
 create mode 100644 meta/recipes-devtools/go/go-cross-canadian_1.8.bb

diff --git a/meta/recipes-devtools/go/go-1.8.inc 
b/meta/recipes-devtools/go/go-1.8.inc
index 2920d06f60..141c0994c3 100644
--- a/meta/recipes-devtools/go/go-1.8.inc
+++ b/meta/recipes-devtools/go/go-1.8.inc
@@ -15,6 +15,7 @@ SRC_URI += "\
file://split-host-and-target-build.patch \
file://gotooldir.patch \
file://make-goroot-precious.patch \
+   file://set-gotooldir-during-bootstrap.patch \
 "
 SRC_URI[main.md5sum] = "64e9380e07bba907e26a00cf5fcbe77e"
 SRC_URI[main.sha256sum] = 
"5f5dea2447e7dcfdc50fa6b94c512e58bfba5673c039259fd843f68829d99fa6"
diff --git 
a/meta/recipes-devtools/go/go-1.8/set-gotooldir-during-bootstrap.patch 
b/meta/recipes-devtools/go/go-1.8/set-gotooldir-during-bootstrap.patch
new file mode 100644
index 00..4b5e424d96
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.8/set-gotooldir-during-bootstrap.patch
@@ -0,0 +1,22 @@
+Set GOTOOLDIR during bootstrap 
+
+Signed-off-by: Matt Madison 
+Upstream-Status: Pending
+
+Index: go/src/make.bash
+===
+--- go.orig/src/make.bash
 go/src/make.bash
+@@ -172,10 +172,11 @@ if [ "$do_host_build" = "yes" ]; then
+   mv cmd/dist/dist "$GOTOOLDIR"/dist
+   echo
+ 
++  GOTOOLDIR_BOOTSTRAP="${GOTOOLDIR_BOOTSTRAP:-$GOTOOLDIR}"
+   echo "# Building packages and commands for host, 
$GOHOSTOS/$GOHOSTARCH."
+   # CC_FOR_TARGET is recorded as the default compiler for the go tool. 
When building for the host, however,
+   # use the host compiler, CC, from `cmd/dist/dist env` instead.
+-  CC=$CC GOOS=$GOHOSTOS GOARCH=$GOHOSTARCH \
++  CC=$CC GOOS=$GOHOSTOS GOARCH=$GOHOSTARCH 
GOTOOLDIR="$GOTOOLDIR_BOOTSTRAP" \
+   "$GOTOOLDIR"/go_bootstrap install -gcflags "$GO_GCFLAGS" 
-ldflags "$GO_LDFLAGS" -v std cmd
+   echo
+ fi
diff --git a/meta/recipes-devtools/go/go-cross-canadian.inc 
b/meta/recipes-devtools/go/go-cross-canadian.inc
new file mode 100644
index 00..f0315d558a
--- /dev/null
+++ b/meta/recipes-devtools/go/go-cross-canadian.inc
@@ -0,0 +1,64 @@
+inherit cross-canadian
+
+DEPENDS = "go-native virtual/${HOST_PREFIX}gcc-crosssdk 
virtual/nativesdk-${HOST_PREFIX}libc-for-gcc 
virtual/nativesdk-${HOST_PREFIX}compilerlibs"
+PN = "go-cross-canadian-${TRANSLATED_TARGET_ARCH}"
+
+export GOHOSTOS = "${BUILD_GOOS}"
+export GOHOSTARCH = "${BUILD_GOARCH}"
+export GOOS = "${HOST_GOOS}"
+export GOARCH = "${HOST_GOARCH}"
+export GOARM = "${HOST_GOARM}"
+export GOROOT_BOOTSTRAP = "${STAGING_LIBDIR_NATIVE}/go"
+export GOTOOLDIR_BOOTSTRAP = "${GOROOT_BOOTSTRAP}/pkg/tool/${BUILD_GOTUPLE}"
+export GOROOT_FINAL = "${libdir}/go"
+export CGO_ENABLED = "1"
+export CC_FOR_TARGET = "${HOST_CC}"
+export CXX_FOR_TARGET = "${HOST_CXX}"
+CC = "${@d.getVar('BUILD_CC', True).strip()}"
+export GO_LDFLAGS = '-linkmode external -extld ${HOST_PREFIX}gcc -extldflags 
"${TOOLCHAIN_OPTIONS} ${LDFLAGS}"'
+
+do_configure[noexec] = "1"
+
+do_compile() {
+   export GOBIN="${B}/bin"
+   rm -rf ${GOBIN} ${B}/pkg
+   mkdir ${GOBIN}
+   cd src
+   ./make.bash --host-only --no-banner
+   cd ${B}
+}
+
+
+make_wrapper() {
+rm -f ${D}${bindir}/$2
+cat <${D}${bindir}/$2
+#!/bin/bash
+here=\`dirname \$0\`
+native_goroot=\`readlink -f \$here/../../lib/${TARGET_SYS}/go\`
+export GOARCH="${TARGET_GOARCH}"
+export GOOS="${TARGET_GOOS}"
+export GOARM="\${GOARM:-${TARGET_GOARM}}"
+export GOTOOLDIR="\$native_goroot/pkg/tool/${HOST_GOTUPLE}"
+export GOROOT="\${GOROOT:-\$OECORE_TARGET_SYSROOT/${target_libdir}/go}"
+\$here/../../lib/${TARGET_SYS}/go/bin/$1 "\$@"
+END
+chmod +x ${D}${bindir}/$2
+}
+
+do_install() {
+   install -d ${D}${libdir}/go
+   cp --preserve=mode,timestamps -R ${B}/pkg ${D}${libdir}/go/
+   install -d ${D}${libdir}/go/src
+   (cd ${S}/src; for d in *; do \
+   [ -d $d ] && cp --preserve=mode,timestamps -R ${S}/src/$d 
${D}${libdir}/go/src/; \
+   done)
+   install -d ${D}${bindir} ${D}${libdir}/go/bin
+   for 

[OE-core] [PATCH v8 12/13] go.bbclass: enable nativesdk builds for Go packages

[Otavio Salvador]

From: Matt Madison 

Adding the necessary overrides for nativesdk builds.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- new patch

 meta/classes/go.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index 8fb41e5c09..8d363e86a2 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -20,12 +20,14 @@ def get_go_parallel_make(d):
 GO_PARALLEL_BUILD ?= "${@get_go_parallel_make(d)}"
 
 GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
+GOROOT_class-nativesdk = "${STAGING_DIR_TARGET}${libdir}/go"
 GOROOT = "${STAGING_LIBDIR}/go"
 export GOROOT
 export GOROOT_FINAL = "${libdir}/go"
 
 DEPENDS_GOLANG_class-target = "virtual/${TARGET_PREFIX}go 
virtual/${TARGET_PREFIX}go-runtime"
 DEPENDS_GOLANG_class-native = "go-native"
+DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk 
virtual/${TARGET_PREFIX}go-runtime"
 
 DEPENDS_append = " ${DEPENDS_GOLANG}"
 
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 05/13] go.bbclass: remove some xxx_FINAL variables

[Otavio Salvador]

From: Matt Madison 

GOROOT_FINAL is used by the Go linker for rewriting
source paths when the build GOROOT is not the same
as the runtime GOROOT, but the other _FINAL variables
aren't really needed.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- new patch

 meta/classes/go.bbclass | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index 0ff82ca2bb..c0b117d155 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -21,8 +21,7 @@ GO_PARALLEL_BUILD ?= "${@get_go_parallel_make(d)}"
 
 GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
 GOROOT = "${STAGING_LIBDIR}/go"
-GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
-GOBIN_FINAL = "${GOROOT_FINAL}/${GO_BUILD_BINDIR}"
+export GOROOT_FINAL = "${libdir}/go"
 
 DEPENDS_GOLANG_class-target = "virtual/${TARGET_PREFIX}go 
virtual/${TARGET_PREFIX}go-runtime"
 DEPENDS_GOLANG_class-native = "go-native"
@@ -38,18 +37,11 @@ GOTOOLDIR_class-native = 
"${STAGING_LIBDIR_NATIVE}/go/pkg/tool/${BUILD_GOTUPLE}"
 export GOTOOLDIR
 export CGO_ENABLED = "1"
 export GOROOT
-export GOROOT_FINAL = "${libdir}/go"
-export GOBIN_FINAL
-export GOPKG_FINAL = "${GOROOT_FINAL}/pkg/${TARGET_GOTUPLE}"
-export GOSRC_FINAL = "${GOROOT_FINAL}/src"
 export CGO_CFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_CFLAGS}"
 export CGO_CPPFLAGS = "${TARGET_CPPFLAGS}"
 export CGO_CXXFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} 
${TARGET_CXXFLAGS}"
 export CGO_LDFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_LDFLAGS}"
 
-FILES_${PN}-staticdev += "${GOSRC_FINAL}/${GO_IMPORT}"
-FILES_${PN}-staticdev += "${GOPKG_FINAL}/${GO_IMPORT}*"
-
 GO_INSTALL ?= "${GO_IMPORT}/..."
 GO_INSTALL_FILTEROUT ?= "${GO_IMPORT}/vendor/"
 
@@ -92,10 +84,10 @@ go_do_compile() {
 do_compile[cleandirs] = "${B}/bin ${B}/pkg"
 
 go_do_install() {
-   install -d ${D}${GOROOT_FINAL}/src/${GO_IMPORT}
+   install -d ${D}${libdir}/go/src/${GO_IMPORT}
tar -C ${S}/src/${GO_IMPORT} -cf - --exclude-vcs . | \
-   tar -C ${D}${GOROOT_FINAL}/src/${GO_IMPORT} --no-same-owner -xf 
-
-   tar -C ${B} -cf - pkg | tar -C ${D}${GOROOT_FINAL} --no-same-owner -xf -
+   tar -C ${D}${libdir}/go/src/${GO_IMPORT} --no-same-owner -xf -
+   tar -C ${B} -cf - pkg | tar -C ${D}${libdir}/go --no-same-owner -xf -
 
if [ -n "`ls ${B}/${GO_BUILD_BINDIR}/`" ]; then
install -d ${D}${bindir}
@@ -104,3 +96,6 @@ go_do_install() {
 }
 
 EXPORT_FUNCTIONS do_unpack do_configure do_compile do_install
+
+FILES_${PN}-dev = "${libdir}/go/src"
+FILES_${PN}-staticdev = "${libdir}/go/pkg"
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 08/13] go: rename go.inc -> go-target.inc

[Otavio Salvador]

From: Matt Madison 

to make it clearer that it is only used for building
the toolchain for the target.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- new patch

 meta/recipes-devtools/go/{go.inc => go-target.inc} | 0
 meta/recipes-devtools/go/go_1.8.bb | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/go/{go.inc => go-target.inc} (100%)

diff --git a/meta/recipes-devtools/go/go.inc 
b/meta/recipes-devtools/go/go-target.inc
similarity index 100%
rename from meta/recipes-devtools/go/go.inc
rename to meta/recipes-devtools/go/go-target.inc
diff --git a/meta/recipes-devtools/go/go_1.8.bb 
b/meta/recipes-devtools/go/go_1.8.bb
index ef8bc14383..08ab793f86 100644
--- a/meta/recipes-devtools/go/go_1.8.bb
+++ b/meta/recipes-devtools/go/go_1.8.bb
@@ -1,4 +1,4 @@
 require go-${PV}.inc
-require go.inc
+require go-target.inc
 TUNE_CCARGS_remove = "-march=mips32r2"
 SECURITY_PIE_CFLAGS_remove = "-fPIE -pie"
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 09/13] go-cross: take GOARM environment setting

[Otavio Salvador]

From: Matt Madison 

Instead of hard-coding GOARM to ${TARGET_GOARM} in
the wrapper script, take it from an existing
environment setting if present.  This allows the
same cross-compiler to be used for different ARM
targets.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- new patch

 meta/recipes-devtools/go/go-cross.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/go/go-cross.inc 
b/meta/recipes-devtools/go/go-cross.inc
index df3e4ea914..d18d9613ff 100644
--- a/meta/recipes-devtools/go/go-cross.inc
+++ b/meta/recipes-devtools/go/go-cross.inc
@@ -36,7 +36,7 @@ make_wrapper() {
 here=\`dirname \$0\`
 export GOARCH="${TARGET_GOARCH}"
 export GOOS="${TARGET_GOOS}"
-export GOARM="${TARGET_GOARM}"
+export GOARM="\${GOARM:-${TARGET_GOARM}}"
 \$here/../../lib/${CROSS_TARGET_SYS_DIR}/go/bin/$1 "\$@"
 END
 chmod +x ${D}${bindir}/$2
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 11/13] go-crosssdk: add recipe

[Otavio Salvador]

From: Matt Madison 

Enable crosssdk builds for the Go toolchain.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- new patch

 meta/recipes-devtools/go/go-crosssdk.inc| 55 +
 meta/recipes-devtools/go/go-crosssdk_1.8.bb |  2 ++
 2 files changed, 57 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-crosssdk.inc
 create mode 100644 meta/recipes-devtools/go/go-crosssdk_1.8.bb

diff --git a/meta/recipes-devtools/go/go-crosssdk.inc 
b/meta/recipes-devtools/go/go-crosssdk.inc
new file mode 100644
index 00..e9bc677131
--- /dev/null
+++ b/meta/recipes-devtools/go/go-crosssdk.inc
@@ -0,0 +1,55 @@
+inherit crosssdk
+
+DEPENDS = "go-native virtual/${TARGET_PREFIX}gcc-crosssdk 
virtual/nativesdk-${TARGET_PREFIX}compilerlibs 
virtual/${TARGET_PREFIX}binutils-crosssdk"
+PN = "go-crosssdk-${TARGET_ARCH}"
+PROVIDES = "virtual/${TARGET_PREFIX}go-crosssdk"
+
+export GOHOSTOS = "${BUILD_GOOS}"
+export GOHOSTARCH = "${BUILD_GOARCH}"
+export GOOS = "${TARGET_GOOS}"
+export GOARCH = "${TARGET_GOARCH}"
+export GOROOT_BOOTSTRAP = "${STAGING_LIBDIR_NATIVE}/go"
+export GOROOT_FINAL = "${libdir}/go"
+export CGO_ENABLED = "1"
+export CC_FOR_TARGET="${TARGET_PREFIX}gcc ${TARGET_CC_ARCH} 
--sysroot=${STAGING_DIR_TARGET}"
+export CXX_FOR_TARGET="${TARGET_PREFIX}g++ ${TARGET_CC_ARCH} 
--sysroot=${STAGING_DIR_TARGET}"
+CC = "${@d.getVar('BUILD_CC', True).strip()}"
+
+do_configure[noexec] = "1"
+
+do_compile() {
+   export GOBIN="${B}/bin"
+   rm -rf ${GOBIN} ${B}/pkg
+   mkdir ${GOBIN}
+   cd src
+   ./make.bash --host-only
+   cd ${B}
+}
+
+make_wrapper() {
+rm -f ${D}${bindir}/$2
+cat <${D}${bindir}/$2
+#!/bin/bash
+here=\`dirname \$0\`
+export GOARCH="${TARGET_GOARCH}"
+export GOOS="${TARGET_GOOS}"
+\$here/../../lib/${CROSS_TARGET_SYS_DIR}/go/bin/$1 "\$@"
+END
+chmod +x ${D}${bindir}/$2
+}
+
+do_install() {
+   install -d ${D}${libdir}/go
+   install -d ${D}${libdir}/go/bin
+   install -d ${D}${libdir}/go/pkg/tool
+   install -d ${D}${bindir}
+   cp --preserve=mode,timestamps -R ${S}/pkg/tool/${TARGET_GOTUPLE} 
${D}${libdir}/go/pkg/tool/
+   for f in ${B}/${GO_BUILD_BINDIR}/*
+   do
+   base=`basename $f`
+   install -m755 $f ${D}${libdir}/go/bin
+   make_wrapper $base ${TARGET_PREFIX}$base
+   done
+}
+
+FILES_${PN}-staticdev = "${libdir}/go/pkg"
diff --git a/meta/recipes-devtools/go/go-crosssdk_1.8.bb 
b/meta/recipes-devtools/go/go-crosssdk_1.8.bb
new file mode 100644
index 00..1857c8a577
--- /dev/null
+++ b/meta/recipes-devtools/go/go-crosssdk_1.8.bb
@@ -0,0 +1,2 @@
+require go-crosssdk.inc
+require go-${PV}.inc
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 10/13] go: enable nativesdk builds for the toolchain

[Otavio Salvador]

From: Matt Madison 

All that's needed is setting BBCLASSEXTEND.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- new patch

 meta/recipes-devtools/go/go-target.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/go/go-target.inc 
b/meta/recipes-devtools/go/go-target.inc
index 5984a60c28..0d80bf0d97 100644
--- a/meta/recipes-devtools/go/go-target.inc
+++ b/meta/recipes-devtools/go/go-target.inc
@@ -1,5 +1,6 @@
 inherit goarch
 DEPENDS = "virtual/${TARGET_PREFIX}go go-native"
+DEPENDS_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk go-native"
 
 export GOHOSTOS = "${BUILD_GOOS}"
 export GOHOSTARCH = "${BUILD_GOARCH}"
@@ -49,3 +50,5 @@ FILES_${PN} = "${libdir}/go/bin 
${libdir}/go/pkg/tool/${TARGET_GOTUPLE} ${bindir
 FILES_${PN}-dev = "${libdir}/go"
 RDEPENDS_${PN}-dev = "perl bash"
 INSANE_SKIP_${PN} = "ldflags"
+
+BBCLASSEXTEND = "nativesdk"
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 06/13] go-dep: Move bash dependency to -dev package

[Otavio Salvador]

The src content has been moved to -dev package, so does the test
routines. Fix the runtime dependency accordingly.

Signed-off-by: Otavio Salvador 
---

Changes in v8:
- new patch

Changes in v7: None
Changes in v6: None

 meta/recipes-devtools/go/go-dep_0.3.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/go/go-dep_0.3.0.bb 
b/meta/recipes-devtools/go/go-dep_0.3.0.bb
index c65b4f7cb5..5e4544a104 100644
--- a/meta/recipes-devtools/go/go-dep_0.3.0.bb
+++ b/meta/recipes-devtools/go/go-dep_0.3.0.bb
@@ -15,4 +15,4 @@ GO_INSTALL = "${GO_IMPORT}/cmd/dep"
 
 INSANE_SKIP_${PN} += "ldflags"
 
-RDEPENDS_${PN}-staticdev += "bash"
+RDEPENDS_${PN}-dev += "bash"
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 07/13] go.bbclass: clean up CGO_xxx settings

[Otavio Salvador]

From: Matt Madison 

* use conditional assignment for  the CGO_xxx
  variables, so they can be overridden more easily
* remove the TOOLCHAIN_OPTIONS and TARGET_CC_ARCH
  references, since those are already present in
  CC and CXX
* remove the TARGET_ prefix so the values are
  appropriate for native, nativesdk, etc. builds
* move the GOROOT export away from the CGO settings
  and closer to its definition

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- new patch

 meta/classes/go.bbclass | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index c0b117d155..8fb41e5c09 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -21,6 +21,7 @@ GO_PARALLEL_BUILD ?= "${@get_go_parallel_make(d)}"
 
 GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
 GOROOT = "${STAGING_LIBDIR}/go"
+export GOROOT
 export GOROOT_FINAL = "${libdir}/go"
 
 DEPENDS_GOLANG_class-target = "virtual/${TARGET_PREFIX}go 
virtual/${TARGET_PREFIX}go-runtime"
@@ -35,12 +36,12 @@ export GO = "${HOST_PREFIX}go"
 GOTOOLDIR = 
"${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go/pkg/tool/${BUILD_GOTUPLE}"
 GOTOOLDIR_class-native = 
"${STAGING_LIBDIR_NATIVE}/go/pkg/tool/${BUILD_GOTUPLE}"
 export GOTOOLDIR
-export CGO_ENABLED = "1"
-export GOROOT
-export CGO_CFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_CFLAGS}"
-export CGO_CPPFLAGS = "${TARGET_CPPFLAGS}"
-export CGO_CXXFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} 
${TARGET_CXXFLAGS}"
-export CGO_LDFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_LDFLAGS}"
+
+export CGO_ENABLED ?= "1"
+export CGO_CFLAGS ?= "${CFLAGS}"
+export CGO_CPPFLAGS ?= "${CPPFLAGS}"
+export CGO_CXXFLAGS ?= "${CXXFLAGS}"
+export CGO_LDFLAGS ?= "${LDFLAGS}"
 
 GO_INSTALL ?= "${GO_IMPORT}/..."
 GO_INSTALL_FILTEROUT ?= "${GO_IMPORT}/vendor/"
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 04/13] go.bbclass: remove GO_GCFLAGS nad GO_LDFLAGS

[Otavio Salvador]

From: Matt Madison 

These variables are not used anywhere.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- new patch

 meta/classes/go.bbclass | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index b3464d2105..0ff82ca2bb 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -42,8 +42,6 @@ export GOROOT_FINAL = "${libdir}/go"
 export GOBIN_FINAL
 export GOPKG_FINAL = "${GOROOT_FINAL}/pkg/${TARGET_GOTUPLE}"
 export GOSRC_FINAL = "${GOROOT_FINAL}/src"
-export GO_GCFLAGS = "${TARGET_CFLAGS}"
-export GO_LDFLAGS = "${TARGET_LDFLAGS}"
 export CGO_CFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_CFLAGS}"
 export CGO_CPPFLAGS = "${TARGET_CPPFLAGS}"
 export CGO_CXXFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} 
${TARGET_CXXFLAGS}"
-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 03/13] go: split out go-runtime into separate recipe

[Otavio Salvador]

From: Matt Madison 

Reorganize the Go toolchain build to split out
the Go standard runtime libraries into a separate
recipe.  This simplifies the extension to crosssdk
and cross-canadian builds.

* Adds a patch to the go build tool to prevent it
  from trying to rebuild anything in GOROOT, which
  is now resident in the target sysroot.

* 'go' bb and inc files are now for building the
  compiler for the target only.

* 'go-cross' bb and inc files are now just for
  the cross-compiler.

* Adds virtual/ PROVIDES for the compiler
  and runtime

* Removes testdata directories from the sysroot
  during staging, as they are unnecessary and
  can cause strip errors (some of the test files
  are ELF files).

* Re-enables pacakage QA checks, adding selective
  INSANE_SKIP settings where needed.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7:
- Fix Upstream-Status header typo

Changes in v6:
- new patch

 meta/classes/go.bbclass| 22 +++
 meta/recipes-devtools/go/go-1.8.inc|  1 +
 .../go/go-1.8/make-goroot-precious.patch   | 21 +++
 meta/recipes-devtools/go/go-cross.inc  | 61 ---
 meta/recipes-devtools/go/go-cross_1.8.bb   |  5 +-
 meta/recipes-devtools/go/go-runtime.inc| 58 ++
 meta/recipes-devtools/go/go-runtime_1.8.bb |  2 +
 meta/recipes-devtools/go/go.inc| 68 ++
 8 files changed, 167 insertions(+), 71 deletions(-)
 create mode 100644 meta/recipes-devtools/go/go-1.8/make-goroot-precious.patch
 create mode 100644 meta/recipes-devtools/go/go-runtime.inc
 create mode 100644 meta/recipes-devtools/go/go-runtime_1.8.bb

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index cb1e96d88b..b3464d2105 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -20,11 +20,11 @@ def get_go_parallel_make(d):
 GO_PARALLEL_BUILD ?= "${@get_go_parallel_make(d)}"
 
 GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
-GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
+GOROOT = "${STAGING_LIBDIR}/go"
 GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
 GOBIN_FINAL = "${GOROOT_FINAL}/${GO_BUILD_BINDIR}"
 
-DEPENDS_GOLANG_class-target = "go-cross-${TARGET_ARCH}"
+DEPENDS_GOLANG_class-target = "virtual/${TARGET_PREFIX}go 
virtual/${TARGET_PREFIX}go-runtime"
 DEPENDS_GOLANG_class-native = "go-native"
 
 DEPENDS_append = " ${DEPENDS_GOLANG}"
@@ -32,14 +32,15 @@ DEPENDS_append = " ${DEPENDS_GOLANG}"
 export GOBUILDFLAGS ?= "-v"
 GOBUILDFLAGS_prepend_task-compile = "${GO_PARALLEL_BUILD} "
 
-export GOOS = "${TARGET_GOOS}"
-export GOARCH = "${TARGET_GOARCH}"
-export GOARM = "${TARGET_GOARM}"
+export GO = "${HOST_PREFIX}go"
+GOTOOLDIR = 
"${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go/pkg/tool/${BUILD_GOTUPLE}"
+GOTOOLDIR_class-native = 
"${STAGING_LIBDIR_NATIVE}/go/pkg/tool/${BUILD_GOTUPLE}"
+export GOTOOLDIR
 export CGO_ENABLED = "1"
 export GOROOT
-export GOROOT_FINAL = "${libdir}/${TARGET_SYS}/go"
+export GOROOT_FINAL = "${libdir}/go"
 export GOBIN_FINAL
-export GOPKG_FINAL = "${GOROOT_FINAL}/pkg/${GOOS}_${GOARCH}"
+export GOPKG_FINAL = "${GOROOT_FINAL}/pkg/${TARGET_GOTUPLE}"
 export GOSRC_FINAL = "${GOROOT_FINAL}/src"
 export GO_GCFLAGS = "${TARGET_CFLAGS}"
 export GO_LDFLAGS = "${TARGET_LDFLAGS}"
@@ -55,6 +56,7 @@ GO_INSTALL ?= "${GO_IMPORT}/..."
 GO_INSTALL_FILTEROUT ?= "${GO_IMPORT}/vendor/"
 
 B = "${WORKDIR}/build"
+export GOPATH = "${B}"
 
 python go_do_unpack() {
 src_uri = (d.getVar('SRC_URI') or "").split()
@@ -75,7 +77,7 @@ python go_do_unpack() {
 }
 
 go_list_packages() {
-   GOPATH=${B}:${STAGING_LIBDIR}/${TARGET_SYS}/go go list -f 
'{{.ImportPath}}' ${GOBUILDFLAGS} ${GO_INSTALL} | \
+   ${GO} list -f '{{.ImportPath}}' ${GOBUILDFLAGS} ${GO_INSTALL} | \
egrep -v '${GO_INSTALL_FILTEROUT}'
 }
 
@@ -84,9 +86,9 @@ go_do_configure() {
 }
 
 go_do_compile() {
-   GOPATH=${B}:${STAGING_LIBDIR}/${TARGET_SYS}/go go env
+   ${GO} env
if [ -n "${GO_INSTALL}" ]; then
-   GOPATH=${B}:${STAGING_LIBDIR}/${TARGET_SYS}/go go install 
${GOBUILDFLAGS} `go_list_packages`
+   ${GO} install ${GOBUILDFLAGS} `go_list_packages`
fi
 }
 do_compile[cleandirs] = "${B}/bin ${B}/pkg"
diff --git a/meta/recipes-devtools/go/go-1.8.inc 
b/meta/recipes-devtools/go/go-1.8.inc
index bfb26de01d..2920d06f60 100644
--- a/meta/recipes-devtools/go/go-1.8.inc
+++ b/meta/recipes-devtools/go/go-1.8.inc
@@ -14,6 +14,7 @@ SRC_URI += "\
file://fix-cc-handling.patch \
file://split-host-and-target-build.patch \
file://gotooldir.patch \
+   file://make-goroot-precious.patch \
 "
 SRC_URI[main.md5sum] = "64e9380e07bba907e26a00cf5fcbe77e"
 SRC_URI[main.sha256sum] = 
"5f5dea2447e7dcfdc50fa6b94c512e58bfba5673c039259fd843f68829d99fa6"
diff --git 

[OE-core] [PATCH v8 00/13] Revamp the Go support

[Otavio Salvador]

This improves the Go support on OE-Core.

We are trying to port as much as possible work done by Matt on
meta-golang back to OE-Core and also to avoid carrying old releases as
there is no need to support more versions of Go toolchain.

This fixes issues in existing support as well as add support for SDK
generation which supports Go.

Changes in v8:
- new patch
- Fix patch header

Changes in v7:
- Fix Upstream-Status header typo
- Add patch header

Changes in v6:
- new patch
- new patch
- new patch
- new patch
- new patch
- new patch
- new patch
- new patch
- new patch
- new patch
- new patch
- new patch

Matt Madison (12):
  go-native: remove dependency on go-bootstrap-native
  go-bootstrap-native: remove recipe
  go: split out go-runtime into separate recipe
  go.bbclass: remove GO_GCFLAGS nad GO_LDFLAGS
  go.bbclass: remove some xxx_FINAL variables
  go.bbclass: clean up CGO_xxx settings
  go: rename go.inc -> go-target.inc
  go-cross: take GOARM environment setting
  go: enable nativesdk builds for the toolchain
  go-crosssdk: add recipe
  go.bbclass: enable nativesdk builds for Go packages
  go-cross-canadian: add recipe

Otavio Salvador (1):
  go-dep: Move bash dependency to -dev package

 meta/classes/go.bbclass|  54 +++--
 meta/recipes-devtools/go/go-1.4.inc|  16 --
 ...alignment-for-the-.rel.plt-section-on-32-.patch |  33 ---
 .../go/go-1.4/016-armhf-elf-header.patch   |  24 ---
 ...ckport-cmd-link-support-new-386-amd64-rel.patch | 225 -
 meta/recipes-devtools/go/go-1.4/syslog.patch   |  62 --
 meta/recipes-devtools/go/go-1.8.inc|   6 +-
 .../go/go-1.8/make-goroot-precious.patch   |  21 ++
 .../go/go-1.8/set-gotooldir-during-bootstrap.patch |  22 ++
 .../recipes-devtools/go/go-bootstrap-native_1.4.bb |   3 -
 meta/recipes-devtools/go/go-common.inc |   2 +-
 meta/recipes-devtools/go/go-cross-canadian.inc |  64 ++
 meta/recipes-devtools/go/go-cross-canadian_1.8.bb  |   2 +
 meta/recipes-devtools/go/go-cross.inc  |  61 +-
 meta/recipes-devtools/go/go-cross_1.8.bb   |   5 +-
 meta/recipes-devtools/go/go-crosssdk.inc   |  55 +
 meta/recipes-devtools/go/go-crosssdk_1.8.bb|   2 +
 meta/recipes-devtools/go/go-dep_0.3.0.bb   |   2 +-
 meta/recipes-devtools/go/go-native.inc |  48 +++--
 meta/recipes-devtools/go/go-native_1.8.bb  |   1 -
 meta/recipes-devtools/go/go-runtime.inc|  58 ++
 meta/recipes-devtools/go/go-runtime_1.8.bb |   2 +
 meta/recipes-devtools/go/go-target.inc |  54 +
 meta/recipes-devtools/go/go.inc|  81 
 meta/recipes-devtools/go/go_1.8.bb |   2 +-
 25 files changed, 394 insertions(+), 511 deletions(-)
 delete mode 100644 meta/recipes-devtools/go/go-1.4.inc
 delete mode 100644 
meta/recipes-devtools/go/go-1.4/0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch
 delete mode 100644 
meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.4/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.8/make-goroot-precious.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.8/set-gotooldir-during-bootstrap.patch
 delete mode 100644 meta/recipes-devtools/go/go-bootstrap-native_1.4.bb
 create mode 100644 meta/recipes-devtools/go/go-cross-canadian.inc
 create mode 100644 meta/recipes-devtools/go/go-cross-canadian_1.8.bb
 create mode 100644 meta/recipes-devtools/go/go-crosssdk.inc
 create mode 100644 meta/recipes-devtools/go/go-crosssdk_1.8.bb
 create mode 100644 meta/recipes-devtools/go/go-runtime.inc
 create mode 100644 meta/recipes-devtools/go/go-runtime_1.8.bb
 create mode 100644 meta/recipes-devtools/go/go-target.inc
 delete mode 100644 meta/recipes-devtools/go/go.inc

-- 
2.14.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v8 01/13] go-native: remove dependency on go-bootstrap-native

[Otavio Salvador]

From: Matt Madison 

The go1.4 toolchain is only required for bootstrapping
go-native, and should not be used for anything else,
so build it as part of the go-native build. This way,
we don't have to carry around its built artifacts in
the native sysroot.

The go-cross and target toolchains can then just depend
on go-native, using that for their 'bootstrap' toolchain.

Also removed some unnecessary package-related noexec
settings, since native recipes inherit nopackages.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- new patch

 meta/recipes-devtools/go/go-1.8.inc   |  4 +--
 meta/recipes-devtools/go/go-common.inc|  2 +-
 meta/recipes-devtools/go/go-native.inc| 48 +--
 meta/recipes-devtools/go/go-native_1.8.bb |  1 -
 meta/recipes-devtools/go/go.inc   |  4 +--
 5 files changed, 32 insertions(+), 27 deletions(-)

diff --git a/meta/recipes-devtools/go/go-1.8.inc 
b/meta/recipes-devtools/go/go-1.8.inc
index 3690f310bd..bfb26de01d 100644
--- a/meta/recipes-devtools/go/go-1.8.inc
+++ b/meta/recipes-devtools/go/go-1.8.inc
@@ -15,5 +15,5 @@ SRC_URI += "\
file://split-host-and-target-build.patch \
file://gotooldir.patch \
 "
-SRC_URI[md5sum] = "64e9380e07bba907e26a00cf5fcbe77e"
-SRC_URI[sha256sum] = 
"5f5dea2447e7dcfdc50fa6b94c512e58bfba5673c039259fd843f68829d99fa6"
+SRC_URI[main.md5sum] = "64e9380e07bba907e26a00cf5fcbe77e"
+SRC_URI[main.sha256sum] = 
"5f5dea2447e7dcfdc50fa6b94c512e58bfba5673c039259fd843f68829d99fa6"
diff --git a/meta/recipes-devtools/go/go-common.inc 
b/meta/recipes-devtools/go/go-common.inc
index f74b8b7650..ce1eb86812 100644
--- a/meta/recipes-devtools/go/go-common.inc
+++ b/meta/recipes-devtools/go/go-common.inc
@@ -14,7 +14,7 @@ LICENSE = "BSD-3-Clause"
 
 inherit goarch
 
-SRC_URI = "http://golang.org/dl/go${PV}.src.tar.gz;
+SRC_URI = "http://golang.org/dl/go${PV}.src.tar.gz;name=main;
 S = "${WORKDIR}/go"
 B = "${S}"
 
diff --git a/meta/recipes-devtools/go/go-native.inc 
b/meta/recipes-devtools/go/go-native.inc
index c21f8fda78..9eb2b3211f 100644
--- a/meta/recipes-devtools/go/go-native.inc
+++ b/meta/recipes-devtools/go/go-native.inc
@@ -1,16 +1,28 @@
+# Use immediate assingment here to get the original (/usr/lib)
+# instead of the one rewritten by native.bbclass.
+nonstaging_libdir := "${libdir}"
+
 inherit native
 
-BOOTSTRAP ?= ""
+SRC_URI_append = " 
http://golang.org/dl/go1.4.3.src.tar.gz;name=bootstrap;subdir=go1.4;
+SRC_URI[bootstrap.md5sum] = "dfb60455dd402a77a553a5923a04"
+SRC_URI[bootstrap.sha256sum] = 
"9947fc705b0b841b5938c48b22dc33e9647ec0752bae66e50278df4f23f64959"
+
 export GOOS = "${BUILD_GOOS}"
 export GOARCH = "${BUILD_GOARCH}"
-export GOROOT_FINAL = "${STAGING_LIBDIR_NATIVE}/go${BOOTSTRAP}"
-export GOROOT_BOOTSTRAP = "${STAGING_LIBDIR_NATIVE}/go1.4"
+CC = "${@d.getVar('BUILD_CC', True).strip()}"
+
 export CGO_ENABLED = "1"
 
-do_configure[noexec] = "1"
+do_configure() {
+cd ${WORKDIR}/go1.4/go/src
+CGO_ENABLED=0 GOROOT=${WORKDIR}/go1.4/go ./make.bash
+}
 
 do_compile() {
export GOBIN="${B}/bin"
+   export GOROOT_FINAL="${nonstaging_libdir}/go"
+   export GOROOT_BOOTSTRAP="${WORKDIR}/go1.4/go"
rm -rf ${GOBIN}
mkdir ${GOBIN}
 
@@ -18,7 +30,7 @@ do_compile() {
mkdir -p ${WORKDIR}/build-tmp
 
cd src
-   CGO_ENABLED=0 ./make.bash --host-only
+   ./make.bash --host-only
 }
 
 make_wrapper() {
@@ -26,31 +38,25 @@ make_wrapper() {
cat <${D}${bindir}/$2$3
 #!/bin/bash
 here=\`dirname \$0\`
-export GOROOT="${GOROOT:-\`readlink -f \$here/../lib/go$3\`}"
-\$here/../lib/go$3/bin/$1 "\$@"
+export GOROOT="${GOROOT:-\`readlink -f \$here/../lib/go\`}"
+\$here/../lib/go/bin/$1 "\$@"
 END
-   chmod +x ${D}${bindir}/$2$3
+   chmod +x ${D}${bindir}/$2
 }
 
 do_install() {
-   install -d ${D}${libdir}/go${BOOTSTRAP}
-   cp -a ${B}/pkg ${D}${libdir}/go${BOOTSTRAP}/
-   install -d ${D}${libdir}/go${BOOTSTRAP}/src
+   install -d ${D}${libdir}/go
+   cp --preserve=mode,timestamps -R ${B}/pkg ${D}${libdir}/go/
+   install -d ${D}${libdir}/go/src
(cd ${S}/src; for d in *; do \
-   [ -d $d ] && cp -a ${S}/src/$d 
${D}${libdir}/go${BOOTSTRAP}/src/; \
+   [ -d $d ] && cp -a ${S}/src/$d ${D}${libdir}/go/src/; \
done)
 
-   install -d ${D}${bindir} ${D}${libdir}/go${BOOTSTRAP}/bin
+   install -d ${D}${bindir} ${D}${libdir}/go/bin
for f in ${B}/bin/*
do
base=`basename $f`
-   install -m755 $f ${D}${libdir}/go${BOOTSTRAP}/bin
-   make_wrapper $base $base ${BOOTSTRAP}
+   install -m755 $f ${D}${libdir}/go/bin
+   make_wrapper $base $base
done
 }
-
-do_package[noexec] = "1"
-do_packagedata[noexec] = "1"
-do_package_write_ipk[noexec] = "1"

[OE-core] [PATCH v8 02/13] go-bootstrap-native: remove recipe

[Otavio Salvador]

From: Matt Madison 

No longer needed, with go-native handling its own
bootstrap phase.

Signed-off-by: Matt Madison 
Signed-off-by: Otavio Salvador 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- new patch

 meta/recipes-devtools/go/go-1.4.inc|  16 --
 ...alignment-for-the-.rel.plt-section-on-32-.patch |  33 ---
 .../go/go-1.4/016-armhf-elf-header.patch   |  24 ---
 ...ckport-cmd-link-support-new-386-amd64-rel.patch | 225 -
 meta/recipes-devtools/go/go-1.4/syslog.patch   |  62 --
 .../recipes-devtools/go/go-bootstrap-native_1.4.bb |   3 -
 6 files changed, 363 deletions(-)
 delete mode 100644 meta/recipes-devtools/go/go-1.4.inc
 delete mode 100644 
meta/recipes-devtools/go/go-1.4/0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch
 delete mode 100644 
meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch
 delete mode 100644 meta/recipes-devtools/go/go-1.4/syslog.patch
 delete mode 100644 meta/recipes-devtools/go/go-bootstrap-native_1.4.bb

diff --git a/meta/recipes-devtools/go/go-1.4.inc 
b/meta/recipes-devtools/go/go-1.4.inc
deleted file mode 100644
index 2f500f32b9..00
--- a/meta/recipes-devtools/go/go-1.4.inc
+++ /dev/null
@@ -1,16 +0,0 @@
-require go-common.inc
-
-PV = "1.4.3"
-GO_BASEVERSION = "1.4"
-FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:"
-
-SRC_URI += "\
-file://016-armhf-elf-header.patch \
-file://go-cross-backport-cmd-link-support-new-386-amd64-rel.patch \
-file://syslog.patch \
-file://0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch 
\
-"
-
-LIC_FILES_CHKSUM = "file://LICENSE;md5=591778525c869cdde0ab5a1bf283cd81"
-SRC_URI[md5sum] = "dfb60455dd402a77a553a5923a04"
-SRC_URI[sha256sum] = 
"9947fc705b0b841b5938c48b22dc33e9647ec0752bae66e50278df4f23f64959"
diff --git 
a/meta/recipes-devtools/go/go-1.4/0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch
 
b/meta/recipes-devtools/go/go-1.4/0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch
deleted file mode 100644
index f2adc200b1..00
--- 
a/meta/recipes-devtools/go/go-1.4/0001-cmd-ld-set-alignment-for-the-.rel.plt-section-on-32-.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From 855145d5c03c4b4faf60736c38d7a299c682af4a Mon Sep 17 00:00:00 2001
-From: Shenghou Ma 
-Date: Sat, 7 Feb 2015 14:06:02 -0500
-Subject: [PATCH] cmd/ld: set alignment for the .rel.plt section on 32-bit
- architectures
-
-Fixes #9802.
-
-Change-Id: I22c52a37bdb23a14cc4615c9519431bb14ca81ca
-Reviewed-on: https://go-review.googlesource.com/4170
-Reviewed-by: Ian Lance Taylor 

-Upstream-Status: Backport
-Signed-off-by: Khem Raj 
-
- src/cmd/ld/elf.c | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/src/cmd/ld/elf.c b/src/cmd/ld/elf.c
-index 12ced98..97ed4bd 100644
 a/src/cmd/ld/elf.c
-+++ b/src/cmd/ld/elf.c
-@@ -1363,6 +1363,7 @@ asmbelf(vlong symo)
-   sh->type = SHT_REL;
-   sh->flags = SHF_ALLOC;
-   sh->entsize = ELF32RELSIZE;
-+  sh->addralign = 4;
-   sh->link = elfshname(".dynsym")->shnum;
-   shsym(sh, linklookup(ctxt, ".rel.plt", 0));
- 
--- 
-1.9.1
-
diff --git a/meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch 
b/meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch
deleted file mode 100644
index e6e414e52f..00
--- a/meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch
+++ /dev/null
@@ -1,24 +0,0 @@
-Description: Use correct ELF header for armhf binaries.
-Author: Adam Conrad 
-Last-Update: 2013-07-08
-
-Upstream-Status: Pending
-Signed-off-by: Khem Raj 
-
-Index: go/src/cmd/ld/elf.c
-===
 go.orig/src/cmd/ld/elf.c   2015-02-20 10:49:58.763451586 -0800
-+++ go/src/cmd/ld/elf.c2015-02-20 10:49:27.895478521 -0800
-@@ -57,7 +57,11 @@
-   case '5':
-   // we use EABI on both linux/arm and freebsd/arm.
-   if(HEADTYPE == Hlinux || HEADTYPE == Hfreebsd)
--  hdr.flags = 0x502; // has entry point, Version5 EABI
-+#ifdef __ARM_PCS_VFP
-+  hdr.flags = 0x5000402; // has entry point, Version5 
EABI, hard-float ABI
-+#else
-+  hdr.flags = 0x5000202; // has entry point, Version5 
EABI, soft-float ABI
-+#endif
-   // fallthrough
-   default:
-   hdr.phoff = ELF32HDRSIZE;   /* Must be be ELF32HDRSIZE: 
first PHdr must follow ELF header */
diff --git 
a/meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch
 

Re: [OE-core] [PATCH] image_types: support lz4 compressed squashfs

[Richard Purdie]

On Fri, 2017-09-08 at 12:22 +0200, Enrico Scholz wrote:
> Signed-off-by: Enrico Scholz 
> ---
>  meta/classes/image_types.bbclass | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

This seems to cause "oe-selftest -r
imagefeatures.ImageFeatures.test_image_fstypes" to fail:


2017-09-12 12:20:48,435 - oe-selftest - INFO - 
==
2017-09-12 12:20:48,435 - oe-selftest - INFO - FAIL [61.543s]: 
test_image_fstypes (imagefeatures.ImageFeatures)
2017-09-12 12:20:48,435 - oe-selftest - INFO - 
--
2017-09-12 12:20:48,436 - oe-selftest - INFO - Traceback (most recent call 
last):
  File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/core/decorator/__init__.py",
 line 32, in wrapped_f
return func(*args, **kwargs)
  File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/selftest/cases/imagefeatures.py",
 line 228, in test_image_fstypes
"%s image %s doesn't exist" % (itype, image_path))
AssertionError: False is not true : squashfs-lz4 image 
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.squashfs-lz4
 doesn't exist

(from 
https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/512/steps/Running%20oe-selftest/logs/stdio)

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-commits] [openembedded-core] branch master updated (cc319b6 -> 2ebbeb6)

[Bruce Ashfield]

On 09/12/2017 06:58 AM, Martin Jansa wrote:

Hi,

I don't see any obvious change in this update which should cause this, 
but rebuilding my image for raspberrypi3-64 after this update (the 
previous image was built without errors) shows:


NOTE: Running task 417 of 6399 
(/OE/build/owpb/webos-ports/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_validate_branches)
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task 
do_validate_branches: Started


NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task 
do_validate_branches: Succeeded
NOTE: Running task 434 of 6399 
(/OE/build/owpb/webos-ports/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_kernel_metadata)
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task 
do_kernel_metadata: Started
ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0 
do_kernel_metadata: Could not locate BSP definition for 
raspberrypi3-64/standard and no defconfig was provided
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task 
do_kernel_metadata: Succeeded

...
NOTE: Running task 454 of 6399 
(/OE/build/owpb/webos-ports/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_patch)
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task 
do_patch: Started
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task 
do_patch: Succeeded
NOTE: Running task 491 of 6399 
(/OE/build/owpb/webos-ports/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_kernel_configme)
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task 
do_kernel_configme: Started
ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0 
do_kernel_configme: [ERROR]: no configuration queue found in outdir 
(.kernel-meta)


  scc [--help] [--configs] [--force] [-i] [-w] [--cmds list>] [-o outdir:] [-D=] [-I] [-v] 
infiles


   --help:  This message
   --force: force overwrite output file if it already exists
   --cmds:  list of supported commands. If not passed, all found 
commands are loaded,

valid commands are: patch, kconf, branch, define
   --configs:   Output the list of compiled configuration fragments 
(if available), -o  is

used to locate the configuration options
   -D:  define  to  which will be available to 
sub scripts

   -I:  include path  will be searched for files
   -i:  leave intermediate files on failure
   -w:  only warn on missing files
   -v:  verbose output
   -o:  output directory and artifacts. artifacts follow the 
colon and ar a comma

separated list of:
meta:  full meta-series (patches, config, 
branches, etc)

cfg:   configure fragment queue
patch: patch queue

   infiles  files to preprocess, and output into outfile or stdout
ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0 
do_kernel_configme: Could not find configuration queue 
(.kernel-meta/config.queue)
ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0 
do_kernel_configme: Function failed: do_kernel_configme (log file is 
located at 
/OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_64-webos-linux/linux-raspberrypi/1_4.9.41+gitAUTOINC+4153f509b4-r0/temp/log.do_kernel_configme.19498)
ERROR: Logfile of failure stored in: 
/OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_64-webos-linux/linux-raspberrypi/1_4.9.41+gitAUTOINC+4153f509b4-r0/temp/log.do_kernel_configme.19498

Log data follows:
| DEBUG: Executing shell function do_kernel_configme
| ERROR: [ERROR]: no configuration queue found in outdir (.kernel-meta)
|
|  scc [--help] [--configs] [--force] [-i] [-w] [--cmds list>] [-o outdir:] [-D=] [-I] [-v] 
infiles

|
|   --help:  This message
|   --force: force overwrite output file if it already exists
|   --cmds:  list of supported commands. If not passed, all 
found commands are loaded,

|valid commands are: patch, kconf, branch, define
|   --configs:   Output the list of compiled configuration fragments 
(if available), -o  is

|used to locate the configuration options
|   -D:  define  to  which will be available to 
sub scripts

|   -I:  include path  will be searched for files
|   -i:  leave intermediate files on failure
|   -w:  only warn on missing files
|   -v:  verbose output
|   -o:  output directory and artifacts. artifacts follow 
the colon and ar a comma

|separated list of:
|meta:  full meta-series (patches, config, 
branches, etc)

|cfg:   configure fragment queue
|patch: patch queue
|
|   infiles  files to 

Re: [OE-core] [PATCH v7 00/12] Revamp the Go support

[Otavio Salvador]

On Tue, Sep 12, 2017 at 8:57 AM, Matt Madison  wrote:
> On Tue, Sep 12, 2017 at 2:58 AM, Martin Jansa  wrote:
>> Interesting I've seen this issue only for PN-staticdev package
>> ERROR: QA Issue: go-dep-staticdev rdepends on bash, but it isn't a build
>> dependency, missing bash in DEPENDS or PACKAGECONFIG? [build-deps]
>>
>> and the bash is already in RDEPENDS (the warning is shown in our builds,
>> because we use busybox as RPROVIDER for bash).
>>
>> So maybe this file isn't always included? Or something else might be
>> non-deterministic.
>
> Depends on which patch set you were testing against.  One of the
> recent go.bbclass changes moved the sources from the -staticdev
> package to the -dev package (which is more appropriate, since the
> sources are also the header files).  I thought I had updated the
> go-dep recipe along with that, but I may have missed it.

You're right. I am fixing it now ...

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v7 00/12] Revamp the Go support

[Martin Jansa]

On Tue, Sep 12, 2017 at 04:57:49AM -0700, Matt Madison wrote:
> On Tue, Sep 12, 2017 at 2:58 AM, Martin Jansa  wrote:
> > Interesting I've seen this issue only for PN-staticdev package
> > ERROR: QA Issue: go-dep-staticdev rdepends on bash, but it isn't a build
> > dependency, missing bash in DEPENDS or PACKAGECONFIG? [build-deps]
> >
> > and the bash is already in RDEPENDS (the warning is shown in our builds,
> > because we use busybox as RPROVIDER for bash).
> >
> > So maybe this file isn't always included? Or something else might be
> > non-deterministic.
> 
> Depends on which patch set you were testing against.  One of the
> recent go.bbclass changes moved the sources from the -staticdev
> package to the -dev package (which is more appropriate, since the
> sources are also the header files).  I thought I had updated the
> go-dep recipe along with that, but I may have missed it.

I was testing only what is currenly in master. I'm sorry if this is new
patchset on top of what was already merged I didn't notice it.

> > On Tue, Sep 12, 2017 at 11:45 AM, Richard Purdie
> >  wrote:
> >>
> >> On Mon, 2017-09-11 at 15:28 -0300, Otavio Salvador wrote:
> >> > This improves the Go support on OE-Core.
> >> >
> >> > We are trying to port as much as possible work done by Matt on
> >> > meta-golang back to OE-Core and also to avoid carrying old releases
> >> > as
> >> > there is no need to support more versions of Go toolchain.
> >> >
> >> > This fixes issues in existing support as well as add support for SDK
> >> > generation which supports Go.
> >>
> >>
> >> https://autobuilder.yocto.io/builders/nightly-no-x11/builds/471/steps/BuildImages/logs/stdio
> >>
> >> ERROR: go-dep-0.3.0-r0 do_package_qa: QA Issue:
> >> /usr/lib/go/src/github.com/golang/dep/vendor/github.com/pelletier/go-toml/test.sh
> >> contained in package go-dep-dev requires /bin/bash, but no providers found
> >> in RDEPENDS_go-dep-dev? [file-rdeps]
> >> ERROR: go-dep-0.3.0-r0 do_package_qa: QA run found fatal errors. Please
> >> consider fixing them.
> >> ERROR: go-dep-0.3.0-r0 do_package_qa: Function failed: do_package_qa
> >>
> >> Should be easy to fix hopefully!
> >>
> >> Cheers,
> >>
> >> Richard
> >>
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] wic: apply --extra-space + --overhead to squashfs

[Enrico Scholz]

Ed Bartosh  writes:

>> >> >> The --extra-space and --overhead option did not had an effect to 
>> >> >> squashfs
>> >> >> partitions.  Although squashfs is read-only, it can be useful to 
>> >> >> allocate
>> >> >> more space for the on-disk partition to avoid repartitioning of the 
>> >> >> whole
>> >> >> disk when a new (and larger) squashfs image is written on later 
>> >> >> updates.
>> >> >
>> >> > Is it possible to just use --size or --fixed-size in .wks to allocate
>> >> > partition of certain size?
>> >> 
>> >> --fixed-size works with this patch (tested); --size should work.
>> >
>> > Sorry for not being clear. Why do we need this if we can use --size to
>> > explicity specify partition size?
>> 
>> --size and --fixed-size did not had an effect for squashfs with the old
>> code.
>>
>
> I'd propose to fix this instead of applying extra space and overhead
> factor to the filesystems that don't support this by design.
>
> The idea is to make size and fixed-size parameters to set partition size
> and use extra-space and overhead-factor to extend filesystem size as
> they're currently used.

For what is this overhead to be used?  In most cases, to allow future
updates.  And this is required for squashfs too.

Only difference is, that updates for squashfs are to be applied on
partition level and these for other file systems on file system level.
But the need for extra space exists in both cases.


>> I want/need it to allow updates of the running system without complete
>> repartitioning.  E.g. at wic creation time, the squashfs has a certain
>> size.  Sometime in the future, there are needed e.g. 5 MiB more because
>> a new package was added or so.
>>
>
> Yep, I understood what you want. I think it's better achieved by setting
> partition size with --size option than artificially apply extra-space and
> overhead factor to the filesystem that doesn't support this.

It really does not matter for me whether the filesystem itself can be
extended or whether I need a larger partition to apply future updates.

I just need a partition which provides an absolute or relative amount of
additional space.


>> I need to reserve space in the partition so that I can 'dd' the new
>> image without a complete repartitioning.
>> 
>> --extra-space/--overhead has the meaning which I want (e.g. to say
>> "reserve +20% for changes in the future").
>
> So far extra-space and overhead factor were used to allocate additional
> space on the file system. This is different from the way you want to
> use them. You're not allocating space on squashfs, you're allocating
> unformatted space on the partition. It's better to use --size for this.

No; --size is not what I want. --size (or --fixed-size) assume that I
know the absolute size.

Of course, I can get this size empirically.  But it is highly inflexible
and requires different wks files for different image types.

I want to reserve an extra percentage for future updates.  And these
percentages can be in the range of 1 - 5 MB (for small images with
only test tools) or several hundred MB (for large image types with
e.g. desktop environments).

--size or --fixed-size for these image types would be in completely
different ranges while --extra-space/--overhead fits to all.


> I mean that method is called for all possible filesystems, but makes
> sense only for squashfs. It makes code less understandable for no
> reason. When code is used in the only place it's much more easy to
> understand from my point of view.

Not in my one.



Enrico
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v7 00/12] Revamp the Go support

[Otavio Salvador]

On Tue, Sep 12, 2017 at 6:45 AM, Richard Purdie
 wrote:
> On Mon, 2017-09-11 at 15:28 -0300, Otavio Salvador wrote:
>> This improves the Go support on OE-Core.
>>
>> We are trying to port as much as possible work done by Matt on
>> meta-golang back to OE-Core and also to avoid carrying old releases
>> as
>> there is no need to support more versions of Go toolchain.
>>
>> This fixes issues in existing support as well as add support for SDK
>> generation which supports Go.
>
> https://autobuilder.yocto.io/builders/nightly-no-x11/builds/471/steps/BuildImages/logs/stdio
>
> ERROR: go-dep-0.3.0-r0 do_package_qa: QA Issue: 
> /usr/lib/go/src/github.com/golang/dep/vendor/github.com/pelletier/go-toml/test.sh
>  contained in package go-dep-dev requires /bin/bash, but no providers found 
> in RDEPENDS_go-dep-dev? [file-rdeps]
> ERROR: go-dep-0.3.0-r0 do_package_qa: QA run found fatal errors. Please 
> consider fixing them.
> ERROR: go-dep-0.3.0-r0 do_package_qa: Function failed: do_package_qa
>
> Should be easy to fix hopefully!

I will try to reproduce it. I guess it may be varying when build host
is == target. Checking ...

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v7 00/12] Revamp the Go support

[Matt Madison]

On Tue, Sep 12, 2017 at 2:58 AM, Martin Jansa  wrote:
> Interesting I've seen this issue only for PN-staticdev package
> ERROR: QA Issue: go-dep-staticdev rdepends on bash, but it isn't a build
> dependency, missing bash in DEPENDS or PACKAGECONFIG? [build-deps]
>
> and the bash is already in RDEPENDS (the warning is shown in our builds,
> because we use busybox as RPROVIDER for bash).
>
> So maybe this file isn't always included? Or something else might be
> non-deterministic.

Depends on which patch set you were testing against.  One of the
recent go.bbclass changes moved the sources from the -staticdev
package to the -dev package (which is more appropriate, since the
sources are also the header files).  I thought I had updated the
go-dep recipe along with that, but I may have missed it.

-Matt


>
> On Tue, Sep 12, 2017 at 11:45 AM, Richard Purdie
>  wrote:
>>
>> On Mon, 2017-09-11 at 15:28 -0300, Otavio Salvador wrote:
>> > This improves the Go support on OE-Core.
>> >
>> > We are trying to port as much as possible work done by Matt on
>> > meta-golang back to OE-Core and also to avoid carrying old releases
>> > as
>> > there is no need to support more versions of Go toolchain.
>> >
>> > This fixes issues in existing support as well as add support for SDK
>> > generation which supports Go.
>>
>>
>> https://autobuilder.yocto.io/builders/nightly-no-x11/builds/471/steps/BuildImages/logs/stdio
>>
>> ERROR: go-dep-0.3.0-r0 do_package_qa: QA Issue:
>> /usr/lib/go/src/github.com/golang/dep/vendor/github.com/pelletier/go-toml/test.sh
>> contained in package go-dep-dev requires /bin/bash, but no providers found
>> in RDEPENDS_go-dep-dev? [file-rdeps]
>> ERROR: go-dep-0.3.0-r0 do_package_qa: QA run found fatal errors. Please
>> consider fixing them.
>> ERROR: go-dep-0.3.0-r0 do_package_qa: Function failed: do_package_qa
>>
>> Should be easy to fix hopefully!
>>
>> Cheers,
>>
>> Richard
>>
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] wic: apply --extra-space + --overhead to squashfs

[Ed Bartosh]

On Tue, Sep 12, 2017 at 11:44:02AM +0200, Enrico Scholz wrote:
> Ed Bartosh  writes:
> 
> >> >> The --extra-space and --overhead option did not had an effect to 
> >> >> squashfs
> >> >> partitions.  Although squashfs is read-only, it can be useful to 
> >> >> allocate
> >> >> more space for the on-disk partition to avoid repartitioning of the 
> >> >> whole
> >> >> disk when a new (and larger) squashfs image is written on later updates.
> >> >
> >> > Is it possible to just use --size or --fixed-size in .wks to allocate
> >> > partition of certain size?
> >> 
> >> --fixed-size works with this patch (tested); --size should work.
> >
> > Sorry for not being clear. Why do we need this if we can use --size to
> > explicity specify partition size?
> 
> --size and --fixed-size did not had an effect for squashfs with the old
> code.
>

I'd propose to fix this instead of applying extra space and overhead
factor to the filesystems that don't support this by design.

The idea is to make size and fixed-size parameters to set partition size
and use extra-space and overhead-factor to extend filesystem size as
they're currently used.

> 
> > --extra-space and --overhead have the same meaning as
> > IMAGE_ROOTFS_EXTRA_SPACE and IMAGE_OVERHEAD_SIZE variables. From my
> > point of view their purpose is to allocate additional space on the
> > file system. This doesn't make sense for squashfs. That's the reason
> > those options are not used for squashfs. Using them to implicitly make
> > bigger partition is a questionable and possible confusing approach.
> 
> I want/need it to allow updates of the running system without complete
> repartitioning.  E.g. at wic creation time, the squashfs has a certain
> size.  Sometime in the future, there are needed e.g. 5 MiB more because
> a new package was added or so.
>

Yep, I understood what you want. I think it's better achieved by setting
partition size with --size option than artificially apply extra-space and
overhead factor to the filesystem that doesn't support this.

> I need to reserve space in the partition so that I can 'dd' the new
> image without a complete repartitioning.
> 
> --extra-space/--overhead has the meaning which I want (e.g. to say
> "reserve +20% for changes in the future").
> 

So far extra-space and overhead factor were used to allocate additional
space on the file system. This is different from the way you want to use
them. You're not allocating space on squashfs, you're allocating
unformatted space on the partition. It's better to use --size for this.

> >> I would keep it as is.  It is a non trivial function which is reusable.
> >> Perhaps, somebody adds CRAMFS or another file system which does not
> >> support extending its size.
> >> 
> >
> > I personally find this much more understandable and logical:
> 
> me not ;) As I said, functionality is perfect for putting into an extra
> method and it makes code much more readable.  When somebody implements
> CRAMFS he can use this method instead of copy the code.
> 

When somebody implements something that would require this functionality
he/she can create this method instead of copy the code. Let's
not try to solve problems before they arise as they may never arise :)

> > Then introducing a method that will be called for all supported
> > filesystems except squashfs without any effect.
> 
> You mean, function should be called at the end of prepare_rootfs()
> (after "method(...)")?  Yes, it would reduce code duplication but other
> methods needs to be touch too (to give information whether rootfs size
> has been adjusted already).
> 

I mean that method is called for all possible filesystems, but makes
sense only for squashfs. It makes code less understandable for no
reason. When code is used in the only place it's much more easy to
understand from my point of view.

--
Regards,
Ed
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v7 1/2] kernel: Move Device Tree support to kernel.bbclass

[Otavio Salvador]

Hello Richard,

On Tue, Sep 12, 2017 at 5:34 AM, Richard Purdie
 wrote:
> On Mon, 2017-09-11 at 18:18 -0300, Otavio Salvador wrote:
>> The Device Tree is commonly used but it is still kept as a .inc file
>> instead of a proper class. Instead now we move the Device Tree code
>> to
>> a kernel-devicetree class and automatically enable it when the
>> KERNEL_DEVICETREE variable is set.
>>
>> While converting to the class, we reworked the compile and install in
>> tasks as well as run the build of the Device Tree files in parallel,
>> if possible.
>>
>> To avoid breakage in existing layers, we kept a linux-dtb.inc file
>> which raises a warning telling the user about the change so in next
>> release this can be removed.
>
> Sorry but this patchset doesn't appear to be well tested and has big
> issues. For example:
>
> https://autobuilder.yocto.io/builders/nightly-x86/builds/497/steps/Buil
> dImages/logs/stdio
>
> I'm going to guess that do_compile_devicetree is racing
> against do_compile_kernelmodules. Debugging these kinds of races is
> tremendously hard and taking a patchset on a key component like the
> kernel at this point in M4 where this hasn't been considered is
> worrying/risky.
>
> https://autobuilder.yocto.io/builders/nightly-mips-lsb/builds/461/steps
> /BuildImages/logs/stdio
>
> another form of the same race? The autobuilder is full of these
> failures :(

Ok.

> I think if this patchset is to go anywhere it needs to be split into
> more incremental changes, one to move to the new file structure but not
> change the functionality, another looking at parallelisation etc. as
> the current approach of "this patch does X + Y + Z" makes review harder
> and makes it harder to merge any piece of it.

I will do; I will split to the patchset so we have a more granular change.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] externalsrc.bbclass: Avoid symlink clashes for virtclasses

[Ola x Nilsson]

I noticed that the preceding commit has been merged. 
Is there some problem with this one?

--
Ola Nilsson

From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Ola x Nilsson 

Sent: Monday, August 28, 2017 16:58
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 2/2] externalsrc.bbclass: Avoid symlink clashes   
for virtclasses

There was a race condifion in externalsrc_configure_prefuncs when the
same source folder is used for several variants of the same recipe,
like this:

EXTERNALSRC_pn-foo = "..."
EXTERNALSRC_pn-foo-native = "..."

The symlinks were created once for each variant of the recipe, and
where they led in the end depended on which do_configure task executed
last.  Create one set of symlinks for each variant by adding an EXTSRC_SUFFIX
variable to the end of the link names.
Tries to handle all known virtclasses and multilib variants.

Use a lockfile for externalsrc_configure_prefuncs to protect the
.git/info/exclude file.

Signed-off-by: Ola x Nilsson 
---
 meta/classes/externalsrc.bbclass| 16 ++-
 meta/lib/oeqa/selftest/cases/devtool.py | 48 +
 2 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 8141f25e04..980e339cdc 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -24,8 +24,21 @@
 # EXTERNALSRC_BUILD_pn-myrecipe = "/path/to/my/source/tree"
 #

+def get_symlink_suffix(var, suffixes, d):
+# Like oe.utils.prune_suffix but return the suffix instead
+for suffix in suffixes:
+if var.endswith(suffix):
+return suffix
+if var.startswith('nativesdk-'):
+return '-nativesdk'
+prefix = d.getVar("MLPREFIX")
+if prefix and var.startswith(prefix):
+return '-' + prefix[:-1]
+return ''
+
 SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch"
-EXTERNALSRC_SYMLINKS ?= "oe-workdir:${WORKDIR} oe-logs:${T}"
+EXTSRC_SUFFIX = "${@get_symlink_suffix(d.getVar('PN'), 
d.getVar('SPECIAL_PKGSUFFIX').split(), d)}"
+EXTERNALSRC_SYMLINKS ?= "oe-workdir${EXTSRC_SUFFIX}:${WORKDIR} 
oe-logs${EXTSRC_SUFFIX}:${T}"

 python () {
 externalsrc = d.getVar('EXTERNALSRC')
@@ -128,6 +141,7 @@ python () {
 d.setVar('STAMPCLEAN', '${STAMPS_DIR}/work-shared/${PN}/*-*')
 }

+externalsrc_configure_prefunc[lockfiles] += " ${S}/conf_prefunc.lock"
 python externalsrc_configure_prefunc() {
 s_dir = d.getVar('S')
 # Create desired symlinks
diff --git a/meta/lib/oeqa/selftest/cases/devtool.py 
b/meta/lib/oeqa/selftest/cases/devtool.py
index 88d69724f9..4119280b48 100644
--- a/meta/lib/oeqa/selftest/cases/devtool.py
+++ b/meta/lib/oeqa/selftest/cases/devtool.py
@@ -491,6 +491,54 @@ class DevtoolTests(DevtoolBase):
 result = runCmd('devtool status')
 self.assertNotIn('mdadm', result.output)

+def test_devtool_modify_configure_prefunc(self):
+self.write_config("""
+MACHINE = "qemux86-64"
+require conf/multilib.conf
+MULTILIBS = "multilib:lib32"
+DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
+""")
+self.add_command_to_tearDown('bitbake-layers remove-layer */workspace')
+self.write_recipeinc('emptytest', '''
+BBCLASSEXTEND = "native nativesdk"
+do_patch[noexec] = "1"
+INHIBIT_DEFAULT_DEPS = "1"
+''')
+self.track_for_cleanup(self.recipeinc('emptytest'))
+targets = 'emptytest emptytest-native nativesdk-emptytest 
lib32-emptytest'
+self.add_command_to_tearDown('bitbake -c clean ' + targets)
+tempdir = tempfile.mkdtemp(prefix='devtoolqa')
+self.track_for_cleanup(tempdir)
+runCmd('devtool modify emptytest -x %s' % tempdir)
+self.track_for_cleanup(self.workspacedir)
+self.append_recipeinc('emptytest', 'EXTERNALSRC_pn-emptytest-native = 
"%s"\n' % tempdir)
+self.append_recipeinc('emptytest', 'EXTERNALSRC_pn-nativesdk-emptytest 
= "%s"\n' % tempdir)
+self.append_recipeinc('emptytest', 'EXTERNALSRC_pn-lib32-emptytest = 
"%s"\n' % tempdir)
+bitbake('-c cleansstate ' + targets)
+bitbake('-c configure ' + targets)
+
+def assert_link(linkname, destdir):
+linkname = os.path.join(tempdir, linkname)
+self.assertExists(linkname)
+self.assertTrue(os.path.islink(linkname))
+dst = os.readlink(linkname)
+self.assertEqual(dst, destdir)
+
+bbvars = {'': get_bb_vars(['WORKDIR', 'T'], 'emptytest'),
+  '-native': get_bb_vars(['WORKDIR', 'T'], 'emptytest-native'),
+  '-lib32': get_bb_vars(['WORKDIR', 'T'], 'lib32-emptytest'),
+  '-nativesdk': get_bb_vars(['WORKDIR', 'T'], 
'nativesdk-emptytest')}
+for variant in bbvars:
+assert_link('oe-logs' + variant, bbvars[variant]['T'])
+

Re: [OE-core] [oe-commits] [openembedded-core] branch master updated (cc319b6 -> 2ebbeb6)

[Martin Jansa]

Hi,

I don't see any obvious change in this update which should cause this, but
rebuilding my image for raspberrypi3-64 after this update (the previous
image was built without errors) shows:

NOTE: Running task 417 of 6399
(/OE/build/owpb/webos-ports/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:
do_validate_branches)
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
do_validate_branches: Started

NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
do_validate_branches: Succeeded
NOTE: Running task 434 of 6399
(/OE/build/owpb/webos-ports/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:
do_kernel_metadata)
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
do_kernel_metadata: Started
ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0
do_kernel_metadata: Could not locate BSP definition for
raspberrypi3-64/standard and no defconfig was provided
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
do_kernel_metadata: Succeeded
...
NOTE: Running task 454 of 6399
(/OE/build/owpb/webos-ports/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:
do_patch)
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
do_patch: Started
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
do_patch: Succeeded
NOTE: Running task 491 of 6399
(/OE/build/owpb/webos-ports/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:
do_kernel_configme)
NOTE: recipe linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0: task
do_kernel_configme: Started
ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0
do_kernel_configme: [ERROR]: no configuration queue found in outdir
(.kernel-meta)

 scc [--help] [--configs] [--force] [-i] [-w] [--cmds ] [-o outdir:] [-D=] [-I] [-v]
infiles

  --help:  This message
  --force: force overwrite output file if it already exists
  --cmds:  list of supported commands. If not passed, all found
commands are loaded,
   valid commands are: patch, kconf, branch, define
  --configs:   Output the list of compiled configuration fragments (if
available), -o  is
   used to locate the configuration options
  -D:  define  to  which will be available to sub
scripts
  -I:  include path  will be searched for files
  -i:  leave intermediate files on failure
  -w:  only warn on missing files
  -v:  verbose output
  -o:  output directory and artifacts. artifacts follow the
colon and ar a comma
   separated list of:
   meta:  full meta-series (patches, config, branches,
etc)
   cfg:   configure fragment queue
   patch: patch queue

  infiles  files to preprocess, and output into outfile or stdout
ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0
do_kernel_configme: Could not find configuration queue
(.kernel-meta/config.queue)
ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0
do_kernel_configme: Function failed: do_kernel_configme (log file is
located at
/OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_64-webos-linux/linux-raspberrypi/1_4.9.41+gitAUTOINC+4153f509b4-r0/temp/log.do_kernel_configme.19498)
ERROR: Logfile of failure stored in:
/OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_64-webos-linux/linux-raspberrypi/1_4.9.41+gitAUTOINC+4153f509b4-r0/temp/log.do_kernel_configme.19498
Log data follows:
| DEBUG: Executing shell function do_kernel_configme
| ERROR: [ERROR]: no configuration queue found in outdir (.kernel-meta)
|
|  scc [--help] [--configs] [--force] [-i] [-w] [--cmds ] [-o outdir:] [-D=] [-I] [-v]
infiles
|
|   --help:  This message
|   --force: force overwrite output file if it already exists
|   --cmds:  list of supported commands. If not passed, all found
commands are loaded,
|valid commands are: patch, kconf, branch, define
|   --configs:   Output the list of compiled configuration fragments
(if available), -o  is
|used to locate the configuration options
|   -D:  define  to  which will be available to sub
scripts
|   -I:  include path  will be searched for files
|   -i:  leave intermediate files on failure
|   -w:  only warn on missing files
|   -v:  verbose output
|   -o:  output directory and artifacts. artifacts follow the
colon and ar a comma
|separated list of:
|meta:  full meta-series (patches, config,
branches, etc)
|cfg:   configure fragment queue
|patch: patch queue
|
|   infiles  files to preprocess, and output into outfile or stdout
| ERROR: Could not find configuration queue (.kernel-meta/config.queue)
| 

[OE-core] [PATCH 2/2] devtool: ensure recipes devtool is working on are unlocked within the eSDK

[Paul Eggleton]

Alongside reworking the way devtool extracts source, we now need to
ensure that within the extensible SDK where task signatures are locked,
the signatures of the tasks for the recipes being worked on get unlocked
at the right time or otherwise we'll now get taskhash mismatches when
running devtool modify on a recipe that was included in the eSDK such as
the kernel (due to a separate bug). The existing mechanism for
auto-unlocking recipes was a little weak and was happening too late, so
I've reimplemented it so that:
(a) it gets triggered immediately when the recipe/append is created
(b) we avoid writing to the unlocked signatures file unnecessarily
(since it's a global configuration file) and
(c) within the eSDK configuration we whitelist SIGGEN_UNLOCKED_RECIPES
to avoid unnecessary reparses every time we perform one of the
devtool operations that does need to change this list.

Fixes [YOCTO #11883] (not the underlying cause, but this manifestation
of the issue).

Signed-off-by: Paul Eggleton 
---
 meta/classes/populate_sdk_ext.bbclass |  3 +++
 scripts/devtool   | 20 --
 scripts/lib/devtool/__init__.py   | 40 +++
 scripts/lib/devtool/standard.py   | 20 +++---
 scripts/lib/devtool/upgrade.py|  9 +---
 5 files changed, 61 insertions(+), 31 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 6620445..3620995 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -346,6 +346,9 @@ python copy_buildsystem () {
 # the sig computed from the metadata.
 f.write('SIGGEN_LOCKEDSIGS_TASKSIG_CHECK = "warn"\n\n')
 
+# We want to be able to set this without a full reparse
+f.write('BB_HASHCONFIG_WHITELIST_append = " 
SIGGEN_UNLOCKED_RECIPES"\n\n')
+
 # Set up whitelist for run on install
 f.write('BB_SETSCENE_ENFORCE_WHITELIST = "%:* *:do_shared_workdir 
*:do_rm_work wic-tools:* *:do_addto_recipe_sysroot"\n\n')
 
diff --git a/scripts/devtool b/scripts/devtool
index c9ad9dd..5292f18 100755
--- a/scripts/devtool
+++ b/scripts/devtool
@@ -130,25 +130,6 @@ def read_workspace():
  'recipefile': recipefile}
 logger.debug('Found recipe %s' % workspace[pn])
 
-def create_unlockedsigs():
-""" This function will make unlocked-sigs.inc match the recipes in the
-workspace. This runs on every run of devtool, but it lets us ensure
-the unlocked items are in sync with the workspace. """
-
-confdir = os.path.join(basepath, 'conf')
-unlockedsigs = os.path.join(confdir, 'unlocked-sigs.inc')
-bb.utils.mkdirhier(confdir)
-with open(os.path.join(confdir, 'unlocked-sigs.inc'), 'w') as f:
-f.write("# DO NOT MODIFY! YOUR CHANGES WILL BE LOST.\n" +
-"# This layer was created by the OpenEmbedded devtool" +
-" utility in order to\n" +
-"# contain recipes that are unlocked.\n")
-
-f.write('SIGGEN_UNLOCKED_RECIPES += "\\\n')
-for pn in workspace:
-f.write('' + pn)
-f.write('"')
-
 def create_workspace(args, config, basepath, workspace):
 if args.layerpath:
 workspacedir = os.path.abspath(args.layerpath)
@@ -332,7 +313,6 @@ def main():
 
 if not getattr(args, 'no_workspace', False):
 read_workspace()
-create_unlockedsigs()
 
 try:
 ret = args.func(args, config, basepath, workspace)
diff --git a/scripts/lib/devtool/__init__.py b/scripts/lib/devtool/__init__.py
index 14170cb..94e3d7d 100644
--- a/scripts/lib/devtool/__init__.py
+++ b/scripts/lib/devtool/__init__.py
@@ -297,3 +297,43 @@ def replace_from_file(path, old, new):
 except ValueError:
 pass
 write_file(path, "\n".join(new_contents))
+
+
+def update_unlockedsigs(basepath, workspace, fixed_setup, extra=None):
+""" This function will make unlocked-sigs.inc match the recipes in the
+workspace plus any extras we want unlocked. """
+
+if not fixed_setup:
+# Only need to write this out within the eSDK
+return
+
+if not extra:
+extra = []
+
+confdir = os.path.join(basepath, 'conf')
+unlockedsigs = os.path.join(confdir, 'unlocked-sigs.inc')
+
+# Get current unlocked list if any
+values = {}
+def get_unlockedsigs_varfunc(varname, origvalue, op, newlines):
+values[varname] = origvalue
+return origvalue, None, 0, True
+if os.path.exists(unlockedsigs):
+with open(unlockedsigs, 'r') as f:
+bb.utils.edit_metadata(f, ['SIGGEN_UNLOCKED_RECIPES'], 
get_unlockedsigs_varfunc)
+unlocked = sorted(values.get('SIGGEN_UNLOCKED_RECIPES', []))
+
+# If the new list is different to the current list, write it out
+newunlocked = sorted(list(workspace.keys()) 

[OE-core] [PATCH 0/2] A couple of devtool fixes

[Paul Eggleton]

A fix for devtool modify and other source extracting subcommands to
handle dependencies, and a fix for devtool modify within the eSDK.

NOTE: the patch I just sent to the bitbake list is required for patch
1/2 to work.


The following changes since commit 2ebbeb61114e4b847e9164c621ac87b5cf03a299:

  staging: gracefully abort if two recipes conflict in the sysroot (2017-09-11 
17:30:15 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib paule/devtool30-oe
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/devtool30-oe

Paul Eggleton (2):
  devtool: rework source extraction so that dependencies are handled
  devtool: ensure recipes devtool is working on are unlocked within the eSDK

 meta/classes/devtool-source.bbclass | 165 
 meta/classes/populate_sdk_ext.bbclass   |   3 +
 meta/classes/sstate.bbclass |   9 +-
 meta/lib/oeqa/selftest/cases/devtool.py |  10 +-
 scripts/devtool |  20 ---
 scripts/lib/devtool/__init__.py |  40 ++
 scripts/lib/devtool/standard.py | 218 ++--
 scripts/lib/devtool/upgrade.py  |   9 +-
 8 files changed, 296 insertions(+), 178 deletions(-)
 create mode 100644 meta/classes/devtool-source.bbclass

-- 
2.9.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] devtool: rework source extraction so that dependencies are handled

[Paul Eggleton]

Since it was first implemented, devtool's source extraction (as used by
the devtool modify, extract and upgrade subcommands) ignored other recipe
dependencies - so for example if you ran devtool modify on a recipe that
fetches from svn or is compressed using xz then it would fail if those
dependencies hadn't been built first. Now that we can execute tasks in
the normal way (i.e. tinfoil.build_targets()) then we can rework it to
use that. This is slightly tricky in that the source extraction needs to
insert some logic in between tasks; luckily we can use a helper class
that conditionally adds prefuncs to make that possible.

Some side-effects / aspects of this change worth noting:
* Operations are a little slower because we have to go through the task
  dependency graph generation and other startup processing. There's not
  really any way to avoid this though.
* devtool extract didn't used to require a workspace, now it does
  because it needs to create a temporary bbappend for the recipe. (As
  with other commands the workspace be created on the fly if it doesn't
  already exist.)
* Since we are creating (or modifying) a bbappend on the fly after the
  initial cache load has taken place, we need to ensure that this gets
  noticed otherwise it won't have any effect. In order to do this
  properly with the way cooker currently works, we have to be able to
  set its parsecache_valid flag to False. A new invalidateParseCache
  command on the bitbake side makes this possible.
* I want any existing sysroot files and stamps to be left alone during
  extraction since we are running the tasks off to the side, and
  especially devtool extract should be able to be used without touching
  these. However, this was hampered by the automatic removal process in
  sstate.bbclass triggered by bb.event.ReachableStamps when the task
  signatures change, thus I had to introduce a way to disable this
  removal on a per-recipe basis (we still want it to function for any
  dependencies that we aren't working on). To implement this I elected
  to use a file written to tmp/sstate-control which gets deleted
  automatically after reading so that there's less chance of stale files
  affecting future sessions. I could have used a variable but this would
  have needed to be whitelisted and I'd have to have poked its value in
  using the setVariable command.

Fixes [YOCTO #11198].

Signed-off-by: Paul Eggleton 
---
 meta/classes/devtool-source.bbclass | 165 +
 meta/classes/sstate.bbclass |   9 +-
 meta/lib/oeqa/selftest/cases/devtool.py |  10 +-
 scripts/lib/devtool/standard.py | 208 ++--
 scripts/lib/devtool/upgrade.py  |   2 +-
 5 files changed, 241 insertions(+), 153 deletions(-)
 create mode 100644 meta/classes/devtool-source.bbclass

diff --git a/meta/classes/devtool-source.bbclass 
b/meta/classes/devtool-source.bbclass
new file mode 100644
index 000..8f5bc86
--- /dev/null
+++ b/meta/classes/devtool-source.bbclass
@@ -0,0 +1,165 @@
+# Development tool - source extraction helper class
+#
+# NOTE: this class is intended for use by devtool and should not be
+# inherited manually.
+#
+# Copyright (C) 2014-2017 Intel Corporation
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+
+DEVTOOL_TEMPDIR ?= ""
+DEVTOOL_PATCH_SRCDIR = "${DEVTOOL_TEMPDIR}/patchworkdir"
+
+
+python() {
+tempdir = d.getVar('DEVTOOL_TEMPDIR')
+
+if not tempdir:
+bb.fatal('devtool-source class is for internal use by devtool only')
+
+# Make a subdir so we guard against WORKDIR==S
+workdir = os.path.join(tempdir, 'workdir')
+d.setVar('WORKDIR', workdir)
+if not d.getVar('S').startswith(workdir):
+# Usually a shared workdir recipe (kernel, gcc)
+# Try to set a reasonable default
+if bb.data.inherits_class('kernel', d):
+d.setVar('S', '${WORKDIR}/source')
+else:
+d.setVar('S', '${WORKDIR}/%s' % os.path.basename(d.getVar('S')))
+if bb.data.inherits_class('kernel', d):
+# We don't want to move the source to STAGING_KERNEL_DIR here
+d.setVar('STAGING_KERNEL_DIR', '${S}')
+
+d.setVar('STAMPS_DIR', os.path.join(tempdir, 'stamps'))
+d.setVar('T', os.path.join(tempdir, 'temp'))
+
+# Hook in pre/postfuncs
+is_kernel_yocto = 

Re: [OE-core] [PATCH v7 00/12] Revamp the Go support

[Martin Jansa]

Interesting I've seen this issue only for PN-staticdev package
ERROR: QA Issue: go-dep-staticdev rdepends on bash, but it isn't a build
dependency, missing bash in DEPENDS or PACKAGECONFIG? [build-deps]

and the bash is already in RDEPENDS (the warning is shown in our builds,
because we use busybox as RPROVIDER for bash).

So maybe this file isn't always included? Or something else might be
non-deterministic.

On Tue, Sep 12, 2017 at 11:45 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Mon, 2017-09-11 at 15:28 -0300, Otavio Salvador wrote:
> > This improves the Go support on OE-Core.
> >
> > We are trying to port as much as possible work done by Matt on
> > meta-golang back to OE-Core and also to avoid carrying old releases
> > as
> > there is no need to support more versions of Go toolchain.
> >
> > This fixes issues in existing support as well as add support for SDK
> > generation which supports Go.
>
> https://autobuilder.yocto.io/builders/nightly-no-x11/
> builds/471/steps/BuildImages/logs/stdio
>
> ERROR: go-dep-0.3.0-r0 do_package_qa: QA Issue: /usr/lib/go/src/
> github.com/golang/dep/vendor/github.com/pelletier/go-toml/test.sh
> contained in package go-dep-dev requires /bin/bash, but no providers found
> in RDEPENDS_go-dep-dev? [file-rdeps]
> ERROR: go-dep-0.3.0-r0 do_package_qa: QA run found fatal errors. Please
> consider fixing them.
> ERROR: go-dep-0.3.0-r0 do_package_qa: Function failed: do_package_qa
>
> Should be easy to fix hopefully!
>
> Cheers,
>
> Richard
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v7 00/12] Revamp the Go support

[Richard Purdie]

On Mon, 2017-09-11 at 15:28 -0300, Otavio Salvador wrote:
> This improves the Go support on OE-Core.
> 
> We are trying to port as much as possible work done by Matt on
> meta-golang back to OE-Core and also to avoid carrying old releases
> as
> there is no need to support more versions of Go toolchain.
> 
> This fixes issues in existing support as well as add support for SDK
> generation which supports Go.

https://autobuilder.yocto.io/builders/nightly-no-x11/builds/471/steps/BuildImages/logs/stdio

ERROR: go-dep-0.3.0-r0 do_package_qa: QA Issue: 
/usr/lib/go/src/github.com/golang/dep/vendor/github.com/pelletier/go-toml/test.sh
 contained in package go-dep-dev requires /bin/bash, but no providers found in 
RDEPENDS_go-dep-dev? [file-rdeps]
ERROR: go-dep-0.3.0-r0 do_package_qa: QA run found fatal errors. Please 
consider fixing them.
ERROR: go-dep-0.3.0-r0 do_package_qa: Function failed: do_package_qa

Should be easy to fix hopefully!

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] wic: apply --extra-space + --overhead to squashfs

[Enrico Scholz]

Ed Bartosh  writes:

>> >> The --extra-space and --overhead option did not had an effect to squashfs
>> >> partitions.  Although squashfs is read-only, it can be useful to allocate
>> >> more space for the on-disk partition to avoid repartitioning of the whole
>> >> disk when a new (and larger) squashfs image is written on later updates.
>> >
>> > Is it possible to just use --size or --fixed-size in .wks to allocate
>> > partition of certain size?
>> 
>> --fixed-size works with this patch (tested); --size should work.
>
> Sorry for not being clear. Why do we need this if we can use --size to
> explicity specify partition size?

--size and --fixed-size did not had an effect for squashfs with the old
code.


> --extra-space and --overhead have the same meaning as
> IMAGE_ROOTFS_EXTRA_SPACE and IMAGE_OVERHEAD_SIZE variables. From my
> point of view their purpose is to allocate additional space on the
> file system. This doesn't make sense for squashfs. That's the reason
> those options are not used for squashfs. Using them to implicitly make
> bigger partition is a questionable and possible confusing approach.

I want/need it to allow updates of the running system without complete
repartitioning.  E.g. at wic creation time, the squashfs has a certain
size.  Sometime in the future, there are needed e.g. 5 MiB more because
a new package was added or so.

I need to reserve space in the partition so that I can 'dd' the new
image without a complete repartitioning.

--extra-space/--overhead has the meaning which I want (e.g. to say
"reserve +20% for changes in the future").


>> I would keep it as is.  It is a non trivial function which is reusable.
>> Perhaps, somebody adds CRAMFS or another file system which does not
>> support extending its size.
>> 
>
> I personally find this much more understandable and logical:

me not ;) As I said, functionality is perfect for putting into an extra
method and it makes code much more readable.  When somebody implements
CRAMFS he can use this method instead of copy the code.


> Then introducing a method that will be called for all supported
> filesystems except squashfs without any effect.

You mean, function should be called at the end of prepare_rootfs()
(after "method(...)")?  Yes, it would reduce code duplication but other
methods needs to be touch too (to give information whether rootfs size
has been adjusted already).


Enrico
-- 
SIGMA Chemnitz GmbH   Registergericht:   Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13   Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] wic: apply --extra-space + --overhead to squashfs

[Ed Bartosh]

On Mon, Sep 11, 2017 at 04:04:40PM +0200, Enrico Scholz wrote:
> Ed Bartosh  writes:
> 
> >> The --extra-space and --overhead option did not had an effect to squashfs
> >> partitions.  Although squashfs is read-only, it can be useful to allocate
> >> more space for the on-disk partition to avoid repartitioning of the whole
> >> disk when a new (and larger) squashfs image is written on later updates.
> >
> > Is it possible to just use --size or --fixed-size in .wks to allocate
> > partition of certain size?
> 
> --fixed-size works with this patch (tested); --size should work.

Sorry for not being clear. Why do we need this if we can use --size to
explicity specify partition size?

--extra-space and --overhead have the same meaning as
IMAGE_ROOTFS_EXTRA_SPACE and IMAGE_OVERHEAD_SIZE variables. From my
point of view their purpose is to allocate additional space on the file
system. This doesn't make sense for squashfs. That's the reason those
options are not used for squashfs. Using them to implicitly make bigger
partition is a questionable and possible confusing approach.


> 
> >> +def __extend_rootfs_image(self, rootfs):
> >
> > Do we really need to mangle name of this method?
> 
> ok; I will make it _extend_rootfs_image
> 
> 
> > As this function is not going to be used anywhere I'd just use this
> > code in prepare_rootfs_squashfs. It would be less generic, but much
> > more readable and understandable.
> 
> I would keep it as is.  It is a non trivial function which is reusable.
> Perhaps, somebody adds CRAMFS or another file system which does not
> support extending its size.
> 

I personally find this much more understandable and logical:
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -338,6 +338,14 @@ class Partition():
(rootfs_dir, rootfs, extraopts)
 exec_native_cmd(squashfs_cmd, native_sysroot, pseudo=pseudo)
 
+# Enlarges the image to make bigger partition
+sz = (os.stat(rootfs).st_size + 1023) // 1024
+pad_sz = self.get_rootfs_size(sz)
+
+if pad_sz > sz:
+with open(rootfs, 'a') as fimage:
+  fimage.truncate(pad_sz * 1024)
+
 def prepare_empty_partition_ext(self, rootfs, oe_builddir,
 native_sysroot):

Then introducing a method that will be called for all supported
filesystems except squashfs without any effect.

> partition.py is full of redundant code (look for all the "du" calls or
> generally at the beginning of the prepare_rootfs_*() methods) where
> probably somebody thought that it is not going to be used anywhere else
> ;)
Feel free to send a patch then.
I'd not consider it a good excuse for the above new method though :)

--
Regards,
Ed
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v7 1/2] kernel: Move Device Tree support to kernel.bbclass

[Richard Purdie]

On Mon, 2017-09-11 at 18:18 -0300, Otavio Salvador wrote:
> The Device Tree is commonly used but it is still kept as a .inc file
> instead of a proper class. Instead now we move the Device Tree code
> to
> a kernel-devicetree class and automatically enable it when the
> KERNEL_DEVICETREE variable is set.
> 
> While converting to the class, we reworked the compile and install in
> tasks as well as run the build of the Device Tree files in parallel,
> if possible.
> 
> To avoid breakage in existing layers, we kept a linux-dtb.inc file
> which raises a warning telling the user about the change so in next
> release this can be removed.

Sorry but this patchset doesn't appear to be well tested and has big
issues. For example:

https://autobuilder.yocto.io/builders/nightly-x86/builds/497/steps/Buil
dImages/logs/stdio

I'm going to guess that do_compile_devicetree is racing
against do_compile_kernelmodules. Debugging these kinds of races is
tremendously hard and taking a patchset on a key component like the
kernel at this point in M4 where this hasn't been considered is
worrying/risky.

https://autobuilder.yocto.io/builders/nightly-mips-lsb/builds/461/steps
/BuildImages/logs/stdio

another form of the same race? The autobuilder is full of these
failures :(

I think if this patchset is to go anywhere it needs to be split into
more incremental changes, one to move to the new file structure but not
change the functionality, another looking at parallelisation etc. as
the current approach of "this patch does X + Y + Z" makes review harder
and makes it harder to merge any piece of it.

Cheers,

Richard




-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V3 1/1] ovmf: fix do_compile error when len(tmp)=410

[Dengke Du]

[YOCTO #11354]

Signed-off-by: Dengke Du 
---
 .../ovmf/0004-ovmf-enable-long-path-file.patch | 28 ++
 meta/recipes-core/ovmf/ovmf_git.bb |  3 ++-
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-file.patch

diff --git a/meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-file.patch 
b/meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-file.patch
new file mode 100644
index 000..35fc3ac
--- /dev/null
+++ b/meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-file.patch
@@ -0,0 +1,28 @@
+From 49d0923dce509127828b0867c2af31ec84a5c2a9 Mon Sep 17 00:00:00 2001
+From: Dengke Du 
+Date: Mon, 11 Sep 2017 02:21:55 -0400
+Subject: [PATCH] ovmf: enable long path file
+
+Upstream-Status: Inappropriate
+
+Signed-off-by: Dengke Du 
+---
+ BaseTools/Source/C/Common/CommonLib.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/BaseTools/Source/C/Common/CommonLib.h 
b/BaseTools/Source/C/Common/CommonLib.h
+index 2041b89..8116aa2 100644
+--- a/BaseTools/Source/C/Common/CommonLib.h
 b/BaseTools/Source/C/Common/CommonLib.h
+@@ -19,7 +19,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
+ #include 
+ #define PRINTED_GUID_BUFFER_SIZE  37  // including null-termination
+ 
+-#define MAX_LONG_FILE_PATH 500
++#define MAX_LONG_FILE_PATH 1023
+ 
+ #ifdef __cplusplus
+ extern "C" {
+-- 
+2.8.1
+
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb 
b/meta/recipes-core/ovmf/ovmf_git.bb
index 1872c95..50c01aa 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -11,10 +11,11 @@ PACKAGECONFIG ??= ""
 PACKAGECONFIG[secureboot] = ",,,"
 
 SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
+   file://0001-ia32-Dont-use-pie.patch \
file://0002-ovmf-update-path-to-native-BaseTools.patch \
file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \
+   file://0004-ovmf-enable-long-path-file.patch \
file://VfrCompile-increase-path-length-limit.patch \
-   file://0001-ia32-Dont-use-pie.patch \
file://no-stack-protector-all-archs.patch \
 "
 UPSTREAM_VERSION_UNKNOWN = "1"
-- 
2.8.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V3 0/1] ovmf: fix do_compile error when len(tmp)=410

[Dengke Du]

Changed in V2:
Add the MAX_LONG_FILE_PATH to 1023 suggested by ross.

Changed in V3:
Let the patch Upstream-Status be Inappropriate suggested by patrick.

The following changes since commit e3a69364eb1fdbf1dcb98a04b3ddfc8f9841a7fa:

  staging: gracefully abort if two recipes conflict in the sysroot (2017-09-11 
17:30:30 +0100)

are available in the git repository at:

  https://github.com/DengkeDu/openembedded-core.git 
dengke/fix-ovmf-do-compile-error-when-enable-long-file-path
  
https://github.com//tree/dengke/fix-ovmf-do-compile-error-when-enable-long-file-path

Dengke Du (1):
  ovmf: fix do_compile error when len(tmp)=410

 .../ovmf/0004-ovmf-enable-long-path-file.patch | 28 ++
 meta/recipes-core/ovmf/ovmf_git.bb |  3 ++-
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-file.patch

-- 
2.8.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] at-spi2-atk: Add HOMEPAGE info into recipe file.

[Huang Qiyu]

Signed-off-by: Huang Qiyu 
---
 meta/recipes-support/atk/at-spi2-atk_2.24.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/atk/at-spi2-atk_2.24.1.bb 
b/meta/recipes-support/atk/at-spi2-atk_2.24.1.bb
index ac55081..4a0e411 100644
--- a/meta/recipes-support/atk/at-spi2-atk_2.24.1.bb
+++ b/meta/recipes-support/atk/at-spi2-atk_2.24.1.bb
@@ -1,4 +1,5 @@
 SUMMARY = "AT-SPI 2 Toolkit Bridge"
+HOMEPAGE = "https://wiki.linuxfoundation.org/accessibility/d-bus;
 LICENSE = "LGPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=e9f288ba982d60518f375b5898283886"
 
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] m4: Add HOMEPAGE info into recipe file.

[Huang Qiyu]

Signed-off-by: Huang Qiyu 
---
 meta/recipes-devtools/m4/m4.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/m4/m4.inc b/meta/recipes-devtools/m4/m4.inc
index 75d8bbe..2002594 100644
--- a/meta/recipes-devtools/m4/m4.inc
+++ b/meta/recipes-devtools/m4/m4.inc
@@ -1,4 +1,5 @@
 SUMMARY = "Traditional Unix macro processor"
+HOMEPAGE = "https://www.gnu.org/software/m4/m4.html;
 DESCRIPTION = "GNU m4 is an implementation of the traditional Unix macro 
processor.  It is mostly SVR4 \
 compatible although it has some extensions (for example, handling more than 9 
positional parameters to macros). \
 GNU M4 also has built-in functions for including files, running shell 
commands, doing arithmetic, etc."
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] at-spi2-core: Add HOMEPAGE info into recipe file.

[Huang Qiyu]

Signed-off-by: Huang Qiyu 
---
 meta/recipes-support/atk/at-spi2-core_2.24.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/atk/at-spi2-core_2.24.1.bb 
b/meta/recipes-support/atk/at-spi2-core_2.24.1.bb
index b5b71e7..1687ae3 100644
--- a/meta/recipes-support/atk/at-spi2-core_2.24.1.bb
+++ b/meta/recipes-support/atk/at-spi2-core_2.24.1.bb
@@ -1,4 +1,5 @@
 SUMMARY = "Assistive Technology Service Provider Interface (dbus core)"
+HOMEPAGE = "https://wiki.linuxfoundation.org/accessibility/d-bus;
 LICENSE = "LGPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=e9f288ba982d60518f375b5898283886"
 
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2 1/1] ovmf: fix do_compile error when len(tmp)=410

[Dengke Du]

On 2017年09月12日 15:46, Patrick Ohly wrote:

On Mon, 2017-09-11 at 21:20 -0400, Dengke Du wrote:

diff --git a/meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-
file.patch b/meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-
file.patch
new file mode 100644
index 000..9cc85ad
--- /dev/null
+++ b/meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-
file.patch
@@ -0,0 +1,28 @@
+From 032fc6b1f7691bd537fd2a6bd13821fcf3c45e64 Mon Sep 17 00:00:00
2001
+From: Dengke Du 
+Date: Mon, 11 Sep 2017 02:21:55 -0400
+Subject: [PATCH] ovmf: enable long path file
+
+Upstream-Status: Pending

Pending which action? I.e. what's the next step?

To me this patch looks more like local customization to fit into path
lengths used by the OE build system, so "Inappropriate" might be more
reasonable.


Yes, you are right, it just fit for OE build system.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2 1/1] ovmf: fix do_compile error when len(tmp)=410

[Patrick Ohly]

On Mon, 2017-09-11 at 21:20 -0400, Dengke Du wrote:
> diff --git a/meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-
> file.patch b/meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-
> file.patch
> new file mode 100644
> index 000..9cc85ad
> --- /dev/null
> +++ b/meta/recipes-core/ovmf/ovmf/0004-ovmf-enable-long-path-
> file.patch
> @@ -0,0 +1,28 @@
> +From 032fc6b1f7691bd537fd2a6bd13821fcf3c45e64 Mon Sep 17 00:00:00
> 2001
> +From: Dengke Du 
> +Date: Mon, 11 Sep 2017 02:21:55 -0400
> +Subject: [PATCH] ovmf: enable long path file
> +
> +Upstream-Status: Pending

Pending which action? I.e. what's the next step?

To me this patch looks more like local customization to fit into path
lengths used by the OE build system, so "Inappropriate" might be more
reasonable.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-commits] [openembedded-core] 01/36: expat: Don't use getrandom() in the -native case

[Richard Purdie]

On Tue, 2017-09-12 at 00:59 +0200, Martin Jansa wrote:
> Was this tested with the version in pyro? The patch fails to apply:
> 
> 
> http://errors.yoctoproject.org/Errors/Build/46432/
> 
> NOTE: Applying patch 'autotools.patch' (oe-core/meta/recipes-
> core/expat/expat/autotools.patch)
> NOTE: Applying patch 'no_getrandom.patch' (oe-core/meta/recipes-
> core/expat/expat/no_getrandom.patch)
> ERROR: Command Error: 'quilt --quiltrc TOPDIR/BUILD/work/x86_64-
> linux/expat-native/2.2.0-r0/recipe-sysroot-native/etc/quiltrc push'
> exited with 0  Output:
> Applying patch no_getrandom.patch
> patching file configure.ac
> Hunk #1 FAILED at 151.
> 1 out of 1 hunk FAILED -- rejects in file configure.ac
> Patch no_getrandom.patch does not apply (enforce with -f)

Sorry, I reverted this last night, it was a merge error and mistake on
my part.

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core