Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack

2015-08-12 Thread Andreas Müller 
On Wed, Aug 12, 2015 at 7:15 PM, Andreas Müller
 wrote:
> FYI: I managed to get the vc4 driver loaded (should be in my repo
> branch vc4-2). With this I get some repeating kernel error messages
> (don't have them here). I am sure that I read something about these
> messages when preparing vc4 (yes I started similar before you sent
> patches).
>
> Hope I have some energy left tonight to check further and let you know...
>
From xorg perspective all looks fine

[595923.730] (II) modeset(0): [DRI2] Setup complete
[595923.730] (II) modeset(0): [DRI2]   DRI driver: vc4
[595923.730] (II) modeset(0): [DRI2]   VDPAU driver: vc4
[595923.740] (--) RandR disabled
[595923.745] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[595923.745] (II) AIGLX: enabled GLX_ARB_create_context
[595923.745] (II) AIGLX: enabled GLX_ARB_create_context_profile
[595923.745] (II) AIGLX: enabled GLX_EXT_create_context_es2_profile
[595923.745] (II) AIGLX: enabled GLX_INTEL_swap_event
[595923.745] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[595923.745] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
[595923.745] (II) AIGLX: enabled GLX_ARB_fbconfig_float
[595923.745] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[595923.747] (II) AIGLX: Loaded and initialized vc4
[595923.747] (II) GLX: Initialized DRI2 GL provider for screen 0
[595923.782] (II) modeset(0): Setting screen physical size to 338 x 270

but kernel complains periodically ~6s with

[   36.814922] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires
BOs to validate
[   43.060516] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires
BOs to validate
[   49.325115] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires
BOs to validate
[   55.558433] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires
BOs to validate

Will check what this message want me to say - anybody out there with
helping hints?

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

Re: [yocto] [meta-darwin][PATCH] osx-runtime: OSX Yosemite v10.10

2015-08-12 Thread Bystricky, Juro 
ccess building? The line I'm using to invoke the build is:
> 
> $ SDKMACHINE=i386-darwin bitbake core-image-minimal -c populate_sdk
> 
> and the details of my build are:
> 
> Build Configuration:
> BB_VERSION= "1.27.1"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "openSUSE-project-13.2"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "firefly-emmc-mainline"
> DISTRO= "poky"
> DISTRO_VERSION= "1.8+snapshot-20150812"
> TUNE_FEATURES = "arm armv7a vfp neon cortexa15"
> TARGET_FPU= "vfp-neon"
> meta  = "master:4c3329630e5bf6f2229c6a85052ce71f7cc71703"
> meta-rockchip =
> "contrib/twoerner/emmc-first-
> draft:be45e46f73c5ea7118e4be9511e1ee7652e1ebcf"
> meta-yocto= "master:eefd3580e451a09e7f4696f306d955a4caa1cf88"
> meta-darwin   =
> "contrib/twoerner/fixes:6234b82444b1ebf9bfb0ac8deb5cb582c89cb41d"
> 
> my layers are:
>   openembedded-core/meta
>   meta-rockchip
>   meta-yocto/meta-yocto
>   meta-darwin
> 
> Thoughts?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-darwin][PATCH] osx-runtime: OSX Yosemite v10.10

2015-08-12 Thread Trevor Woerner 
On 08/11/15 17:48, Juro Bystricky wrote:
> Set of patches to allow building against OSX Yosemite v10.10 runtime.

Excellent! My build failed, then I noticed your patches.

Even with this patch applied, however, my build fails with native-libffi
in do_patch. It appears the existing "darwinfix.patch" no longer
applies. I updated the patch so libffi can now do_patch successfully,
but I don't know if it builds since gcc-crosssdk-i386 fails in do_compile.

|
/z/layerindex/firefly/tmp/work/i386-linux/gcc-crosssdk-i386/4.9.3-r0/gcc-4.9.3/build.x86_64-linux.i386-pokysdk-darwin/./gcc/xgcc
-B/z/layerindex/firefly/tmp/work/i386-linux/gcc-crosssdk-i386/4.9.3-r0/gcc-4.9.3/build.x86_64-linux.i386-pokysdk-darwin/./gcc/
-B/z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk-darwin/bin/
-B/z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk-darwin/lib/
-isystem
/z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk-darwin/include
-isystem
/z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk-darwin/sys-include
--sysroot=/z/layerindex/firefly/tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin
  -O2  -g -Os -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -pipe
-fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-dynamiclib -nodefaultlibs -install_name
/z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk-darwin/lib/libgcc_s.1.dylib
-single_module -o ./libgcc_s.dylib -Wl,-exported_symbols_list,libgcc.map
-compatibility_version 1 -current_version 1.0 -g -Os -B./ _muldi3_s.o
_negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o
_ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o
_absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o
_mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o
_ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o
_ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o
_paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o
_powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o
_divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o
_clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o
_fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o
_fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o
_floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o
_fixsfti_s.o _fixdfti_s.o _fixxfti_s.o _fixtfti_s.o _fixunssfti_s.o
_fixunsdfti_s.o _fixunsxfti_s.o _fixunstfti_s.o _floattisf_s.o
_floattidf_s.o _floattixf_s.o _floattitf_s.o _floatuntisf_s.o
_floatuntidf_s.o _floatuntixf_s.o _floatuntitf_s.o _divdi3_s.o
_moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o
darwin-64_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o
divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o
subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o
floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o
extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o
trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o
unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o
libgcc.a -lc
| ld: library not found for -ldylib1.o

It's strange that it says "library not found for -ldylib1.o" because
that library is in my sdk's sysroot:

$ find . -name "*dylib1*" -print
./tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin/usr/lib/dylib1.o
./tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin/usr/lib/dylib1.10.5.o
./tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin/usr/lib/lazydylib1.o


Have you had any success building? The line I'm using to invoke the
build is:

$ SDKMACHINE=i386-darwin bitbake core-image-minimal -c populate_sdk

and the details of my build are:

Build Configuration:
BB_VERSION= "1.27.1"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "openSUSE-project-13.2"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "firefly-emmc-mainline"
DISTRO= "poky"
DISTRO_VERSION= "1.8+snapshot-20150812"
TUNE_FEATURES = "arm armv7a vfp neon cortexa15"
TARGET_FPU= "vfp-neon"
meta  = "master:4c3329630e5bf6f2229c6a85052ce71f7cc71703"
meta-rockchip =
"contrib/twoerner/emmc-first-draft:be45e46f73c5ea7118e4be9511e1ee7652e1ebcf"
meta-yocto= "master:eefd3580e451a09e7f4696f306d955a4caa1cf88"
meta-darwin   =
"contrib/twoerner/fixes:6234b82444b1ebf9bfb0ac8deb5cb582c89cb41d"

my layers are:
openembedded-core/meta
meta-rockchip
meta-yocto/meta-yocto
meta-darwin

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

Re: [yocto] ipk zImage in master-next

2015-08-12 Thread Alejandro del Castillo 


On 08/10/2015 08:49 AM, Trevor Woerner wrote:
> On 08/09/15 06:07, Paul Barker wrote:
>> On Fri, Aug 07, 2015 at 09:19:45AM -0400, Trevor Woerner wrote:
>>> When packaging a zImage kernel for IPK in master-next the following
>>> error shows up:
>>>
>>> | kernel-image-zImage-4.1.2-fslc+g95d9e15
>>> | *** Error: Package name  contains illegal characters, (other than
>>> [a-z0-9.+-])
>>>
>>> It looks like the newer kernel.bbclass is much more sophisticated about
>>> generating package names than before.
>>>
>>> Has anyone else seen this? Is there a simple way of saying "the type is
>>> zimage where packaging for ipk is concerned but zImage otherwise"?
>>>
>>> Best regards,
>>> Trevor
>>
>> I believe this check is present in opkg-build just to ensure compatibility 
>> with
>> the Debian Policy Manual. I don't remember this being an actual restriction 
>> of
>> opkg.
>>
>> You could try patching the opkg-build script (in opkg-utils) to remove this
>> check and see if opkg is happy to install the resulting package.
> 
> Yes, this works. Removing the check from opkg-build causes my build to
> succeed, and the resulting image boots with this kernel (meaning opkg is
> happy to install the package into the image).
> 
> Normally this is the part where I'd ask if you want me to send a patch,
> but if that check is there for a reason, simply removing it isn't a
> proper solution.
> 
> Thoughts?

Looks like the dpkg back-end should be broken too. Sounds to me like the problem
is not on opkg-build but on the new changes to the kernel class, maybe is
missing a call to legitimize_package_name?.

-- 
cheers,

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

Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack

2015-08-12 Thread Andreas Müller 
On Wed, Aug 12, 2015 at 4:59 PM, Javier Martinez Canillas
 wrote:
> Hello,
>
> On 08/10/2015 10:22 AM, Javier Martinez Canillas wrote:
>> Hello Andreas,
>>
>> On 08/10/2015 01:37 AM, Andreas Müller wrote:
 Khem definitely has a very good point. Maybe his way of putting it in 
 words was
 not that productive. But the core idea was definitely right: I don't want 
 rpi
 layer to introduce distro features.
>>> Agreed but I still have issues make the changes work
>>>
>>> What I have done to test:
>>>
>>> 1. add
>>> MASK_GPU_INTERRUPT = "0x400"
>>> DISTRO_FEATURES_append = " vc4-gfx"
>>>
>>> to my local.conf
>>>
>>> 2. put [1] on top of the VC4 patches sent  (this is a WIP patch not
>>> yet finished)
>>> 3. tested running X11
>>>
>
> I tested Andreas' WIP patch under X11 using the core-image-sato image and I
> could reproduce the same behavior. KMS/DRM works when using the modesetting
> Xorg DDX but no GLES with HW acceleration.
>
>>
>> I did only test with Weston since that is what Tizen uses and not with X11.
>> I'll make sure to test with X11 and also include a mesa_%.bbappend for v2.
>>
>>> Question: What setting does the trick getting vc4 driver created by
>>> mesa doing the OpenGL work. I see only swrast which is bulls...
>>>
>>
>> I'm not really a graphics person so I'll let Derek to answer this. He is
>> in fact the author of most of these patches and I'm just working on push
>> them upstream.
>>
>
> Derek is on holidays until next week so I tried to dig on this. When running
> the glmark2-es2 benchmark I get:
>
> $ glmark2-es2
> libEGL warning: DRI2: failed to authenticate
> ** Failed to set swap interval. Results may be bounded above by refresh rate.
> ===
> glmark2 2014.03
> ===
> OpenGL Information
> GL_VENDOR: Mesa Project
> GL_RENDERER:   Software Rasterizer
> GL_VERSION:OpenGL ES 2.0 Mesa 10.5.8
> ===
>
> so as Andreas said, it is using swrast instead of the VC4 hw one. And in fact
> by running strace I see that there is a open("/usr/lib/dri/swrast_dri.so",...)
> but /usr/lib/dri/vc4_dri.so is never opened.
>
> I tried bumping the mesa git recipe to use the same sha1 we are using in our
> Tizen port but ran into build issues...
>
> But I've reworked the patch series according to your suggestions and I can 
> post
> a v2 if you want since at least KMS/DRM is working with Andreas' changes or do
> you want to first sort out the mesa bits for 3D HW accel before posting a v2?
>
FYI: I managed to get the vc4 driver loaded (should be in my repo
branch vc4-2). With this I get some repeating kernel error messages
(don't have them here). I am sure that I read something about these
messages when preparing vc4 (yes I started similar before you sent
patches).

Hope I have some energy left tonight to check further and let you know...

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

Re: [yocto] Selecting a preferred recipe version for devtools

2015-08-12 Thread Khem Raj 
On Wed, Aug 12, 2015 at 6:48 AM, PIEWALD Georg
 wrote:
> PREFERRED_VERSION_subversion = "1.6.15"
>
> in my local.conf, but it turned out that this only affects the builds for
> the target-machine (cortexa8hf-vfp-neon-3.8-oe-linux-gnueabi), but not the
> devtools on the build-machine (x86_64-linux).

you might need to set preferred version for native extension as well.
PREFERRED_VERSION_subversion-native = "1.6.15"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack

2015-08-12 Thread Javier Martinez Canillas 
Hello,

On 08/10/2015 10:22 AM, Javier Martinez Canillas wrote:
> Hello Andreas,
> 
> On 08/10/2015 01:37 AM, Andreas Müller wrote:
>>> Khem definitely has a very good point. Maybe his way of putting it in words 
>>> was
>>> not that productive. But the core idea was definitely right: I don't want 
>>> rpi
>>> layer to introduce distro features.
>> Agreed but I still have issues make the changes work
>>
>> What I have done to test:
>>
>> 1. add
>> MASK_GPU_INTERRUPT = "0x400"
>> DISTRO_FEATURES_append = " vc4-gfx"
>>
>> to my local.conf
>>
>> 2. put [1] on top of the VC4 patches sent  (this is a WIP patch not
>> yet finished)
>> 3. tested running X11
>>

I tested Andreas' WIP patch under X11 using the core-image-sato image and I
could reproduce the same behavior. KMS/DRM works when using the modesetting
Xorg DDX but no GLES with HW acceleration.

> 
> I did only test with Weston since that is what Tizen uses and not with X11.
> I'll make sure to test with X11 and also include a mesa_%.bbappend for v2.
> 
>> Question: What setting does the trick getting vc4 driver created by
>> mesa doing the OpenGL work. I see only swrast which is bulls...
>>
> 
> I'm not really a graphics person so I'll let Derek to answer this. He is
> in fact the author of most of these patches and I'm just working on push
> them upstream.
>

Derek is on holidays until next week so I tried to dig on this. When running
the glmark2-es2 benchmark I get:

$ glmark2-es2
libEGL warning: DRI2: failed to authenticate
** Failed to set swap interval. Results may be bounded above by refresh rate.
===
glmark2 2014.03
===
OpenGL Information
GL_VENDOR: Mesa Project
GL_RENDERER:   Software Rasterizer
GL_VERSION:OpenGL ES 2.0 Mesa 10.5.8
===

so as Andreas said, it is using swrast instead of the VC4 hw one. And in fact
by running strace I see that there is a open("/usr/lib/dri/swrast_dri.so",...)
but /usr/lib/dri/vc4_dri.so is never opened.

I tried bumping the mesa git recipe to use the same sha1 we are using in our
Tizen port but ran into build issues...

But I've reworked the patch series according to your suggestions and I can post
a v2 if you want since at least KMS/DRM is working with Andreas' changes or do
you want to first sort out the mesa bits for 3D HW accel before posting a v2?

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH v1] libpam: use wildcard for version and cleanup

2015-08-12 Thread Shrikant Bobade 
On Tue, Aug 11, 2015 at 7:07 PM, Joe MacDonald 
wrote:

> [Re: [yocto] [meta-selinux][PATCH v1] libpam: use wildcard for version and
> cleanup] On 15.08.11 (Tue 16:39) Shrikant Bobade wrote:
>
> > Hi Philip,
> >
> >
> > On Tue, Aug 11, 2015 at 10:39 AM, Philip Tricca  wrote:
> >
> > Hey Shrikant,
> >
> > On 07/30/2015 02:31 AM, Shrikant Bobade wrote:
> > > This patch provides green build for core-image-selinux
> > > (meta-selinux:master & poky:master) against libpam upgrade from
> 1.1.6 to
> > > 1.2.1,
> > > image boots fine,but I am unable to login at target. I have
> prepared
> > > build for qemuarm, does anyone else facing similar issue? please
> advice.
> > >
> > > Observed the login issue appears even with disabled selinux support
> > > (selinux=0).
> >
> > I just tested this again after Joe merged the commits from the
> backlog.
> > I'm not longer able to reproduce the failed login. Are you still
> having
> > login problems?
> >
> >
> > I also got similar results:
> > With the check on latest bits: the login issue is not reproducible on
> > core-image-selinux(with poky-selinux distro)
> > I can now login properly.
>
> I'm glad to hear that, guys, because I wasn't able to reproduce the
> login problem on my setup and was thinking I needed to spend time in the
> next couple of days hunting down what's polluting my environment that I
> was getting different results than you.  :-)  This is a nice treat.
>
> -J.
>
>
Thanks Joe & Philip,

I just compared my latest setup (login working) with older one(login issue)
observed this patch at poky served the login fix:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-extended/pam/libpam?id=c75cefe8a382a63f625123c156137782db118f64

Thanks!
Shrikant


> >
> >
> > Build Configuration:
> > BB_VERSION= "1.27.1"
> > BUILD_SYS = "x86_64-linux"
> > NATIVELSBSTRING   = "Ubuntu-12.04"
> > TARGET_SYS= "arm-poky-linux-gnueabi"
> > MACHINE   = "qemuarm"
> > DISTRO= "poky-selinux"
> > DISTRO_VERSION= "1.8+snapshot-20150811"
> > TUNE_FEATURES = "arm armv5 thumb dsp"
> > TARGET_FPU= "soft"
> > meta
> > meta-yocto
> > meta-yocto-bsp= "master:a16e0b4014173af46ef80d643bb71055219b0dab"
> > meta-selinux  = "master:684ee9401f33db7c9d5b183988d89c688c9dd0be"
> >
> > Thanks!
> > Shrikant
> >
> >
> >
> >
> > Philip
> >
> > > On Thu, Jul 30, 2015 at 2:55 PM, Shrikant Bobade
> > > mailto:bobadeshrik...@gmail.com>>
> wrote:
> > >
> > > From: Shrikant Bobade  > > >
> > >
> > > use wildcard for version: adopting libpam upgrade from 1.1.6 to
> > 1.2.1,
> > > cleanup older recipe and remove patch
> > sepermit-add-DESTDIR-prefix.patch
> > > since the changes already available with latest source.
> > >
> > > Signed-off-by: Shrikant Bobade  > > >
> > > ---
> > >  .../pam/libpam/sepermit-add-DESTDIR-prefix.patch   |   31
> > > 
> > >  recipes-extended/pam/libpam_%.bbappend |3 ++
> > >  recipes-extended/pam/libpam_1.1.6.bbappend |   10
> ---
> > >  3 files changed, 3 insertions(+), 41 deletions(-)
> > >  delete mode 100644
> > > recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
> > >  create mode 100644 recipes-extended/pam/libpam_%.bbappend
> > >  delete mode 100644 recipes-extended/pam/libpam_1.1.6.bbappend
> > >
> > > diff --git
> > > a/recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
> > > b/recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
> > > deleted file mode 100644
> > > index d48d386..000
> > > ---
> a/recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
> > > +++ /dev/null
> > > @@ -1,31 +0,0 @@
> > > -Subject: [PATCH] libpam: add missing DESTDIR prefix
> > > -
> > > -The DESTDIR prefix is missing, this will cause build failures
> for
> > > -mkdir /var/run/sepermit on the host.
> > > -
> > > -| mkdir -p /var/run/sepermit
> > > -| mkdir: cannot create directory `/var/run/sepermit':
> Permission
> > denied
> > > -
> > > -Upstream-Status: Pending
> > > -
> > > -Signed-off-by: Xin Ouyang  > > >
> > > 
> > > - modules/pam_sepermit/Makefile.am |2 +-
> > > - 1 files changed, 1 insertions(+), 1 deletions(-)
> > > -
> > > -diff --git a/modules/pam_sepermit/Makefile.am
> > > b/modules/pam_sepermit/Makefile.am
> > > -index cfc5594..bc82275 100644
> > >  a/modules/pam_sepermit/Makefile.am
> > > -+++ b/modules/pam_sepermit/Makefile.am
> > > -@@ -35,

[yocto] Selecting a preferred recipe version for devtools

2015-08-12 Thread PIEWALD Georg 
Hi all,

I have two recipes for building Subversion (which I only need as a devtool on 
the build-machine):

$ ls oe-core/meta/recipes-devtools/subversion/*.bb
subversion_1.6.15.bb
subversion_1.7.8.bb

Naturally Yocto uses 1.7.8, which is the newer. However, unfortunately I must 
use 1.6.15 on my build machine. How can I instruct Yocto to use the older 
version?

I tried to put a variable
PREFERRED_VERSION_subversion = "1.6.15"
in my local.conf, but it turned out that this only affects the builds for the 
target-machine (cortexa8hf-vfp-neon-3.8-oe-linux-gnueabi), but not the devtools 
on the build-machine (x86_64-linux).

One apparent solution is to simply remove the subversion_1.7.8.bb file, but I'm 
wondering if there is a better way, and how I can select a preferred version 
specifically for devtools.

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

Re: [yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?

2015-08-12 Thread Joe MacDonald 
[[yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?] On 
15.08.12 (Wed 17:08) wenzong fan wrote:

> Hi All,
> 
> There's a libcap-ng in meta-oe layer, it has been updated to 0.7.7 and the
> one in meta-selinux is 0.7.3.
> 
> How about removing the one in meta-selinux and get this layer depends on
> meta-oe? Any suggestions?

The last time we had this discussion my sense was that most users of
meta-selinux wanted to continue with it only depending on oe-core.
That's my preference as well.

I'm happy to merge an updated version of libcap-ng (or maybe I'll get to
it myself, since I've known about it since Armin removed it from
meta-security, that was the time of the last discussion, I think).

All I'm saying right now is that this isn't a case of accidental
duplication of recipes in multiple layers, it's the result of a
conscious decision.  It's totally worthwhile re-visiting that decision,
though to make sure the reasons are still valid.

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] RFC on choice of tool for patch review

2015-08-12 Thread Alex J Lennon 


On 12/08/2015 10:45, Joshua Lock wrote:
> On Wed, 2015-08-12 at 10:25 +0100, Joshua Lock wrote:
>> On Wed, 2015-08-12 at 10:17 +0100, Alex J Lennon wrote:
>>> We've been having a discussion on a way forward to manage patches 
>>> and
>>> code review and would like to open this up for discussion to agree 
>>> a 
>>> way
>>> forward.
>> There's http://patchwork.openembedded.org/. I'm not sure who 
>> maintains
>> it, nor if anyone uses it, but patches sent to the mailing list end 
>> up
>> there.
>>
>> OOI who are "we" in this context? What benefits would a change bring?
> I managed to miss both the [yocto] and [meta-raspberrypi] tags on this
> mail, apologies for that. I guess that "we" are the meta-raspberrypi
> maintainers.

Yes :)

Andrei (maintainer) was using Gerrit but that went away for reasons
outlined in the preceding email.

Some visibility and control of the review process has been lost as a
result and so it was suggested we kick off a conversation on what
tooling to use to restore that.

> Still, the patchwork instance may be an option? The meta-freescale
> layers appear to be using it.

Many thanks!

Cheers,

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

Re: [yocto] [meta-raspberrypi] RFC on choice of tool for patch review

2015-08-12 Thread Joshua Lock 
On Wed, 2015-08-12 at 10:25 +0100, Joshua Lock wrote:
> On Wed, 2015-08-12 at 10:17 +0100, Alex J Lennon wrote:
> > We've been having a discussion on a way forward to manage patches 
> > and
> > code review and would like to open this up for discussion to agree 
> > a 
> > way
> > forward.
> 
> There's http://patchwork.openembedded.org/. I'm not sure who 
> maintains
> it, nor if anyone uses it, but patches sent to the mailing list end 
> up
> there.
> 
> OOI who are "we" in this context? What benefits would a change bring?

I managed to miss both the [yocto] and [meta-raspberrypi] tags on this
mail, apologies for that. I guess that "we" are the meta-raspberrypi
maintainers.

Still, the patchwork instance may be an option? The meta-freescale
layers appear to be using it.

Cheers,

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

Re: [yocto] [meta-raspberrypi] RFC on choice of tool for patch review

2015-08-12 Thread Joshua Lock 
On Wed, 2015-08-12 at 10:17 +0100, Alex J Lennon wrote:
> We've been having a discussion on a way forward to manage patches and
> code review and would like to open this up for discussion to agree a 
> way
> forward.

There's http://patchwork.openembedded.org/. I'm not sure who maintains
it, nor if anyone uses it, but patches sent to the mailing list end up
there.

OOI who are "we" in this context? What benefits would a change bring?

Cheers,

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

[yocto] [meta-raspberrypi] RFC on choice of tool for patch review

2015-08-12 Thread Alex J Lennon 

We've been having a discussion on a way forward to manage patches and
code review and would like to open this up for discussion to agree a way
forward.

Options appear to be github, gerrit, or bitbucket although there may be
others. This is in addition to continuing to send patches to the mailing
list.

Quote from Andrei,

"We dropped gerrit because at that time google dropped the support for
loging in with their accounts and gerrit didn't support OAUTH. The only
options left were involving me maintaining users / groups / permissions
etc - which obviously didn't have the time for. So, at that time, we
decided to use mailing list as the only way of patches review.

Now, I work with github, bitbucket and gerrit and I definitely, as Alex
said, feel the need of reviewing patches using a tool like these. But I
want to state the fact that, even if we decide using them, we will still
need to send patches to mailing list too - so we can keep the awareness
of this project. In terms of preference, I don't really have one. The
easiest would be github/bitbucket but I can invest some time in
installing gerrit back (as they now have the required support for google
accounts logins). So, I consider this is a community decision and, if a
have to vote, I would go for github."

Quote from Petter,

"About using github and similar, I'm a huge fan of gerrit [...] Gerrit
is really nice for reviewing and working closely together with similar
changesets that are ongoing.."

...

For my five euro-cents, I have used Gerrit a little and GitHub more. I
found Gerrit hard to get to grips with, but have been impressed with
GitHub.

So my own preference would be to use github as the UI and
fork/pull-req/commenting support all seems very accessible and intuitive.

Can others comment?

Thanks,

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

[yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?

2015-08-12 Thread wenzong fan 

Hi All,

There's a libcap-ng in meta-oe layer, it has been updated to 0.7.7 and 
the one in meta-selinux is 0.7.3.


How about removing the one in meta-selinux and get this layer depends on 
meta-oe? Any suggestions?


Thanks
Wenzong

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

Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: support configuration fragments

2015-08-12 Thread Petter Mabäcker 
 

2015-08-12 10:28 skrev Alex J Lennon: 

> On 12/08/2015 09:08,
Petter Mabäcker wrote:
> 
>> 2015-08-11 21:20 skrev Alex J Lennon: 
>>

>>> On 11/08/2015 19:54, Petter Mabäcker wrote: 
>>> 
 2015-08-11
19:04 skrev Alex J Lennon: 
 
> - remove placeholder defconfig
and custom copying logic - use KBUILD_DEFCONFIG for default in-tree
configurations instead - do not replace all Yocto configured settings in
do_configure_prepen see:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474 [1]
Signed-off-by: Alex J Lennon mailto:ajlen...@dynamicdevices.co.uk>
>> ---
recipes-kernel/linux/linux-raspberrypi.inc | 15 ---
recipes-kernel/linux/linux-raspberrypi/defconfig | 1 -
recipes-kernel/linux/linux.inc | 6 +++--- 3 files changed, 7
insertions(+), 15 deletions(-) delete mode 100644
recipes-kernel/linux/linux-raspberrypi/defconfig diff --git
a/recipes-kernel/linux/linux-raspberrypi.inc
b/recipes-kernel/linux/linux-raspberrypi.inc index 7e36408..e38d905
100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,17 +6,14 @@ SECTION =
"kernel" LICENSE = "GPLv2" LIC_FILES_CHKSUM =
"file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" -SRC_URI += " -
file://defconfig - " - COMPATIBLE_MACHINE = "raspberrypi" PV =
"${LINUX_VERSION}+git${SRCREV}" -# NOTE: For now we pull in the default
config from the RPi kernel GIT tree. -KERNEL_DEFCONFIG_raspberrypi ?=
"bcmrpi_defconfig" -KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
+KMACHINE ?= "${MACHINE}" +KCONFIG_MODE = "--alldefconfig"
+KBUILD_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
+KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig" # CMDLINE for
raspberrypi CMDLINE = "dwc_otg.lpm_enable=0 console=ttyAMA0,115200
kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait" @@
-38,10 +35,6 @@ python __anonymous () { d.setVar("DEPENDS", depends) }
-do_kernel_configme_prepend() { - install -m 0644
${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig ||
die "No default configuration for ${MACHINE} / ${KERNEL_DEFCONFIG}
available." -} - do_install_prepend() { install -d ${D}/lib/firmware }
diff --git a/recipes-kernel/linux/linux-raspberrypi/defconfig
b/recipes-kernel/linux/linux-raspberrypi/defconfig deleted file mode
100644 index ecbf32c..000 ---
a/recipes-kernel/linux/linux-raspberrypi/defconfig +++ /dev/null @@ -1
+0,0 @@ -# Dummy file to get through do_kernel_configme. diff --git
a/recipes-kernel/linux/linux.inc b/recipes-kernel/linux/linux.inc index
fae78b7..103512b 100644 --- a/recipes-kernel/linux/linux.inc +++
b/recipes-kernel/linux/linux.inc @@ -33,8 +33,7 @@
kernel_configure_variable() { } do_configure_prepend() { - # Clean
.config - echo "" > ${B}/.config + mv -f ${B}/.config
${B}/.config.patched CONF_SED_SCRIPT="" # oabi / eabi support @@ -109,7
+108,8 @@ do_configure_prepend() { # Keep this the last line # Remove
all modified configs and add the rest to .config - sed -e
"${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config' + sed -e
"${CONF_SED_SCRIPT}" < '${B}/.config.patched' >> '${B}/.config' + rm -f
${B}/.config.patched yes '' | oe_runmake oldconfig } -- 1.9.1
 Nice,
some small comments only. Please write a short summary of the feature
(kernel-yocto: allow in-tree defconfig) but keep the bugzilla as a
reference for further info. Always good to have some background
found
>>> This is seems a significant core change so I wanted to make
sure these individual changes were as easily searchable as possible in
case any problems arise in future. Can you provide an example of what
you are suggesting for the commit msg?
>> Perhaps something like: Start
using the "in-tree defconfig" solution provided in poky[0]. To specify
an "in-tree" defconfig file, edit the recipe that builds your kernel so
that it has the following command form: KBUILD_DEFCONFIG_KMACHINE ?=
defconfig_file You need to append the variable with KMACHINE and then
supply the path to your "in-tree" defconfig file. In order to achieve
this in meta-raspberrypi will need to: - start using
KBUILD_DEFCONFIG_KMACHINE - Remove placeholder defconfig and custom
copying logic. - Avoid replacing all Yocto project configured settings
in do_configure_prepend. For more background regarding this migration
read the bugzilla bug info[1]. [0] -
http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
[2] [1] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474 [1]
>

> Very comprehensive. Many thanks.
> 
 directly in the commit msg
itself. Have you tested it using both poky:master and poky:fido?
>>>
Rpi2 fido 3.18.16 with/without sound patch, 4.1.3 with/without sound
patch. BR, Alex
>> Ok, since there has been some changes (not only the
early DT change) in poky:master it would be good to do the same tests
there. Andrei have to correct me if wrong, but since we have a fido
branch in meta-ras

Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: support configuration fragments

2015-08-12 Thread Alex J Lennon 
On 12/08/2015 09:08, Petter Mabäcker wrote:
> 2015-08-11 21:20 skrev Alex J Lennon:
> 
>> On 11/08/2015 19:54, Petter Mabäcker wrote:
>>> 2015-08-11 19:04 skrev Alex J Lennon:
 - remove placeholder defconfig and custom copying logic - use
 KBUILD_DEFCONFIG for default in-tree configurations instead - do not
 replace all Yocto configured settings in do_configure_prepen see:
 https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474
 Signed-off-by: Alex J Lennon >>> 
 >> ---
 recipes-kernel/linux/linux-raspberrypi.inc | 15 ---
 recipes-kernel/linux/linux-raspberrypi/defconfig | 1 -
 recipes-kernel/linux/linux.inc | 6 +++--- 3 files changed, 7
 insertions(+), 15 deletions(-) delete mode 100644
 recipes-kernel/linux/linux-raspberrypi/defconfig diff --git
 a/recipes-kernel/linux/linux-raspberrypi.inc
 b/recipes-kernel/linux/linux-raspberrypi.inc index 7e36408..e38d905
 100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
 b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,17 +6,14 @@
 SECTION = "kernel" LICENSE = "GPLv2" LIC_FILES_CHKSUM =
 "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" -SRC_URI += "
 \ - file://defconfig \ - " - COMPATIBLE_MACHINE = "raspberrypi" PV =
 "${LINUX_VERSION}+git${SRCREV}" -# NOTE: For now we pull in the
 default config from the RPi kernel GIT tree.
 -KERNEL_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
 -KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig" +KMACHINE ?=
 "${MACHINE}" +KCONFIG_MODE = "--alldefconfig"
 +KBUILD_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
 +KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig" # CMDLINE for
 raspberrypi CMDLINE = "dwc_otg.lpm_enable=0 console=ttyAMA0,115200
 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
 @@ -38,10 +35,6 @@ python __anonymous () { d.setVar("DEPENDS",
 depends) } -do_kernel_configme_prepend() { - install -m 0644
 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig
 || die "No default configuration for ${MACHINE} /
 ${KERNEL_DEFCONFIG} available." -} - do_install_prepend() { install
 -d ${D}/lib/firmware } diff --git
 a/recipes-kernel/linux/linux-raspberrypi/defconfig
 b/recipes-kernel/linux/linux-raspberrypi/defconfig deleted file mode
 100644 index ecbf32c..000 ---
 a/recipes-kernel/linux/linux-raspberrypi/defconfig +++ /dev/null @@
 -1 +0,0 @@ -# Dummy file to get through do_kernel_configme. diff
 --git a/recipes-kernel/linux/linux.inc
 b/recipes-kernel/linux/linux.inc index fae78b7..103512b 100644 ---
 a/recipes-kernel/linux/linux.inc +++
 b/recipes-kernel/linux/linux.inc @@ -33,8 +33,7 @@
 kernel_configure_variable() { } do_configure_prepend() { - # Clean
 .config - echo "" > ${B}/.config + mv -f ${B}/.config
 ${B}/.config.patched CONF_SED_SCRIPT="" # oabi / eabi support @@
 -109,7 +108,8 @@ do_configure_prepend() { # Keep this the last line
 # Remove all modified configs and add the rest to .config - sed -e
 "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config' +
 sed -e "${CONF_SED_SCRIPT}" < '${B}/.config.patched' >>
 '${B}/.config' + rm -f ${B}/.config.patched yes '' | oe_runmake
 oldconfig } -- 1.9.1
>>> Nice, some small comments only. Please write a short summary of the
>>> feature (kernel-yocto: allow in-tree defconfig) but keep the bugzilla
>>> as a reference for further info. Always good to have some background
>>> found
>> This is seems a significant core change so I wanted to make sure these
>> individual changes were as easily searchable as possible in case any
>> problems arise in future. Can you provide an example of what you are
>> suggesting for the commit msg?
> Perhaps something like:
> 
> Start using the "in-tree defconfig" solution provided in poky[0]. To specify 
> an "in-tree" defconfig file, edit the recipe that builds your kernel so that 
> it has the following command form:
> 
>  KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file
> 
> 
> You need to append the variable with KMACHINE and then supply the path to 
> your "in-tree" defconfig file. 
> 
> In order to achieve this in meta-raspberrypi will need to:
> 
> - start using KBUILD_DEFCONFIG_KMACHINE
> - Remove placeholder defconfig and custom copying logic.
> - Avoid replacing all Yocto project configured settings in 
> do_configure_prepend.
> 
> For more background regarding this migration read the bugzilla bug info[1].
> 
> [0] - 
> http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
> [1] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474
> 

Very comprehensive. Many thanks.

>>> directly in the commit msg itself. Have you tested it using both
>>> poky:master and poky:fido?
>> Rpi2 fido 3.1

Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: support configuration fragments

2015-08-12 Thread Petter Mabäcker 
 

2015-08-11 21:20 skrev Alex J Lennon: 

> On 11/08/2015 19:54,
Petter Mabäcker wrote:
> 
>> 2015-08-11 19:04 skrev Alex J Lennon: 
>>

>>> - remove placeholder defconfig and custom copying logic - use
KBUILD_DEFCONFIG for default in-tree configurations instead - do not
replace all Yocto configured settings in do_configure_prepen see:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474 [1]
Signed-off-by: Alex J Lennon mailto:ajlen...@dynamicdevices.co.uk>> ---
recipes-kernel/linux/linux-raspberrypi.inc | 15 ---
recipes-kernel/linux/linux-raspberrypi/defconfig | 1 -
recipes-kernel/linux/linux.inc | 6 +++--- 3 files changed, 7
insertions(+), 15 deletions(-) delete mode 100644
recipes-kernel/linux/linux-raspberrypi/defconfig diff --git
a/recipes-kernel/linux/linux-raspberrypi.inc
b/recipes-kernel/linux/linux-raspberrypi.inc index 7e36408..e38d905
100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,17 +6,14 @@ SECTION =
"kernel" LICENSE = "GPLv2" LIC_FILES_CHKSUM =
"file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" -SRC_URI += " -
file://defconfig - " - COMPATIBLE_MACHINE = "raspberrypi" PV =
"${LINUX_VERSION}+git${SRCREV}" -# NOTE: For now we pull in the default
config from the RPi kernel GIT tree. -KERNEL_DEFCONFIG_raspberrypi ?=
"bcmrpi_defconfig" -KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
+KMACHINE ?= "${MACHINE}" +KCONFIG_MODE = "--alldefconfig"
+KBUILD_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
+KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig" # CMDLINE for
raspberrypi CMDLINE = "dwc_otg.lpm_enable=0 console=ttyAMA0,115200
kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait" @@
-38,10 +35,6 @@ python __anonymous () { d.setVar("DEPENDS", depends) }
-do_kernel_configme_prepend() { - install -m 0644
${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig ||
die "No default configuration for ${MACHINE} / ${KERNEL_DEFCONFIG}
available." -} - do_install_prepend() { install -d ${D}/lib/firmware }
diff --git a/recipes-kernel/linux/linux-raspberrypi/defconfig
b/recipes-kernel/linux/linux-raspberrypi/defconfig deleted file mode
100644 index ecbf32c..000 ---
a/recipes-kernel/linux/linux-raspberrypi/defconfig +++ /dev/null @@ -1
+0,0 @@ -# Dummy file to get through do_kernel_configme. diff --git
a/recipes-kernel/linux/linux.inc b/recipes-kernel/linux/linux.inc index
fae78b7..103512b 100644 --- a/recipes-kernel/linux/linux.inc +++
b/recipes-kernel/linux/linux.inc @@ -33,8 +33,7 @@
kernel_configure_variable() { } do_configure_prepend() { - # Clean
.config - echo "" > ${B}/.config + mv -f ${B}/.config
${B}/.config.patched CONF_SED_SCRIPT="" # oabi / eabi support @@ -109,7
+108,8 @@ do_configure_prepend() { # Keep this the last line # Remove
all modified configs and add the rest to .config - sed -e
"${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config' + sed -e
"${CONF_SED_SCRIPT}" < '${B}/.config.patched' >> '${B}/.config' + rm -f
${B}/.config.patched yes '' | oe_runmake oldconfig } -- 1.9.1
>> Nice,
some small comments only. Please write a short summary of the feature
(kernel-yocto: allow in-tree defconfig) but keep the bugzilla as a
reference for further info. Always good to have some background found
>

> This is seems a significant core change so I wanted to make sure
these
> individual changes were as easily searchable as possible in case
any
> problems arise in future. Can you provide an example of what you
are
> suggesting for the commit msg?

Perhaps something like:

Start
using the "in-tree defconfig" solution provided in poky[0]. To specify
an "in-tree" defconfig file, edit the recipe that builds your kernel so
that it has the following command form:

 KBUILD_DEFCONFIG_KMACHINE ?=
defconfig_file

You need to append the variable with KMACHINE and then
supply the path to your "in-tree" defconfig file. 

In order to achieve
this in meta-raspberrypi will need to:

- start using
KBUILD_DEFCONFIG_KMACHINE
- Remove placeholder defconfig and custom
copying logic.
- Avoid replacing all Yocto project configured settings
in do_configure_prepend.

For more background regarding this migration
read the bugzilla bug info[1].

[0] -
http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
[1]
- https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474

>> directly
in the commit msg itself. Have you tested it using both poky:master and
poky:fido?
> 
> Rpi2 fido 3.18.16 with/without sound patch, 4.1.3
with/without sound patch.
> 
> BR,
> 
> Alex

Ok, since there has been
some changes (not only the early DT change) in poky:master it would be
good to do the same tests there. Andrei have to correct me if wrong, but
since we have a fido branch in meta-raspberrypi that's the branch that
is recommended to use against poky:fido, 'master' is in first place
verified against poky:master (latest and greatest). 

BR Petter


Links:
--
[1]
https://bugzilla.yoctoproject

Re: [yocto] core-image-sato raspberrypi2

2015-08-12 Thread Khem Raj 

> On Jul 21, 2015, at 6:07 PM, Edward Vidal  wrote:
> 
> Hi all,
> In the file poky/meta/recipes-graphics/libepoxy/libepoxy_git.bb
> I tried to add --disable-egl, with no success
> 
> 
> PACKAGECONFIG[x11] = "--enable-glx, --disable-glx, virtual/libx11"
> | checking for EGL... no
> | configure: error: Package requirements (egl) were not met:
> |
> | No package 'egl’ found
> 

Please update to latest on meta-raspberrypi and apply

https://lists.yoctoproject.org/pipermail/yocto/2015-August/026035.html 


if you want you can also apply below patch but is not must

https://lists.yoctoproject.org/pipermail/yocto/2015-August/026074.html 





signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Add custom tools to yocto build environment

2015-08-12 Thread Khem Raj 

> On Jul 22, 2015, at 12:00 AM, Lukas Weiss  wrote:
> 
> Hello yocto friends,
> 
> I have a problem with yocto you could help me with. The Background:
> Iam working on a yocto-linux for a TI OMAP-L138, which is a ARM9+DSP in one 
> package. The Linux on ARM is running fine, and does everything I want. I have 
> implemented a kernel driver to start the DSP-Core from the Linux on the 
> ARM9-Core, but now I need to generate the Firmware for the DSP with the Yocto 
> buid system. Main problem is, that I need a compiler/toolchain from TI to 
> compile the Code for the DSP in the yocto build environment.
> 
> At this point I did not understand how to add tools to the yocto build 
> environment at all. I think there must be a way to add software to my host 
> (build) system for generating code for my target. But I have no idea how to 
> do it. When I write a BB-recipe, the architecture of the resulting files is 
> checked to be from targets type (arm in my case), but host tools are of type 
> x86... (which is totally correct!)
> 
> I think I need a recipe, which downloads the compiler/toolchain for the DSP, 
> extracts and installs it to my yocto build environment, so that I can use it 
> in another recipe that compiles my code to a loadable firmware-image (which 
> is placed to my targets rootfs).
> 
> Do you have any suggestions for me how to do that?

This is a multi machine build case, and in single bitbake invocation we only 
support single arch. But this is not a big issue you can issue two cmds

MACHINE=dsp-machine bitbake blah

and then

MACHINE=arm-machine bitbake blah

I think DSP firmware is another rootfs+kernel  or may be bare metal app, you 
could certainly use OE/Yocto tooling for that however, I think its not trivial 
if you want to build from source and I think there is no support for this DSP 
chip as supported architecture in OE, which means it will require changes in 
OE-Core to support the DSP architecture and then you would either build the 
toolchain internally or you can also hook in a prebuilt toolchain into OE and 
only after that you can start to build
packages for firmware. You can look into git history and see how a new 
architecture is added ( mips64 was one I remember last I did ) you will need 
something like that.

quick method would be to keep building DSP firmware outside OE/yocto 
environment ( as you have been ) then just package the final firmware blob into 
ARM image

> 
> Thanks,
> 
> Lukas
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto