Re: [yocto] [meta-selinux][PATCH] Remove recipes for kernel 3.14 and 3.19 from master branch, to fix a build error. ERROR: No recipes available for: meta-selinux/recipes-kernel/linux/linux-yocto_3.19.
Merged. Thanks.
On 01/04/2016 10:31 AM, Thomas Perrot wrote:
> Signed-off-by: Thomas Perrot
> ---
> recipes-kernel/linux/linux-yocto_3.14.bbappend | 8
> recipes-kernel/linux/linux-yocto_3.19.bbappend | 8
> 2 files changed, 16 deletions(-)
> delete mode 100644 recipes-kernel/linux/linux-yocto_3.14.bbappend
> delete mode 100644 recipes-kernel/linux/linux-yocto_3.19.bbappend
>
> diff --git a/recipes-kernel/linux/linux-yocto_3.14.bbappend
> b/recipes-kernel/linux/linux-yocto_3.14.bbappend
> deleted file mode 100644
> index 65c79ef..000
> --- a/recipes-kernel/linux/linux-yocto_3.14.bbappend
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> -
> -# Enable selinux support in the kernel if the feature is enabled
> -SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux',
> 'file://selinux.cfg', '', d)}"
> -
> -# For inconsistent kallsyms data bug on ARM
> -#
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/thread.html#89718
>
> -EXTRA_OEMAKE += "${@bb.utils.contains('TARGET_ARCH', 'arm', '
> KALLSYMS_EXTRA_PASS=1', '', d)}"
> diff --git a/recipes-kernel/linux/linux-yocto_3.19.bbappend
> b/recipes-kernel/linux/linux-yocto_3.19.bbappend
> deleted file mode 100644
> index a8c0647..000
> --- a/recipes-kernel/linux/linux-yocto_3.19.bbappend
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> -
> -# Enable selinux support in the kernel if the feature is enabled
> -SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux',
> 'file://selinux.cfg', '', d)}"
> -
> -# For inconsistent kallsyms data bug on ARM
> -#
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/thread.html#89718
> -EXTRA_OEMAKE += "${@bb.utils.contains('TARGET_ARCH', 'arm', '
> KALLSYMS_EXTRA_PASS=1', '', d)}"
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW09
This is the sort of case where it'd be nice if bitbake provided a plugin mechanism, pure python, no metadata parsing. Something to think about in the long term.. On Fri, Feb 26, 2016 at 1:59 PM Burton, Ross wrote: > > On 26 February 2016 at 20:16, Philip Balister wrote: > >> I must admit, I'm surprised this is tricky. I look forward to seeing >> what needs doing. Hopefully, it shows me things I can avoid in my work. >> > > The moral of the story is don't rename layers if you want to maintain a > semblance of migration. Renaming meta-yocto to meta-poky means the > bblayers.conf is invalid, so the migration code can't run because bitbake > aborts too early. > > Ross > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: fix path to mkknlimg
On 27 February 2016 at 06:55, Andrei Gherzan wrote:
> On Fri, Feb 26, 2016 at 07:04:28PM +0100, Andrei Gherzan wrote:
>>--
>>Andrei Gherzan
>>On Fri, Feb 26, 2016 at 6:48 PM, Petter Mabäcker
>><[1]pet...@technux.se> wrote:
>>
>>2016-02-26 18:14 skrev Andrei Gherzan:
>>
>> On Fri, Feb 26, 2016 at 08:26:57PM +1100, Jonathan Liu wrote:
>>
>> The path had libexecdir hardcoded so it was no longer correct when
>> libexecdir was changed in meta/conf/bitbake.conf from
>> ${libdir}/${BPN} to ${prefix_native}/libexec for nativesdk recipes.
>> Fixes "No such file or directory" error when executing
>> do_rpiboot_mkimage. Signed-off-by: Jonathan Liu
>> <[2]net...@gmail.com> --- recipes-kernel/linux/linux-raspberrypi.inc
>> | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git
>> a/recipes-kernel/linux/linux-raspberrypi.inc
>> b/recipes-kernel/linux/linux-raspberrypi.inc index 70e8bfe..8c7c46c
>> 100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
>> b/recipes-kernel/linux/linux-raspberrypi.inc @@ -60,7 +60,7 @@
>> do_rpiboot_mkimage() { if test "x${KERNEL_IMAGETYPE}" != "xuImage" ;
>> then if test -n "${KERNEL_DEVICETREE}"; then # Add RPi bootloader
>> trailer to kernel image to enable DeviceTree support -
>> ${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg --dtok
>> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT} +
>> ${STAGING_LIBEXECDIR_NATIVE}/mkknlimg --dtok ${KERNEL_OUTPUT}
>> ${KERNEL_OUTPUT} fi fi } -- 2.7.1
>>
>> Back alive. testing this.
>>
>> --
>> Andrei Gherzan
>>
>>
>>Hi,
>>I think we should use the older patchset from Maciej Borzecki (that
>>solves this and some other minor stuffs) instead. It also keeps the
>>rpi-mkimage structure:
>>[3]https://lists.yoctoproject.org/pipermail/yocto/2016-February/028271.
>>html
>>BR Petter
>>
>>Very good catch Petter. I'll test that PR.
>
> Merged the patch set sent by Maciej. Which covers this patch too.
> Thanks,
>
> --
> Andrei Gherzan
Note that Maciej's patch doesn't really preserve the path on older
branches like you expect.
On master branch:
${libexecdir}/rpi-mkimage expands to /usr/libexec/rpi-mkimage
On daisy branch:
${libexecdir}/rpi-mkimage expands to /usr/lib/rpi-mkimage/rpi-mkimage
Regards,
Jonathan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW09
On 26 February 2016 at 20:16, Philip Balister wrote: > I must admit, I'm surprised this is tricky. I look forward to seeing > what needs doing. Hopefully, it shows me things I can avoid in my work. > The moral of the story is don't rename layers if you want to maintain a semblance of migration. Renaming meta-yocto to meta-poky means the bblayers.conf is invalid, so the migration code can't run because bitbake aborts too early. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW09
On 02/26/2016 02:52 PM, Rudolf J Streif wrote: * We're about to try and transition meta-yocto within meta-yocto to meta-poky. The amount of pain this is causing is horrible :(. >>> >>> Thanks for doing this. Can you summarize the pain? Are there any >>> important lessons here? >> >> The key lesson is our current "migration" code in OE-Core sucks and I >> have some patches in progress which rewrite pieces of it in a way that >> makes it more useful. I'm therefore trying to make some positives from >> it. >> >> That said, I haven't found a way to make this work without leaving a >> dummy layer.conf in the old location since a missing layer.conf file is >> fatal to bitbake very early on before any migration code triggers. >> >> More should become clear when I post the patches, I've been holding off >> that until I actually manage a patch set that works on the >> autobuilder... >> >> Patches should be out over the weekend (in time for the freeze). > > Sounds like a lot of work and potential for breaking things with little added > value other than a more consistent naming. What was the rationale for making > the change, if I may ask? Consistent naming :) It does it make it much easier to explain what the meta-yocto layer is for. This has been one source of a great deal of confusion about how all the pieces come together. I must admit, I'm surprised this is tricky. I look forward to seeing what needs doing. Hopefully, it shows me things I can avoid in my work. Philip > > Thanks, > :rjs > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ANNOUNCEMENT] Milestone 2 for Yocto Project 2.1 now available.
The second milestone release for Yocto Project 2.1 is available for download now. http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.1_M2/ Thank you to everyone for your contributions. eclipse-poky/kepler-master cf60ac293629fc8ecd6c4eb3709a6f334b499d0c eclipse-poky/luna-master 45aa5c77523bdf051d548fff4305382942db2ebb eclipse-poky/mars-master 1d179ddcbd1983bf7bcfe98efdcbb186bdccca4f meta-qt3 7d958b928a4a38a186746fabbc0d8169dd8bb3a6 meta-qt4 4058b0773381f894d915ea3dfac5fe052d82a9a7 poky 152914f2983c5d69001de1d46ce99547fa1e75fe Test report at: https://wiki.yoctoproject.org/wiki/WW08_-_2016-02-17_-_Full_Pass_2.1_M2.rc3 Tracy Graydon Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: fix path to mkknlimg
On Fri, Feb 26, 2016 at 07:04:28PM +0100, Andrei Gherzan wrote:
>--
>Andrei Gherzan
>On Fri, Feb 26, 2016 at 6:48 PM, Petter Mabäcker
><[1]pet...@technux.se> wrote:
>
>2016-02-26 18:14 skrev Andrei Gherzan:
>
> On Fri, Feb 26, 2016 at 08:26:57PM +1100, Jonathan Liu wrote:
>
> The path had libexecdir hardcoded so it was no longer correct when
> libexecdir was changed in meta/conf/bitbake.conf from
> ${libdir}/${BPN} to ${prefix_native}/libexec for nativesdk recipes.
> Fixes "No such file or directory" error when executing
> do_rpiboot_mkimage. Signed-off-by: Jonathan Liu
> <[2]net...@gmail.com> --- recipes-kernel/linux/linux-raspberrypi.inc
> | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git
> a/recipes-kernel/linux/linux-raspberrypi.inc
> b/recipes-kernel/linux/linux-raspberrypi.inc index 70e8bfe..8c7c46c
> 100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
> b/recipes-kernel/linux/linux-raspberrypi.inc @@ -60,7 +60,7 @@
> do_rpiboot_mkimage() { if test "x${KERNEL_IMAGETYPE}" != "xuImage" ;
> then if test -n "${KERNEL_DEVICETREE}"; then # Add RPi bootloader
> trailer to kernel image to enable DeviceTree support -
> ${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg --dtok
> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT} +
> ${STAGING_LIBEXECDIR_NATIVE}/mkknlimg --dtok ${KERNEL_OUTPUT}
> ${KERNEL_OUTPUT} fi fi } -- 2.7.1
>
> Back alive. testing this.
>
> --
> Andrei Gherzan
>
>
>Hi,
>I think we should use the older patchset from Maciej Borzecki (that
>solves this and some other minor stuffs) instead. It also keeps the
>rpi-mkimage structure:
>[3]https://lists.yoctoproject.org/pipermail/yocto/2016-February/028271.
>html
>BR Petter
>
>Very good catch Petter. I'll test that PR.
Merged the patch set sent by Maciej. Which covers this patch too.
Thanks,
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 0/3] libexecdir fixes
On Tue, Feb 02, 2016 at 03:31:44PM +0100, Maciej Borzecki wrote:
> A couple of fixes that resolve issues with recent change of libexecdir
> in OE-core.
>
> The first patch cleans up the recipe to install rpi-mkimage tools into
> ${libexecdir}/rpi-mkimage. This preserves the original nesting of
> rpi-mkimage under ${libdir}.
>
> The 2nd and 3rd patch use ${STAGING_LIBEXECDIR_NATIVE} rather than a mix
> of ${STAGING_DIR_NATIVE}${libexecdir} to keep things clean.
>
> Maciej Borzecki (3):
> rpi-mkimage: install tools under {libexecdir}/rpi-mkimage
> u-boot-rpi: use STAGING_LIBEXECDIR_NATIVE for rpi-mkimage tools
> linux-raspberrypi: use STAGING_LIBEXECDIR_NATIVE for rpi-mkimage tools
>
> recipes-bsp/rpi-mkimage/rpi-mkimage_git.bb | 4 ++--
> recipes-bsp/u-boot/u-boot-rpi_git.bb | 2 +-
> recipes-kernel/linux/linux-raspberrypi.inc | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> --
> 2.5.0
>
Hi,
Merged the patch set to master. Thank you.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW09
> > > > > > * We're about to try and transition meta-yocto within meta-yocto to > > > > > > meta-poky. The amount of pain this is causing is horrible :(. > > > > Thanks for doing this. Can you summarize the pain? Are there any > > important lessons here? > > The key lesson is our current "migration" code in OE-Core sucks and I > have some patches in progress which rewrite pieces of it in a way that > makes it more useful. I'm therefore trying to make some positives from > it. > > That said, I haven't found a way to make this work without leaving a > dummy layer.conf in the old location since a missing layer.conf file is > fatal to bitbake very early on before any migration code triggers. > > More should become clear when I post the patches, I've been holding off > that until I actually manage a patch set that works on the > autobuilder... > > Patches should be out over the weekend (in time for the freeze). Sounds like a lot of work and potential for breaking things with little added value other than a more consistent naming. What was the rationale for making the change, if I may ask? Thanks, :rjs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW09
On Fri, 2016-02-26 at 13:45 -0500, Philip Balister wrote: > On 02/26/2016 12:36 PM, Richard Purdie wrote: > > Current Dev Position: YP 2.1 M3 > > Next Deadline: YP 2.1 M3 Cutoff (Feature Freeze) February 29, 2016 > > > > SWAT team rotation: Tracy -> Alejandero > > https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team > > > > Key Status/Updates: > > * 2.1 Feature Freeze is upon us. If there is any feature you want > > to > > see in 2.1 which isn't going to make the deadline, talk to RP. > > * We plan to release 2.1 M2 despite the sato glib issue, granting > > an > > exception for the high bug and then concentrate on 2.1 M3. > > * 2.1 M3 build won't happen until sato glib issue resolved. > > * Also planning to merge the gobject-introspection changes > > * Pseudo connection issue appears to be addressed with increased > > retry > > numbers. Tests ongoing. > > * We're about to try and transition meta-yocto within meta-yocto to > > meta-poky. The amount of pain this is causing is horrible :(. > > Thanks for doing this. Can you summarize the pain? Are there any > important lessons here? The key lesson is our current "migration" code in OE-Core sucks and I have some patches in progress which rewrite pieces of it in a way that makes it more useful. I'm therefore trying to make some positives from it. That said, I haven't found a way to make this work without leaving a dummy layer.conf in the old location since a missing layer.conf file is fatal to bitbake very early on before any migration code triggers. More should become clear when I post the patches, I've been holding off that until I actually manage a patch set that works on the autobuilder... Patches should be out over the weekend (in time for the freeze). Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW09
On 02/26/2016 12:36 PM, Richard Purdie wrote: > Current Dev Position: YP 2.1 M3 > Next Deadline: YP 2.1 M3 Cutoff (Feature Freeze) February 29, 2016 > > SWAT team rotation: Tracy -> Alejandero > https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team > > Key Status/Updates: > * 2.1 Feature Freeze is upon us. If there is any feature you want to > see in 2.1 which isn't going to make the deadline, talk to RP. > * We plan to release 2.1 M2 despite the sato glib issue, granting an > exception for the high bug and then concentrate on 2.1 M3. > * 2.1 M3 build won't happen until sato glib issue resolved. > * Also planning to merge the gobject-introspection changes > * Pseudo connection issue appears to be addressed with increased retry > numbers. Tests ongoing. > * We're about to try and transition meta-yocto within meta-yocto to > meta-poky. The amount of pain this is causing is horrible :(. Thanks for doing this. Can you summarize the pain? Are there any important lessons here? Philip > * We're considering a bump in the minimum git version requirements > due to the requirements of various pieces of project tooling. > * We're rebuilding jethro 2.0.1 due to the glibc security issue, now > at -rc7. > > Key YP 2.1 Dates: > YP 2.1 M2 Target release date is February 12, 2016 (Will slip a few > weeks.) > YP 2.1 M3 Cutoff (Feature Freeze) date is February 29, 2016 noon GMT > YP 2.1 M3 Target release date is March 18, 2016 > YP 2.1 M4 / Final Cutoff: March 28, 2016 noon GMT - Stabilization only > milestone. > YP 2.1 Final Release Target: April 29, 2016 > > Key Status Links for YP: > https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.1_Status > https://wiki.yoctoproject.org/wiki/Yocto_2.1_Schedule > https://wiki.yoctoproject.org/wiki/Yocto_2.1_Features > > Tracking Metrics: > WDD 2565 (last week 2585) > (https://wiki.yoctoproject.org/charts/combo.html) > > [If anyone has suggestions for other information you’d like to see on > this weekly status update, let us know!] > > Thanks, > > Richard > > > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: fix path to mkknlimg
--
Andrei Gherzan
On Fri, Feb 26, 2016 at 6:48 PM, Petter Mabäcker wrote:
> 2016-02-26 18:14 skrev Andrei Gherzan:
>
> On Fri, Feb 26, 2016 at 08:26:57PM +1100, Jonathan Liu wrote:
>
> The path had libexecdir hardcoded so it was no longer correct when
> libexecdir was changed in meta/conf/bitbake.conf from ${libdir}/${BPN} to
> ${prefix_native}/libexec for nativesdk recipes. Fixes "No such file or
> directory" error when executing do_rpiboot_mkimage. Signed-off-by: Jonathan
> Liu --- recipes-kernel/linux/linux-raspberrypi.inc | 2
> +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git
> a/recipes-kernel/linux/linux-raspberrypi.inc
> b/recipes-kernel/linux/linux-raspberrypi.inc index 70e8bfe..8c7c46c 100644
> --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
> b/recipes-kernel/linux/linux-raspberrypi.inc @@ -60,7 +60,7 @@
> do_rpiboot_mkimage() { if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
> if test -n "${KERNEL_DEVICETREE}"; then # Add RPi bootloader trailer to
> kernel image to enable DeviceTree support -
> ${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg --dtok ${KERNEL_OUTPUT}
> ${KERNEL_OUTPUT} + ${STAGING_LIBEXECDIR_NATIVE}/mkknlimg --dtok
> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT} fi fi } -- 2.7.1
>
> Back alive. testing this.
> --
> Andrei Gherzan
>
>
> Hi,
>
> I think we should use the older patchset from *Maciej Borzecki * (that
> solves this and some other minor stuffs) instead. It also keeps the
> rpi-mkimage structure:
>
>
> https://lists.yoctoproject.org/pipermail/yocto/2016-February/028271.html
>
> BR Petter
>
Very good catch Petter. I'll test that PR.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Changing file group from an image recipe
In dizzy, I have a problem with changing a file group from an image recipe.
I create a user admin from an application recipe, say app.bb:
...
inherit pkgconfig cmake update-rc.d useradd
USERADD_PACKAGES = "${PN}"
USERADD_PARAM_${PN} = "admin"
...
Creating the user works fine. Now I need to grant the admin user rights to
reboot the system. I tested I need to change the group ownership of
/sbin/halt.sysvinit and move "/sbin/reboot" from /etc/busybox.links.nosuid
to /etc/busybox.links.suid. So I do the following in the image recipe, say
myimage.bb:
...
inherit core-image
ROOTFS_POSTPROCESS_COMMAND += "set_admin_rights;"
set_admin_rights () {
# admin needs to be able to reboot the system
echo /sbin/reboot >> ${IMAGE_ROOTFS}/${sysconfdir}/busybox.links.suid
sed -i '/\/sbin\/reboot/d'
${IMAGE_ROOTFS}/${sysconfdir}/busybox.links.nosuid
chgrp admin ${IMAGE_ROOTFS}/sbin/halt.sysvinit
}
Anyway, this does not work, and I get the following output during bitbaking:
WARNING: log_check: warning: group admin does not exist - using root
It looks like the myimage.bb recipe does not know about the created admin
user, even though it is known in app.bb and changing some files' group
locally in that recipe works as expected.
Can someone please suggest how to properly change the group, or how to
achieve required functionality more elegantly?
Thanks, Petr
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: fix path to mkknlimg
2016-02-26 18:14 skrev Andrei Gherzan:
> On Fri, Feb 26, 2016 at
08:26:57PM +1100, Jonathan Liu wrote:
>
>> The path had libexecdir
hardcoded so it was no longer correct when libexecdir was changed in
meta/conf/bitbake.conf from ${libdir}/${BPN} to ${prefix_native}/libexec
for nativesdk recipes. Fixes "No such file or directory" error when
executing do_rpiboot_mkimage. Signed-off-by: Jonathan Liu
--- recipes-kernel/linux/linux-raspberrypi.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-) diff --git
a/recipes-kernel/linux/linux-raspberrypi.inc
b/recipes-kernel/linux/linux-raspberrypi.inc index 70e8bfe..8c7c46c
100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
b/recipes-kernel/linux/linux-raspberrypi.inc @@ -60,7 +60,7 @@
do_rpiboot_mkimage() { if test "x${KERNEL_IMAGETYPE}" != "xuImage" ;
then if test -n "${KERNEL_DEVICETREE}"; then # Add RPi bootloader
trailer to kernel image to enable DeviceTree support -
${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg --dtok
${KERNEL_OUTPUT} ${KERNEL_OUTPUT} +
${STAGING_LIBEXECDIR_NATIVE}/mkknlimg --dtok ${KERNEL_OUTPUT}
${KERNEL_OUTPUT} fi fi } -- 2.7.1
>
> Back alive. testing this.
>
> --
> Andrei Gherzan
Hi,
I think we should use the older patchset from
_Maciej Borzecki _ (that solves this and some other minor stuffs)
instead. It also keeps the rpi-mkimage
structure:
https://lists.yoctoproject.org/pipermail/yocto/2016-February/028271.html
BR
Petter --
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [OE-core] Yocto Project Status WW09
Current Dev Position: YP 2.1 M3 Next Deadline: YP 2.1 M3 Cutoff (Feature Freeze) February 29, 2016 SWAT team rotation: Tracy -> Alejandero https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: * 2.1 Feature Freeze is upon us. If there is any feature you want to see in 2.1 which isn't going to make the deadline, talk to RP. * We plan to release 2.1 M2 despite the sato glib issue, granting an exception for the high bug and then concentrate on 2.1 M3. * 2.1 M3 build won't happen until sato glib issue resolved. * Also planning to merge the gobject-introspection changes * Pseudo connection issue appears to be addressed with increased retry numbers. Tests ongoing. * We're about to try and transition meta-yocto within meta-yocto to meta-poky. The amount of pain this is causing is horrible :(. * We're considering a bump in the minimum git version requirements due to the requirements of various pieces of project tooling. * We're rebuilding jethro 2.0.1 due to the glibc security issue, now at -rc7. Key YP 2.1 Dates: YP 2.1 M2 Target release date is February 12, 2016 (Will slip a few weeks.) YP 2.1 M3 Cutoff (Feature Freeze) date is February 29, 2016 noon GMT YP 2.1 M3 Target release date is March 18, 2016 YP 2.1 M4 / Final Cutoff: March 28, 2016 noon GMT - Stabilization only milestone. YP 2.1 Final Release Target: April 29, 2016 Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.1_Status https://wiki.yoctoproject.org/wiki/Yocto_2.1_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.1_Features Tracking Metrics: WDD 2565 (last week 2585) (https://wiki.yoctoproject.org/charts/combo.html) [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Richard-- ___ Openembedded-core mailing list openembedded-c...@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: fix path to mkknlimg
On Fri, Feb 26, 2016 at 08:26:57PM +1100, Jonathan Liu wrote:
> The path had libexecdir hardcoded so it was no longer correct when
> libexecdir was changed in meta/conf/bitbake.conf from ${libdir}/${BPN}
> to ${prefix_native}/libexec for nativesdk recipes.
>
> Fixes "No such file or directory" error when executing do_rpiboot_mkimage.
>
> Signed-off-by: Jonathan Liu
> ---
> recipes-kernel/linux/linux-raspberrypi.inc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc
> b/recipes-kernel/linux/linux-raspberrypi.inc
> index 70e8bfe..8c7c46c 100644
> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> @@ -60,7 +60,7 @@ do_rpiboot_mkimage() {
> if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
> if test -n "${KERNEL_DEVICETREE}"; then
> # Add RPi bootloader trailer to kernel image to enable
> DeviceTree support
> -${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg --dtok
> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
> +${STAGING_LIBEXECDIR_NATIVE}/mkknlimg --dtok ${KERNEL_OUTPUT}
> ${KERNEL_OUTPUT}
> fi
> fi
> }
> --
> 2.7.1
>
Back alive. testing this.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Hanging during kernel boot
I have been getting the same error; "The system doesn't crash. I can bang on the keyboard, and the keys are echoed. After seven or so presses, I get a "random: nonblocking pool is initialized" message (something to do with entropy collection, I guess). So the kernel is running, but it's like systemd (which I've substituted for sysvinit) has just hung." Did you ever resolve this one? Mark Clark Embedded Software Engineer Embedded Software, Cedar Park, TX [Description: Description: Description: Description: National Oilwell Varco Logo Color CMYK.jpg] Wellbore Technologies - Dynamic Drilling Solutions Global Software Engineering Office: (512) 340-5435 Mobile: (512) 736-9396 "One Team - Infinite Solutions" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Adjust for libexecdir changes
On Fri, Feb 26, 2016 at 3:35 AM, Jonathan Liu wrote:
> Hi Khem,
>
> I just posted another patch which does basically the same thing but
> uses ${STAGING_LIBEXECDIR_NATIVE}.
> I checked the expansion of ${STAGING_LIBEXECDIR_NATIVE} on daisy
> branch and master.
>
> daisy:
> [...]/sysroots/x86_64-linux/usr/lib/rpi-mkimage/mkknlimg
> which matches the previous hardcoded path before the patch
>
> master:
> [...]/sysroots/x86_64-linux/usr/libexec/mkknlimg
>
> So it looks like my patch should work on older branches too...
>
yes this approach is better. Therefore I have picked it into
kraj/master, I will test it out and push is
shortly.
> Regards,
> Jonathan
>
> On 25 February 2016 at 08:44, Khem Raj wrote:
>>
>> On Feb 24, 2016 1:30 PM, "Anders Darander" wrote:
>>>
>>> * Andreas Müller [160223 22:38]:
>>> > > * Khem Raj [160130 18:07]:
>>> > >
>>> > >> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc
>>> > >> b/recipes-kernel/linux/linux-raspberrypi.inc
>>> > >> index 70e8bfe..0798788 100644
>>> > >> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>>> > >> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>>> > >> @@ -60,7 +60,7 @@ do_rpiboot_mkimage() {
>>> > >> if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
>>> > >> if test -n "${KERNEL_DEVICETREE}"; then
>>> > >> # Add RPi bootloader trailer to kernel image to enable
>>> > >> DeviceTree support
>>> > >> -${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg
>>> > >> --dtok ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
>>> > >> +${STAGING_DIR_NATIVE}${libexecdir}/mkknlimg --dtok
>>> > >> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
>>> > >> fi
>>> > >> fi
>>> > >> }
>>> > This patch is mandatory but there was a serial with additional fixes
>>> > send by Maciej Borzecki on Feb 2nd. I think this is worth taken into
>>> > account.
>>> >
>>>
>>> Yes, that's right.
>>>
>>> If the rest of the patches in that series is non-controversial, could we
>>> have them applied? Otherwise, could we have Khem's patch applied, and
>>> the other series rebased upon that?
>>>
>>
>> This will also make layer incompatible with jethro and older releases. So
>> before applying this patch jethro has to branch out
>>
>>> We've had the master branch non-building for quite a while now...
>>>
>>> I'm just keen to get either of those patches applied to
>>> meta-raspberrypi. I'd like to avoid having to use a local fork as much
>>> as possible...
>>>
>>> Cheers,
>>> Anders
>>>
>>> --
>>> Anders Darander, Senior System Architect
>>> ChargeStorm AB / eStorm AB
>>> --
>>> ___
>>> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Source for recipe on local drive
Additionally, I use the following sentence to get directly the location where these sources are: bitbake -e | grep "^WORKDIR=" El Viernes 26 de febrero de 2016 16:00, "Burton, Ross" escribió: On 26 February 2016 at 14:55, Marius Liebenberg wrote: How do I get all the source code for a specific recipe onto my local drive. That is without sifting through all the config files to try and get url's "bitbake [recipe] -c fetch" will just run the fetch task. 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] Source for recipe on local drive
On 26 February 2016 at 14:55, Marius Liebenberg wrote: > How do I get all the source code for a specific recipe onto my local > drive. That is without sifting through all the config files to try and get > url's > "bitbake [recipe] -c fetch" will just run the fetch task. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Source for recipe on local drive
Hi How do I get all the source code for a specific recipe onto my local drive. That is without sifting through all the config files to try and get url's Regards Marius -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Removing Hob for 2.1
On 2016-02-26 08:37 AM, Philip Balister wrote: > On 02/25/2016 09:49 PM, Paul Eggleton wrote: >> Hi folks, >> >> So we've been gearing up the Toaster web UI to replace the Hob (GTK+ based) >> UI >> for some time now; Hob has basically been on life support for the past few >> releases. As of late last month in master, Toaster has the capability to > > Please remove Hob. > > I've heard that the Linux Foundation training still mentions Hob, I'll > double check that this content is removed and shifted to Toaster. > > Philip > >> select the packages in an image, removing the last thing that Hob could do >> that Toaster couldn't. This means it's about time we looked at removing Hob >> - >> particularly if we want to do so for the upcoming 2.1 release as we should >> really do so within the M3 development timeframe which is almost over. >> >> To recap, the reasons why Hob ought to be removed include: >> >> - The code is tightly woven into BitBake, making it fragile. This means it >> needs significant QA and maintenance on an ongoing basis. >> >> - Some of the implementation is not ideal; we'll be able to remove some >> cruft >> from BitBake and OE-Core at the same time. >> >> - It's GTK+ 2 based, not the current GTK+ 3. >> >> - Toaster is now a much more capable UI and is being actively maintained >> >> I'm maintaining a list of things we would drop together with Hob, so I could >> probably come up with a patchset - I just wanted to give people a heads up >> and >> double check that this is something we indeed want to do in 2.1. Any >> comments? >> I haven't been using the last few versions of Yocto, last I used was 1.8 I believe unless we just jumped to 2.0/2.1. I was wondering for people somewhat used to using HOB for easier distribution build tuning how big is the learning curve(I assume it isn't much). Further more can Toaster be configured to make iso/vmware images as I find this very useful plus from what I known Toaster needs to be run with a browser can it be made to run as a non browser based service similar to Hob if not already done so. Just my thoughts, Nick P.S. Sorry if anybody gets a second email as I was not subscribed to openembedded architecture. >> Cheers, >> Paul >> -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Removing Hob for 2.1
On 2016-02-26 08:37 AM, Philip Balister wrote: > On 02/25/2016 09:49 PM, Paul Eggleton wrote: >> Hi folks, >> >> So we've been gearing up the Toaster web UI to replace the Hob (GTK+ based) >> UI >> for some time now; Hob has basically been on life support for the past few >> releases. As of late last month in master, Toaster has the capability to > > Please remove Hob. > > I've heard that the Linux Foundation training still mentions Hob, I'll > double check that this content is removed and shifted to Toaster. > > Philip > >> select the packages in an image, removing the last thing that Hob could do >> that Toaster couldn't. This means it's about time we looked at removing Hob >> - >> particularly if we want to do so for the upcoming 2.1 release as we should >> really do so within the M3 development timeframe which is almost over. >> >> To recap, the reasons why Hob ought to be removed include: >> >> - The code is tightly woven into BitBake, making it fragile. This means it >> needs significant QA and maintenance on an ongoing basis. >> >> - Some of the implementation is not ideal; we'll be able to remove some >> cruft >> from BitBake and OE-Core at the same time. >> >> - It's GTK+ 2 based, not the current GTK+ 3. >> >> - Toaster is now a much more capable UI and is being actively maintained >> >> I'm maintaining a list of things we would drop together with Hob, so I could >> probably come up with a patchset - I just wanted to give people a heads up >> and >> double check that this is something we indeed want to do in 2.1. Any >> comments? >> I haven't been using the last few versions of Yocto, last I used was 1.8 I believe unless we just jumped to 2.0/2.1. I was wondering for people somewhat used to using HOB for easier distribution build tuning how big is the learning curve(I assume it isn't much). Further more can Toaster be configured to make iso/vmware images as I find this very useful plus from what I known Toaster needs to be run with a browser can it be made to run as a non browser based service similar to Hob if not already done so. Just my thoughts, Nick >> Cheers, >> Paul >> -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Removing Hob for 2.1
On 02/25/2016 09:49 PM, Paul Eggleton wrote: > Hi folks, > > So we've been gearing up the Toaster web UI to replace the Hob (GTK+ based) > UI > for some time now; Hob has basically been on life support for the past few > releases. As of late last month in master, Toaster has the capability to Please remove Hob. I've heard that the Linux Foundation training still mentions Hob, I'll double check that this content is removed and shifted to Toaster. Philip > select the packages in an image, removing the last thing that Hob could do > that Toaster couldn't. This means it's about time we looked at removing Hob - > particularly if we want to do so for the upcoming 2.1 release as we should > really do so within the M3 development timeframe which is almost over. > > To recap, the reasons why Hob ought to be removed include: > > - The code is tightly woven into BitBake, making it fragile. This means it > needs significant QA and maintenance on an ongoing basis. > > - Some of the implementation is not ideal; we'll be able to remove some cruft > from BitBake and OE-Core at the same time. > > - It's GTK+ 2 based, not the current GTK+ 3. > > - Toaster is now a much more capable UI and is being actively maintained > > I'm maintaining a list of things we would drop together with Hob, so I could > probably come up with a patchset - I just wanted to give people a heads up > and > double check that this is something we indeed want to do in 2.1. Any comments? > > Cheers, > Paul > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH] omxplayer: fix host-user-contaminated QA warnings
Explicitly chown the installed files to fix host-user-contaminated QA
warnings for libavcodec, libavdevice, libavfilter, libavformat,
libavutil and libswresample shared libraries.
Signed-off-by: Jonathan Liu
---
recipes-multimedia/omxplayer/omxplayer_git.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/recipes-multimedia/omxplayer/omxplayer_git.bb
b/recipes-multimedia/omxplayer/omxplayer_git.bb
index a0690a0..8816273 100644
--- a/recipes-multimedia/omxplayer/omxplayer_git.bb
+++ b/recipes-multimedia/omxplayer/omxplayer_git.bb
@@ -61,6 +61,7 @@ do_install() {
oe_runmake STRIP='echo skipping strip' dist
mkdir -p ${D}${datadir}/fonts/truetype/freefont/
install ${S}/fonts/* ${D}${datadir}/fonts/truetype/freefont/
+chown root:root -R ${D}
}
FILES_${PN} = "${bindir}/omxplayer* \
--
2.7.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Build External Kernel Modules error
Hello all, I'm trying to build external kernel module for example : bitbake cryptodev-module with yocto jethro based branch, but I get the follwoing error : NOTE: Preparing RunQueue WARNING: /home/inst/Projects/poky/build/../meta/recipes-kernel/cryptodev/cryptodev-module_1.7.bb.do_rm_work_all is tainted from a forced run NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: Function failed: do_make_scripts (log file is located at /home/inst/Projects/poky/build/tmp/work/shc-poky-linux-gnueabi/cryptodev-module/1.7-r0/temp/log.do_make_scripts.21222) ERROR: Logfile of failure stored in: /home/inst/Projects/poky/build/tmp/work/shc-poky-linux-gnueabi/cryptodev-module/1.7-r0/temp/log.do_make_scripts.21222 Log data follows: | DEBUG: Executing shell function do_make_scripts | make: Entering directory `/home/inst/Projects/poky/build/tmp/work-shared/shc/kernel-source' | make[1]: Entering directory `/home/inst/Projects/poky/build/tmp/work-shared/shc/kernel-build-artifacts' | HOSTCC scripts/basic/fixdep | GEN ./Makefile | HOSTCC scripts/kconfig/conf.o | SHIPPED scripts/kconfig/zconf.tab.c | SHIPPED scripts/kconfig/zconf.lex.c | SHIPPED scripts/kconfig/zconf.hash.c | HOSTCC scripts/kconfig/zconf.tab.o | HOSTLD scripts/kconfig/conf | scripts/kconfig/conf --silentoldconfig Kconfig | *** | *** Configuration file ".config" not found! | *** | *** Please run some configurator (e.g. "make oldconfig" or | *** "make menuconfig" or "make xconfig"). | *** | make[3]: *** [silentoldconfig] Error 1 | make[2]: *** [silentoldconfig] Error 2 | make[1]: *** No rule to make target `include/config/auto.conf', needed by `scripts'. Stop. | make[1]: Leaving directory `/home/inst/Projects/poky/build/tmp/work-shared/shc/kernel-build-artifacts' | make: *** [sub-make] Error 2 I'm using a linux 4.1 mainline based kernel and I set the Kernel defconfig in my machine.conf as follow : KBUILD_DEFCONFIG = "shc_defconfig" The kernel and internal modules are built correctly. Anyone facing the same issue ? how to fix that ? Cheers, Ayoub Zaki -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH] omxplayer: bump revision
Fixes compile errors with ffmpeg 3.0. Signed-off-by: Jonathan Liu --- recipes-multimedia/omxplayer/omxplayer_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-multimedia/omxplayer/omxplayer_git.bb b/recipes-multimedia/omxplayer/omxplayer_git.bb index 2f45fb0..a0690a0 100644 --- a/recipes-multimedia/omxplayer/omxplayer_git.bb +++ b/recipes-multimedia/omxplayer/omxplayer_git.bb @@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" DEPENDS = "libpcre libav virtual/egl boost freetype dbus openssl samba libssh" PR = "r4" -SRCREV = "d99bd86c9fd80ea01f98761e130d7ac9a2bb7588" +SRCREV = "15a490b2397b358776c56b017a137c4716eb6b4e" SRC_URI = "git://github.com/popcornmix/omxplayer.git;protocol=git;branch=master \ file://0001-Remove-Makefile.include-which-includes-hardcoded.patch \ file://0002-Libraries-and-headers-from-ffmpeg-are-installed-in-u.patch \ -- 2.7.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Adjust for libexecdir changes
Hi Khem,
I just posted another patch which does basically the same thing but
uses ${STAGING_LIBEXECDIR_NATIVE}.
I checked the expansion of ${STAGING_LIBEXECDIR_NATIVE} on daisy
branch and master.
daisy:
[...]/sysroots/x86_64-linux/usr/lib/rpi-mkimage/mkknlimg
which matches the previous hardcoded path before the patch
master:
[...]/sysroots/x86_64-linux/usr/libexec/mkknlimg
So it looks like my patch should work on older branches too...
Regards,
Jonathan
On 25 February 2016 at 08:44, Khem Raj wrote:
>
> On Feb 24, 2016 1:30 PM, "Anders Darander" wrote:
>>
>> * Andreas Müller [160223 22:38]:
>> > > * Khem Raj [160130 18:07]:
>> > >
>> > >> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc
>> > >> b/recipes-kernel/linux/linux-raspberrypi.inc
>> > >> index 70e8bfe..0798788 100644
>> > >> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>> > >> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>> > >> @@ -60,7 +60,7 @@ do_rpiboot_mkimage() {
>> > >> if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
>> > >> if test -n "${KERNEL_DEVICETREE}"; then
>> > >> # Add RPi bootloader trailer to kernel image to enable
>> > >> DeviceTree support
>> > >> -${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg
>> > >> --dtok ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
>> > >> +${STAGING_DIR_NATIVE}${libexecdir}/mkknlimg --dtok
>> > >> ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
>> > >> fi
>> > >> fi
>> > >> }
>> > This patch is mandatory but there was a serial with additional fixes
>> > send by Maciej Borzecki on Feb 2nd. I think this is worth taken into
>> > account.
>> >
>>
>> Yes, that's right.
>>
>> If the rest of the patches in that series is non-controversial, could we
>> have them applied? Otherwise, could we have Khem's patch applied, and
>> the other series rebased upon that?
>>
>
> This will also make layer incompatible with jethro and older releases. So
> before applying this patch jethro has to branch out
>
>> We've had the master branch non-building for quite a while now...
>>
>> I'm just keen to get either of those patches applied to
>> meta-raspberrypi. I'd like to avoid having to use a local fork as much
>> as possible...
>>
>> Cheers,
>> Anders
>>
>> --
>> Anders Darander, Senior System Architect
>> ChargeStorm AB / eStorm AB
>> --
>> ___
>> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: fix path to mkknlimg
The path had libexecdir hardcoded so it was no longer correct when
libexecdir was changed in meta/conf/bitbake.conf from ${libdir}/${BPN}
to ${prefix_native}/libexec for nativesdk recipes.
Fixes "No such file or directory" error when executing do_rpiboot_mkimage.
Signed-off-by: Jonathan Liu
---
recipes-kernel/linux/linux-raspberrypi.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-kernel/linux/linux-raspberrypi.inc
b/recipes-kernel/linux/linux-raspberrypi.inc
index 70e8bfe..8c7c46c 100644
--- a/recipes-kernel/linux/linux-raspberrypi.inc
+++ b/recipes-kernel/linux/linux-raspberrypi.inc
@@ -60,7 +60,7 @@ do_rpiboot_mkimage() {
if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
if test -n "${KERNEL_DEVICETREE}"; then
# Add RPi bootloader trailer to kernel image to enable DeviceTree
support
-${STAGING_DIR_NATIVE}/usr/lib/rpi-mkimage/mkknlimg --dtok
${KERNEL_OUTPUT} ${KERNEL_OUTPUT}
+${STAGING_LIBEXECDIR_NATIVE}/mkknlimg --dtok ${KERNEL_OUTPUT}
${KERNEL_OUTPUT}
fi
fi
}
--
2.7.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Package generates RPM with lib${PN} - how to include in SDK
> On Feb 25, 2016, at 5:45 AM, Gaurang Shastri wrote:
>
> Hi Team,
>
> I have one package X and recipe as X.bb, which generates RPM as lib${X}-*.rpm
>
> If I want this package as part of my SDK, what entry should i write in
> meta-toolchain.bb
