Re: [yocto] Patchwork users: Help test new version
On Mon, Jun 20, 2016 at 10:47:16AM -0700, Michael Halstead wrote: > Hello, > > OpenEmbedded is nearly ready to upgrade to a new version of Patchwork. > The new version offers several new features that will allow OpenEmbedded > to improve developer workflow and automated checks on incoming patches. > > If you are a Patchwork user please visit > https://patchwork-next.openembedded.org/ and take a look. If you find > anything amiss please e-mail me directly and include patchwork in the > subject line. > > Thank you for your help upgrading this important system! I was using it to update meta-oe/master-next in last few days and it seems to work the same as old patchwork for me. But quite often I've noticed very slow response, is it running on slower HW while testing or is the new version just a lot slower? -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] is there a recipe for building a ppc-based installer image?
i've been fighting with this for a few days, so i'm going to describe what i'm *trying* to do, and if someone has a solution, terrific; in the meantime, i'm going to ask specific questions about particular recipe and class files, since i think i see all the *pieces* i want, i just don't know how to put them together to *get* what i want. the scenario: powerpc target board, for which we already have working u-boot, kernel and rootfs, and which will have u-boot already installed as the basis for further adventures. as i *see* it, what i want to do is (and i'm willing to be corrected) build a basic kernel with an integrated initramfs that is loaded with installation utilities (fdisk, parted, mkfs, etc, etc.), and whose job it is to then fetch (from somewhere) the installable contents and load up the hard drive, then maybe use fw_setenv to tweak the u-boot env variables, and reboot to the full system. make sense so far? also, since it's ppc and u-boot, there's nothing grub or EFI related i will need, correct? finally, i'd love to be able to test this on a qemuppc image first, so if there's a quick way to build a recipe that does this for qemuppc, that would be ducky. as i see it, there are a number of images under both recipes-core and recipes-extended (those "testmaster" images) i've been looking at that seem to be relevant, but i've yet to find a combination that works. so i'm going to leave this very general description of what i'm after here, and follow up with more specific questions about some of those recipes, and about qemu sessions. and if someone already has a pointer to do all this, well, we're done. rday p.s. if i can get a general solution to this that is not written up elsewhere, i will be delighted to write it up for public consumption so everyone else can take advantage. -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] what is "core-image-testmaster.bb" supposed to do?
first question related to building an installer -- how is one supposed to use the recipe core-image-testmaster.bb? i've already noted (i think) that it has a bug in that it uses the old (obsolete) variable INITRD_IMAGE, whereas the old occurrences of that were changed to either INITRD_IMAGE_VM or INITRD_IMAGE_LIVE. so it seems pretty clear that that recipe doesn't work at the moment. however, if it *did* work, how would one use it? it appears that it builds both a simple initramfs, as well as a standard image. so would it boot to the initramfs, and use the installation tools there to install using the content from the standard image? is that what is supposed to be going on there? or am i misreading this? in any event, it doesn't appear to work, and i get the feeling it's probably overkill for my needs, but i'm still curious as to how one would use it. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a recipe for building a ppc-based installer image?
Robert, Have you looked at using existing updaters such as meta-swupdate or swupd or rauc? I'm sure one of those would do what you want. Rgds, Chris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Regarding backslash in bblayers.conf file
Hello,
We were facing a issue when building 'weston'. The issue is we had included
meta-renesas & poky in our bblayers.conf file. The weston package is provided
by both poky(v1.8.0) and meta-renesas(v1.9.0). We want the weston provided by
the meta-renesas layer as it is the latest and also includes some changes done
by Renesas.
But for some reason, it was building the weston provided by poky(1.8.0) which
we don't want. Then we realized the issue to a backslash added by mistake in
the bblayers.conf file after meta-rcar-gen3 as shown below.
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
${TOPDIR}/../poky/meta \
${TOPDIR}/../poky/meta-yocto \
${TOPDIR}/../poky/meta-yocto-bsp \
${TOPDIR}/../meta-renesas/meta-rcar-gen3/ \
${TOPDIR}/../meta-linaro/meta-linaro-toolchain/ \
${TOPDIR}/../meta-visteon-monarch \
${TOPDIR}/../meta-browser \
${TOPDIR}/../meta-openembedded/meta-oe \
${TOPDIR}/../meta-openembedded/meta-gnome \
${TOPDIR}/../meta-openembedded/meta-networking \
${TOPDIR}/../meta-openembedded/meta-python \
"
BBLAYERS_NON_REMOVABLE ?= " \
${TOPDIR}/../poky/meta \
${TOPDIR}/../poky/meta-yocto \
"
After removing the character, its now building the weston provided by the
mera-rcar-gen3 layer(v1.9.0) correctly as we expect. But I am not able to
understand what was happening when the backslash character was present. Also
when I was building weston with this unwanred character, I was getting the
warning shown below which I couldn't understand.
Loading cache...done.
Loaded 4665 entries from dependency cache.
Parsing recipes...done.
Parsing of 2046 .bb files complete (2045 cached, 1 parsed). 4666 targets, 943
skipped, 2 masked, 0 errors.
WARNING: No bb files matched BBFILE_PATTERN_rcar-gen3
'^/home/hari/salvator-x-1.1.0/monarch-distribution/build_release/../meta-renesas/meta-rcar-gen3//'
WARNING: No bb files matched BBFILE_PATTERN_linaro-toolchain
'^/home/hari/salvator-x-1.1.0/monarch-distribution/build_release/../meta-linaro/meta-linaro-toolchain//'
NOTE: Resolving any missing task queue dependencies
NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to
PREFERRED_PROVIDERS
Thanks & Regards,
Hari Prasath
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Regarding backslash in bblayers.conf file
This looks to be a bug. System should either accept path names with or
without trailing '/'. Please file a bug on bugzilla.yoctoproject.org
On 06/23/2016 08:45 AM, Gujulan Elango, Hari Prasath (H.) wrote:
Hello,
We were facing a issue when building 'weston'. The issue is we had
included meta-renesas & poky in our bblayers.conf file. The weston
package is provided by both poky(v1.8.0) and meta-renesas(v1.9.0). We
want the weston provided by the meta-renesas layer as it is the latest
and also includes some changes done by Renesas.
But for some reason, it was building the weston provided by
poky(1.8.0) which we don't want. Then we realized the issue to a
backslash added by mistake in the bblayers.conf file after
meta-rcar-gen3 as shown below.
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
${TOPDIR}/../poky/meta \
${TOPDIR}/../poky/meta-yocto \
${TOPDIR}/../poky/meta-yocto-bsp \
${TOPDIR}/../meta-renesas/meta-rcar-gen3/ \
${TOPDIR}/../meta-linaro/meta-linaro-toolchain/ \
${TOPDIR}/../meta-visteon-monarch \
${TOPDIR}/../meta-browser \
${TOPDIR}/../meta-openembedded/meta-oe \
${TOPDIR}/../meta-openembedded/meta-gnome \
${TOPDIR}/../meta-openembedded/meta-networking \
${TOPDIR}/../meta-openembedded/meta-python \
"
BBLAYERS_NON_REMOVABLE ?= " \
${TOPDIR}/../poky/meta \
${TOPDIR}/../poky/meta-yocto \
"
After removing the character, its now building the weston provided by
the mera-rcar-gen3 layer(v1.9.0) correctly as we expect. But I am not
able to understand what was happening when the backslash character was
present. Also when I was building weston with this unwanred character,
I was getting the warning shown below which I couldn't understand.
Loading cache...done.
Loaded 4665 entries from dependency cache.
Parsing recipes...done.
Parsing of 2046 .bb files complete (2045 cached, 1 parsed). 4666
targets, 943 skipped, 2 masked, 0 errors.
WARNING: No bb files matched BBFILE_PATTERN_rcar-gen3
'^/home/hari/salvator-x-1.1.0/monarch-distribution/build_release/../meta-renesas/meta-rcar-gen3//'
WARNING: No bb files matched BBFILE_PATTERN_linaro-toolchain
'^/home/hari/salvator-x-1.1.0/monarch-distribution/build_release/../meta-linaro/meta-linaro-toolchain//'
NOTE: Resolving any missing task queue dependencies
NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due
to PREFERRED_PROVIDERS
Thanks & Regards,
Hari Prasath
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a recipe for building a ppc-based installer image?
On Thu, 23 Jun 2016, chris simmonds wrote: > Robert, > > Have you looked at using existing updaters such as meta-swupdate or > swupd or rauc? I'm sure one of those would do what you want. huh ... i was unaware of any of those options, will have to check them out. but i would still like to figure out whether the classes and recipes that come with OE/poky can still do the job. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [[yocto-autobuilder][PATCHv2] 00/15] Add support for generate bitbake/oe-selftest error reports
On 06/22/2016 03:17 PM, Aníbal Limón wrote:
>
>
> On 06/22/2016 02:44 AM, Beth 'pidge' Flanagan wrote:
>> On Tue, 2016-06-21 at 18:07 -0500, Aníbal Limón wrote:
>>> This v2 adds support for generate also oe-selftest reports this is
>>> almost
>>> the previous version with changes requested in review [1], the next
>>> patches
>>> starts from patch,
>>>
>>> autobuilder/lib/{ABtools,builsteps}.py: Create
>>> save_error_report func
>>
>> A few comments.
>>
>> - Please rebase the last two commits. They can be merged into prior
>> commits.
>>
>> Example: 0eb495d93eefa9ead8f4b1242f251f1a2288db68 should be squashed
>> into 83b6707622128436b4ece9d4c2a89311b000c209
>>
>> We shouldn't need rename commits for a pull request that created the
>> original thing we're renaming.
>>
>> - Please fix the title for 83b6707622128436b4ece9d4c2a89311b000c209
>> 's/buiidsets/buildsets/'
>
> I squashed the changes now at,
>
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/log/?h=contrib/alimon/devel2
>
> alimon
Hi,
The Error report web needed changes are now integrated [1], if you
ack'ed the changes we could proceed to integrate/deploy these changes to
enable send Bitbake/OE-seltest errors to ERW.
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7583#c14
Cheers,
alimon
>>
>>
>> -b
>>
>
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [[yocto-autobuilder][PATCHv2] 00/15] Add support for generate bitbake/oe-selftest error reports
On Thu, 2016-06-23 at 10:27 -0500, Aníbal Limón wrote:
>
> On 06/22/2016 03:17 PM, Aníbal Limón wrote:
> >
> >
> >
> > On 06/22/2016 02:44 AM, Beth 'pidge' Flanagan wrote:
> > >
> > > On Tue, 2016-06-21 at 18:07 -0500, Aníbal Limón wrote:
> > > >
> > > > This v2 adds support for generate also oe-selftest reports this
> > > > is
> > > > almost
> > > > the previous version with changes requested in review [1], the
> > > > next
> > > > patches
> > > > starts from patch,
> > > >
> > > > autobuilder/lib/{ABtools,builsteps}.py: Create
> > > > save_error_report func
> > > A few comments.
> > >
> > > - Please rebase the last two commits. They can be merged into
> > > prior
> > > commits.
> > >
> > > Example: 0eb495d93eefa9ead8f4b1242f251f1a2288db68 should be
> > > squashed
> > > into 83b6707622128436b4ece9d4c2a89311b000c209
> > >
> > > We shouldn't need rename commits for a pull request that created
> > > the
> > > original thing we're renaming.
> > >
> > > - Please fix the title for
> > > 83b6707622128436b4ece9d4c2a89311b000c209
> > > 's/buiidsets/buildsets/'
> > I squashed the changes now at,
> >
> > http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/log/?h=
> > contrib/alimon/devel2
> >
> > alimon
> Hi,
>
> The Error report web needed changes are now integrated [1], if you
> ack'ed the changes we could proceed to integrate/deploy these changes
> to
> enable send Bitbake/OE-seltest errors to ERW.
>
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7583#c14
>
> Cheers,
> alimon
Let me review them tonight and if they're ok, I'll pull them into
master.
-b
>
> >
> > >
> > >
> > >
> > > -b
> > >
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Regarding backslash in bblayers.conf file
On Thu, Jun 23, 2016 at 7:12 AM, Leonardo Sandoval < leonardo.sandoval.gonza...@linux.intel.com> wrote: > This looks to be a bug. System should either accept path names with or > without trailing '/'. Please file a bug on bugzilla.yoctoproject.org > Yeah, we likely need to sanitize that path so it aligns with the expected value of BBFILES. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [autobuilder][PATCH] CreateAutoConf.py: check for empty env history variables before using
I saw this error on a new AB setup:
File
"/home/pokybuild/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py",
line 181, in start
ta_history_repos=ast.literal_eval(os.environ.get('BUILD_HISTORY_THROWAWAY_WHITELIST').encode('utf-8'))
exceptions.AttributeError: 'NoneType' object has no attribute 'encode'
Since the code above line 181 checks for either
BUILD_HISTORY_THROWAWAY_WHITELIST
or BUILD_HISTORY_WHITELIST being set, it's possible one of them could be empty.
Signed-off-by: Bill Randle
---
.../site-packages/autobuilder/buildsteps/CreateAutoConf.py| 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
index 0845ff1..91607e6 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
@@ -177,9 +177,13 @@ class CreateAutoConf(ShellCommand):
if os.environ.get('BUILD_HISTORY_WHITELIST') is not None or \
os.environ.get('BUILD_HISTORY_THROWAWAY_WHITELIST') is not
None:
+ta_history_repos={}
+history_repos={}
fout = fout + 'ERROR_QA_remove =
"version-going-backwards"\n'
-
ta_history_repos=ast.literal_eval(os.environ.get('BUILD_HISTORY_THROWAWAY_WHITELIST').encode('utf-8'))
-
history_repos=ast.literal_eval(os.environ.get('BUILD_HISTORY_WHITELIST').encode('utf-8'))
+if os.environ.get('BUILD_HISTORY_THROWAWAY_WHITELIST') is
not None:
+
ta_history_repos=ast.literal_eval(os.environ.get('BUILD_HISTORY_THROWAWAY_WHITELIST').encode('utf-8'))
+if os.environ.get('BUILD_HISTORY_WHITELIST') is not None:
+
history_repos=ast.literal_eval(os.environ.get('BUILD_HISTORY_WHITELIST').encode('utf-8'))
if repo in history_repos.keys() and \
self.getProperty("branch") in
history_repos[self.getProperty("repository")]:
# We keep this build history
--
2.5.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 1/4] userland: Upgrade to latest tip
Drop upstream applied patches
Signed-off-by: Khem Raj
---
...applications-to-set-next-resource-handle.patch} | 6 +-
...make-generate-and-install-pkgconfig-files.patch | 114 -
...yland-Add-support-for-the-Wayland-winsys.patch} | 10 +-
...atch => 0003-wayland-Add-Wayland-example.patch} | 6 +-
...wayland-egl-Add-bcm_host-to-dependencies.patch} | 6 +-
...move-faulty-assert-to-make-weston-happy-.patch} | 8 +-
...-zero-out-wl-buffers-in-egl_surface_free.patch} | 6 +-
...07-initialize-front-back-wayland-buffers.patch} | 6 +-
...RPC_FLUSH.patch => 0008-Remove-RPC_FLUSH.patch} | 6 +-
patch => 0009-fix-cmake-dependency-race.patch} | 6 +-
...tch => 0010-Fix-enum-conversion-warnings.patch} | 6 +-
...ix-for-framerate-with-nested-composition.patch} | 6 +-
...> 0012-build-shared-library-for-vchostif.patch} | 6 +-
...t-buffer-wrapping-interface-for-dispmanx.patch} | 14 ++-
recipes-graphics/userland/userland_git.bb | 29 +++---
15 files changed, 66 insertions(+), 169 deletions(-)
rename
recipes-graphics/userland/userland/{0003-Allow-applications-to-set-next-resource-handle.patch
=> 0001-Allow-applications-to-set-next-resource-handle.patch} (98%)
delete mode 100644
recipes-graphics/userland/userland/0002-cmake-generate-and-install-pkgconfig-files.patch
rename
recipes-graphics/userland/userland/{0004-wayland-Add-support-for-the-Wayland-winsys.patch
=> 0002-wayland-Add-support-for-the-Wayland-winsys.patch} (99%)
rename
recipes-graphics/userland/userland/{0005-wayland-Add-Wayland-example.patch =>
0003-wayland-Add-Wayland-example.patch} (99%)
rename
recipes-graphics/userland/userland/{0006-wayland-egl-Add-bcm_host-to-dependencies.patch
=> 0004-wayland-egl-Add-bcm_host-to-dependencies.patch} (86%)
rename
recipes-graphics/userland/userland/{0007-interface-remove-faulty-assert-to-make-weston-happy-.patch
=> 0005-interface-remove-faulty-assert-to-make-weston-happy-.patch} (86%)
rename
recipes-graphics/userland/userland/{0008-zero-out-wl-buffers-in-egl_surface_free.patch
=> 0006-zero-out-wl-buffers-in-egl_surface_free.patch} (87%)
rename
recipes-graphics/userland/userland/{0009-initialize-front-back-wayland-buffers.patch
=> 0007-initialize-front-back-wayland-buffers.patch} (88%)
rename recipes-graphics/userland/userland/{0010-Remove-RPC_FLUSH.patch =>
0008-Remove-RPC_FLUSH.patch} (87%)
rename
recipes-graphics/userland/userland/{0011-fix-cmake-dependency-race.patch =>
0009-fix-cmake-dependency-race.patch} (95%)
rename
recipes-graphics/userland/userland/{0012-Fix-enum-conversion-warnings.patch =>
0010-Fix-enum-conversion-warnings.patch} (97%)
rename
recipes-graphics/userland/userland/{0013-Fix-for-framerate-with-nested-composition.patch
=> 0011-Fix-for-framerate-with-nested-composition.patch} (94%)
rename
recipes-graphics/userland/userland/{0014-build-shared-library-for-vchostif.patch
=> 0012-build-shared-library-for-vchostif.patch} (84%)
rename
recipes-graphics/userland/userland/{0015-wl-dispmanx-buffer-wrapping.patch =>
0013-implement-buffer-wrapping-interface-for-dispmanx.patch} (85%)
diff --git
a/recipes-graphics/userland/userland/0003-Allow-applications-to-set-next-resource-handle.patch
b/recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
similarity index 98%
rename from
recipes-graphics/userland/userland/0003-Allow-applications-to-set-next-resource-handle.patch
rename to
recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
index 4a8b16d..4d026bd 100644
---
a/recipes-graphics/userland/userland/0003-Allow-applications-to-set-next-resource-handle.patch
+++
b/recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
@@ -1,7 +1,7 @@
-From 1d750c8922cbb4276e4337d2af2776676c0bd224 Mon Sep 17 00:00:00 2001
+From 83c5ac5892d0cd29caa8922ff8b639b9a373c3cb Mon Sep 17 00:00:00 2001
From: Dom Cobley
Date: Tue, 9 Jul 2013 09:26:26 -0400
-Subject: [PATCH 03/13] Allow applications to set next resource handle
+Subject: [PATCH 01/13] Allow applications to set next resource handle
This patch adds provisions in userland to
let apps callers set the next rendereing dispmanx resource.
@@ -204,5 +204,5 @@ index 8a5734c..51b3580 100644
FN(void, eglIntGetColorData_impl, (EGL_SURFACE_ID_T s, KHRN_IMAGE_FORMAT_T
format, uint32_t width, uint32_t height, int32_t stride, uint32_t y_offset,
void *data))
--
-2.7.4
+2.9.0
diff --git
a/recipes-graphics/userland/userland/0002-cmake-generate-and-install-pkgconfig-files.patch
b/recipes-graphics/userland/userland/0002-cmake-generate-and-install-pkgconfig-files.patch
deleted file mode 100644
index 50ebaa6..000
---
a/recipes-graphics/userland/userland/0002-cmake-generate-and-install-pkgconfig-files.patch
+++ /dev/null
@@ -1,114 +0,0 @@
-From 9abccc4553b29643eee3c5a7edad641bc83f58f4 Mon Sep 17 00:00:00 2001
-From: Khem Raj
-Date: Sun, 9 Aug 2015 23:59:32 -070
[yocto] [meta-raspberrypi][PATCH 4/4] sdcard_image-rpi.bbclass: Exclude DATETIME from task stamp
This helps in fixing occasional error seen quite often
ERROR: wpe-image-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch
7ea6b505bb7a2cc5ca03552bcffa verses 3be7cdad8c4532430d96368c5ca523d4 for
/a/builder/home/kraj/work/oe/meta-metrological/recipes-core/images/wp
e-image.bb.do_image_rpi_sdimg
ERROR: Taskhash mismatch 7ea6b505bb7a2cc5ca03552bcffa verses
3be7cdad8c4532430d96368c5ca523d4 for
/a/builder/home/kraj/work/oe/meta-metrological/recipes-core/images/wpe-image.bb.do_image_rpi_sdimg
Signed-off-by: Khem Raj
---
classes/sdcard_image-rpi.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/classes/sdcard_image-rpi.bbclass b/classes/sdcard_image-rpi.bbclass
index 4dfd7a3..e59 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -73,6 +73,7 @@ FATPAYLOAD ?= ""
IMAGEDATESTAMP = "${@time.strftime('%Y.%m.%d',time.gmtime())}"
IMAGE_CMD_rpi-sdimg[vardepsexclude] = "IMAGEDATESTAMP"
+IMAGE_CMD_rpi-sdimg[vardepsexclude] = "DATETIME"
IMAGE_CMD_rpi-sdimg () {
--
2.9.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 3/4] linux-raspberrypi_4.4: Upgrade to 4.4.13
Signed-off-by: Khem Raj
---
recipes-kernel/linux/linux-raspberrypi_4.4.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.4.bb
b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
index ba47b22..3291ffd 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.4.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
@@ -1,8 +1,8 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-LINUX_VERSION ?= "4.4.9"
+LINUX_VERSION ?= "4.4.13"
-SRCREV = "3b440738b5c1adc3ec3ee72ceca799d1b8d264df"
+SRCREV = "680be5e27a9593cf26079c6e5744a04cc2809d13"
SRC_URI =
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.4.y \
"
require linux-raspberrypi.inc
--
2.9.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 2/4] firmware: Upgrade to 20160622
Signed-off-by: Khem Raj
---
recipes-bsp/common/firmware.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
index bf11e4c..9df6156 100644
--- a/recipes-bsp/common/firmware.inc
+++ b/recipes-bsp/common/firmware.inc
@@ -1,5 +1,5 @@
-RPIFW_SRCREV ?= "3816e1ce1e6ebc6d2bf0596dbd52849e16aa7e94"
-RPIFW_DATE ?= "20160512"
+RPIFW_SRCREV ?= "390f53ed0fd79df274bdcc81d99e09fa262f03ab"
+RPIFW_DATE ?= "20160622"
RPIFW_SRC_URI ?=
"git://github.com/raspberrypi/firmware.git;protocol=git;branch=master"
RPIFW_S ?= "${WORKDIR}/git"
--
2.9.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] question: yocto-bsp tool warnings
I've been looking into setting up my own BSP layer based on the standard/beaglebone branch and I've run into some warnings I wasn't familiar with. I created a test BSP with the yocto-bsp tool and set MACHINE=test, (which is the name of my meta layer) then ran it. This produced several warnings: WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: After meta data application, the kernel tree branch is standard/test. WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: The SRC_URI specified branch standard/base. WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: The branch will be forced to standard/base, but this means the board meta data WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: (.scc files) do not match the SRC_URI specification. WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: The meta data and branch standard/base should be inspected to ensure the proper WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: kernel is being built. I found the patch which enabled this warning, but I'm unsure how to alleviate it. I do intend to use the standard/test branch, but I'm not sure which SRC_URI is telling bitbake to build the standard/base. Any idea where to start looking? Patch that enabled the warnings: http://lists.openembedded.org/pipermail/openembedded-core/2016-April/119808.html -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
