Re: [yocto] Strange bitbake error
On 2017-01-25 07:50, Gary Thomas wrote:
For the last couple of days, I've been seeing my bitbake builds
just shutdown, without actually completing, like this:
Initialising tasks: 100%
|###| Time:
0:00:10
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
WARNING: /local/poky-cutting-edge/bitbake/lib/bb/runqueue.py:1159:
ResourceWarning: unclosed file <_io.BufferedWriter
name=31>
self.worker = {}
This happened after completing ~650 out of 5786 tasks.
If I rerun the build it will likely complete without any more errors.
Any clues what might be happening? Is there any information (logs, etc)
that might help me understand?
BTW I'm using the latest Poky (62d7d4130202d8ede16abf9e7d779361ca70847e)
updated just a few hours ago.
Sorry for the noise - it looks like my system was out of memory
and the bitbake processes were being killed by the kernel oom :-(
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Strange bitbake error
For the last couple of days, I've been seeing my bitbake builds
just shutdown, without actually completing, like this:
Initialising tasks: 100%
|###| Time:
0:00:10
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
ERROR: Worker process (22132) exited unexpectedly (-9), shutting down...
WARNING: /local/poky-cutting-edge/bitbake/lib/bb/runqueue.py:1159: ResourceWarning: unclosed file <_io.BufferedWriter
name=31>
self.worker = {}
This happened after completing ~650 out of 5786 tasks.
If I rerun the build it will likely complete without any more errors.
Any clues what might be happening? Is there any information (logs, etc)
that might help me understand?
BTW I'm using the latest Poky (62d7d4130202d8ede16abf9e7d779361ca70847e)
updated just a few hours ago.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] DISTRO_FEATURES vs IMAGE_FEATURES
Hello Yocto. Though it may feel to me matter of taste, is there suggestion on when which of these to use when you need to define your customized feature. DISTRO_FEATURES seems to be more relaxed, you can define things in your distro conf. IMAGE_FEATURE seems to be more strict, and you need to add your item also as one of the 'validitems', unless you use it through FEATURE_PACKAGES. (Or this is not needed when you use EXTRA_IMAGE_FEATURES?) These two just mean one if for DISTRO associated features and another for your image - it is all that? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] u-boot: drop backported patches
On Tue, 24 Jan 2017 19:32:04 +0100 Mirza Krak wrote: > From: Mirza Krak > > U-boot has been updated to 2017.01 in poky/oe-core which contains > these patches. > > Signed-off-by: Mirza Krak I've been working on the exact same patch here, just hadn't had chance to test it yet. Looks good to me. Acked-by: Paul Barker -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH] u-boot: drop backported patches
From: Mirza Krak
U-boot has been updated to 2017.01 in poky/oe-core which contains these
patches.
Signed-off-by: Mirza Krak
---
...0001-arm-add-save_boot_params-for-ARM1176.patch | 56
...through-of-the-firmware-provided-FDT-blob.patch | 156 -
recipes-bsp/u-boot/u-boot_%.bbappend | 5 -
3 files changed, 217 deletions(-)
delete mode 100644
recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
delete mode 100644
recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
diff --git
a/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
b/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
deleted file mode 100644
index a5ebff5..000
--- a/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 3e10fcde3f3c24a488866dd33fa3f5d46ff3d7a3 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?C=C3=A9dric=20Schieli?=
-Date: Fri, 11 Nov 2016 11:59:06 +0100
-Subject: [PATCH] arm: add save_boot_params for ARM1176
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Implement a hook to allow boards to save boot-time CPU state for later
-use. When U-Boot is chain-loaded by another bootloader, CPU registers may
-contain useful information such as system configuration information. This
-feature mirrors the equivalent ARMv7 feature.
-
-Signed-off-by: Cédric Schieli
-Acked-by: Stephen Warren
-Signed-off-by: Paul Barker
-Upstream-status: Backport
- arch/arm/cpu/arm1176/start.S | 10 ++
- 1 file changed, 10 insertions(+)
-
-diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S
-index a602d4e..7c00201 100644
a/arch/arm/cpu/arm1176/start.S
-+++ b/arch/arm/cpu/arm1176/start.S
-@@ -16,6 +16,7 @@
-
- #include
- #include
-+#include
-
- #ifndef CONFIG_SYS_PHY_UBOOT_BASE
- #define CONFIG_SYS_PHY_UBOOT_BASE CONFIG_SYS_UBOOT_BASE
-@@ -37,6 +38,11 @@
- .globl reset
-
- reset:
-+ /* Allow the board to save important registers */
-+ b save_boot_params
-+.globlsave_boot_params_ret
-+save_boot_params_ret:
-+
- /*
-* set the cpu to SVC32 mode
-*/
-@@ -110,3 +116,7 @@ mmu_disable_phys:
- c_runtime_cpu_setup:
-
- mov pc, lr
-+
-+WEAK(save_boot_params)
-+ b save_boot_params_ret/* back to my caller */
-+ENDPROC(save_boot_params)
---
-2.1.4
-
diff --git
a/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
b/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
deleted file mode 100644
index 323b7ab..000
---
a/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
+++ /dev/null
@@ -1,156 +0,0 @@
-From ade243a211d62327e9ebadce27bbbff7981e37f0 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?C=C3=A9dric=20Schieli?=
-Date: Fri, 11 Nov 2016 11:59:07 +0100
-Subject: [PATCH] rpi: passthrough of the firmware provided FDT blob
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
-but this is not true anymore. The address now depends on both the
-memory size and the blob size [1].
-
-If one wants to passthrough this FDT blob to the kernel, the most
-reliable way is to save its address from the r2/x0 register in the
-U-Boot entry point and expose it in a environment variable for
-further processing.
-
-This patch just does this:
-- save the provided address in the global variable fw_dtb_pointer
-- expose it in ${fdt_addr} if it points to a a valid FDT blob
-
-There are many different ways to use it. One can, for example, use
-the following script which will extract from the tree the command
-line built by the firmware, then hand over the blob to a previously
-loaded kernel:
-
-fdt addr ${fdt_addr}
-fdt get value bootargs /chosen bootargs
-bootz ${kernel_addr_r} - ${fdt_addr}
-
-Alternatively, users relying on sysboot/pxe can simply omit any FDT
-statement in their extlinux.conf file, U-Boot will automagically pick
-${fdt_addr} and pass it to the kernel.
-
-[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018
-
-Upstream-Status: Backport
-
-Signed-off-by: Cédric Schieli
-Acked-by: Stephen Warren
-Signed-off-by: Jonathan Liu
- board/raspberrypi/rpi/Makefile| 1 +
- board/raspberrypi/rpi/lowlevel_init.S | 36 +++
- board/raspberrypi/rpi/rpi.c | 29
- 3 files changed, 66 insertions(+)
- create mode 100644 board/raspberrypi/rpi/lowlevel_init.S
-
-diff --git a/board/raspberrypi/rpi/Makefile b/board/raspberrypi/rpi/Makefile
-index 4ce2c98..dcb25ac 100644
a/board/raspberrypi/rpi/Makefile
-+++ b/board/raspberrypi/rpi/Makefile
-@@ -5,3 +5,4 @@
- #
-
- obj-y := rpi.o
-+obj-y += lowlevel_init.o
-dif
Re: [yocto] Problems with building out-of-tree modules in morty
On 1/24/17 7:16 AM, Bogusz Brodziński wrote: > Hi, > > TL;DR after migrating from jethro to morty my out-of-tree modules do not > load. > > Long version: > Im developing uio driver for a custom FPGA. The base is xilinx zu15 > (note: as the explanation will go on I *think* it will be clear that > this is not related to meta-xilinx). > It's basically a debug interface that generates IRQ-like events on files > (poll) for newly developed/tested features. The initial structure was > poky jethro, meta-xilinx with linux-xlnx 4.4 for aarch64. The module is > basically uio driver, but creates individual uio for each signal. The > makefile is straight from > https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html and the > recipee inherits from module. > When using jethro the module got built out-of-tree with no problem and I > could load it. After migrating to morty (I also bumped meta-xilinx rev, > but I use the same kernel SRCREV and project layer) I still can build > the module, but when loading it I get: > > $ modprobe uio_pdrv_testirq > [ 79.059558] module uio_pdrv_testirq: unsupported RELA relocation: 275 > modprobe: can't load module uio_pdrv_testirq > (testirq/uio_pdrv_testirq.ko): invalid module format > > $ modinfo uio_pdrv_testirq > filename: testirq/uio_pdrv_testirq.ko > license:GPL v2 > author: BB > description:Userspace I/O test driver irq handler > depends: > vermagic: 4.4.0-xilinx SMP preempt mod_unload modversions aarch64 > > I looked for a solution and found this > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/375429.html > thread > I checked that I have all the ERRATUM enabled (with emphasys on > ARM64_ERRATUM_843419): > CONFIG_ARM64_ERRATUM_826319=y > CONFIG_ARM64_ERRATUM_827319=y > CONFIG_ARM64_ERRATUM_824069=y > CONFIG_ARM64_ERRATUM_819472=y > CONFIG_ARM64_ERRATUM_832075=y > CONFIG_ARM64_ERRATUM_845719=y > CONFIG_ARM64_ERRATUM_843419=y > > and I added > CFLAGS_MODULE += -mcmodel=large > > Result: no change; testirq still fails to load. > > I would be grateful for any suggestions where to look or what to do next. > Backport https://github.com/torvalds/linux/commit/df057cc7b4fa59e9b55f07ffdb6c62bf02e99a00 https://github.com/torvalds/linux/commit/67dfa1751ce71e629aad7c438e1678ad41054677 To your kernel. Additionally you also can have gcc fix https://github.com/kraj/gcc/commit/947be775c188312ff802d9f63dbdccd017cb4a29 hopefully these will help > Best regards, > Bogusz Brodzinski > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [layerindex-web] issue with webinterface
Right, we have not tested the layer index code with Django > 1.8.x, I would expect problems like this until we migrate (which probably won't be for a while I suspect). Cheers, Paul On Tuesday, 24 January 2017 2:57:46 PM NZDT Peter Tulpen wrote: > Hello Paul, > you are brilliant: > I had errors with django 1.10 and uncommented: > from django.conf.global_settings import TEMPLATE_CONTEXT_PROCESSORS as TCP > TEMPLATE_CONTEXT_PROCESSORS = TCP + ( > 'django.core.context_processors.request', > 'layerindex.context_processors.layerindex_context', > ) > > Since it was causing problems and was deprecated and not needed in 1.10 > (according to some websites) But since I cold not get it working with 1.10 > anyway, I downgraded to 1.8 again and forgot about this parts > > Thanks a lot > > > --- Ursprüngliche Nachricht --- > Von: Paul Eggleton > Datum: 22.01.2017 20:23:43 > An: Peter Tulpen > Betreff: Re: [yocto] [layerindex-web] issue with webinterface > > > Hi Peter, > > > > On Thu, 19 Jan 2017 18:05:12 Peter Tulpen wrote: > > > Hello, I installed the webinterface locally and configured it with > > > several > > > > > > branches But when I want to browse it, I can only choose master: > > > > > > https://postimg.org/image/dq1vj6v7h/ > > > > > > When I browse to http://MYSERVER/layerindex/branch/jethro/layers/, I > > > > see > > > > > that the branches are there My installation based on a git clone from > > > > the > > > > > master tree. > > > > > > Did I miss something or did I hit a bug? > > > > There's no filtering on the query used to get the list of branches to show > > > > other than the name is not "oe-classic". However, one way I can > > think of that > > that could be blank would be if the context processors used to inject the > > > > "all_branches" queryset results into the context for each page. > > You haven't > > modified settings.py such that > > layerindex.context_processors.layerindex_context has been removed from the > > > > TEMPLATE_CONTEXT_PROCESSORS value by any chance? > > > > Otherwise, what changes did you make to settings.py? Which Django version > > are > > you using? > > > > Cheers, > > Paul > > > > -- > > > > Paul Eggleton > > Intel Open Source Technology Centre -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][morty][PATCH V2] Revert "u-boot: drop patch to include lowlevel_init"
From: Mirza Krak
Not applicable on U-boot 2016.03 which is used in poky/morty and causes an build
error when KERNEL_IMAGETYPE = "uImage".
This reverts commit 031e26954b95d49a66ea4677b9e867d08441f450.
[Issue #43]
Signed-off-by: Mirza Krak
---
Changes in V2:
- Fixed spelling and improved commit message
.../0003-Include-lowlevel_init.o-for-rpi2.patch| 25 ++
recipes-bsp/u-boot/u-boot_%.bbappend | 1 +
2 files changed, 26 insertions(+)
create mode 100644
recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
diff --git
a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
new file mode 100644
index 000..ce0273f
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
@@ -0,0 +1,25 @@
+From 1eb01436bc57ad32519a4567a1c9ec82d52d60a1 Mon Sep 17 00:00:00 2001
+From: Paul Barker
+Date: Tue, 29 Nov 2016 19:47:49 +
+Subject: [PATCH] Include lowlevel_init.o for rpi2
+
+Signed-off-by: Paul Barker
+Upstream-status: Inappropriate
+(not needed upstream as rpi_2 board directory is removed in latest
+version)
+---
+ board/raspberrypi/rpi_2/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/board/raspberrypi/rpi_2/Makefile
b/board/raspberrypi/rpi_2/Makefile
+index d82cd21..9f865c5 100644
+--- a/board/raspberrypi/rpi_2/Makefile
b/board/raspberrypi/rpi_2/Makefile
+@@ -5,3 +5,4 @@
+ #
+
+ obj-y := ../rpi/rpi.o
++obj-y += ../rpi/lowlevel_init.o
+--
+2.1.4
+
diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend
b/recipes-bsp/u-boot/u-boot_%.bbappend
index 0edc8dc..a4545f0 100644
--- a/recipes-bsp/u-boot/u-boot_%.bbappend
+++ b/recipes-bsp/u-boot/u-boot_%.bbappend
@@ -3,4 +3,5 @@ RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
SRC_URI_append_rpi = " \
file://0001-arm-add-save_boot_params-for-ARM1176.patch \
file://0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch \
+file://0003-Include-lowlevel_init.o-for-rpi2.patch \
"
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][morty][PATCH] Revert "u-boot: drop patch to include lowlevel_init"
From: Mirza Krak
Not applicaple on U-boot 2016.03 which is used in poky/morty.
This reverts commit 031e26954b95d49a66ea4677b9e867d08441f450.
[Issue #43]
Signed-off-by: Mirza Krak
---
.../0003-Include-lowlevel_init.o-for-rpi2.patch| 25 ++
recipes-bsp/u-boot/u-boot_%.bbappend | 1 +
2 files changed, 26 insertions(+)
create mode 100644
recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
diff --git
a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
new file mode 100644
index 000..ce0273f
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
@@ -0,0 +1,25 @@
+From 1eb01436bc57ad32519a4567a1c9ec82d52d60a1 Mon Sep 17 00:00:00 2001
+From: Paul Barker
+Date: Tue, 29 Nov 2016 19:47:49 +
+Subject: [PATCH] Include lowlevel_init.o for rpi2
+
+Signed-off-by: Paul Barker
+Upstream-status: Inappropriate
+(not needed upstream as rpi_2 board directory is removed in latest
+version)
+---
+ board/raspberrypi/rpi_2/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/board/raspberrypi/rpi_2/Makefile
b/board/raspberrypi/rpi_2/Makefile
+index d82cd21..9f865c5 100644
+--- a/board/raspberrypi/rpi_2/Makefile
b/board/raspberrypi/rpi_2/Makefile
+@@ -5,3 +5,4 @@
+ #
+
+ obj-y := ../rpi/rpi.o
++obj-y += ../rpi/lowlevel_init.o
+--
+2.1.4
+
diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend
b/recipes-bsp/u-boot/u-boot_%.bbappend
index 0edc8dc..a4545f0 100644
--- a/recipes-bsp/u-boot/u-boot_%.bbappend
+++ b/recipes-bsp/u-boot/u-boot_%.bbappend
@@ -3,4 +3,5 @@ RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
SRC_URI_append_rpi = " \
file://0001-arm-add-save_boot_params-for-ARM1176.patch \
file://0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch \
+file://0003-Include-lowlevel_init.o-for-rpi2.patch \
"
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [layerindex-web][PATCH 2/2] views.py: Consider layer name in recipe search
ping On 01/18/2017 04:31 PM, Jose Lamego wrote: > From: Alex Franco > > Recipe search cannot be narrowed to a specific layer, producing > unnecessary results. > > This change allows including a layers name when searching for recipes to > narrow the yielded results by adding a layer name to the simplesearch.getquery > call in the recipe search view. > > [YOCTO #6618] > > Signed-off-by: Jose Lamego > --- > layerindex/views.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/layerindex/views.py b/layerindex/views.py > index 03fadbb..5db6fbc 100644 > --- a/layerindex/views.py > +++ b/layerindex/views.py > @@ -406,7 +406,8 @@ class RecipeSearchView(ListView): > qs0 = init_qs.filter(pn=query_string).order_by(*order_by) > qs0 = recipes_preferred_count(qs0) > > -entry_query = simplesearch.get_query(query_string, ['pn']) > +entry_query = simplesearch.get_query( > +query_string, ['pn', 'layerbranch__layer__name']) > qs1 = init_qs.filter(entry_query).order_by(*order_by) > qs1 = recipes_preferred_count(qs1) > > -- Jose Lamego | OTC Embedded Platforms & Tools | GDC -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [layerindex-web][PATCH 1/2] views.py: Redirect to recipe details for single results
ping
On 01/18/2017 04:31 PM, Jose Lamego wrote:
> From: Alex Franco
>
> When a recipe search returns only one result, clicking the single
> result at the results view is still required to view further
> recipe detail.
>
> This change automatically redirects to the recipe details view
> when the recipe search returns a single result.
>
> [YOCTO #6618]
>
> Signed-off-by: Jose Lamego
> ---
> layerindex/views.py | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/layerindex/views.py b/layerindex/views.py
> index 0f73e93..03fadbb 100644
> --- a/layerindex/views.py
> +++ b/layerindex/views.py
> @@ -372,6 +372,14 @@ class RecipeSearchView(ListView):
> context_object_name = 'recipe_list'
> paginate_by = 50
>
> +def render_to_response(self, context, **kwargs):
> +if len(self.object_list) == 1:
> +return HttpResponseRedirect("/layerindex/recipe/%s/"
> +% self.object_list[0].id)
> +else:
> +return super(ListView, self).render_to_response(context,
> +**kwargs)
> +
> def get_queryset(self):
> _check_url_branch(self.kwargs)
> query_string = self.request.GET.get('q', '')
>
--
Jose Lamego | OTC Embedded Platforms & Tools | GDC
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/7] introduce rockchip offical linux support to meta-rockchip
Hi Jacob, Sorry for the delay, I hadn't noticed the patches initially because the tag was missing, then I was busy with other things. I'm taking a look at them now. On Thu, Jan 19, 2017 at 10:17 AM, Leon Woestenberg wrote: > Hi Jacob, > > On Thu, Jan 19, 2017 at 11:09 AM, Jacob Chen wrote: >> >> This series of patches add below features, will add more supports in the >> future(medias, more chips). >> 1 >> Rockchip 4.4 kernel is currently the latest version of the rockchip >> offical kernel, will be an upstream tracking branch. >> We regularly release the kernel through github. It support all rockchip >> 64-bit chips and a few 32-bit chips. >> > The topic mentions "official kernel" and you mention "we". > > Does this mean this is a rock-chips driven effort? > > Good to see such (vendor) support, welcome aboard, but please understand the > "layers" system of Yocto, like the others already pointed out in this email > thread. > > - Basically you create a (BSP) layer, that sits on top of Yocto / > OpenEmbedded core. > - Also, it is good practice to also support the same GIT branch names for > the different Yocto releases (such as krogoth, morty) such that users can > easily match the correct branches so that everything just builds correctly. > > Regards, > > Leon. > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [patchwork][PATCH] parsemail: Set patch state from email metadata
Patch state can only be set/changed at patchwork web interface,
resulting in a poor user experience for project maintainers.
This change allows project maintainers to change a patch status
directly from an email message sent as a reply to the related mailing list
thread by including a the string "[Patchwork-Status: ]"
[YOCTO #10624]
Signed-off-by: Jose Lamego
---
patchwork/bin/parsemail.py | 31 +++
1 file changed, 31 insertions(+)
diff --git a/patchwork/bin/parsemail.py b/patchwork/bin/parsemail.py
index 1ce0cdf..eb92243 100755
--- a/patchwork/bin/parsemail.py
+++ b/patchwork/bin/parsemail.py
@@ -820,6 +820,37 @@ def parse_mail(mail):
comment.save()
LOGGER.debug('Comment saved')
+# if comment's author has project-maintainer permissions,
+# parse comment content and process the status-change command
+# if it is found
+if project in (author.user).profile.maintainer_projects.all():
+cmd = None
+comment_re = re.compile('^\[Patchwork-Status:\s*(Under Review|\
+Rejected|RFC|Not Applicable|Changes Requested|Awaiting Upstream|Superseded|\
+Deferred)\]$', re.M | re.I)
+# if multiple valid status-change commands are found, use last one
+for match in comment_re.finditer(comment.content):
+cmd = re.sub(r'(\[Patchwork-Status:\s*)(.*)(\])', r'\2',
+ "{}".format(match.group(0)))
+if cmd is not None:
+new_state = State.objects.get(name=cmd.title())
+mod_patch = Patch.objects.get(pk=comment.patch.pk)
+if new_state and mod_patch.state != new_state:
+mod_patch.state = new_state
+mod_patch.save()
+cmd_message = 'This is a system generated Comment: Patch \
+%s status was updated to "%s" due to request in comment.' % (
+ comment.patch.pk, cmd)
+cmd_msgid = "%s: System generated by comment %s" % (
+datetime.datetime.now().strftime("\
+%d%b%Y.%H:%M:%S.%f"), comment.pk)
+new_comment = Comment(pk=None, patch=comment.patch,
+ content=cmd_message,
+ date=datetime.datetime.now(),
+ submitter=comment.submitter,
+ msgid=cmd_msgid)
+new_comment.save()
+
series_revision_complete.disconnect(on_revision_complete)
return 0
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Ordering of anonymous Python functions and task signature calculations
On Tue, Jan 24, 2017 at 9:55 AM, Matt Hoosier wrote:
> In order to support a use-case that embeds information about the Git
> revision of Yocto itself that was used to make a build, I would like to run
> some arbitrary Python code and dump the results (Git SHA1's, tag names, etc)
> into a Bitbake variable.
>
> The idea is that the variable would get consumed in a do_install() task to
> populate some cookie-crumb file in the package payload.
>
> Something like:
>
> DEPENDS = "git-native"
>
> python () {
> # This pseudocode isn't strictly functional for invoking Git, but you
> get the idea
> d.setVar('GIT_INFO', subprocess.Popen(['git', 'rev-list',
> ...]).communicate().stdout)
> }
>
> do_install () {
> install -d ${D}/etc
> echo "${GIT_INFO}" > ${D}/etc/git-info.txt
> }
>
> This all works on a fresh run, but Bitbake appears not to be evaluating the
> anonymous Python function on each execution. This leads it to have
> out-of-date information about the Git working copy when global state changes
> but happens not to impact the particular recipe holding this logic.
>
> Is there any trick available to cause the Python function to execute (and
> hence update the value of ${GIT_INFO} each Bitbake execution so that the
> up-to-the-moment contents of it filter into the calculation of the signature
> for do_install()? Or am I just trying a wrong-headed approach and doing
> something illegitimate?
>
May be you can do it as a post processing step at image build time.
> -Matt
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Ordering of anonymous Python functions and task signature calculations
In order to support a use-case that embeds information about the Git
revision of Yocto itself that was used to make a build, I would like to run
some arbitrary Python code and dump the results (Git SHA1's, tag names,
etc) into a Bitbake variable.
The idea is that the variable would get consumed in a do_install() task to
populate some cookie-crumb file in the package payload.
Something like:
DEPENDS = "git-native"
python () {
# This pseudocode isn't strictly functional for invoking Git, but you
get the idea
d.setVar('GIT_INFO', subprocess.Popen(['git', 'rev-list',
...]).communicate().stdout)
}
do_install () {
install -d ${D}/etc
echo "${GIT_INFO}" > ${D}/etc/git-info.txt
}
This all works on a fresh run, but Bitbake appears not to be evaluating the
anonymous Python function on each execution. This leads it to have
out-of-date information about the Git working copy when global state
changes but happens not to impact the particular recipe holding this logic.
Is there any trick available to cause the Python function to execute (and
hence update the value of ${GIT_INFO} each Bitbake execution so that the
up-to-the-moment contents of it filter into the calculation of the
signature for do_install()? Or am I just trying a wrong-headed approach and
doing something illegitimate?
-Matt
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-2.3_M2.rc1 now available.
A release candidate build for yocto-2.3_M2.rc1 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M2.rc1 Please begin QA on this build as soon as possible. Build hash information: meta-qt4 : 2c7f8df9039be498f8a2232d1428adb7f4e5e800 meta-intel : 1d36b0c379d3e08507d07ada1ad277e0c99fb80d meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f poky : 62d7d4130202d8ede16abf9e7d779361ca70847e \nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: git://git.yoctoproject.org/yocto-autobuilder\nEmail: joshua.g.l...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problems with building out-of-tree modules in morty
Hi, TL;DR after migrating from jethro to morty my out-of-tree modules do not load. Long version: Im developing uio driver for a custom FPGA. The base is xilinx zu15 (note: as the explanation will go on I *think* it will be clear that this is not related to meta-xilinx). It's basically a debug interface that generates IRQ-like events on files (poll) for newly developed/tested features. The initial structure was poky jethro, meta-xilinx with linux-xlnx 4.4 for aarch64. The module is basically uio driver, but creates individual uio for each signal. The makefile is straight from https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html and the recipee inherits from module. When using jethro the module got built out-of-tree with no problem and I could load it. After migrating to morty (I also bumped meta-xilinx rev, but I use the same kernel SRCREV and project layer) I still can build the module, but when loading it I get: $ modprobe uio_pdrv_testirq [ 79.059558] module uio_pdrv_testirq: unsupported RELA relocation: 275 modprobe: can't load module uio_pdrv_testirq (testirq/uio_pdrv_testirq.ko): invalid module format $ modinfo uio_pdrv_testirq filename: testirq/uio_pdrv_testirq.ko license:GPL v2 author: BB description:Userspace I/O test driver irq handler depends: vermagic: 4.4.0-xilinx SMP preempt mod_unload modversions aarch64 I looked for a solution and found this http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/375429.html thread I checked that I have all the ERRATUM enabled (with emphasys on ARM64_ERRATUM_843419): CONFIG_ARM64_ERRATUM_826319=y CONFIG_ARM64_ERRATUM_827319=y CONFIG_ARM64_ERRATUM_824069=y CONFIG_ARM64_ERRATUM_819472=y CONFIG_ARM64_ERRATUM_832075=y CONFIG_ARM64_ERRATUM_845719=y CONFIG_ARM64_ERRATUM_843419=y and I added CFLAGS_MODULE += -mcmodel=large Result: no change; testirq still fails to load. I would be grateful for any suggestions where to look or what to do next. Best regards, Bogusz Brodzinski -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] ref-manual: New SSHD_CONFIG variable description
Add description for the SSHD_CONFIG variable which is used to select the
package to use as provider for sshd-config.
Signed-off-by: David Vincent
---
documentation/ref-manual/ref-variables.xml | 21 +
1 file changed, 21 insertions(+)
diff --git a/documentation/ref-manual/ref-variables.xml
b/documentation/ref-manual/ref-variables.xml
index 6e15e65f54..803f0da980 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -12511,6 +12511,27 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
+SSHD_CONFIG
+
+SSHD_CONFIG[doc] = "The package used to provide OpenSSH sshd
configuration.
+
+
+
+When selecting "ssh-server-openssh" in
+IMAGE_FEATURES,
+specifies which package should be used as provider for
+sshd-config.
+
+
+
+This defaults to openssh-sshd-config.
+If "read-only-rootfs" is also specified in
+IMAGE_FEATURES,
+it defaults to
openssh-sshd-config-readonly
+
+
+
+
SSTATE_DIR
SSTATE_DIR[doc] = "The directory for the shared state cache."
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] Add SSHD_CONFIG variable description
Add the SSHD_CONFIG variable description to the glossary. This variable is introduced by the following patch series on OE-Core: https://patchwork.openembedded.org/series/4904 David Vincent (1): ref-manual: New SSHD_CONFIG variable description documentation/ref-manual/ref-variables.xml | 21 + 1 file changed, 21 insertions(+) -- 2.11.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [layerindex-web] issue with webinterface
Hello Paul, you are brilliant: I had errors with django 1.10 and uncommented: from django.conf.global_settings import TEMPLATE_CONTEXT_PROCESSORS as TCP TEMPLATE_CONTEXT_PROCESSORS = TCP + ( 'django.core.context_processors.request', 'layerindex.context_processors.layerindex_context', ) Since it was causing problems and was deprecated and not needed in 1.10 (according to some websites) But since I cold not get it working with 1.10 anyway, I downgraded to 1.8 again and forgot about this parts Thanks a lot --- Ursprüngliche Nachricht --- Von: Paul Eggleton Datum: 22.01.2017 20:23:43 An: Peter Tulpen Betreff: Re: [yocto] [layerindex-web] issue with webinterface > Hi Peter, > > On Thu, 19 Jan 2017 18:05:12 Peter Tulpen wrote: > > Hello, I installed the webinterface locally and configured it with several > > > branches But when I want to browse it, I can only choose master: > > > > https://postimg.org/image/dq1vj6v7h/ > > > > When I browse to http://MYSERVER/layerindex/branch/jethro/layers/, I > see > > that the branches are there My installation based on a git clone from > the > > master tree. > > > > Did I miss something or did I hit a bug? > > There's no filtering on the query used to get the list of branches to show > > other than the name is not "oe-classic". However, one way I can > think of that > that could be blank would be if the context processors used to inject the > > "all_branches" queryset results into the context for each page. > You haven't > modified settings.py such that > layerindex.context_processors.layerindex_context has been removed from the > > TEMPLATE_CONTEXT_PROCESSORS value by any chance? > > Otherwise, what changes did you make to settings.py? Which Django version > are > you using? > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SRC_URI patch slection
On 01/24/2017 06:37 AM, Takashi Matsuzawa wrote: In other words, in my iii) recipe I could say SRC_URI_remove = "file://.patch", but I want to make it only for specific SRCREV revisions. Or any other way of writing my iii) recipe for this? I would remove ii) altogether in the local layer tree, and copy-paste necessary bits and pieces from it into iii). Alternatively, remove iii) and make necessary changes to ii). Either way, you'll have to maintain a local fork of files maintained by other people, at least until maintainer of i) updates SRCREV to something that suits everybody. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] SRC_URI patch slection
Hello. I have following recipe files and want to remove .patch added to SRC_URI at ii). i) _git.bb - specifies RC_URI revision by SRCREV parameter ii) _%.bbappend - adds several .patch to SRC_URI iii) _%.bbappend - my recipe I want to make it (removal) conditional to SRCREV value. i), ii) and iii) are maintained by 3 different people, and .patch is needed or not needed according to the source revision. In other words, in my iii) recipe I could say SRC_URI_remove = "file://.patch", but I want to make it only for specific SRCREV revisions. Or any other way of writing my iii) recipe for this? Thank you very much for your advice. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
