[yocto] Problems to build xen-guest-image-minimal

2017-05-31 Thread Pello Heriz 
Hi,

I'm trying to build xen-guest-image-minimal with master branch of Yocto,
but I keep stuck in the next error:

bitbake xen-guest-image-minimal
NOTE: /opt/yocto_GE/poky/meta-qt5/recipes-qt/qt5/qtbase_git.bb:
base_contains is deprecated, please use bb.utils.contains instead.
NOTE: /opt/yocto_GE/poky/meta-qt5/recipes-qt/qt5/qtbase_git.bb:
base_contains is deprecated, please use bb.utils.contains instead.
WARNING:
/opt/yocto_GE/poky/meta-petalinux/recipes-external/external-xilinx-toolchain/
libgcc-xilinx.bb: LICENSE_libgcov-dev includes licenses (GPL-3.0) that are
not listed in LICENSE
Parsing recipes: 100% |##| Time:
0:04:34
Parsing of 2477 .bb files complete (0 cached, 2477 parsed). 3310 targets,
312 skipped, 0 masked, 0 errors.
WARNING: No recipes available for:

/opt/yocto_GE/poky/meta-petalinux/recipes-devtools/python/python-smartpm_%.bbappend
WARNING: No bb files matched BBFILE_PATTERN_gpe-layer
'^/opt/yocto_GE/poky/meta-openembedded/meta-gpe/'
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'rpmresolve-native'. Close matches:
  meson-native
  rpm-native
  perl-native
ERROR: Required build target 'xen-guest-image-minimal' has no buildable
providers.
Missing or unbuildable dependency chain was: ['xen-guest-image-minimal',
'rpmresolve-native']


The bblayers that I have included to the project are the next ones:

BBLAYERS ?= " \
${MY_META_DIR}/meta \
${MY_META_DIR}/meta-poky \
${MY_META_DIR}/meta-yocto-bsp \
${MY_META_DIR}/meta-openembedded/meta-perl \
${MY_META_DIR}/meta-openembedded/meta-systemd \
${MY_META_DIR}/meta-openembedded/meta-gpe \
${MY_META_DIR}/meta-openembedded/meta-python \
${MY_META_DIR}/meta-openembedded/meta-efl \
${MY_META_DIR}/meta-openembedded/meta-ruby \
${MY_META_DIR}/meta-openembedded/meta-filesystems \
${MY_META_DIR}/meta-openembedded/meta-gnome \
${MY_META_DIR}/meta-openembedded/meta-multimedia \
${MY_META_DIR}/meta-openembedded/meta-networking \
${MY_META_DIR}/meta-openembedded/meta-webserver \
${MY_META_DIR}/meta-openembedded/meta-xfce \
${MY_META_DIR}/meta-openembedded/meta-initramfs \
${MY_META_DIR}/meta-openembedded/meta-oe \
${MY_META_DIR}/meta-qt5 \
${MY_META_DIR}/meta-selftest \
${MY_META_DIR}/meta-skeleton \
${MY_META_DIR}/meta-xilinx \
${MY_META_DIR}/meta-xilinx-tools \
${MY_META_DIR}/meta-petalinux \
${MY_META_DIR}/meta-virtualization \
${MY_META_DIR}/meta-xzd \
  "

How can I solve this issue?

Regards,
Pello
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] rdepend for a kernel recipe

2017-05-31 Thread Jacob Chen 
Hi all,

I have two recipes.

kernel :
https://github.com/rockchip-linux/meta-rockchip/blob/morty/recipes-kernel/linux/linux-mainline_4.11.bb
and kernel module:
https://github.com/rockchip-linux/meta-rockchip/blob/morty/recipes-kernel/linux-extra/rockchip-forwardports_4.11.bb

I want that if I set "PREFERRED_PROVIDER_virtual / kernel" to
"linux-mainline", then  "rockchip-forwardports" will be automatically
installed in my rootfs.

I have set  "RDEPENDS_${PN} += "rockchip-forwardports"" in kernel, but
it didn't work. How can I slove it?

Are there some ways i can do in kernel recipe or image recipe?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to install dbg package and not its dependencies?

2017-05-31 Thread Ngọc Thi Huỳnh 
Thank you very much, setting that flag helped!

Huỳnh Ngọc Thi
-so61pi

On Tue, May 30, 2017 at 8:34 PM, Petter Mabäcker  wrote:

> Hi,
>
> If the problem is the footprint, then you can add below line in the
> libexample recipe:
>
> INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
>
> This will prevent the build system from adding any debug info in the
> libexample-dbg package.
>
> BR Petter
>
> [1] - http://www.yoctoproject.org/docs/current/ref-manual/ref-
> manual.html#var-INHIBIT_PACKAGE_DEBUG_SPLIT
>
>
>
> Petter Mabäcker
>
> Technux www.technux.se
>
> 2017-05-30 04:17 skrev Ngọc Thi Huỳnh:
>
> I have both app-example*-dbg* & app-example in IMAGE_INSTALL and the
> result is app-example-dbg & app-example & libexample-dbg & libexample are
> included in the final image.
>
> Huỳnh Ngọc Thi
> -so61pi
>
> On Mon, May 29, 2017 at 9:58 PM, Leonardo Sandoval <
> leonardo.sandoval.gonza...@linux.intel.com> wrote:
>
>> On Sun, 2017-05-28 at 17:23 +0700, Ngọc Thi Huỳnh wrote:
>> > Hi everyone,
>> >
>> >
>> > Let's say I have app-example package which depends on libexample.
>> >
>> > When I add app-example-dbg to IMAGE_INSTALL, libexample-dbg package is
>> > automatically included in the final image which makes the image size
>> > become bigger.
>> >
>> what about installing the non-dbg ones?
>> >
>> > In this case, is there a way to prevent libexample-dbg from being
>> > installed?
>> >
>> >
>> > Thanks,
>> >
>> > Thi Huynh
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problems to build xen-guest-image-minimal

2017-05-31 Thread Khem Raj 
On Wed, May 31, 2017 at 12:22 AM Pello Heriz <
pello.he...@alumni.mondragon.edu> wrote:

> Hi,
>
> I'm trying to build xen-guest-image-minimal with master branch of Yocto,
> but I keep stuck in the next error:
>
> bitbake xen-guest-image-minimal
> NOTE: /opt/yocto_GE/poky/meta-qt5/recipes-qt/qt5/qtbase_git.bb:
> base_contains is deprecated, please use bb.utils.contains instead.
> NOTE: /opt/yocto_GE/poky/meta-qt5/recipes-qt/qt5/qtbase_git.bb:
> base_contains is deprecated, please use bb.utils.contains instead.
> WARNING:
> /opt/yocto_GE/poky/meta-petalinux/recipes-external/external-xilinx-toolchain/
> libgcc-xilinx.bb: LICENSE_libgcov-dev includes licenses (GPL-3.0) that
> are not listed in LICENSE
> Parsing recipes: 100% |##| Time:
> 0:04:34
> Parsing of 2477 .bb files complete (0 cached, 2477 parsed). 3310 targets,
> 312 skipped, 0 masked, 0 errors.
> WARNING: No recipes available for:
>
> /opt/yocto_GE/poky/meta-petalinux/recipes-devtools/python/python-smartpm_%.bbappend
> WARNING: No bb files matched BBFILE_PATTERN_gpe-layer
> '^/opt/yocto_GE/poky/meta-openembedded/meta-gpe/'
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing PROVIDES 'rpmresolve-native'. Close matches:
>   meson-native
>   rpm-native
>   perl-native
> ERROR: Required build target 'xen-guest-image-minimal' has no buildable
> providers.
> Missing or unbuildable dependency chain was: ['xen-guest-image-minimal',
> 'rpmresolve-native']
>

It's possible that you do not have matching releases of various layers I
would first check that

>
>
>
> The bblayers that I have included to the project are the next ones:
>
> BBLAYERS ?= " \
> ${MY_META_DIR}/meta \
> ${MY_META_DIR}/meta-poky \
> ${MY_META_DIR}/meta-yocto-bsp \
> ${MY_META_DIR}/meta-openembedded/meta-perl \
> ${MY_META_DIR}/meta-openembedded/meta-systemd \
> ${MY_META_DIR}/meta-openembedded/meta-gpe \
> ${MY_META_DIR}/meta-openembedded/meta-python \
> ${MY_META_DIR}/meta-openembedded/meta-efl \
> ${MY_META_DIR}/meta-openembedded/meta-ruby \
> ${MY_META_DIR}/meta-openembedded/meta-filesystems \
> ${MY_META_DIR}/meta-openembedded/meta-gnome \
> ${MY_META_DIR}/meta-openembedded/meta-multimedia \
> ${MY_META_DIR}/meta-openembedded/meta-networking \
> ${MY_META_DIR}/meta-openembedded/meta-webserver \
> ${MY_META_DIR}/meta-openembedded/meta-xfce \
> ${MY_META_DIR}/meta-openembedded/meta-initramfs \
> ${MY_META_DIR}/meta-openembedded/meta-oe \
> ${MY_META_DIR}/meta-qt5 \
> ${MY_META_DIR}/meta-selftest \
> ${MY_META_DIR}/meta-skeleton \
> ${MY_META_DIR}/meta-xilinx \
> ${MY_META_DIR}/meta-xilinx-tools \
> ${MY_META_DIR}/meta-petalinux \
> ${MY_META_DIR}/meta-virtualization \
> ${MY_META_DIR}/meta-xzd \
>   "
>
> How can I solve this issue?
>
> Regards,
> Pello
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Buildbot / Autobuilder / custom?

2017-05-31 Thread Joshua Lock 
On Mon, 2017-05-29 at 17:01 -0400, Alain Achkar wrote:
> Hello Beth and/or Joshua,
> I would really appreciate some pointers on how to get the Variscite
> builds to work with Autobuilder.
> 
> Since my last email, I was able to setup the Yocto Autobuilder, add
> the sample hello.conf and run it.
> I was also able to add another file, nightly-variscite-x11.conf and I
> can see it in the Waterfall view. Initially, I started by filling it
> with content similar to hello.conf and this worked. Now, I need to be
> able to add the Variscite build.
> 
> Since my last email, Variscite have moved to the morty branch, since
> Freescale/NXP have moved to the morty branch. So, the wiki
> instructions here http://variwiki.com/index.php?title=Yocto_Build_Rel
> ease&release=RELEASE_MORTY_BETA_DART-6UL are now simpler:
> 
> 1) Checkout the source code
> $ mkdir ~/var-fslc-yocto
> $ cd ~/var-fslc-yocto
> $ repo init -u https://github.com/varigit/variscite-bsp-platform.git
> -b morty
> $ repo sync -j4
> 
> 2) Run the setup script (which calls oe-init-environment)
> $ cd ~/var-fslc-yocto
> $ MACHINE=imx6ul-var-dart DISTRO=fslc-x11 . setup-environment
> build_x11
> 
> 3) Build X11 demo images
> # Without Qt content:
> $ bitbake fsl-image-gui
> 
> # Or with Qt content:
> $ bitbake fsl-image-qt5
> 
> The 'repo' command reads the file default.xml which has the following
> contents:
> 
> 
> 
> 
> 
>   
> 
> 
>   https://git.yoctoproject.org/git"; name="yocto"/>
>   https://github.com/Freescale";     name="freescale"/>
>   https://github.com/openembedded";  name="oe"/>
>   https://github.com/varigit";       name="variscite"/>
>   https://github.com/OSSystems";     name="OSSystems"/>
>   
> 
> 
>    revision="6a1f33cc40bfac33cf030fe41e1a8efd1e5fad6f" upstream="morty"
>  name="poky" path="sources/poky"/>
>    revision="56a1460777d1e24b1dfb426cad2b103740936a83" upstream="morty"
>  name="meta-freescale" path="sources/meta-freescale" />
> 
> 
>    revision="fe5c83312de11e80b85680ef237f8acb04b4b26e" upstream="morty"
> name="meta-openembedded" path="sources/meta-openembedded" />
> 
> 
>   
>   
>   
>   
> 
> 
>    revision="4be3db25959e741ac9164a32c82b8c09b59213ad" upstream="morty"
> name="meta-freescale-3rdparty" path="sources/meta-freescale-
> 3rdparty"/>
>    revision="dd482aeb7913c099c69f82362776bd92b584553c" upstream="morty"
> name="meta-freescale-distro" path="sources/meta-freescale-distro"/>
>    revision="3601fd2c5306ac6d5d0d536e0be8cbb90da9b4c1" upstream="morty"
> name="meta-qt5" path="sources/meta-qt5"/>
>    revision="7d37ae2adec5cc5ea27367ce125bc7bce2310ca1" upstream="morty"
> name="meta-browser" path="sources/meta-browser"/>
>    revision="7a214e7579869be810aa8992c59627ba064db076" upstream="morty"
> name="meta-variscite-fslc" path="sources/meta-variscite-fslc"  />
> 
> 
> 
> 
> 
> 
> So, AFAIK, I need to either (a) translate these into the 'repos'
> property in my buildset, or write a custom buildstep that can use the
> 'repo' tool to clone the needed repositories.

You are correct.

The other step you might have issues with is the setup environment
script, yocto-autobuilder currently expects to source oe-init-build-env 
and doesn't support other init scripts presently.

I have a WIP patch to support alternative environment scripts, but it
doesn't fully resolve support for your BSP as it seems from the example
above that MACHINE and DISTRO need to be set in the environment when
the script is sourced.
Will those values be picked up from auto.conf if not set in the
environment?

Joshua-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] yocto-bsp: Fix QEMUARM based bsps to not offer SMP support

2017-05-31 Thread Andre McCurdy 
On Tue, May 30, 2017 at 6:15 PM, Bruce Ashfield
 wrote:
> On Tue, May 30, 2017 at 6:52 PM, Alejandro Hernandez
>  wrote:
>> On 05/30/2017 05:32 PM, Andre McCurdy wrote:
>>> On Tue, May 30, 2017 at 1:12 PM, Alejandro Hernandez
>>>  wrote:

 Hey Leo,

 Nope, this change only applies to qemuARM, the other ARM based BSPs are
 based on > ARMv6

 Alejandro


 On 05/30/2017 02:59 PM, Leonardo Sandoval wrote:
>
> Alex,
>
> is this change only applies to qemu arm? I wonder if the native arm
> arch
> needs a similar series.
>
> Leo
>
> On Tue, 2017-05-30 at 11:44 -0700, Alejandro Hernandez wrote:
>>
>> The SMP kernel config presents issues on qemuarm because:
>>
>> CONFIG_SMP=y
>> Dependencies Missing:
>> - CPU_V6K or CPU_V7:
>>   These are selected by setting:
>>   CONFIG_ARCH_MULTI_V7=y
>>   or
>>   CONFIG_ARCH_MULTI_V6=y
>>
>> But our QEMU + ARM BSPs are based on armv4/v5 hence they are
>> incompatible with CONFIG_SMP.
>>>
>>> Maybe time to think (again) about updating OE's qemu ARM builds to ARMv7.
>>
>> I believe qemu has deep issues with newer ARMs, and thats why it's been
>> kept like that.
>
> Qemu itself should be fine with the newer ARMs .. but we've just targeted a
> lowest common
> denominator (and simple) ARM arch for this target. Since the primary goal
> isn't testing the ISA or arch
> specifics via qemuarm/qemuarm64 (rather, sanity, base arch support, etc).
>
> That being said, as long as a newer platform/board was chosen that had full
> disk support
> (something that the qemuarma9 lacks), then it is feasible to do an update to
> something
> newer. Alternatively, we could keep the platform the same and update the CPU
> definition .. but
> there's not a huge value in that.

Keeping the existing platform but updating the CPU would have the
advantage that qemuarm could then share binaries and sstate with real
world ARM targets.

It would also be a step towards defining an official "generic ARMv7"
tuning target within OE, which could be used as the default
DEFAULTTUNE for all ARMv7 targets.

> But if we did bring in something newer, we'd have to drop the existing
> qemuarm and document that
> we aren't doing any coverage on the older ARM arches.
>
> Bruce
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] yocto-bsp: Fix QEMUARM based bsps to not offer SMP support

2017-05-31 Thread Khem Raj 
On Tue, May 30, 2017 at 6:15 PM, Bruce Ashfield 
wrote:
>
>
> On Tue, May 30, 2017 at 6:52 PM, Alejandro Hernandez
>  wrote:
>>
>> Hey Andy,
>>
>>
>> On 05/30/2017 05:32 PM, Andre McCurdy wrote:
>>>
>>> On Tue, May 30, 2017 at 1:12 PM, Alejandro Hernandez
>>>  wrote:

 Hey Leo,

 Nope, this change only applies to qemuARM, the other ARM based BSPs are
 based on > ARMv6

 Alejandro


 On 05/30/2017 02:59 PM, Leonardo Sandoval wrote:
>
> Alex,
>
> is this change only applies to qemu arm? I wonder if the native arm
> arch
> needs a similar series.
>
> Leo
>
> On Tue, 2017-05-30 at 11:44 -0700, Alejandro Hernandez wrote:
>>
>> The SMP kernel config presents issues on qemuarm because:
>>
>> CONFIG_SMP=y
>> Dependencies Missing:
>> - CPU_V6K or CPU_V7:
>>   These are selected by setting:
>>   CONFIG_ARCH_MULTI_V7=y
>>   or
>>   CONFIG_ARCH_MULTI_V6=y
>>
>> But our QEMU + ARM BSPs are based on armv4/v5 hence they are
>> incompatible with CONFIG_SMP.
>>>
>>> Maybe time to think (again) about updating OE's qemu ARM builds to
ARMv7.
>>
>> I believe qemu has deep issues with newer ARMs, and thats why it's been
>> kept like that.
>
>
> Qemu itself should be fine with the newer ARMs .. but we've just targeted
a
> lowest common
> denominator (and simple) ARM arch for this target. Since the primary goal
> isn't testing the ISA or arch
> specifics via qemuarm/qemuarm64 (rather, sanity, base arch support, etc).
>

I think it will be more effective if we tested most used configuration
instead, it would help a larger community. GCC 7 also dropped armv5 ( the t
variants are still supported )

I would think keep the name qemuarm but use armv7 based machine to emulate
would be an option I am sure meta Linaro has some work on this that can be
used in oe core


> That being said, as long as a newer platform/board was chosen that had
full
> disk support
> (something that the qemuarma9 lacks), then it is feasible to do an update
to
> something
> newer. Alternatively, we could keep the platform the same and update the
CPU
> definition .. but
> there's not a huge value in that.
>
> But if we did bring in something newer, we'd have to drop the existing
> qemuarm and document that
> we aren't doing any coverage on the older ARM arches.
>
> Bruce
>
>>
>>
>>>
>> This patch fixes the script, and avoids offering SMP to the user
>> when the created BSP is based on QEMU + ARM.
>>
>
>> [YOCTO #11426]
>>
>> Signed-off-by: Alejandro Hernandez
>> 
>> ---
>>.../target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend
>> | 1 +
>>
>>
.../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
>> | 1 +
>>
>>
>>
.../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend | 1
>> +
>>
>>
.../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
>> | 1 +
>>
>>
.../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.8.bbappend
>> | 1 +
>>.../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.1.bbappend
>> | 1 +
>>
.../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.10.bbappend
>> | 1 +
>>.../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.4.bbappend
>> | 1 +
>>.../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.8.bbappend
>> | 1 +
>>9 files changed, 9 insertions(+)
>>
>> diff --git
>>
>>
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend
>>
>>
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend
>> index 7e3ce5ba12d..11105ebcc26 100644
>> ---
>>
>>
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend
>> +++
>>
>>
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend
>> @@ -45,6 +45,7 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
>>{{ if need_new_kbranch == "n": }}
>>KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
>>+{{ if qemuarch != "arm": }}
>>{{ input type:"boolean" name:"smp" prio:"30" msg:"Would you like
>> SMP
>> support? (y/n)" default:"y"}}
>>{{ if smp == "y": }}
>>KERNEL_FEATURES_append_{{=machine}} += " cfg/smp.scc"
>> diff --git
>>
>>
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
>>
>>
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
>> index 81392ce38ac..ad77a662682 100644
>> ---
>>
>>
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
>> +++
>>
>>
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4

Re: [yocto] [PATCH] yocto-bsp: Fix QEMUARM based bsps to not offer SMP support

2017-05-31 Thread gmane 

On 2017-05-31 21:20, Andre McCurdy wrote:


Keeping the existing platform but updating the CPU would have the
advantage that qemuarm could then share binaries and sstate with real
world ARM targets.

It would also be a step towards defining an official "generic ARMv7"
tuning target within OE, which could be used as the default
DEFAULTTUNE for all ARMv7 targets.



I would highly appreciate a "generic ARMv7" target!

What I usually use on various boards is:

*) DEFAULTTUNE = "armv7a-neon"
   include conf/machine/include/arm/arch-armv7a.inc
*) same rootfs binay for all boards
*) a kernel starting from a multi_v7_defconfig
*) a different device tree for each board
*) a different u-boot for each board

I even got such a kernel/rootfs to work with the qemu which comes with 
the Yocto project with some ancient Yocto version by hacking the qemu 
run script [1][2]. This uses the versatile expressa qemu target and uses 
a device tree. I did not try, but nowadays runqemu is in Python and 
something like this should be possible as well. Like this the same 
binaries could run on qemu and on various boards.


[1] 
https://github.com/RobertBerger/poky/blob/2015-03-20-dizzy%2B/scripts/runqemu
[2] 
https://github.com/RobertBerger/poky/blob/2015-03-20-dizzy%2B/scripts/runqemu-internal

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [layerindex-web][PATCH v2] layerindex/views: support querying by layer name

2017-05-31 Thread Jose Lamego 
This change supports querying recipes that belong to a specific layer
by using the prefix "layer:" + the desired layer name, for example:
"layer: openembedded-core" and this string can be used by itself or
combined with other supported options.

A descriptive error message is displayed when the query string has an
unexpected formatting or a non-valid layer name is searched.

[YOCTO #6618]

Signed-off-by: Jose Lamego 
---
 layerindex/views.py | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/layerindex/views.py b/layerindex/views.py
index 65a536a..3eac3ac 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -390,13 +390,28 @@ class RecipeSearchView(ListView):
 for item in query_items:
 if item.startswith('inherits:'):
 inherits.append(item.split(':')[1])
+# support searches by layer name
+elif item.startswith('layer:'):
+query_layername = item.split(':')[1].strip().lower()
+if not query_layername:
+messages.add_message(self.request, messages.ERROR, 'The \
+layer name is expected to follow the \"layer:\" prefix without any spaces.')
+query_layer = LayerBranch.objects.filter(
+layer__name=query_layername)
+if query_layer:
+init_qs = init_qs.filter(
+layerbranch__layer__id=query_layer[0].id)
+else:
+messages.add_message(self.request, messages.ERROR,
+ 'No layer \"%s\" was found.'
+ % query_layername)
 else:
 query_terms.append(item)
 if inherits:
 # FIXME This is a bit ugly, perhaps we should consider having this 
as a one-many relationship instead
 for inherit in inherits:
 init_qs = init_qs.filter(Q(inherits=inherit) | 
Q(inherits__startswith=inherit + ' ') | Q(inherits__endswith=' ' + inherit) | 
Q(inherits__contains=' %s ' % inherit))
-query_string = ' '.join(query_terms)
+query_string = ' '.join(query_terms)
 
 if query_string.strip():
 order_by = ('pn', 'layerbranch__layer')
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-freescale] etnaviv image

2017-05-31 Thread Stephen Arnold 
Hmm, I built the same commits from your recipes, and I'm still getting the
glx error in my logs :/

Other than that, things seem to work okay...

Steve

On Sat, May 27, 2017 at 9:20 PM, Trevor Woerner  wrote:

> Hey Stephen,
>
> On Fri, May 26, 2017 at 7:23 PM, Stephen Arnold
>  wrote:
> > @Trevor what's your config/setup?  Did you wind up using the
> > "use-mainline-bsp" thing?
>
> Yes.
>
> As I mentioned, I was working with a wandboard, on master, therefore
> my layers are:
> - openembedded-core
> - meta-freescale-3rdparty
> - meta-freescale
>
> If I was working on some other board that didn't require
> meta-freescale-3rdparty I wouldn't have needed that layer.
> Additionally, I had started by using meta-etnaviv as well. That layer
> hasn't seen any commits in roughly 10 months. Back then my guess is
> that "upstream" didn't include very many of the bits required to get
> this to work, therefore meta-etnaviv had to include recipes/bbappends
> for mesa, libdrm, xorg-xserver, etc... in addition to the etnaviv drm
> pieces themselves.
>
> I created my own clone of meta-etnaviv
> [https://github.com/twoerner/meta-etnaviv] and pushed all my
> commits/updates there with the intention of, eventually, sending a
> pull request to its author. But by the time I was done removing all
> the things that are no longer needed (i.e. all the bbappends, since
> upstream mesa, libdrm, etc... all include the necessary bits) and
> updating the remaining stuff, I was left with very little. So little,
> in fact, that I decided to simply fold what was left back into
> meta-freescale itself, conditional on the "use-mainline-bsp"
> MACHINEOVERRIDES, and sent those patches to the meta-fsl mailing list.
>
> If the maintainers of meta-freescale accept the assumption that
> use-mainline-bsp could be the flag that indicates interest between the
> binary vivante drivers and etnaviv, then I hope they like the patches
> and accept them into meta-freescale itself. Otherwise I could just
> send that pull request to meta-etanviv's author (or re-work the
> patches with whatever feedback I get). In any case, for wandboard
> use-mainline-bsp is needed since the default kernel for wandboard is
> linux-wandboard which is still stuck at 4.1.15 and is too old for this
> etnaviv stuff. However using use-mainline-bsp with the wandboard is
> broken, so I had to send some patches for that (u-boot and kernel) as
> well (hopefully those patches are accepted as well).
>
> Due to the fact so much of etnaviv is already upstream, getting
> etanviv working doesn't take very much. It just took me a while to
> reach that point, however :-)
>
> > I pretty much had to hack up some of the meta-fsl/meta-boundary stuff and
> > put everything else in local.conf.  It would be a little easier/cleaner
> if
> > the former had some ?= in a few places...
> >
> > Anyway, I masked the browser stuff so I haven't tested that far yet, but
> all
> > you really need for 3D under X is new kernel/libdrm/mesa for ~110 fps
> with
> > glxgears.
>
> I like to use mesa-demos and (especially) glmark2 as my programs of
> choice for testing GL stuff.
>
> > I added recipes for the x11-armada stuff, which seems to work for
> > 2D but coughs an error in the xorg log.
>
> I'm curious to know which x11-armada stuff you're using. I couldn't
> get the stuff that came with meta-etnaviv to compile so I looked
> around and found Russell King's code which seemed more up-to-date, and
> compiled. Plus my xorg log doesn't have any errors (see attachment).
>
> > I probably tested more with oe-core
> > than poky but both should work.
>
> I just tend to stick with oe-core.
>
> I'm hoping to make a couple blog posts with my findings.
>
[   558.679] 
X.Org X Server 1.19.3
Release Date: 2017-03-15
[   558.679] X Protocol Version 11, Revision 0
[   558.679] Build Operating System: Linux 4.10.10-gentoo armv7l Gentoo
[   558.679] Current Operating System: Linux gencube 4.10.10-gentoo #1 SMP PREEMPT Sun Apr 23 05:44:04 PDT 2017 armv7l
[   558.679] Kernel command line: console=ttymxc0 root=PARTUUID=7d2c5159-01 ro rootfstype=ext4 rootwait video=HDMI-A-1:1024x768 net.ifnames=0 cma=384M console=tty1 ahci_imx.hotplug=1
[   558.680] Build Date: 31 May 2017  03:00:40PM
[   558.680]  
[   558.680] Current version of pixman: 0.34.0
[   558.680] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[   558.680] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   558.680] (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 31 16:19:51 2017
[   558.681] (==) Using config directory: "/etc/X11/xorg.conf.d"
[   558.681] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   558.681] (==) No Layout section.  Using the first Screen section.
[   558.681] (==) No screen section available. Using defaults.
[   558.681] (**) |-->Screen "De

Re: [yocto] [PATCH][meta-raspberrypi] linux-raspberrypi_dev: don't use AUTOREV

2017-05-31 Thread Andrei Gherzan 
On Tue, May 30, 2017 at 6:29 PM, Khem Raj  wrote:

> On Tue, May 30, 2017 at 10:25 AM, Andre McCurdy 
> wrote:
> > On Tue, May 30, 2017 at 10:15 AM, Paul Barker 
> wrote:
> >> On 30 May 2017 5:08 p.m., "Khem Raj"  wrote:
> >>
> >> On Tue, May 30, 2017 at 12:57 AM, Martin Jansa 
> >> wrote:
> >>> * use latest revision in rpi-4.11.y branch
> >>> * using AUTOREV causes bitbake to run git ls-remote on the github.com
> >>> repository in order
> >>>   to convert AUTOREV to currently latest SRCREV even when you don't use
> >>> linux-raspberrypi_dev
> >>>   at all, just happen to have meta-raspberrypi layer in your
> >>> bblayers.conf, that's bad for
> >>>   people who want to be able to build without network access
> (completely
> >>> from premirror)
> >>>
> >>
> >> These branches get rebased often so locking SRCREV caused another
> >> kind of problem. what we can do is.
> >>
> >> 1. Let user like you override the SRCREC via a bbappend or conf file.
> >> so change the assignment to ?=
> >> 2. Delete the recipe completely. We lose some of upstream testing.
> >>
> >> We should be able to skip the recipe if it isn't selected as the
> preferred
> >> version and/or provider of "virtual/kernel". I'm out at the minute so
> can't
> >> look at it now but will try to take a look later this week.
> >
> > The linux-yocto-dev.bb recipe contains an example of doing that.
> >
>
> ah perfect. Thats what we need here
>
> http://cgit.openembedded.org/openembedded-core/tree/meta/
> recipes-kernel/linux/linux-yocto-dev.bb?h=master#n28
>
> please rename the recipe to be linux-raspberrypi-dev.bb and add the magic
> above and send a v2
>
>
Using the magic above we still hardcode a revision there. So if a user
wants to compile the recipe without setting the preferred provider it will
fail.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-raspberrypi] linux-raspberrypi_dev: don't use AUTOREV

2017-05-31 Thread Khem Raj 
On Wed, May 31, 2017 at 5:00 PM, Andrei Gherzan  wrote:
>
> On Tue, May 30, 2017 at 6:29 PM, Khem Raj  wrote:
>>
>> On Tue, May 30, 2017 at 10:25 AM, Andre McCurdy 
>> wrote:
>> > On Tue, May 30, 2017 at 10:15 AM, Paul Barker 
>> > wrote:
>> >> On 30 May 2017 5:08 p.m., "Khem Raj"  wrote:
>> >>
>> >> On Tue, May 30, 2017 at 12:57 AM, Martin Jansa 
>> >> wrote:
>> >>> * use latest revision in rpi-4.11.y branch
>> >>> * using AUTOREV causes bitbake to run git ls-remote on the github.com
>> >>> repository in order
>> >>>   to convert AUTOREV to currently latest SRCREV even when you don't
>> >>> use
>> >>> linux-raspberrypi_dev
>> >>>   at all, just happen to have meta-raspberrypi layer in your
>> >>> bblayers.conf, that's bad for
>> >>>   people who want to be able to build without network access
>> >>> (completely
>> >>> from premirror)
>> >>>
>> >>
>> >> These branches get rebased often so locking SRCREV caused another
>> >> kind of problem. what we can do is.
>> >>
>> >> 1. Let user like you override the SRCREC via a bbappend or conf file.
>> >> so change the assignment to ?=
>> >> 2. Delete the recipe completely. We lose some of upstream testing.
>> >>
>> >> We should be able to skip the recipe if it isn't selected as the
>> >> preferred
>> >> version and/or provider of "virtual/kernel". I'm out at the minute so
>> >> can't
>> >> look at it now but will try to take a look later this week.
>> >
>> > The linux-yocto-dev.bb recipe contains an example of doing that.
>> >
>>
>> ah perfect. Thats what we need here
>>
>>
>> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-kernel/linux/linux-yocto-dev.bb?h=master#n28
>>
>> please rename the recipe to be linux-raspberrypi-dev.bb and add the magic
>> above and send a v2
>>
>
> Using the magic above we still hardcode a revision there. So if a user wants
> to compile the recipe without setting the preferred provider it will fail.

what will be the usecase ? when you have a different kernel selected but
woould like to compile yet another kernel

that rev can be a well known rev like branchpoint. Moreover, I think
if someone wants to use the dev recipe then its expected that they
switch
to using AUTOREV or some other local mechanism for pinning if needed.

>
> --
> Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] yocto-bsp: Fix QEMUARM based bsps to not offer SMP support

2017-05-31 Thread Alejandro Hernandez 

On 05/31/2017 01:46 PM, Khem Raj wrote:



On Tue, May 30, 2017 at 6:15 PM, Bruce Ashfield 
mailto:bruce.ashfi...@gmail.com>> wrote:

>
>
> On Tue, May 30, 2017 at 6:52 PM, Alejandro Hernandez
> > wrote:

>>
>> Hey Andy,
>>
>>
>> On 05/30/2017 05:32 PM, Andre McCurdy wrote:
>>>
>>> On Tue, May 30, 2017 at 1:12 PM, Alejandro Hernandez
>>> > wrote:


 Hey Leo,

 Nope, this change only applies to qemuARM, the other ARM based 
BSPs are

 based on > ARMv6

 Alejandro


 On 05/30/2017 02:59 PM, Leonardo Sandoval wrote:
>
> Alex,
>
> is this change only applies to qemu arm? I wonder if the native arm
> arch
> needs a similar series.
>
> Leo
>
> On Tue, 2017-05-30 at 11:44 -0700, Alejandro Hernandez wrote:
>>
>> The SMP kernel config presents issues on qemuarm because:
>>
>> CONFIG_SMP=y
>> Dependencies Missing:
>> - CPU_V6K or CPU_V7:
>>   These are selected by setting:
>>   CONFIG_ARCH_MULTI_V7=y
>>   or
>>   CONFIG_ARCH_MULTI_V6=y
>>
>> But our QEMU + ARM BSPs are based on armv4/v5 hence they are
>> incompatible with CONFIG_SMP.
>>>
>>> Maybe time to think (again) about updating OE's qemu ARM builds to 
ARMv7.

>>
>> I believe qemu has deep issues with newer ARMs, and thats why it's been
>> kept like that.
>
>
> Qemu itself should be fine with the newer ARMs .. but we've just 
targeted a

> lowest common
> denominator (and simple) ARM arch for this target. Since the primary 
goal

> isn't testing the ISA or arch
> specifics via qemuarm/qemuarm64 (rather, sanity, base arch support, 
etc).

>

I think it will be more effective if we tested most used configuration 
instead, it would help a larger community. GCC 7 also dropped armv5 ( 
the t variants are still supported )


I would think keep the name qemuarm but use armv7 based machine to 
emulate would be an option I am sure meta Linaro has some work on this 
that can be used in oe core



I would also assume they've got some work on this, it'd be nice to 
contact them and see if this can be done, although I asked on IRC 
several times to see what people thoughts were on if we should upgrade 
and I practically got no feedback.


> That being said, as long as a newer platform/board was chosen that 
had full

> disk support
> (something that the qemuarma9 lacks), then it is feasible to do an 
update to

> something
> newer. Alternatively, we could keep the platform the same and update 
the CPU

> definition .. but
> there's not a huge value in that.
>
> But if we did bring in something newer, we'd have to drop the existing
> qemuarm and document that
> we aren't doing any coverage on the older ARM arches.
>
> Bruce
>
>>
>>
>>>
>> This patch fixes the script, and avoids offering SMP to the user
>> when the created BSP is based on QEMU + ARM.
>>
>
>> [YOCTO #11426]
>>
>> Signed-off-by: Alejandro Hernandez
>> >

>> ---
>> .../target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend
>> | 1 +
>>
>> 
.../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend

>> | 1 +
>>
>>
>> 
.../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend 
| 1

>> +
>>
>> 
.../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend

>> | 1 +
>>
>> 
.../target/arch/qemu/recipes-kernel/linux/linux-yocto-tiny_4.8.bbappend

>> | 1 +
>> .../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.1.bbappend
>> | 1 +
>> .../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.10.bbappend
>> | 1 +
>> .../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.4.bbappend
>> | 1 +
>> .../target/arch/qemu/recipes-kernel/linux/linux-yocto_4.8.bbappend
>> | 1 +
>>9 files changed, 9 insertions(+)
>>
>> diff --git
>>
>> 
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend

>>
>> 
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend

>> index 7e3ce5ba12d..11105ebcc26 100644
>> ---
>>
>> 
a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend

>> +++
>>
>> 
b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/linux-yocto-dev.bbappend

>> @@ -45,6 +45,7 @@ COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"
>>{{ if need_new_kbranch == "n": }}
>>KBRANCH_{{=machine}}  = "{{=existing_kbranch}}"
>>+{{ if qemuarch != "arm": }}
>>{{ input type:"boolean" name:"smp" prio:"30" msg:"Would you like
>> SMP
>> support? (y/n)" default:"y"}}
>>{{ if smp == "y": }}
>>KERNEL_FEATURES_append_{{=machine}} += " cfg/smp.scc"
>> diff --git
>>

Re: [yocto] [PATCH] yocto-bsp: Fix QEMUARM based bsps to not offer SMP support

2017-05-31 Thread Khem Raj 
On Wed, May 31, 2017 at 5:41 PM, Alejandro Hernandez
 wrote:
> On 05/31/2017 01:46 PM, Khem Raj wrote:
>
>
>
> On Tue, May 30, 2017 at 6:15 PM, Bruce Ashfield 
> wrote:
>>
>>
>> On Tue, May 30, 2017 at 6:52 PM, Alejandro Hernandez
>>  wrote:
>>>
>>> Hey Andy,
>>>
>>>
>>> On 05/30/2017 05:32 PM, Andre McCurdy wrote:

 On Tue, May 30, 2017 at 1:12 PM, Alejandro Hernandez
  wrote:
>
> Hey Leo,
>
> Nope, this change only applies to qemuARM, the other ARM based BSPs are
> based on > ARMv6
>
> Alejandro
>
>
> On 05/30/2017 02:59 PM, Leonardo Sandoval wrote:
>>
>> Alex,
>>
>> is this change only applies to qemu arm? I wonder if the native arm
>> arch
>> needs a similar series.
>>
>> Leo
>>
>> On Tue, 2017-05-30 at 11:44 -0700, Alejandro Hernandez wrote:
>>>
>>> The SMP kernel config presents issues on qemuarm because:
>>>
>>> CONFIG_SMP=y
>>> Dependencies Missing:
>>> - CPU_V6K or CPU_V7:
>>>   These are selected by setting:
>>>   CONFIG_ARCH_MULTI_V7=y
>>>   or
>>>   CONFIG_ARCH_MULTI_V6=y
>>>
>>> But our QEMU + ARM BSPs are based on armv4/v5 hence they are
>>> incompatible with CONFIG_SMP.

 Maybe time to think (again) about updating OE's qemu ARM builds to
 ARMv7.
>>>
>>> I believe qemu has deep issues with newer ARMs, and thats why it's been
>>> kept like that.
>>
>>
>> Qemu itself should be fine with the newer ARMs .. but we've just targeted
>> a
>> lowest common
>> denominator (and simple) ARM arch for this target. Since the primary goal
>> isn't testing the ISA or arch
>> specifics via qemuarm/qemuarm64 (rather, sanity, base arch support, etc).
>>
>
> I think it will be more effective if we tested most used configuration
> instead, it would help a larger community. GCC 7 also dropped armv5 ( the t
> variants are still supported )
>
> I would think keep the name qemuarm but use armv7 based machine to emulate
> would be an option I am sure meta Linaro has some work on this that can be
> used in oe core
>
>
> I would also assume they've got some work on this, it'd be nice to contact
> them and see if this can be done, although I asked on IRC several times to
> see what people thoughts were on if we should upgrade and I practically got
> no feedback.

http://git.linaro.org/openembedded/meta-linaro.git/tree/meta-aarch64/conf/machine

http://git.linaro.org/openembedded/meta-linaro.git/tree/meta-linaro/conf/machine

looks at genericarm* conf files.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sstate-cache question

2017-05-31 Thread Paul Eggleton 
Hi Gary,

My apologies, I just realised I never sent this reply.

On Tuesday, 23 May 2017 5:27:57 PM NZST you wrote:
> On 2017-05-22 22:35, Paul Eggleton wrote:
> > On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:
> >> I have a build where I've never manually removed anything from
> >> the sstate-cache and this same build has been used for hundreds
> >> of builds over the last 18 months.  I just tried to find out why
> >> gcc-cross-arm had to be rebuilt (it seems to happen almost every
> >> time I update my Poky/Yocto tree (master)).  Here's what I got:
> >>
> >> $ bitbake-diffsigs -t gcc-cross-arm compile
> >> Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from
> > 208373dd9ae01101a26a9412eb50b110 to
> >> d65095d4b9aff89f6990bd17c0ab210b
> >> Unable to find matching sigdata for /local/poky-cutting-edge/meta/
> >> recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
> >> with hashes 208373dd9ae01101a26a9412eb50b110 or
> > d65095d4b9aff89f6990bd17c0ab210b
> >>
> >> So if I didn't remove those files, where did they go?  Am I doing
> >> something wrong running this tool?  (running the same command for
> >> qemu-native seemed to work correctly)
> >
> > Is this with master, pyro, morty or some other version?
> 
> Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06

OK so this is definitely after my recent fixes then.
 
> > If you search for files with those hashes in their name do they show up?
> 
> Only .siginfo files:
> $ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*"
> sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:
> 6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo
> $ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*"
> sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:
> 6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo
> 
> However, I do find some in tmp/stamps:
> $ ls tmp/stamps/x86_64-linux/gcc-cross-arm
> 6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4
> 6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e
> 6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6
> 6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
> 6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b
> 6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110
> 6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
> 6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41
> 6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568
> 6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568
> 6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d
> 6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89
> 6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89
> 6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e
> 6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664
> 6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0
> 6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0
> 6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169
> 6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4
> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
> 6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210
> 
> I guess the sstate-cache info alone is not sufficient to use 'bitbake
> diffsigs'?

It ought to be. At face value it should be finding the files in either place 
- we'd need to debug the code to find out why it isn't. Is that something you 
might be able to help me with?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [layerindex-web][PATCH V2 0/8] Several fixes for layerindex

2017-05-31 Thread Robert Yang 
* V2:
Remove "import bb" from update.py to avoid causing confusions when switch 
branches.

* V1:
The "-a ACTUAL_BRANCH" is a litle different from what we had talked, now it
respects "-l" and "-b", we can use -l to specify layers or default to all,
and it requires "-b" to work, only one branch is supported in a run, for 
example:

$ update.py -b master -a branch_20170526
All the layers which have branch master and actual_branch branch_20170526
will be updated to branch_20170526.

$ update.py -b master -l meta-oe -a branch_20170526
Only meta-oe layer will be updated.

$ update.py -b master -l bitbake -a branch_20170526
The bitbake's bitbake_branch will be updated.

// Robert

The following changes since commit 8dfe44ed5e618d517d4acb4a3107cb3907e773c8:

  TODO: drop implemented items (2017-03-22 14:21:22 +1300)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib rbt/layerindex-8fixes
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rbt/layerindex-8fixes

Robert Yang (8):
  layerconfparse.py: remove unused layerbranch from parse_layer()
  utils.py: remove obsolete dependencies
  update_layer.py: set layerbranch's collection before add_dependencies
  update.py: add -p to git fetch
  update.py: fix -l option
  recipeparse.py: restore cwd when the parsing is done
  update.py: update layers orderly
  update.py: update actual branch for layer and bitbake

 layerindex/layerconfparse.py |   2 +-
 layerindex/recipeparse.py|   3 +
 layerindex/tools/import_layer.py |   2 +-
 layerindex/update.py | 185 +++
 layerindex/update_layer.py   |   6 +-
 layerindex/utils.py  |  59 -
 6 files changed, 215 insertions(+), 42 deletions(-)

-- 
2.10.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH V2 1/8] layerconfparse.py: remove unused layerbranch from parse_layer()

2017-05-31 Thread Robert Yang 
The layerbranch is not used in parse_layer(), so remove it.

Signed-off-by: Robert Yang 
---
 layerindex/layerconfparse.py | 2 +-
 layerindex/tools/import_layer.py | 2 +-
 layerindex/update_layer.py   | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/layerindex/layerconfparse.py b/layerindex/layerconfparse.py
index d599ed5..526d2c2 100644
--- a/layerindex/layerconfparse.py
+++ b/layerindex/layerconfparse.py
@@ -32,7 +32,7 @@ class LayerConfParse:
 
 self.config_data_copy = bb.data.createCopy(self.tinfoil.config_data)
 
-def parse_layer(self, layerbranch, layerdir):
+def parse_layer(self, layerdir):
 
 # This is not a valid layer, parsing will cause exception.
 if not utils.is_layer_valid(layerdir):
diff --git a/layerindex/tools/import_layer.py b/layerindex/tools/import_layer.py
index ad16e40..a806dd1 100755
--- a/layerindex/tools/import_layer.py
+++ b/layerindex/tools/import_layer.py
@@ -377,7 +377,7 @@ def main():
 layerdep.save()
 layerconfparser = LayerConfParse(logger=logger)
 try:
-config_data = layerconfparser.parse_layer(layerbranch, 
layerdir)
+config_data = layerconfparser.parse_layer(layerdir)
 if config_data:
 utils.add_dependencies(layerbranch, config_data, 
logger=logger)
 utils.add_recommends(layerbranch, config_data, 
logger=logger)
diff --git a/layerindex/update_layer.py b/layerindex/update_layer.py
index 9fe96fb..05ab3e7 100644
--- a/layerindex/update_layer.py
+++ b/layerindex/update_layer.py
@@ -267,7 +267,7 @@ def main():
 sys.exit(0)
 
 layerconfparser = layerconfparse.LayerConfParse(logger=logger, 
bitbakepath=bitbakepath, tinfoil=tinfoil)
-config_data = layerconfparser.parse_layer(layerbranch, 
layerdir)
+config_data = layerconfparser.parse_layer(layerdir)
 if not config_data:
 logger.debug("Layer %s does not appear to be valid for 
branch %s" % (layer.name, branchdesc))
 sys.exit(0)
@@ -355,7 +355,7 @@ def main():
 logger.info("Collecting data for layer %s on branch %s" % 
(layer.name, branchdesc))
 
 layerconfparser = layerconfparse.LayerConfParse(logger=logger, 
tinfoil=tinfoil)
-layer_config_data = layerconfparser.parse_layer(layerbranch, 
layerdir)
+layer_config_data = layerconfparser.parse_layer(layerdir)
 if not layer_config_data:
 logger.info("Skipping update of layer %s for branch %s - 
conf/layer.conf may have parse issues" % (layer.name, branchdesc))
 layerconfparser.shutdown()
-- 
2.10.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH V2 3/8] update_layer.py: set layerbranch's collection before add_dependencies

2017-05-31 Thread Robert Yang 
The _add_dependency() uses:
if layerbranch.collection:
var_name = layerbranch.collection

The layerbranch.collection is none if it is newly created, thus it can't get
LAYERDEPENDS, because what defined in layer.conf is LAYERDEPENDS_,
but what it would get is LAYERDEPENDS_, this patch can fix the
problem.

Reproducer:
$ python3 update_layer.py -l mete-xfce -b  --fullreload -d

It would get None LAYERDEPENDS.

Signed-off-by: Robert Yang 
---
 layerindex/update_layer.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/layerindex/update_layer.py b/layerindex/update_layer.py
index 05ab3e7..bcf7056 100644
--- a/layerindex/update_layer.py
+++ b/layerindex/update_layer.py
@@ -360,9 +360,9 @@ def main():
 logger.info("Skipping update of layer %s for branch %s - 
conf/layer.conf may have parse issues" % (layer.name, branchdesc))
 layerconfparser.shutdown()
 sys.exit(1)
+utils.set_layerbranch_collection_version(layerbranch, 
layer_config_data, logger=logger)
 utils.add_dependencies(layerbranch, layer_config_data, 
logger=logger)
 utils.add_recommends(layerbranch, layer_config_data, 
logger=logger)
-utils.set_layerbranch_collection_version(layerbranch, 
layer_config_data, logger=logger)
 layerbranch.save()
 
 try:
-- 
2.10.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH V2 2/8] utils.py: remove obsolete dependencies

2017-05-31 Thread Robert Yang 
Fixed:
  - set LAYERDEPENDS_openembedded-layer = "core"
  - $ "update.py -l meta-oe -b master"
Check from web, its dependency is "openembedded-core"
  - Change LAYERDEPENDS_openembedded-layer = "foo"
  - Run "update.py -l meta-oe -b master"
Check from web, its dependency is "openembedded-core and foo", this is
wrong, it should be "foo" only, this patch can fix the problem.

And also the existing checking should filter(required=required),
otherwise it can't work well when a layer is in both depends and
recommends, this can't happen in a normal case, but it would surprise the
user when this happens.

Signed-off-by: Robert Yang 
---
 layerindex/utils.py | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/layerindex/utils.py b/layerindex/utils.py
index 3b45b07..1a57c07 100644
--- a/layerindex/utils.py
+++ b/layerindex/utils.py
@@ -88,6 +88,7 @@ def _add_dependency(var, name, layerbranch, config_data, 
logger=None, required=T
 logger.debug('Error parsing %s_%s for %s\n%s' % (var, var_name, 
layer_name, str(vse)))
 return
 
+need_delete = None
 for dep, ver_list in list(dep_dict.items()):
 ver_str = None
 if ver_list:
@@ -106,8 +107,14 @@ def _add_dependency(var, name, layerbranch, config_data, 
logger=None, required=T
 logger.error('Cannot resolve %s %s (version %s) for %s' % 
(name, dep, ver_str, layer_name))
 continue
 
+# Preparing to remove obsolete ones
+if not need_delete:
+need_delete = 
LayerDependency.objects.filter(layerbranch=layerbranch).filter(required=required).exclude(dependency=dep_layer)
+else:
+need_delete = need_delete.exclude(dependency=dep_layer)
+
 # Skip existing entries.
-existing = 
list(LayerDependency.objects.filter(layerbranch=layerbranch).filter(dependency=dep_layer))
+existing = 
list(LayerDependency.objects.filter(layerbranch=layerbranch).filter(required=required).filter(dependency=dep_layer))
 if existing:
 logger.debug('Skipping %s - already a dependency for %s' % (dep, 
layer_name))
 continue
@@ -121,6 +128,10 @@ def _add_dependency(var, name, layerbranch, config_data, 
logger=None, required=T
 layerdep.required = required
 layerdep.save()
 
+if need_delete:
+logger.debug("Removing obsolete dependencies: %s" % need_delete)
+need_delete.delete()
+
 def set_layerbranch_collection_version(layerbranch, config_data, logger=None):
 layerbranch.collection = config_data.getVar('BBFILE_COLLECTIONS', True)
 ver_str = "LAYERVERSION_"
-- 
2.10.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH V2 4/8] update.py: add -p to git fetch

2017-05-31 Thread Robert Yang 
-p, --prune
Before fetching, remove any remote-tracking references that no longer exist 
on the remote.

Fixed:
$ git push origin :test_branch
$ ./update.py

The test_branch was still in layerindex which was incorrect, it should
be gone since the branch had been removed from the repo.

Signed-off-by: Robert Yang 
---
 layerindex/update.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index d5c56cd..9c131cb 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -202,7 +202,7 @@ def main():
 if not os.path.exists(repodir):
 out = utils.runcmd("git clone %s %s" % 
(layer.vcs_url, urldir), fetchdir, logger=logger, printerr=False)
 else:
-out = utils.runcmd("git fetch", repodir, 
logger=logger, printerr=False)
+out = utils.runcmd("git fetch -p", repodir, 
logger=logger, printerr=False)
 except subprocess.CalledProcessError as e:
 logger.error("Fetch of layer %s failed: %s" % 
(layer.name, e.output))
 failedrepos[layer.vcs_url] = e.output
@@ -217,7 +217,7 @@ def main():
 if not os.path.exists(bitbakepath):
 out = utils.runcmd("git clone %s %s" % 
(settings.BITBAKE_REPO_URL, 'bitbake'), fetchdir, logger=logger)
 else:
-out = utils.runcmd("git fetch", bitbakepath, logger=logger)
+out = utils.runcmd("git fetch -p", bitbakepath, 
logger=logger)
 
 # Process and extract data from each layer
 # We now do this by calling out to a separate script; doing 
otherwise turned out to be
-- 
2.10.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH V2 5/8] update.py: fix -l option

2017-05-31 Thread Robert Yang 
Fixed:
$ ./update.py -l meta-oe,not_existed

It should report error that "not_existed" doesn't exist, but it didn't, this was
because __in matches any of them.

Signed-off-by: Robert Yang 
---
 layerindex/update.py | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index 9c131cb..541155f 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -152,10 +152,13 @@ def main():
 sys.exit(1)
 
 if options.layers:
-layerquery = 
LayerItem.objects.filter(classic=False).filter(name__in=options.layers.split(','))
-if layerquery.count() == 0:
-logger.error('No layers matching specified query "%s"' % 
options.layers)
-sys.exit(1)
+layers = options.layers.split(',')
+for layer in layers:
+layerquery = 
LayerItem.objects.filter(classic=False).filter(name=layer)
+if layerquery.count() == 0:
+logger.error('No layers matching specified query "%s"' % layer)
+sys.exit(1)
+layerquery = 
LayerItem.objects.filter(classic=False).filter(name__in=layers)
 else:
 # We deliberately exclude status == 'X' ("no update") here
 layerquery = LayerItem.objects.filter(classic=False).filter(status='P')
-- 
2.10.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH V2 6/8] recipeparse.py: restore cwd when the parsing is done

2017-05-31 Thread Robert Yang 
Othewise it may cause troubles to the function who calls it.

Signed-off-by: Robert Yang 
---
 layerindex/recipeparse.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/layerindex/recipeparse.py b/layerindex/recipeparse.py
index dd85bc3..f2a5235 100644
--- a/layerindex/recipeparse.py
+++ b/layerindex/recipeparse.py
@@ -70,10 +70,13 @@ def init_parser(settings, branch, bitbakepath, 
enable_tracking=False, nocheckout
 if not os.path.exists(settings.TEMP_BASE_DIR):
 os.makedirs(settings.TEMP_BASE_DIR)
 tempdir = tempfile.mkdtemp(dir=settings.TEMP_BASE_DIR)
+saved_cwd = os.getcwd()
 os.chdir(tempdir)
 
 tinfoil = utils.setup_tinfoil(bitbakepath, enable_tracking)
 
+os.chdir(saved_cwd)
+
 # Ensure TMPDIR exists (or insane.bbclass will blow up trying to write to 
the QA log)
 oe_tmpdir = tinfoil.config_data.getVar('TMPDIR', True)
 if not os.path.exists(oe_tmpdir):
-- 
2.10.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH V2 7/8] update.py: update layers orderly

2017-05-31 Thread Robert Yang 
* Problems
The update.py couldn't handle new (not only new branch, in fact, but also
existing branches, see below for more info) branch well, for example, there are
3 layers: layer_A, layer_B and layer_C, and create new branch "branch_1" for
them, and they have depends:

layer_A -> layer_B -> layer_C

The "->" means depends on.

Then run "update.py -b branch_1", there would be errors like:

ERROR: Dependency layer_B of layer_A does not have branch record for branch 
branch_1

Though update.py runs "update_layer.py" twice, but it didn't help since
layerbranch was None when it was failed to create in the first run.

The reason is if update.py updates layer_A firstly, it would fail since it
can't find layer_B:branch_1 in database (not added to database yet), similarly,
if add layer_B before layer_C, it would also fail. Only layer_C can be added
(assume it has no dependencies). So we have to re-run update.py again and again
to make it work, here we may have to run update.py 3 times, and more runs are
needed if the dependency chain is longer.

* Solutions:
Make update.py pass layers to update_layer.py orderly can fix the problem, we
can get LAYERDEPENDS and LAYERRECOMMENDS info from tinfoil.

Not only new branch, but also existing branches may have the problem, because
BBFILE_COLLECTIONS maybe changed in the coming update, so we can't trust
database when the layer is going to be updated, for example, if there are 10
layers in database, and 3 of them will be updated (-l layer1,layer2,layer3),
then we can not use the 3 layers' collection data from database, we need get
them from info again, so the code doesn't check whether it is a new branch or
not.

* Performance Improvement:
  It should be faster than before in theory, since it ran update_layer.py
  twice in the past, but now only once, I have tested it with 76 layers:
  - Before: 4m25.912s, but only 30 layers were added, 46 ones were failed, I
have to re-run update.py again and again (maybe 4 times to make all of
them added). So:
(4 * 60 + 25)/30*76/60 = 11.19m

  - Now 8m5.315s, all the layers are added in the first run.

  It improves from 11m to 8m.

Signed-off-by: Robert Yang 
---
 layerindex/update.py | 114 ++-
 layerindex/utils.py  |  35 
 2 files changed, 120 insertions(+), 29 deletions(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index 541155f..f847b85 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -18,6 +18,8 @@ import signal
 from datetime import datetime, timedelta
 from distutils.version import LooseVersion
 import utils
+import operator
+import recipeparse
 
 import warnings
 warnings.filterwarnings("ignore", category=DeprecationWarning)
@@ -151,6 +153,11 @@ def main():
 logger.error("Please set LAYER_FETCH_DIR in settings.py")
 sys.exit(1)
 
+layerquery_all = LayerItem.objects.filter(classic=False).filter(status='P')
+if layerquery_all.count() == 0:
+logger.info("No published layers to update")
+sys.exit(1)
+
 if options.layers:
 layers = options.layers.split(',')
 for layer in layers:
@@ -161,10 +168,7 @@ def main():
 layerquery = 
LayerItem.objects.filter(classic=False).filter(name__in=layers)
 else:
 # We deliberately exclude status == 'X' ("no update") here
-layerquery = LayerItem.objects.filter(classic=False).filter(status='P')
-if layerquery.count() == 0:
-logger.info("No published layers to update")
-sys.exit(1)
+layerquery = layerquery_all
 
 if not os.path.exists(fetchdir):
 os.makedirs(fetchdir)
@@ -186,6 +190,7 @@ def main():
 try:
 lockfn = os.path.join(fetchdir, "layerindex.lock")
 lockfile = utils.lock_file(lockfn)
+tinfoil = None
 if not lockfile:
 logger.error("Layer index lock timeout expired")
 sys.exit(1)
@@ -228,8 +233,82 @@ def main():
 # they never get used during normal operation).
 last_rev = {}
 for branch in branches:
+# If layer_A depends(or recommends) on layer_B, add layer_B 
before layer_A
+deps_dict_all = {}
+layerquery_sorted = []
+collections_done = set()
 branchobj = utils.get_branch(branch)
+try:
+(tinfoil, tempdir) = recipeparse.init_parser(settings, 
branchobj, bitbakepath, nocheckout=options.nocheckout, logger=logger)
+except recipeparse.RecipeParseError as e:
+logger.error(str(e))
+sys.exit(1)
+for layer in layerquery_all:
+# Get all collections from database, but we can't trust the
+# one which will be updated since its collections maybe
+# changed (different from database).
+if layer in layerquery:
+

[yocto] [PATCH V2 8/8] update.py: update actual branch for layer and bitbake

2017-05-31 Thread Robert Yang 
Add an option "-a" to update actual branch for layer and bitbake, it is
useful when there are many layers and need update actual branches
frequantly. We only can update them via website without this patch,
which is not funny and easy to make mistakes.

* It works with "-l", and "-l bitbake" means update bitbake branch.
* It requires "-b" to work, and only one branch is supported in a run.

For example:
$ update.py -b master -a branch_20170526
All the layers which have branch master and actual_branch branch_20170526
will be updated to branch_20170526.

$ update.py -b master -l meta-oe -a branch_20170526
Only meta-oe layer will be updated.

$ update.py -b master -l bitbake -a branch_20170526
The bitbake's bitbake_branch will be updated.

Signed-off-by: Robert Yang 
---
 layerindex/update.py | 56 +++-
 layerindex/utils.py  | 11 +++
 2 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index f847b85..1347e70 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -87,6 +87,41 @@ def prepare_update_layer_command(options, branch, layer, 
updatedeps=False):
 cmd += ' -q'
 return cmd
 
+def update_actual_branch(layerquery, fetchdir, branch, actual_branch, 
update_bitbake, bitbakepath):
+"""Update actual branch for layers and bitbake in database"""
+to_save = set()
+if update_bitbake:
+branchobj = utils.get_branch(branch)
+if actual_branch != branchobj.bitbake_branch:
+if utils.is_branch_valid(bitbakepath, actual_branch):
+logger.info("bitbake: %s.bitbake_branch: %s -> %s" % (branch, 
branchobj.bitbake_branch, actual_branch))
+branchobj.bitbake_branch = actual_branch
+to_save.add(branchobj)
+else:
+logger.info("Skipping update bitbake_branch for bitbake - 
branch %s doens't exist" % actual_branch)
+else:
+logger.info("bitbake: %s.bitbake_branch is already %s, so no 
change" % (branch, actual_branch))
+
+for layer in layerquery:
+urldir = layer.get_fetch_dir()
+repodir = os.path.join(fetchdir, urldir)
+if not utils.is_branch_valid(repodir, actual_branch):
+logger.info("Skipping update actual_branch for %s - branch %s 
doens't exist" % (layer.name, actual_branch))
+continue
+layerbranch = layer.get_layerbranch(branch)
+if not layerbranch:
+logger.info("Skipping update actual_branch for %s - layerbranch %s 
doens't exist" % (layer.name, branch))
+continue
+if actual_branch != layerbranch.actual_branch:
+logger.info("%s: %s.actual_branch: %s -> %s" % (layer.name, 
branch, layerbranch.actual_branch, actual_branch))
+layerbranch.actual_branch = actual_branch
+to_save.add(layerbranch)
+else:
+logger.info("%s: %s.actual_branch is already %s, so no change" % 
(layer.name, branch, actual_branch))
+
+# At last, do the save
+for s in to_save:
+s.save()
 
 def main():
 if LooseVersion(git.__version__) < '0.3.1':
@@ -104,6 +139,9 @@ def main():
 parser.add_option("-l", "--layer",
 help = "Specify layers to update (use commas to separate 
multiple). Default is all published layers.",
 action="store", dest="layers")
+parser.add_option("-a", "--actual-branch",
+help = "Update actual branch for layer and bitbake",
+action="store", dest="actual_branch", default='')
 parser.add_option("-r", "--reload",
 help = "Reload recipe data instead of updating since last update",
 action="store_true", dest="reload")
@@ -158,8 +196,13 @@ def main():
 logger.info("No published layers to update")
 sys.exit(1)
 
+# For -a option to update bitbake branch
+update_bitbake = False
 if options.layers:
 layers = options.layers.split(',')
+if 'bitbake' in layers:
+update_bitbake = True
+layers.remove('bitbake')
 for layer in layers:
 layerquery = 
LayerItem.objects.filter(classic=False).filter(name=layer)
 if layerquery.count() == 0:
@@ -168,6 +211,7 @@ def main():
 layerquery = 
LayerItem.objects.filter(classic=False).filter(name__in=layers)
 else:
 # We deliberately exclude status == 'X' ("no update") here
+update_bitbake = True
 layerquery = layerquery_all
 
 if not os.path.exists(fetchdir):
@@ -217,7 +261,7 @@ def main():
 continue
 fetchedrepos.append(layer.vcs_url)
 
-if not fetchedrepos:
+if not (fetchedrepos or update_bitbake):
 logger.error("No repositories could be fetched, exiting")
 sys.exit(1)
 
@@ -227,6 +271,16 @@ def main():
 else:

Re: [yocto] sstate-cache question

2017-05-31 Thread Gary Thomas 

On 2017-06-01 05:28, Paul Eggleton wrote:

Hi Gary,

My apologies, I just realised I never sent this reply.

On Tuesday, 23 May 2017 5:27:57 PM NZST you wrote:

On 2017-05-22 22:35, Paul Eggleton wrote:

On Tuesday, 23 May 2017 2:53:45 AM NZST Gary Thomas wrote:

I have a build where I've never manually removed anything from
the sstate-cache and this same build has been used for hundreds
of builds over the last 18 months.  I just tried to find out why
gcc-cross-arm had to be rebuilt (it seems to happen almost every
time I update my Poky/Yocto tree (master)).  Here's what I got:

$ bitbake-diffsigs -t gcc-cross-arm compile
Hash for dependent task gcc/gcc-cross_6.3.bb.do_configure changed from

208373dd9ae01101a26a9412eb50b110 to

d65095d4b9aff89f6990bd17c0ab210b
Unable to find matching sigdata for /local/poky-cutting-edge/meta/
recipes-devtools/gcc/gcc-cross_6.3.bb.do_configure
with hashes 208373dd9ae01101a26a9412eb50b110 or

d65095d4b9aff89f6990bd17c0ab210b


So if I didn't remove those files, where did they go?  Am I doing
something wrong running this tool?  (running the same command for
qemu-native seemed to work correctly)


Is this with master, pyro, morty or some other version?


Poky master: 2568e18701fb20d7105eb6e4929f3aff4b9f9c06


OK so this is definitely after my recent fixes then.
  

If you search for files with those hashes in their name do they show up?


Only .siginfo files:
$ find sstate-cache/ -name "*d65095d4b9aff89f6990bd17c0ab210b*"
sstate-cache/universal/d6/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:
6.3.0:r0:x86_64_arm:3:d65095d4b9aff89f6990bd17c0ab210b_configure.tgz.siginfo
$ find sstate-cache -name "*208373dd9ae01101a26a9412eb50b110*"
sstate-cache/universal/20/sstate:gcc-cross-arm:x86_64-amltd-linux-gnueabi:
6.3.0:r0:x86_64_arm:3:208373dd9ae01101a26a9412eb50b110_configure.tgz.siginfo

However, I do find some in tmp/stamps:
$ ls tmp/stamps/x86_64-linux/gcc-cross-arm
6.3.0-r0.do_build.41aca0d85971087f4675d2f504642ce4
6.3.0-r0.do_compile.b0eae7e91833efd5e7eceaedbc59983e
6.3.0-r0.do_compile.sigdata.9a06aa40225be30babaceb7673cef0a6
6.3.0-r0.do_compile.sigdata.b0eae7e91833efd5e7eceaedbc59983e
6.3.0-r0.do_configure.d65095d4b9aff89f6990bd17c0ab210b
6.3.0-r0.do_configure.sigdata.208373dd9ae01101a26a9412eb50b110
6.3.0-r0.do_configure.sigdata.d65095d4b9aff89f6990bd17c0ab210b
6.3.0-r0.do_fetch.1dd3c87b3e509c20fa4ffe61d6dc3b41
6.3.0-r0.do_gcc_stash_builddir.063822f91220bb40cef0696eb604a568
6.3.0-r0.do_gcc_stash_builddir.sigdata.063822f91220bb40cef0696eb604a568
6.3.0-r0.do_gcc_stash_builddir.sigdata.28144d3c18c0a09f23f3b0c5e80f049d
6.3.0-r0.do_install.0f96c5448dc9360ca3a24d551ad3da89
6.3.0-r0.do_install.sigdata.0f96c5448dc9360ca3a24d551ad3da89
6.3.0-r0.do_install.sigdata.f2e4d12289c5039854081a832dc8bc0e
6.3.0-r0.do_populate_lic_setscene.d2c9226ddb0de5277e2347b69ef84664
6.3.0-r0.do_populate_sysroot.15afc3bb019a6c0c1285cbda46cb32b0
6.3.0-r0.do_populate_sysroot.sigdata.15afc3bb019a6c0c1285cbda46cb32b0
6.3.0-r0.do_populate_sysroot.sigdata.a0c5b715ae9217f02318beff6987d169
6.3.0-r0.do_prepare_recipe_sysroot.150112323551011e0e87f99f47ad79c4
6.3.0-r0.do_prepare_recipe_sysroot.sigdata.150112323551011e0e87f99f47ad79c4
6.3.0-r0.do_prepare_recipe_sysroot.sigdata.4a528becf11832cc3b8f6fa479e98210

I guess the sstate-cache info alone is not sufficient to use 'bitbake
diffsigs'?


It ought to be. At face value it should be finding the files in either place
- we'd need to debug the code to find out why it isn't. Is that something you
might be able to help me with?



Happy to give it a go, just let me know what you need

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sstate-cache question

2017-05-31 Thread Paul Eggleton 
On Thursday, 1 June 2017 3:44:49 PM NZST Gary Thomas wrote:
> On 2017-06-01 05:28, Paul Eggleton wrote:
> > It ought to be. At face value it should be finding the files in either
> > place - we'd need to debug the code to find out why it isn't. Is that
> > something you might be able to help me with?
> 
> Happy to give it a go, just let me know what you need

Thanks. A first step would probably be to enable debug output with -d and see 
what it reports in terms of the files being searched for.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-freescale] etnaviv image

2017-05-31 Thread Stephen Arnold 
Apparently my cma arg was dorking up the gpu initialization; if you get
this error in dmesg, then adjusting the cmdline memory args is probably a
good idea:

$ dmesg | grep etnaviv

command buffer outside valid memory window

I had default cma size in kernel config, different (larger) size on the
command line, so I replaced cma with gpumem.  Kernel seems to like it
better than cma=foo

Steve

On Wed, May 31, 2017 at 4:29 PM, Stephen Arnold 
wrote:

> Hmm, I built the same commits from your recipes, and I'm still getting the
> glx error in my logs :/
>
> Other than that, things seem to work okay...
>
> Steve
>
> On Sat, May 27, 2017 at 9:20 PM, Trevor Woerner 
> wrote:
>
>> Hey Stephen,
>>
>> On Fri, May 26, 2017 at 7:23 PM, Stephen Arnold
>>  wrote:
>> > @Trevor what's your config/setup?  Did you wind up using the
>> > "use-mainline-bsp" thing?
>>
>> Yes.
>>
>> As I mentioned, I was working with a wandboard, on master, therefore
>> my layers are:
>> - openembedded-core
>> - meta-freescale-3rdparty
>> - meta-freescale
>>
>> If I was working on some other board that didn't require
>> meta-freescale-3rdparty I wouldn't have needed that layer.
>> Additionally, I had started by using meta-etnaviv as well. That layer
>> hasn't seen any commits in roughly 10 months. Back then my guess is
>> that "upstream" didn't include very many of the bits required to get
>> this to work, therefore meta-etnaviv had to include recipes/bbappends
>> for mesa, libdrm, xorg-xserver, etc... in addition to the etnaviv drm
>> pieces themselves.
>>
>> I created my own clone of meta-etnaviv
>> [https://github.com/twoerner/meta-etnaviv] and pushed all my
>> commits/updates there with the intention of, eventually, sending a
>> pull request to its author. But by the time I was done removing all
>> the things that are no longer needed (i.e. all the bbappends, since
>> upstream mesa, libdrm, etc... all include the necessary bits) and
>> updating the remaining stuff, I was left with very little. So little,
>> in fact, that I decided to simply fold what was left back into
>> meta-freescale itself, conditional on the "use-mainline-bsp"
>> MACHINEOVERRIDES, and sent those patches to the meta-fsl mailing list.
>>
>> If the maintainers of meta-freescale accept the assumption that
>> use-mainline-bsp could be the flag that indicates interest between the
>> binary vivante drivers and etnaviv, then I hope they like the patches
>> and accept them into meta-freescale itself. Otherwise I could just
>> send that pull request to meta-etanviv's author (or re-work the
>> patches with whatever feedback I get). In any case, for wandboard
>> use-mainline-bsp is needed since the default kernel for wandboard is
>> linux-wandboard which is still stuck at 4.1.15 and is too old for this
>> etnaviv stuff. However using use-mainline-bsp with the wandboard is
>> broken, so I had to send some patches for that (u-boot and kernel) as
>> well (hopefully those patches are accepted as well).
>>
>> Due to the fact so much of etnaviv is already upstream, getting
>> etanviv working doesn't take very much. It just took me a while to
>> reach that point, however :-)
>>
>> > I pretty much had to hack up some of the meta-fsl/meta-boundary stuff
>> and
>> > put everything else in local.conf.  It would be a little easier/cleaner
>> if
>> > the former had some ?= in a few places...
>> >
>> > Anyway, I masked the browser stuff so I haven't tested that far yet,
>> but all
>> > you really need for 3D under X is new kernel/libdrm/mesa for ~110 fps
>> with
>> > glxgears.
>>
>> I like to use mesa-demos and (especially) glmark2 as my programs of
>> choice for testing GL stuff.
>>
>> > I added recipes for the x11-armada stuff, which seems to work for
>> > 2D but coughs an error in the xorg log.
>>
>> I'm curious to know which x11-armada stuff you're using. I couldn't
>> get the stuff that came with meta-etnaviv to compile so I looked
>> around and found Russell King's code which seemed more up-to-date, and
>> compiled. Plus my xorg log doesn't have any errors (see attachment).
>>
>> > I probably tested more with oe-core
>> > than poky but both should work.
>>
>> I just tend to stick with oe-core.
>>
>> I'm hoping to make a couple blog posts with my findings.
>>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-raspberrypi] linux-raspberrypi_dev: don't use AUTOREV

2017-05-31 Thread Paul Barker 
On Thu, Jun 1, 2017 at 1:17 AM, Khem Raj  wrote:
> On Wed, May 31, 2017 at 5:00 PM, Andrei Gherzan  wrote:
>>
>> On Tue, May 30, 2017 at 6:29 PM, Khem Raj  wrote:
>>>
>>> On Tue, May 30, 2017 at 10:25 AM, Andre McCurdy 
>>> wrote:
>>> > On Tue, May 30, 2017 at 10:15 AM, Paul Barker 
>>> > wrote:
>>> >> On 30 May 2017 5:08 p.m., "Khem Raj"  wrote:
>>> >>
>>> >> On Tue, May 30, 2017 at 12:57 AM, Martin Jansa 
>>> >> wrote:
>>> >>> * use latest revision in rpi-4.11.y branch
>>> >>> * using AUTOREV causes bitbake to run git ls-remote on the github.com
>>> >>> repository in order
>>> >>>   to convert AUTOREV to currently latest SRCREV even when you don't
>>> >>> use
>>> >>> linux-raspberrypi_dev
>>> >>>   at all, just happen to have meta-raspberrypi layer in your
>>> >>> bblayers.conf, that's bad for
>>> >>>   people who want to be able to build without network access
>>> >>> (completely
>>> >>> from premirror)
>>> >>>
>>> >>
>>> >> These branches get rebased often so locking SRCREV caused another
>>> >> kind of problem. what we can do is.
>>> >>
>>> >> 1. Let user like you override the SRCREC via a bbappend or conf file.
>>> >> so change the assignment to ?=
>>> >> 2. Delete the recipe completely. We lose some of upstream testing.
>>> >>
>>> >> We should be able to skip the recipe if it isn't selected as the
>>> >> preferred
>>> >> version and/or provider of "virtual/kernel". I'm out at the minute so
>>> >> can't
>>> >> look at it now but will try to take a look later this week.
>>> >
>>> > The linux-yocto-dev.bb recipe contains an example of doing that.
>>> >
>>>
>>> ah perfect. Thats what we need here
>>>
>>>
>>> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-kernel/linux/linux-yocto-dev.bb?h=master#n28
>>>
>>> please rename the recipe to be linux-raspberrypi-dev.bb and add the magic
>>> above and send a v2
>>>
>>
>> Using the magic above we still hardcode a revision there. So if a user wants
>> to compile the recipe without setting the preferred provider it will fail.
>
> what will be the usecase ? when you have a different kernel selected but
> woould like to compile yet another kernel
>
> that rev can be a well known rev like branchpoint. Moreover, I think
> if someone wants to use the dev recipe then its expected that they
> switch
> to using AUTOREV or some other local mechanism for pinning if needed.
>

I was thinking of a different approach entirerly. We can add the
following at the top of the recipe file:

python __anonymous() {
if "linux-raspberrypi-dev" not in
d.getVar("PREFERRED_PROVIDER_virtual/kernel"):
msg = "Skipping linux-raspberrypi-dev as it is not the preferred " + \
  "provider of virtual/kernel."
raise bb.parse.SkipRecipe(msg)
}

(Hopefully gmail won't mangle that too much)

I've just tested it and it works fine as long as it's before the use
of ${AUTOREV}. If there's no objections to this approach I'll submit a
patch.

Cheers,

-- 
Paul Barker
Co-Founder & Principal Engineer
Togán Labs Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto