Re: [yocto] [patchwork][PATCH v4] patchwork.models: Include first patch's name in series name
On Fri, 2016-12-02 at 14:29 -0600, Jose Lamego wrote:
> Patch Series created without a cover letter are named using a
> non-descriptive generic string.
>
> This change names the series using either the first 30 characters in
> patch #1 plus the remaining patches number, or the patch name for
> one-patch (1/1) series.
>
> [YOCTO #10625]
>
> Signed-off-by: Jose Lamego
> ---
> patchwork/models.py | 13 +
> 1 file changed, 13 insertions(+)
When you send different versions of your patches, can you include a
revision history? Otherwise, it's hard to see what changes between the
different iterations.
git notes can be used for that for single-commit changes. See "git
format-patch --notes" and "git notes".
> diff --git a/patchwork/models.py b/patchwork/models.py
> index 3f531e6..1521641 100644
> --- a/patchwork/models.py
> +++ b/patchwork/models.py
> @@ -1042,6 +1042,19 @@ def _series_supersede_previous_patches(series):
> def _on_revision_complete(sender, revision, **kwargs):
> series = revision.series
>
> +# Now we know how many patches are in the revision,
> +# so we can update the name for series without a cover letter
> +if series.name == SERIES_DEFAULT_NAME:
> +name = series.latest_revision().ordered_patches()[0].name
> +n = re.compile(r'(\[\d+\/\d+\]\s?)')
> +name = n.sub('', name)
> +c = len(series.latest_revision().ordered_patches())
> +# For one-patch series (1/1) without cover letter
> +if c == 1:
> +series.name = name
> +elif c > 1:
> +series.name = "\"%s...\" and %s more" % (name[:30], c-1)
> +
> # update series.last_revision
> series.last_revision = series.latest_revision()
> series.save()
Looks reasonable to me, but I don't really know the code. Were you
testing this and noticed cases with c == 0, i.e. cases where the last
series,name change didn't make sense?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using files from package dependencies
On Mon, Dec 5, 2016 at 7:59 AM, Paulo Neves wrote: > I have a recipe which depends on another package's file to do it's > job. How can I arbitrarily access a file from another package which my > recipe depends on? > > I searched for this kind of problem but did not find it you can't access (reliably) temporary files from another package. Each package is built independently in their own 'sandbox'. If files from one package are needed for other packages they need to be exported in the sysroot (through the -dev package typically). you don't say much about what 'files' you need, but if you need source code to recompile them into another package, you might need to fetch the source code directly. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using files from package dependencies
Hi Nicolas, The files form this other package are mostly binaries in a directory structure. I have to create an additional package which works with the other package's(the dependency) installed directory structure. Also you hinted at something I didn't know before, which was that packages need to be additionally exported to the sysroot and this was typically done through the -dev package. Can you point me at where this is documented? I am having a huge difficulty trying to find these conventions in the manual or by googling. Thanks Paulo Neves On Mon, Dec 5, 2016 at 8:42 AM, Nicolas Dechesne wrote: > On Mon, Dec 5, 2016 at 7:59 AM, Paulo Neves wrote: >> I have a recipe which depends on another package's file to do it's >> job. How can I arbitrarily access a file from another package which my >> recipe depends on? >> >> I searched for this kind of problem but did not find it > > you can't access (reliably) temporary files from another package. Each > package is built independently in their own 'sandbox'. If files from > one package are needed for other packages they need to be exported in > the sysroot (through the -dev package typically). > > you don't say much about what 'files' you need, but if you need source > code to recompile them into another package, you might need to fetch > the source code directly. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using files from package dependencies
On Mon, Dec 5, 2016 at 9:54 AM, Paulo Neves wrote: > The files form this other package are mostly binaries in a directory > structure. I have to create an additional package which works with the > other package's(the dependency) installed directory structure. > Also you hinted at something I didn't know before, which was that > packages need to be additionally exported to the sysroot and this was > typically done through the -dev package. Can you point me at where > this is documented? I am having a huge difficulty trying to find these > conventions in the manual or by googling. are the binaries "native" binaries (eg. that are intended to run on the host PC) or target binaries (libraries) that would want to link against to build your new package? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using files from package dependencies
Sorry for my ambiguity. When I mentioned binaries I meant general binary data, not necessarily executable. Their only need is that the new recipe needs to be fed these data from the other package so it can produce it's own output. This binary data only needs to be available in the host pc, in the recipe bake. Thanks Paulo Neves On Mon, Dec 5, 2016 at 8:58 AM, Nicolas Dechesne wrote: > On Mon, Dec 5, 2016 at 9:54 AM, Paulo Neves wrote: >> The files form this other package are mostly binaries in a directory >> structure. I have to create an additional package which works with the >> other package's(the dependency) installed directory structure. >> Also you hinted at something I didn't know before, which was that >> packages need to be additionally exported to the sysroot and this was >> typically done through the -dev package. Can you point me at where >> this is documented? I am having a huge difficulty trying to find these >> conventions in the manual or by googling. > > > are the binaries "native" binaries (eg. that are intended to run on > the host PC) or target binaries (libraries) that would want to link > against to build your new package? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using files from package dependencies
On Mon, Dec 5, 2016 at 10:10 AM, Paulo Neves wrote:
> Sorry for my ambiguity. When I mentioned binaries I meant general
> binary data, not necessarily executable. Their only need is that the
> new recipe needs to be fed these data from the other package so it can
> produce it's own output. This binary data only needs to be available
> in the host pc, in the recipe bake.
in that case, i suppose you can consider these 'binary files' as
development files like other .h or libs, and package them in the -dev
package of the dependency. You can control which files get into the
-dev package using FILES_${PN}-dev in your recipe.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH] firmware: Update to 20161125
Signed-off-by: Jonathan Liu
---
recipes-bsp/common/firmware.inc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
index 8862f58..1961b48 100644
--- a/recipes-bsp/common/firmware.inc
+++ b/recipes-bsp/common/firmware.inc
@@ -1,10 +1,10 @@
-RPIFW_DATE ?= "20161020"
+RPIFW_DATE ?= "20161125"
RPIFW_SRC_URI ?=
"https://github.com/raspberrypi/firmware/archive/1.${RPIFW_DATE}.tar.gz";
RPIFW_S ?= "${WORKDIR}/firmware-1.${RPIFW_DATE}"
SRC_URI = "${RPIFW_SRC_URI}"
-SRC_URI[md5sum] = "d3c388c114af4c672dd3ee0ed8e984d3"
-SRC_URI[sha256sum] =
"1c7c49d58800aab2dd1b5ff59a1e297934f9ea6f47ebdf0a3f90632561dc690b"
+SRC_URI[md5sum] = "a9281d2869e2d7673a83d41bacfa66c2"
+SRC_URI[sha256sum] =
"744e050630621c70991c91e0ee8663dc2f579e743583ca762b13b00bc75859bc"
PV = "${RPIFW_DATE}"
--
2.10.2
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] X11 failure
With the latest Poky+RaspberryPi master branches, I get no X11 meta = "fix-kern-tools-native:9e63f81c78e284c9b325fe04a1b59e61c7ad8a1a" meta-raspberrypi = "master:44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9" When I boot (or restart X), I get this: Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory Indeed, the screen is only black (the mouse pointer is there and moves, but there are no windows) I looked around and there is no libGL.so.1, just v2: root@raspberrypi3:~# ls -l /usr/lib/libGL* lrwxrwxrwx1 root root14 Dec 2 05:17 /usr/lib/libGLESv2.so -> libGLESv2.so.2 lrwxrwxrwx1 root root18 Dec 2 05:17 /usr/lib/libGLESv2.so.2 -> libGLESv2.so.2.0.0 -rwxr-xr-x1 root root 80048 Dec 2 05:17 /usr/lib/libGLESv2.so.2.0.0 What do I need to do to get libGL v1 so X11 will work again? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] X11 failure
On 5 December 2016 at 11:12, Gary Thomas wrote: > What do I need to do to get libGL v1 so X11 will work again? > That would be part of mesa-gl, but I'm surprised RPi X needs OpenGL (as that is pure software, not accelerated). Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [patchwork][PATCH v4] patchwork.models: Include first patch's name in series name
On 12/05/2016 02:30 AM, Patrick Ohly wrote:
> On Fri, 2016-12-02 at 14:29 -0600, Jose Lamego wrote:
>> Patch Series created without a cover letter are named using a
>> non-descriptive generic string.
>>
>> This change names the series using either the first 30 characters in
>> patch #1 plus the remaining patches number, or the patch name for
>> one-patch (1/1) series.
>>
>> [YOCTO #10625]
>>
>> Signed-off-by: Jose Lamego
>> ---
>> patchwork/models.py | 13 +
>> 1 file changed, 13 insertions(+)
>
> When you send different versions of your patches, can you include a
> revision history? Otherwise, it's hard to see what changes between the
> different iterations.
>
> git notes can be used for that for single-commit changes. See "git
> format-patch --notes" and "git notes".
Got it, thanks for the tip.
>
>> diff --git a/patchwork/models.py b/patchwork/models.py
>> index 3f531e6..1521641 100644
>> --- a/patchwork/models.py
>> +++ b/patchwork/models.py
>> @@ -1042,6 +1042,19 @@ def _series_supersede_previous_patches(series):
>> def _on_revision_complete(sender, revision, **kwargs):
>> series = revision.series
>>
>> +# Now we know how many patches are in the revision,
>> +# so we can update the name for series without a cover letter
>> +if series.name == SERIES_DEFAULT_NAME:
>> +name = series.latest_revision().ordered_patches()[0].name
>> +n = re.compile(r'(\[\d+\/\d+\]\s?)')
>> +name = n.sub('', name)
>> +c = len(series.latest_revision().ordered_patches())
>> +# For one-patch series (1/1) without cover letter
>> +if c == 1:
>> +series.name = name
>> +elif c > 1:
>> +series.name = "\"%s...\" and %s more" % (name[:30], c-1)
>> +
>> # update series.last_revision
>> series.last_revision = series.latest_revision()
>> series.save()
>
> Looks reasonable to me, but I don't really know the code. Were you
> testing this and noticed cases with c == 0, i.e. cases where the last
> series,name change didn't make sense?
>
Correct. There are cases where only a cover letter is sent (for example,
consolidated pull requests) so the patches number is 0.
--
Jose Lamego | OTC Embedded Platforms & Tools | GDC
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto doesn't recognize cross-compiled binaries inside SDK
On 12/02/2016 08:36 PM, Kun Yi wrote: Thanks for the explanation Alex! Will give the alternative you suggested a try. As I understand I will need to instruct Yocto to fetch necessary "native" toolchains and libs to compile the native variant recipe. Doesn't that make my recipe non-portable to other host architectures? The recipe remains portable, because you don't need to specify any particular native architecure. Simply add BBCLASSEXTEND = "native" to the recipe, and that will enable the native variant without any additional fuss (*): $ bitbake myrecipe-native (*) Depending on your chain of dependencies, you may need to enable native variants for them in a similar fashion. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using files from package dependencies
Hello Nicolas, thank you for your advice and hints but I "need" to
corrupt a bit the conventions of yocto and use specific package names
(due to compatibility with other older build systems)
The magic behind the fact that my special package sysroot directories
were not being moved to the yocto sysroot was due to the fact that
do_populate_sysroot does not match all the toplevel directories in
${D}. For additional directories sysroot_stage_all needs to be
appended with the desired directories. I am perfectly ok with that but
why not make a notification that there were directories that were
packaged but will not be expanded in the sysroots? The lack of
notification is extremely confusing, as files just do not appear where
they should.
A similar question to mine can be found here:
http://stackoverflow.com/questions/35354802/how-to-create-do-populate-sysroot-append-task-in-yocto/40976056#40976056
Best regards
Paulo Neves
On Mon, Dec 5, 2016 at 10:08 AM, Nicolas Dechesne
wrote:
> On Mon, Dec 5, 2016 at 10:10 AM, Paulo Neves wrote:
>> Sorry for my ambiguity. When I mentioned binaries I meant general
>> binary data, not necessarily executable. Their only need is that the
>> new recipe needs to be fed these data from the other package so it can
>> produce it's own output. This binary data only needs to be available
>> in the host pc, in the recipe bake.
>
> in that case, i suppose you can consider these 'binary files' as
> development files like other .h or libs, and package them in the -dev
> package of the dependency. You can control which files get into the
> -dev package using FILES_${PN}-dev in your recipe.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] morty release ?
Hi. I have some questions and remarks and hopefully someone here can answer them. The meta-raspberrpi layer is missing a morty release? Any time frame of when this will be added? There is currently a issue when using U-boot due to some updates in RPi boot firmware. See [1] and [2]. Which should be noted/resolved before a morty release? To provide some more information about above mentioned problem. If you use the current firmware files (20161030 in meta-raspberrypi) together with U-boot (2016.03) you lose the console on U-boot and on Linux kernel. This is due to the fact that "newer" firmware sets a default uart clock to 48 MHz, but U-boot has a hard-coded value of 3 MHz, and since we yet do not support to "forward" the patched DTB provided by the firmware from U-boot to Linux we also break console on Linux. The "default" values has been updated in Linux, see [2]. But if you use that updated Linux kernel there is a mismatch between u-boot and Linux. Should be noted that U-boot 2016.11 does not have this problem since it does not try to initialize the UART port at all and only relies on firmware to set it up correctly (see [3]). Hope I made sense here :). [1]. https://github.com/agherzan/meta-raspberrypi/issues/36 [2]. https://github.com/raspberrypi/linux/issues/1732#issuecomment-264810083 [3]. http://git.denx.de/?p=u-boot.git;a=commit;h=cd0fa5bff8052b19bde6967c2734f323c9848568 Best Regards Mirza -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW50
Current Dev Position: YP 2.3 M1 Next Deadline: YP 2.3 M1 by Dec. 12, 2016 SWAT team rotation: Anibal -> Tracy https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: *We're now coming to the end of the M1 development period with it closing next Monday. *The recipe specific sysroot patchset has been updated with a number of the key issues being addressed. *Patches are being merged but we're continue to struggle to track down which patches in testing are causing which failures which does slow down the overall merge progress. The work Ross has been doing here is much appreciated. We have seen many recipe upgrades being merged. *Performance of bitbake on systems with large numbers of cores appears to have bottlenecks in bitbake-worker. One patch has already merged for this and there are some further patches pending. Python3 appears to have made this issue worse. *The monthly tech meeting is tomorrow at 8am PST. US Phone: 8007302996/9139049836, Bridge: 2705751 Proposed upcoming dot releases: YP 2.0.3 Release by Dec. 9, 2016 YP 2.2.1 Release by Jan. 20, 2017 YP 2.1.3 Release by May. 19, 2017 Key YP 2.3 Dates: YP 2.3 M1 Cutoff is Dec. 12, 2016 YP 2.3 M1 Release is Dec. 23, 2016 YP 2.3 M2 Cutoff is Jan. 23, 2017 YP 2.3 M2 Release is Feb. 3, 2017 YP 2.3 M3 Cutoff is Feb 27, 2017 YP 2.3 M3 Release is Mar. 10, 2017 YP 2.3 M4 Cutoff is April 3, 2017 YP 2.3 M4 Release is April 28, 2017 Tracking Metrics: WDD 2507 (last week 2552) (https://wiki.yoctoproject.org/charts/combo.html) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features [If anyone has suggestions for other information you'd like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone:(503) 712-0534 *Cell: (208) 244-4460 * Email:stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Current master broken
On Sun, Dec 4, 2016 at 10:03 PM, Gary Thomas wrote: > On 2016-12-05 01:54, Andrei Gherzan wrote: >> >> Hi Gary, >> >> >> On Sat, Dec 3, 2016 at 2:16 PM, Paul Barker wrote: >>> >>> On Sat, 3 Dec 2016 08:33:40 +0100 >>> Gary Thomas wrote: >>> I'm currently unable to build for the RaspberryPi-3 using the master branch: Build Configuration: BB_VERSION= "1.32.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS= "arm-amltd-linux-gnueabi" MACHINE = "raspberrypi3" DISTRO= "amltd" DISTRO_VERSION= "2.2+snapshot-20161202" TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard cortexa7" TARGET_FPU= "hard" meta = "master:9e63f81c78e284c9b325fe04a1b59e61c7ad8a1a" meta-amltd= "master:074120ab3a82cea0ac50d4e9eec89130a860a4fa" meta-raspberrypi = "master:44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9" Initialising tasks: 100% |#| Time: 0:00:00 Checking sstate mirror object availability: 100% |#| Time: 0:00:00 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: linux-raspberrypi-1_4.4.28+gitAUTOINC+5afda48c34-r0 do_kernel_metadata: Function failed: do_kernel_metadata (log file is located at /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.5647) ERROR: Logfile of failure stored in: /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.5647 Log data follows: | DEBUG: Executing shell function do_kernel_metadata | [ERROR]: processing of file /tmp/tmp.bXPr8PVPz3 failed | /build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd: line 29: : No such file or directory | | Context around the error is: | | # | prefix /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/ | kconf non-hardware /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig | prefix /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/ | patch "/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch" | # run time: 0 seconds | # processed files: | # _cfg /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig | # _cfg /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch | | See pre-processed file /tmp/tmp.bXPr8PVPz3 for more details | # | # scc v0.8 | # processed: Fri Dec 2 04:12:25 CET 2016 | # | # This is a scc output file, do not edit | # | [ERROR]: processing of file /tmp/tmp.eTLAT789Q2 failed | # _reloc_dir /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux | # _reloc_dir /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux | /build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd: line 29: : No such file or directory | | Context around the error is: | | # | prefix /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/ | kconf non-hardware /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig | prefix /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/ | patch "/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch" | # run time: 1 seconds | # processed files: | # _cfg /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig | # _cfg /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch | | See pre-processed file /tmp/tmp.eTLAT789Q2 for more details | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_kernel_metadata (log file is located at /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.5647) ERROR: Task (/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.4.bb:do_kernel_metadata) failed with exit code '1' I also tried kernel version 4.7: ERROR: linux-raspberrypi-1_4.7.7+gitAUTOINC+a45a35c
[yocto] RFC BuildAppliance future
Please note, this is going out to 3 lists in an attempt to insure that no one who would be impacted by this change misses it. Implied spam apology included. The Yocto Project currently provides a virtual machine image called the Build Appliance ( https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-appliance/). This image can be run using either VirtualBox or VMware. It enables you to build and boot a custom embedded Linux image with the Yocto Project on a non-Linux development system. It is not intended for day to day development use, but instead, is intended to allow users to “try out” the tools even if they do not have access to a Linux system. We are considering replacing the VM based Build Appliance with a set of containers (https://hub.docker.com/r/crops/poky/, or if you want a user interface (https://hub.docker.com/r/crops/toaster-master/ ). These containers currently provide most of the functionality of the Build Appliance and should shortly be at feature parity with the Build Appliance. We are actively adding to and supporting the containers as some of our developers are using them in their day to day development in order to benefit from the host isolation and ease with which other distributions can be tested. This is an RFC to see what features in the Build Appliance are important to you but would not be provided by the container solutions. If the community would be just as content using the container approach as using the VM based Build Appliance image, then we’d be better off deprecating the Build Appliance and applying those resources elsewhere. If there are important features the Build Appliance provides which the container solution does not, or cannot provide, we’d love to hear what they are! Thanks in advance for any feedback, -Brian an Intel Employee -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] firmware: Update to 20161125
this is ok.
On Mon, Dec 5, 2016 at 3:00 AM, Jonathan Liu wrote:
> Signed-off-by: Jonathan Liu
> ---
> recipes-bsp/common/firmware.inc | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
> index 8862f58..1961b48 100644
> --- a/recipes-bsp/common/firmware.inc
> +++ b/recipes-bsp/common/firmware.inc
> @@ -1,10 +1,10 @@
> -RPIFW_DATE ?= "20161020"
> +RPIFW_DATE ?= "20161125"
> RPIFW_SRC_URI ?=
> "https://github.com/raspberrypi/firmware/archive/1.${RPIFW_DATE}.tar.gz";
> RPIFW_S ?= "${WORKDIR}/firmware-1.${RPIFW_DATE}"
>
> SRC_URI = "${RPIFW_SRC_URI}"
> -SRC_URI[md5sum] = "d3c388c114af4c672dd3ee0ed8e984d3"
> -SRC_URI[sha256sum] =
> "1c7c49d58800aab2dd1b5ff59a1e297934f9ea6f47ebdf0a3f90632561dc690b"
> +SRC_URI[md5sum] = "a9281d2869e2d7673a83d41bacfa66c2"
> +SRC_URI[sha256sum] =
> "744e050630621c70991c91e0ee8663dc2f579e743583ca762b13b00bc75859bc"
>
> PV = "${RPIFW_DATE}"
>
> --
> 2.10.2
>
> --
> ___
> 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] [meta-raspberrypi] X11 failure
On Mon, Dec 5, 2016 at 3:15 AM, Burton, Ross wrote: > > On 5 December 2016 at 11:12, Gary Thomas wrote: >> >> What do I need to do to get libGL v1 so X11 will work again? > > > That would be part of mesa-gl, but I'm surprised RPi X needs OpenGL (as that > is pure software, not accelerated). mesa-gl is used as provider for virtual/libgl when using userland display driver. if you use vc4graphics then you will use mesa for everything. > > Ross > > -- > ___ > 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] Using files from package dependencies
On Mon, Dec 5, 2016 at 7:08 AM, Paulo Neves wrote:
> Hello Nicolas, thank you for your advice and hints but I "need" to
> corrupt a bit the conventions of yocto and use specific package names
> (due to compatibility with other older build systems)
>
> The magic behind the fact that my special package sysroot directories
> were not being moved to the yocto sysroot was due to the fact that
> do_populate_sysroot does not match all the toplevel directories in
> ${D}. For additional directories sysroot_stage_all needs to be
> appended with the desired directories. I am perfectly ok with that but
> why not make a notification that there were directories that were
> packaged but will not be expanded in the sysroots? The lack of
> notification is extremely confusing, as files just do not appear where
> they should.
you can add your directory to SYSROOT_DIRS and it will stage it.
by default it uses commonly used directories as explained here
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-SYSROOT_DIRS
As for the warning, may be its a good thing, feel free to file a
ticket in bugzilla
>
> A similar question to mine can be found here:
> http://stackoverflow.com/questions/35354802/how-to-create-do-populate-sysroot-append-task-in-yocto/40976056#40976056
>
> Best regards
> Paulo Neves
>
> On Mon, Dec 5, 2016 at 10:08 AM, Nicolas Dechesne
> wrote:
>> On Mon, Dec 5, 2016 at 10:10 AM, Paulo Neves wrote:
>>> Sorry for my ambiguity. When I mentioned binaries I meant general
>>> binary data, not necessarily executable. Their only need is that the
>>> new recipe needs to be fed these data from the other package so it can
>>> produce it's own output. This binary data only needs to be available
>>> in the host pc, in the recipe bake.
>>
>> in that case, i suppose you can consider these 'binary files' as
>> development files like other .h or libs, and package them in the -dev
>> package of the dependency. You can control which files get into the
>> -dev package using FILES_${PN}-dev in your recipe.
> --
> ___
> 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] [Openembedded-architecture] RFC BuildAppliance future
On 12/5/16 12:04 PM, Brian Avery wrote: > Please note, this is going out to 3 lists in an attempt to insure that no > one > who would be impacted by this change misses it. Implied spam apology included. > > The Yocto Project currently provides a virtual machine image called the > Build > Appliance > (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-appliance/). > This image can be run using either VirtualBox or VMware. It enables you to > build > and boot a custom embedded Linux image with the Yocto Project on a non-Linux > development system. It is not intended for day to day development use, but > instead, is intended to allow users to “try out” the tools even if they do not > have access to a Linux system. What are the requirements for a Windows user to use this, instead of the VM approach. (In the past it was easy for a Windows user to get the VM, and just run it to test out things.) --Mark > We are considering replacing the VM based Build Appliance with a set of > containers (https://hub.docker.com/r/crops/poky/, or if you want a user > interface (https://hub.docker.com/r/crops/toaster-master/ ). These containers > currently provide most of the functionality of the Build Appliance and should > shortly be at feature parity with the Build Appliance. We are actively adding > to and supporting the containers as some of our developers are using them in > their day to day development in order to benefit from the host isolation and > ease with which other distributions can be tested. > > This is an RFC to see what features in the Build Appliance are important to > you but would not be provided by the container solutions. If the community > would be just as content using the container approach as using the VM based > Build Appliance image, then we’d be better off deprecating the Build Appliance > and applying those resources elsewhere. If there are important features the > Build Appliance provides which the container solution does not, or cannot > provide, we’d love to hear what they are! > > Thanks in advance for any feedback, > > -Brian > > an Intel Employee > > > > ___ > Openembedded-architecture mailing list > openembedded-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] morty release ?
On Mon, Dec 5, 2016 at 7:26 AM, Mirza Krak wrote: > Hi. > > I have some questions and remarks and hopefully someone here can answer them. > > The meta-raspberrpi layer is missing a morty release? Any time frame > of when this will be added? We use master as long as possible, when we have a change that makes master incompatible with prior releases we branch out for the prior releases at that point. > > There is currently a issue when using U-boot due to some updates in > RPi boot firmware. See [1] and [2]. Which should be noted/resolved > before a morty release? > > To provide some more information about above mentioned problem. If you > use the current firmware files (20161030 in meta-raspberrypi) together > with U-boot (2016.03) you lose the console on U-boot and on Linux > kernel. This is due to the fact that "newer" firmware sets a default > uart clock to 48 MHz, but U-boot has a hard-coded value of 3 MHz, and > since we yet do not support to "forward" the patched DTB provided by > the firmware from U-boot to Linux we also break console on Linux. > > The "default" values has been updated in Linux, see [2]. But if you > use that updated Linux kernel there is a mismatch between u-boot and > Linux. Should be noted that U-boot 2016.11 does not have this problem > since it does not try to initialize the UART port at all and only > relies on firmware to set it up correctly (see [3]). We should drop 2016.03 and support 2016.11 for keeping it simple. > > Hope I made sense here :). > > [1]. https://github.com/agherzan/meta-raspberrypi/issues/36 > [2]. https://github.com/raspberrypi/linux/issues/1732#issuecomment-264810083 > [3]. > http://git.denx.de/?p=u-boot.git;a=commit;h=cd0fa5bff8052b19bde6967c2734f323c9848568 > > Best Regards > Mirza > -- > ___ > 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] [Openembedded-architecture] RFC BuildAppliance future
On Mon, Dec 5, 2016 at 10:04 AM, Brian Avery wrote: > Please note, this is going out to 3 lists in an attempt to insure that no > one who would be impacted by this change misses it. Implied spam apology > included. > > The Yocto Project currently provides a virtual machine image called the > Build Appliance > (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-appliance/). > This image can be run using either VirtualBox or VMware. It enables you to > build and boot a custom embedded Linux image with the Yocto Project on a > non-Linux development system. It is not intended for day to day development > use, but instead, is intended to allow users to “try out” the tools even if > they do not have access to a Linux system. > > We are considering replacing the VM based Build Appliance with a set of > containers (https://hub.docker.com/r/crops/poky/, or if you want a user > interface (https://hub.docker.com/r/crops/toaster-master/ ). These > containers currently provide most of the functionality of the Build > Appliance and should shortly be at feature parity with the Build Appliance. > We are actively adding to and supporting the containers as some of our > developers are using them in their day to day development in order to > benefit from the host isolation and ease with which other distributions can > be tested. > > This is an RFC to see what features in the Build Appliance are important > to you but would not be provided by the container solutions. If the > community would be just as content using the container approach as using the > VM based Build Appliance image, then we’d be better off deprecating the > Build Appliance and applying those resources elsewhere. If there are > important features the Build Appliance provides which the container solution > does not, or cannot provide, we’d love to hear what they are! Personally, I dont use build appliance but I think using containers is a good step forward, provided, we can address all build host OSes that virtual appliance could. Build appliance is also a sort of "eat your own dog-food" for ensuring that we are doing ok on preparing cloud images for deployment. Hopefully we wont lose that testing, may be we can add another image to cover that. > > Thanks in advance for any feedback, > > -Brian > > an Intel Employee > > > ___ > Openembedded-architecture mailing list > openembedded-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] RFC BuildAppliance future
Excellent Questions! Dogfooding – Good point. The https://bugzilla.yoctoproject.org/show_bug.cgi?id=9502 bug is intended to address that. With this, we can build and test container images just as we can do with the Build Appliance. As an added win, those folks building Busybox based minimal sized containers would have a different way to do that... OS availability: Docker is available for Windows, Mac, and Linux. Were there fears about specific Linux distributions? It does not seem to be too much harder to try Docker on Windows than it was to try Virtualbox. That being said, Docker is moving/changing more quickly so it may have more bumps in the road but more features too… Windows explained more in depth or one of those bumps…: The answer is a little complicated, so please bear with me. There are 2 different versions of Docker for Windows. The original version is known as “Docker Toolbox” https://www.docker.com/products/docker-toolbox. This is basically Docker running in a minimal VirtualBox Linux VM. They made a separate host binary called docker-machine to help manage the images. This is, in my opinion, a little clunky and does add some complexity when switching from Docker running on Linux to Docker Toolbox running on Windows. The clunkiness is largely due to the VirtualBox VM being “between” the host and the Docker Engine. This version is targeted to people whose Windows version does not meet the requirements specified below. If you have 64bit Windows 10 Pro, Enterprise and Education (1511 November update, Build 10586 or later) and Microsoft Hyper-V, then you can download “Docker for Windows” https://docs.docker.com/docker-for-windows/. This is a Docker implementation for Windows that relies on Hyper-V and a much smaller vm. It is also better integrated into the host environment so that the discontinuity between the host side and the Docker Engine is no longer as jarring. For example, you get a disk tray icon for Docker, can set up http proxies for it, can manage how much memory and how many cpus it will get… This (https://docs.docker.com/docker-for-mac/docker-toolbox/) is nice page that addresses the difference between the newer hypervisor approach and the older "Docker Toolbox aka VirtualBox" approach. The page is discussing it from a Mac perspective but if you replace xhyve with Windows 10 Hyper-V, the page is relevant to Windows as well. The Mac implementation is functionally equivalent to “Docker for Windows” and is called “Docker for Mac” https://docs.docker.com/engine/installation/mac/. It runs on a modified xhyve hypervisor. The Linux implementation runs as a container and uses the same kernel as the host. Thanks for the feedback and if I missed or shortchanged something please let me know, -Brian an intel employee On Mon, Dec 5, 2016 at 10:42 AM, Khem Raj wrote: > On Mon, Dec 5, 2016 at 10:04 AM, Brian Avery > wrote: > > Please note, this is going out to 3 lists in an attempt to insure that > no > > one who would be impacted by this change misses it. Implied spam apology > > included. > > > > The Yocto Project currently provides a virtual machine image called the > > Build Appliance > > (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build- > appliance/). > > This image can be run using either VirtualBox or VMware. It enables you > to > > build and boot a custom embedded Linux image with the Yocto Project on a > > non-Linux development system. It is not intended for day to day > development > > use, but instead, is intended to allow users to “try out” the tools even > if > > they do not have access to a Linux system. > > > > We are considering replacing the VM based Build Appliance with a set of > > containers (https://hub.docker.com/r/crops/poky/, or if you want a user > > interface (https://hub.docker.com/r/crops/toaster-master/ ). These > > containers currently provide most of the functionality of the Build > > Appliance and should shortly be at feature parity with the Build > Appliance. > > We are actively adding to and supporting the containers as some of our > > developers are using them in their day to day development in order to > > benefit from the host isolation and ease with which other distributions > can > > be tested. > > > > This is an RFC to see what features in the Build Appliance are > important > > to you but would not be provided by the container solutions. If the > > community would be just as content using the container approach as using > the > > VM based Build Appliance image, then we’d be better off deprecating the > > Build Appliance and applying those resources elsewhere. If there are > > important features the Build Appliance provides which the container > solution > > does not, or cannot provide, we’d love to hear what they are! > > Personally, I dont use build appliance but I think using containers is a > good > step forward, provided, we can address all build host OSes that > virtual appli
Re: [yocto] Using files from package dependencies
On Mon, 05 Dec 2016 09:42:42 Nicolas Dechesne wrote:
> On Mon, Dec 5, 2016 at 7:59 AM, Paulo Neves wrote:
> > I have a recipe which depends on another package's file to do it's
> > job. How can I arbitrarily access a file from another package which my
> > recipe depends on?
> >
> > I searched for this kind of problem but did not find it
>
> you can't access (reliably) temporary files from another package. Each
> package is built independently in their own 'sandbox'. If files from
> one package are needed for other packages they need to be exported in
> the sysroot (through the -dev package typically).
Just to clear up a bit of confusion, packaging (e.g. the -dev package) has
nothing to do with populating files into the sysroot, other than that files
for each are originally pulled from the same location (i.e. files that get
installed into ${D} during do_install). So the determining factors for a file
going into the sysroot are (a) it has been installed into ${D} during
do_install and (b) it has been installed under one of a list of specific paths
as controlled by SYSROOT_DIRS.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using files from package dependencies
On Mon, 05 Dec 2016 21:06:05 Paulo Neves wrote: > Hello Paul, I understood that. The part of the specific paths is the > one that breaks convention and has no easily visible documentation, or > am I missing something. We do mention it in at least a couple of places: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-sharing-files-between-recipes http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-tasks-populate_sysroot Was there anywhere else you'd expect to see it covered? Our documentation can always be improved (as can our code). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] morty release ?
2016-12-05 19:37 GMT+01:00 Khem Raj : > On Mon, Dec 5, 2016 at 7:26 AM, Mirza Krak wrote: >> Hi. >> >> I have some questions and remarks and hopefully someone here can answer them. >> >> The meta-raspberrpi layer is missing a morty release? Any time frame >> of when this will be added? > > We use master as long as possible, when we have a change that makes master > incompatible with prior releases we branch out for the prior releases > at that point. Thank you for the clarification. > >> >> There is currently a issue when using U-boot due to some updates in >> RPi boot firmware. See [1] and [2]. Which should be noted/resolved >> before a morty release? >> >> To provide some more information about above mentioned problem. If you >> use the current firmware files (20161030 in meta-raspberrypi) together >> with U-boot (2016.03) you lose the console on U-boot and on Linux >> kernel. This is due to the fact that "newer" firmware sets a default >> uart clock to 48 MHz, but U-boot has a hard-coded value of 3 MHz, and >> since we yet do not support to "forward" the patched DTB provided by >> the firmware from U-boot to Linux we also break console on Linux. >> >> The "default" values has been updated in Linux, see [2]. But if you >> use that updated Linux kernel there is a mismatch between u-boot and >> Linux. Should be noted that U-boot 2016.11 does not have this problem >> since it does not try to initialize the UART port at all and only >> relies on firmware to set it up correctly (see [3]). > > We should drop 2016.03 and support 2016.11 for keeping it simple. Should also update Linux which contains the updated default value (since we do not yet support pass-trough of firmware DTB, I know I have seen some patches on the mailing list but nothing in upstream yet). But U-boot is in meta-openembedded, are you suggesting that we update it in meta-raspberry? Or updating it in meta-openembedded? Best Regards Mirza -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] morty release ?
2016-12-05 22:46 GMT+01:00 Mirza Krak : > 2016-12-05 19:37 GMT+01:00 Khem Raj : >> On Mon, Dec 5, 2016 at 7:26 AM, Mirza Krak wrote: >>> Hi. >>> >>> I have some questions and remarks and hopefully someone here can answer >>> them. >>> >>> The meta-raspberrpi layer is missing a morty release? Any time frame >>> of when this will be added? >> >> We use master as long as possible, when we have a change that makes master >> incompatible with prior releases we branch out for the prior releases >> at that point. > > Thank you for the clarification. > >> >>> >>> There is currently a issue when using U-boot due to some updates in >>> RPi boot firmware. See [1] and [2]. Which should be noted/resolved >>> before a morty release? >>> >>> To provide some more information about above mentioned problem. If you >>> use the current firmware files (20161030 in meta-raspberrypi) together >>> with U-boot (2016.03) you lose the console on U-boot and on Linux >>> kernel. This is due to the fact that "newer" firmware sets a default >>> uart clock to 48 MHz, but U-boot has a hard-coded value of 3 MHz, and >>> since we yet do not support to "forward" the patched DTB provided by >>> the firmware from U-boot to Linux we also break console on Linux. >>> >>> The "default" values has been updated in Linux, see [2]. But if you >>> use that updated Linux kernel there is a mismatch between u-boot and >>> Linux. Should be noted that U-boot 2016.11 does not have this problem >>> since it does not try to initialize the UART port at all and only >>> relies on firmware to set it up correctly (see [3]). >> >> We should drop 2016.03 and support 2016.11 for keeping it simple. > > Should also update Linux which contains the updated default value > (since we do not yet support pass-trough of firmware DTB, I know I > have seen some patches on the mailing list but nothing in upstream > yet). > > But U-boot is in meta-openembedded, are you suggesting that we update > it in meta-raspberry? Or updating it in meta-openembedded? I mean openembedded-core/poky. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] morty release ?
> On Dec 5, 2016, at 1:46 PM, Mirza Krak wrote: > > 2016-12-05 19:37 GMT+01:00 Khem Raj : >> On Mon, Dec 5, 2016 at 7:26 AM, Mirza Krak wrote: >>> Hi. >>> >>> I have some questions and remarks and hopefully someone here can answer >>> them. >>> >>> The meta-raspberrpi layer is missing a morty release? Any time frame >>> of when this will be added? >> >> We use master as long as possible, when we have a change that makes master >> incompatible with prior releases we branch out for the prior releases >> at that point. > > Thank you for the clarification. > >> >>> >>> There is currently a issue when using U-boot due to some updates in >>> RPi boot firmware. See [1] and [2]. Which should be noted/resolved >>> before a morty release? >>> >>> To provide some more information about above mentioned problem. If you >>> use the current firmware files (20161030 in meta-raspberrypi) together >>> with U-boot (2016.03) you lose the console on U-boot and on Linux >>> kernel. This is due to the fact that "newer" firmware sets a default >>> uart clock to 48 MHz, but U-boot has a hard-coded value of 3 MHz, and >>> since we yet do not support to "forward" the patched DTB provided by >>> the firmware from U-boot to Linux we also break console on Linux. >>> >>> The "default" values has been updated in Linux, see [2]. But if you >>> use that updated Linux kernel there is a mismatch between u-boot and >>> Linux. Should be noted that U-boot 2016.11 does not have this problem >>> since it does not try to initialize the UART port at all and only >>> relies on firmware to set it up correctly (see [3]). >> >> We should drop 2016.03 and support 2016.11 for keeping it simple. > > Should also update Linux which contains the updated default value > (since we do not yet support pass-trough of firmware DTB, I know I > have seen some patches on the mailing list but nothing in upstream > yet). > > But U-boot is in meta-openembedded, are you suggesting that we update > it in meta-raspberry? Or updating it in meta-openembedded? Yeah I realized that u-boot is coming from OE-Core, it is possible to carry patches in meta-raspberrypi to fix the version for morty in bbappends. May be we need to branch out morty after we have fixed this if we want to drop this version of u-boot beyond morty. > > Best Regards > Mirza -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] X11 failure
On 2016-12-05 19:22, Khem Raj wrote: On Mon, Dec 5, 2016 at 3:15 AM, Burton, Ross wrote: On 5 December 2016 at 11:12, Gary Thomas wrote: What do I need to do to get libGL v1 so X11 will work again? That would be part of mesa-gl, but I'm surprised RPi X needs OpenGL (as that is pure software, not accelerated). mesa-gl is used as provider for virtual/libgl when using userland display driver. if you use vc4graphics then you will use mesa for everything. I used to do this with these lines in local.conf PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp" PREFERRED_PROVIDER_virtual/libgles2 ?= "vc-graphics-hardfp" However this now leads to a cascade of errors: ERROR: Nothing PROVIDES 'userland' (but /local/poky-cutting-edge/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.8.3.bb DEPENDS on or otherwise requires it) ERROR: userland was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to vc-graphics-hardfp, not userland NOTE: Runtime target 'gst-player-dev' is unbuildable, removing... Missing or unbuildable dependency chain was: ['gst-player-dev', 'gstreamer1.0-plugins-bad', 'userland'] NOTE: Runtime target 'gst-player-bin' is unbuildable, removing... Missing or unbuildable dependency chain was: ['gst-player-bin', 'gstreamer1.0-plugins-bad', 'userland'] ERROR: Required build target 'video-demo-image' has no buildable providers. Missing or unbuildable dependency chain was: ['video-demo-image', 'gst-player-bin', 'gstreamer1.0-plugins-bad', 'userland'] If I remove gst-player-* from my image, I can build using vc-graphics-hardfp and X11 works again. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Reminder: Yocto Project Technical Team Meeting - Tuesday, Dec. 6, 2016 8:00 AM US Pacific Time
Tuesday, Dec. 6, 2016 8:00 AM US Pacific Time Agenda: * Opens collection - 5 min (Stephen) * Yocto Project status - 5 min (Stephen/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features * Opens - 10 min * Team Sharing - 10 min We encourage people attending the meeting to logon the Yocto Project IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html Conference Details: Company: WIND RIVER SYS Ready-Access Number: 8007302996/9139049836 Access Code: 2705751 For International numbers see: https://www.yoctoproject.org/tools-resources/community/monthly-technical-call Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone:(503) 712-0534 *Cell: (208) 244-4460 * Email:stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
