Re: [OE-core] [PATCH] kernel-module-split: Add support for KERNEL_MODULE_AUTOLOAD and KERNEL_MODULE_PROBECONF

2014-06-13 Thread Denys Dmytriyenko 
On Fri, Jun 13, 2014 at 03:02:05PM -0400, Bruce Ashfield wrote:
 On Fri, Jun 13, 2014 at 11:46 AM, Richard Purdie
 richard.pur...@linuxfoundation.org wrote:
  The current module_autoload_* and module_conf_* variables are error
  both ugly and error prone. They aren't registered in the task checksums
  so changes to them aren't reflected in the build. This turns out to
  be near impossible to fix with the current variable format in any
  sensible way :(.
 
  This patch replace module_autoload with the list of variables in
  KERNEL_MODULE_AUTOLOAD which is a much simpler and usable API. An
  error is printed if an old style variable is encountered. It should
  be simple to convert to this.
 
  module_conf_* are harder to deal with since there is data associated
  with it, it isn't simply a flag. We need a list of variables that are set
  in order to be able to correctly handle the task checksum so we add
  KERNEL_MODULE_PROBECONF for this purpose and error if the user hasn't
  added a module to it when they should have.
 
 Looks reasonable to me. In my experience, there aren't a lot of users of
 the module_* variables, so the transition to the new names and semantics
 shouldn't be a big issue.

Right, only BSP/Distro maintainers should care... :)

BTW, how about a documentation patch? :)

-- 
Denys


  [YOCTO #5786]
 
  Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
 
  diff --git a/meta/classes/kernel-module-split.bbclass 
  b/meta/classes/kernel-module-split.bbclass
  index d43f743..e38a6f6 100644
  --- a/meta/classes/kernel-module-split.bbclass
  +++ b/meta/classes/kernel-module-split.bbclass
  @@ -130,8 +130,11 @@ python split_kernel_module_packages () {
 
   # If autoloading is requested, output 
  /etc/modules-load.d/name.conf and append
   # appropriate modprobe commands to the postinst
  +autoloadlist = (d.getVar(KERNEL_MODULE_AUTOLOAD, True) or 
  ).split()
   autoload = d.getVar('module_autoload_%s' % basename, True)
   if autoload:
  +bb.error(KERNEL_MODULE_AUTOLOAD has replaced 
  module_autoload_%s, please replace it! % basename)
  +if basename in autoloadlist:
   name = '%s/etc/modules-load.d/%s.conf' % (dvar, basename)
   f = open(name, 'w')
   for m in autoload.split():
  @@ -144,12 +147,15 @@ python split_kernel_module_packages () {
   d.setVar('pkg_postinst_%s' % pkg, postinst)
 
   # Write out any modconf fragment
  +modconflist = (d.getVar(KERNEL_MODULE_PROBECONF, True) or 
  ).split()
   modconf = d.getVar('module_conf_%s' % basename, True)
  -if modconf:
  +if modconf and basename in modconflist:
   name = '%s/etc/modprobe.d/%s.conf' % (dvar, basename)
   f = open(name, 'w')
   f.write(%s\n % modconf)
   f.close()
  +elif modconf:
  +bb.error(Please ensure module %s is listed in 
  KERNEL_MODULE_PROBECONF since module_conf_%s is set % (basename, basename))
 
   files = d.getVar('FILES_%s' % pkg, True)
   files = %s /etc/modules-load.d/%s.conf /etc/modprobe.d/%s.conf % 
  (files, basename, basename)
  @@ -185,3 +191,5 @@ python split_kernel_module_packages () {
   if len(os.listdir(dir)) == 0:
   os.rmdir(dir)
   }
  +
  +do_package[vardeps] += '${@ .join(map(lambda s: module_conf_ + s, 
  (d.getVar(KERNEL_MODULE_PROBECONF, True) or ).split()))}'
 
 
 
 
 
 -- 
 Thou shalt not follow the NULL pointer, for chaos and madness await
 thee at its end
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] textinfo failure

2014-06-13 Thread Denys Dmytriyenko 
On Fri, Jun 13, 2014 at 11:59:52AM -0600, Gary Thomas wrote:
 On 2014-06-13 10:32, Denys Dmytriyenko wrote:
 Hi,
 
 The recent texinfo change now breaks at least bison-native for me:
 
 | Traceback (most recent call last):
 |   File 
 /OE/tmp-eglibc/sysroots/x86_64-linux/usr/bin/texinfo-dummy-native/makeinfo,
  line 109, in module
 | -E option not yet supported + stub_msg
 | AssertionError: -E option not yet supported
 | This stand-in version of makeinfo is not yet fully capable of emulating 
 the real
 | version from the GNU texinfo suite. If you see this message, file a bug 
 report
 | with details on the recipe that failed.
 |
 | mv: cannot move `.am14993/bison.info' to 
 `.//OE/tmp-eglibc/work/x86_64-linux/bison-native/2.7.1-r0/bison-2.7.1/doc/': 
 No such file or directory
 | make[2]: *** 
 [/OE/tmp-eglibc/work/x86_64-linux/bison-native/2.7.1-r0/bison-2.7.1/doc/bison.info]
  Error 1
 | make[2]: Leaving directory 
 `/OE/tmp-eglibc/work/x86_64-linux/bison-native/2.7.1-r0/build/doc'
 | make[1]: *** [install-recursive] Error 1
 | make[1]: Leaving directory 
 `/OE/tmp-eglibc/work/x86_64-linux/bison-native/2.7.1-r0/build'
 | make: *** [install] Error 2
 | ERROR: oe_runmake failed
 | WARNING: 
 /OE/tmp-eglibc/work/x86_64-linux/bison-native/2.7.1-r0/temp/run.do_install.13309:1
  exit 1 from
 |   exit 1
 | ERROR: Function failed: do_install (log file is located at 
 /OE/tmp-eglibc/work/x86_64-linux/bison-native/2.7.1-r0/temp/log.do_install.13309)
 NOTE: recipe bison-native-2.7.1-r0: task do_install: Failed
 ERROR: Task 770 
 (virtual:native:/home/jenkins/distroless-build/sources/oe-core/meta/recipes-devtools/bison/bison_2.7.1.bb,
  do_install)
 
 
 Odd - I just built it in a clean tree with Poky/Yocto master
 rev 8e0c54cd0e82ffe120f84f495101cd29e6fd06bf.
 
 What did you do to get that 'texinfo-dummy-native' version installed?
 None of my builds end up with makeinfo in sysroots.

That was a very recent change in oe-core (at the time of my failure it was 
about 4 hours old commit):

http://cgit.openembedded.org/openembedded-core/commit/?id=0d8d5a2d44988d32a5c8b995202a12ac106ba93c

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [daisy-backport][PATCH 0/6] Daisy backports

2014-05-22 Thread Denys Dmytriyenko 
On Thu, May 22, 2014 at 03:56:40PM -0300, Otavio Salvador wrote:
 Hello,
 
 (Adding Denys in Cc)
 
 On Thu, May 22, 2014 at 3:47 PM, Saul Wold s...@linux.intel.com wrote:
  On 05/22/2014 11:27 AM, Otavio Salvador wrote:
 
  Hello,
 
  Those are the changes I have in my local backport branch which I run
  on top of 'sgw/daisy' branch.
 
  Chen Qi (2):
 tcf-agent: add systemd support
 gdb: add PACKAGECONFIG for babeltrace
 
  These are already in my branch
 
 Good.
 
  Denys Dmytriyenko (3):
 cryptodev-linux: move to recipes-kernel to be shared with module and
   tests
 cryptodev-linux: create common .inc file to be shared by module and
   tests
 cryptodev-tests: recipe for cryptodev test suite based on OpenSSL
 
  I have pulled these for testing, but we don't normally enable new
  functionality in point releases.  I would like to get a clear justification
  as to why these are needed to be back-ported.
 
  Please provide more details on the cryptodev functionality and why it should
  be backported.
 
 We need those to use crypto support in some SoC as is the case for
 Freescale (in meta-fsl-arm) and TI (in meta-ti). Unfortunately this
 has been sent late in the release but with the drop of ocf-linux it
 makes sense to provide cryptodev in my opinion.
 
 Denys?

Did you miss the 4th patch in the series adding the actual cryptodev-module?

Otherwise I'd support this backport. ocf-linux was dropped before the release, 
but complete cryptodev replacement didn't make in time for the release and was 
added afterwards. The partial cryptodev support was for the header file only 
and assumed that the kernel had been patched with the rest of cryptodev device 
driver...

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] OEDAM: OpenEmbedded Developers (Americas) Meeting

2014-05-07 Thread Denys Dmytriyenko 
The OpenEmbedded Board of Directors would like to thank everyone who was able 
to participate (either in person in Santa Clara or online) in our first OEDAM 
OpenEmbedded Developers (Americas) Meeting on May 2nd and 3rd! The meeting was 
a huge success and a lot of fun!

We would also like to thank Ettus Research/NI for providing the premises, as 
well as Jefro and the Yocto Project for sponsoring the event and providing 
food!

The meeting minutes should be published shortly.

-- 
Denys


On Thu, Feb 20, 2014 at 07:03:24PM -0500, Philip Balister wrote:
 The OpenEmbedded Project is holding a developers meeting May 2-3,
 2014, in Santa Clara, CA. This meeting is immediately after the Embedded
 Linux Conference North America. All active OpenEmbedded and Yocto
 Project developers are invited to attend.
 
 NOTE: this is a development meeting for the project itself, not a
 training session.
 
 May 2-3, 2014
 time TBD
 
 Ettus Research/National Instruments
 4600 Patrick Henry Drive
 Santa Clara, CA 95054 USA
 
 Lunch will be provided on both days.
 
 For more information and to add yourself to the list of attendees, see
 the wiki page at
 http://openembedded.org/wiki/OEDAM
 
 Here are a couple of photos from 2009:
 
 http://www.flickr.com/photos/32615155@N00/sets/72157622653686647/
 
 I'd like to thank Jefro for help with this announcement. Any errors are
 mine though.
 
 Philip, OpenEmbedded eV Chair.
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] meta-toolchain doesn't compile working binaries

2014-05-06 Thread Denys Dmytriyenko 
On Tue, May 06, 2014 at 10:14:45AM +0200, Björn Krombholz wrote:
 Hi,
 
 I'm having trouble building a working toolchain (meta-toolchain) on 
 yocto-1.4 release.
 
 Buildsystem is x86_64, on current Debian Sid.
 
 The problem seems to be with ld-linux[...].so, SDKMACHINE doesn't seem to 
 matter (x86_64 and i686 produce broken binaries).
 
 The effect is, that (almost) every binary in the toolchain segfaults when 
 being run.
 
 
 Example m4:
 (in /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux)
 
 Host ld:
 $ usr/bin/m4 --help
 Segmentation fault
 
 Explicitly using the toolchain ld:
 $ lib/ld-linux-x86-64.so.2 usr/bin/m4 --help
 Usage: usr/bin/m4 [OPTION]... [FILE]...
 [...]
 
 
 Comparing the build with a toolchain created on Jul 30th 2013 (which works 
 fine) I see one major difference:
 
 Old (working) toolchain:
 $ ldd m4
 linux-vdso.so.1 (0x7fffdae0)
 libc.so.6 = 
 /usr/local/oecore-x86_64.old_201307/sysroots/x86_64-angstromsdk-linux/usr/bin/./../../lib/libc.so.6
  (0x7f6a71ed)
 
 /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/lib/ld-linux-x86-64.so.2
  = /lib64/ld-linux-x86-64.so.2 (0x7f6a7228)
 
 
 New (broken) toolchain:
 $ ldd m4
 linux-vdso.so.1 (0x7fff36e0)
 libc.so.6 = 
 /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/./../../lib/libc.so.6
  (0x7f00e786)
 /lib64/ld-linux-x86-64.so.2 (0x7f00e7c1)
 
 
 The internal toolchain (from tmp/build/) is working fine, though the ldd 
 output looks similar to the broken built one:
 
 [...]build/tmp-angstrom_v2013_06-eglibc/sysroots/x86_64-linux/usr/bin$ ldd m4 
 linux-vdso.so.1 (0x7fff9fdc8000)  
   
   
  
 libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f481cda8000) 
   
   
  
 /lib64/ld-linux-x86-64.so.2 (0x7f481d188000)
 
 ATM, on Debian Sid /lib64/ld-linux-x86-64.so.2 is just a link 
 /lib64/ld-linux-x86-64.so.2 - /lib/x86_64-linux-gnu/ld-2.18.so
 
 I'd appreciate if someone could give me a hint on this matter, or a point me 
 in a direction, where the problem might be. As mentioned I already tried 
 changing the SDKMACHINE and a completely clean build folder with no effect.

Do you know that OE toolchain is not relocatable? The above symptoms are very 
similar to when you try to execute toolchain binaries from a different 
location that the toolchain was built for or installed to. There is a script 
called relocate_sdk.py that adjusts binaries and libraries to work in the 
required location - it's called during install of the SDK. See pages 24-27 of 
my last year ELC presentation about more details on how OE SDK works:

http://elinux.org/images/c/c8/ExternalToolchainsInYocto.pdf

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Recipes erroneously marked as commercial?

2014-05-06 Thread Denys Dmytriyenko 
So, long time ago we had a short list of commercial packages in a global 
variable COMMERCIAL_LICENSE:

COMMERCIAL_LICENSE ?= lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp

Then, at some point, the packages that depend on commercial ones were added to 
the list, to allow wold builds to be successful:

http://cgit.openembedded.org/openembedded-core/commit/?id=c69453fe94a649c518b0e6d79616f05579b864ce

So, the list was appended with this:

COMMERCIAL_LICENSE_DEPENDEES ?= gst-plugins-ugly libomxil gst-openmax

Then, later on, the feature was changed from a global list to a per-recipe 
flags:

http://cgit.openembedded.org/openembedded-core/commit/?id=a2760661b8c7a4a1b6f2e556853b3a9ae38cbcb5
http://cgit.openembedded.org/openembedded-core/commit/?id=43410523a07d9eb52a7d57ae3dc1cc320cbbc6f9

And all those recipes got marked with LICENSE_FLAGS = commercial 
automatically, even if they are not really commercial.

The question is - should we clean those up now? I can send a quick patch, if 
my understanding above is correct.

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] meta-toolchain doesn't compile working binaries

2014-05-06 Thread Denys Dmytriyenko 
On Tue, May 06, 2014 at 04:25:15PM -0500, Mark Hatle wrote:
 On 5/6/14, 3:56 PM, Khem Raj wrote:
 On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko de...@denix.org wrote:
 Do you know that OE toolchain is not relocatable?
 
 is that true ?
 
 
 It's the load path of the executables, they use the libc-nativesdk,
 so they need a hard path to the correct ld.so to get started.

More specifically, it's PT_INTERP section of the ELF header in every binary 
that hardcodes the full path to our own dynamic linker/loader (i.e. mentioned 
libc-nativesdk). I wish it would support the use of $ORIGIN similar to RPATH 
and RUNPATH for libraries, but I bet there are all kinds of corner cases with 
that... :)

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] meta-toolchain doesn't compile working binaries

2014-05-06 Thread Denys Dmytriyenko 
On Tue, May 06, 2014 at 04:44:08PM -0500, Mark Hatle wrote:
 On 5/6/14, 4:40 PM, Khem Raj wrote:
 
 On May 6, 2014 2:25 PM, Mark Hatle mark.ha...@windriver.com
 mailto:mark.ha...@windriver.com wrote:
  
   On 5/6/14, 3:56 PM, Khem Raj wrote:
  
   On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko de...@denix.org
 mailto:de...@denix.org wrote:
  
   Do you know that OE toolchain is not relocatable?
  
  
   is that true ?
  
  
   It's the load path of the executables, they use the libc-nativesdk, so 
   they
 need a hard path to the correct ld.so to get started.
 
 isnt this fixed by the installer when it is run
 
 Yes, it sounds like either he moved the files after the the
 installer ran, or didn't use the installer at all and just tried to
 execute them out of the build system.

Exactly what I said earlier about using relocate_sdk.py in the installer, 
which Khem conveniently ignored and removed when replying... :) Just kidding.


 (If the installer -was- used, then it's definitely a bug.)

There's no bug as far as I know, as SDK/toolchain is a major part of our 
product and we test it actively with every release.

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] meta-toolchain doesn't compile working binaries

2014-05-06 Thread Denys Dmytriyenko 
On Tue, May 06, 2014 at 01:56:57PM -0700, Khem Raj wrote:
 On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko de...@denix.org wrote:
  Do you know that OE toolchain is not relocatable?
 
 is that true ?

Is not auto-relocatable - is it better?

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] meta-toolchain doesn't compile working binaries

2014-05-06 Thread Denys Dmytriyenko 
On Tue, May 06, 2014 at 04:49:09PM -0500, Mark Hatle wrote:
 On 5/6/14, 4:44 PM, Denys Dmytriyenko wrote:
 On Tue, May 06, 2014 at 04:25:15PM -0500, Mark Hatle wrote:
 On 5/6/14, 3:56 PM, Khem Raj wrote:
 On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko de...@denix.org wrote:
 Do you know that OE toolchain is not relocatable?
 
 is that true ?
 
 
 It's the load path of the executables, they use the libc-nativesdk,
 so they need a hard path to the correct ld.so to get started.
 
 More specifically, it's PT_INTERP section of the ELF header in every binary
 that hardcodes the full path to our own dynamic linker/loader (i.e. mentioned
 libc-nativesdk). I wish it would support the use of $ORIGIN similar to RPATH
 and RUNPATH for libraries, but I bet there are all kinds of corner cases with
 that... :)
 
 
 $ORIGIN, RPATH and RUNPATH are all implemented by the ld.so, there
 is no way to dynamically assign the interpreter (ld.so).

Yes, the above wish was highly abstract and hypothetical and would probably 
require kernel to support $ORIGIN used in the ELF header... But I'm not 
suggesting it, just speculating! :)

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/5] WIP: feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix

2014-04-25 Thread Denys Dmytriyenko 
On Fri, Apr 25, 2014 at 06:04:34PM +0100, Richard Purdie wrote:
 On Fri, 2014-04-25 at 18:40 +0200, Martin Jansa wrote:
  * this means that recipes with ARM_INSTRUCTION_SET explicitly changed
to arm will be built in feed without thumb suffix
  * It looks like the rest of system doesn't correctly support different
TUNE_PKGARCHs for different recipes (e.g. eglibc-initial fails)
so this needs a bit more work
  
config.log:
configure:2768: arm-oe-linux-gnueabi-gcc  -march=armv5e -marm 
  -mthumb-interwork --sysroot=/OE/build/oe-core/tmp-eglibc/sysroots/qemuarm 
  -c  -O2 -pipe -g -feliminate-unused-debug-types  conftest.c 5

  /OE/build/oe-core/tmp-eglibc/work/armv5e-oe-linux-gnueabi/eglibc-initial/2.18-r0/eglibc-2.18/libc/configure:
   line 2770: arm-oe-linux-gnueabi-gcc: command not found
configure:2772: $? = 127
  
and the problem is basically that STAGING_BINDIR_TOOLCHAIN points to
different directory when building recipe with thumb enabled and
disabled, in this case gcc was built with thumb enabled and is installed
in:
  
sysroots/x86_64-linux/usr/bin/armv5te-oe-linux-gnueabi
  
OE qemuarm@ ~/build/oe-core $ ls 
  /OE/build/oe-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/armv5te-oe-linux-gnueabi
arm-oe-linux-gnueabi-addr2line  arm-oe-linux-gnueabi-elfedit
arm-oe-linux-gnueabi-nm   arm-oe-linux-gnueabi-readelf
arm-oe-linux-gnueabi-ar arm-oe-linux-gnueabi-gprof
arm-oe-linux-gnueabi-objcopy  arm-oe-linux-gnueabi-size
arm-oe-linux-gnueabi-as arm-oe-linux-gnueabi-ld
arm-oe-linux-gnueabi-objdump  arm-oe-linux-gnueabi-strings
arm-oe-linux-gnueabi-c++filtarm-oe-linux-gnueabi-ld.bfd
arm-oe-linux-gnueabi-ranlib   arm-oe-linux-gnueabi-strip
  
but when building eglibc-initial with thumb disalbed, TUNE_PKGARCH
becames armv5e and STAGING_BINDIR_TOOLCHAIN in PATH points to wrong dir:
  
$STAGING_BINDIR_TOOLCHAIN
  set conf/bitbake.conf:354
   
  ${STAGING_DIR_NATIVE}${bindir_native}/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}

  STAGING_BINDIR_TOOLCHAIN=/OE/build/oe-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/armv5e-oe-linux-gnueabi
  
OE qemuarm@ ~/build/oe-core $ ls 
  /OE/build/oe-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/armv5e-oe-linux-gnueabi
ls: cannot access 
  /OE/build/oe-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/armv5e-oe-linux-gnueabi:
   No such file or directory
  
  Signed-off-by: Martin Jansa martin.ja...@gmail.com
  ---
   meta/conf/machine/include/arm/feature-arm-thumb.inc | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
 
 You might find my WIP gcc changes happen to fix some of the issues
 you're running into here since there is one compiler for all of arm
 regardless of tune.
 
 Half of this merged to master, the other half is roughly what is on the
 top of:
 
 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/t222
 
 although this is still WIP too.

Heh, and I was also looking into STAGING_BINDIR_TOOLCHAIN and TUNE_PKGARCH 
issues lately, although for slightly different reason. I'll be sure to check 
your WIP fixes soon...


  diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc 
  b/meta/conf/machine/include/arm/feature-arm-thumb.inc
  index 8a38665..6c5d1d6 100644
  --- a/meta/conf/machine/include/arm/feature-arm-thumb.inc
  +++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
  @@ -28,7 +28,8 @@ python () {
   TUNE_CCARGS .= ${@bb.utils.contains('TUNE_FEATURES', 'thumb', ' 
  -m${ARM_M_OPT}', '', d)}
   OVERRIDES .= ${@bb.utils.contains('TUNE_FEATURES', 'thumb', ':thumb', '', 
  d)}
   
  -ARMPKGSFX_THUMB .= ${ARM_THUMB_SUFFIX}
  +# Add suffix from ARM_THUMB_SUFFIX only if after all this we still set 
  ARM_M_OPT to thumb
  +ARMPKGSFX_THUMB .= ${@ d.getVar('ARM_THUMB_SUFFIX', True) if 
  d.getVar('ARM_M_OPT', True) == 'thumb' else ''}
   
   # Whether to compile with code to allow interworking between the two
   # instruction sets. This allows thumb code to be executed on a primarily
  -- 
  1.9.1
  
 
 
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] udev: Update touchscreen rule for ID_INPUT_TOUCHSCREEN

2014-04-24 Thread Denys Dmytriyenko 
On Thu, Apr 24, 2014 at 09:56:20AM +0100, Paul Eggleton wrote:
 On Wednesday 23 April 2014 19:41:56 Denys Dmytriyenko wrote:
  On Thu, Oct 31, 2013 at 07:27:30AM -0400, Tom Rini wrote:
   On Tue, Oct 22, 2013 at 12:37:10PM -0400, Tom Rini wrote:
Since udev 174 udev has been running input_id as a built-in command and
setting this value in the environment for touchscreens.  Use this logic
to detect when to make a touchscreen0 symlink.

Signed-off-by: Tom Rini tr...@ti.com
---

 meta/recipes-core/udev/udev/local.rules |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/udev/udev/local.rules
b/meta/recipes-core/udev/udev/local.rules index 72d92ef..d0b0216 100644
--- a/meta/recipes-core/udev/udev/local.rules
+++ b/meta/recipes-core/udev/udev/local.rules
@@ -17,5 +17,5 @@

 ACTION==add, DEVPATH==/devices/*, ENV{MODALIAS}==?*,
 RUN+=/sbin/modprobe $env{MODALIAS}
 
 # Create a symlink to any touchscreen input device

-SUBSYSTEM==input, KERNEL==event[0-9]*,
ATTRS{modalias}==input:*-e0*,3,*a0,1,*18,*,
SYMLINK+=input/touchscreen0 +SUBSYSTEM==input,
KERNEL==event[0-9]*, ENV{ID_INPUT_TOUCHSCREEN}==1,
SYMLINK+=input/touchscreen0 
   Ping
  
  Was it ever reviewed? Ping^2
 
 Sorry, what do you mean? It was reviewed and merged:
 
 http://cgit.openembedded.org/openembedded-core/commit/?id=5abcfcd4380aacafc45d776f557738fb18089113

Oops, I guess I looked in Dora and it was merged after the release. Sorry for 
the noise.

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] udev: Update touchscreen rule for ID_INPUT_TOUCHSCREEN

2014-04-23 Thread Denys Dmytriyenko 
On Thu, Oct 31, 2013 at 07:27:30AM -0400, Tom Rini wrote:
 On Tue, Oct 22, 2013 at 12:37:10PM -0400, Tom Rini wrote:
 
  Since udev 174 udev has been running input_id as a built-in command and
  setting this value in the environment for touchscreens.  Use this logic
  to detect when to make a touchscreen0 symlink.
  
  Signed-off-by: Tom Rini tr...@ti.com
  ---
   meta/recipes-core/udev/udev/local.rules |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/meta/recipes-core/udev/udev/local.rules 
  b/meta/recipes-core/udev/udev/local.rules
  index 72d92ef..d0b0216 100644
  --- a/meta/recipes-core/udev/udev/local.rules
  +++ b/meta/recipes-core/udev/udev/local.rules
  @@ -17,5 +17,5 @@
   ACTION==add, DEVPATH==/devices/*, ENV{MODALIAS}==?*, 
  RUN+=/sbin/modprobe $env{MODALIAS}
   
   # Create a symlink to any touchscreen input device
  -SUBSYSTEM==input, KERNEL==event[0-9]*, 
  ATTRS{modalias}==input:*-e0*,3,*a0,1,*18,*, SYMLINK+=input/touchscreen0
  +SUBSYSTEM==input, KERNEL==event[0-9]*, ENV{ID_INPUT_TOUCHSCREEN}==1, 
  SYMLINK+=input/touchscreen0
 
 Ping

Was it ever reviewed? Ping^2

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 3/4] cryptodev-module: recipe for out-of-tree cryptodev device driver

2014-04-21 Thread Denys Dmytriyenko 
ping. Is master-next open for new changes?

On Thu, Apr 10, 2014 at 01:55:27PM -0400, Denys Dmytriyenko wrote:
 From: Denys Dmytriyenko de...@ti.com
 
 Depends on cryptodev-linux for providing a header file
 
 Signed-off-by: Denys Dmytriyenko de...@ti.com
 ---
 v2 - add patch to fix INIT_COMPLETION rename in 3.13+ kernels
 
  .../cryptodev/cryptodev-module_1.6.bb  | 18 +
  ...talling-header-file-provided-by-another-p.patch | 28 +++
  ...-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch | 86 
 ++
  3 files changed, 132 insertions(+)
  create mode 100644 meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb
  create mode 100644 
 meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
  create mode 100644 
 meta/recipes-kernel/cryptodev/files/0002-In-the-3.13-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch
 
 diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb 
 b/meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb
 new file mode 100644
 index 000..df50e5a
 --- /dev/null
 +++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb
 @@ -0,0 +1,18 @@
 +require cryptodev_${PV}.inc
 +
 +SUMMARY = A /dev/crypto device driver kernel module
 +
 +inherit module
 +
 +# Header file provided by a separate package
 +DEPENDS += cryptodev-linux
 +
 +SRC_URI +=  \
 +file://0001-Disable-installing-header-file-provided-by-another-p.patch \
 +file://0002-In-the-3.13-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch \
 +
 +
 +EXTRA_OEMAKE='KERNEL_DIR=${STAGING_KERNEL_DIR} PREFIX=${D}'
 +
 +RCONFLICTS_${PN} = ocf-linux
 +RREPLACES_${PN} = ocf-linux
 diff --git 
 a/meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
  
 b/meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
 new file mode 100644
 index 000..a580fc6
 --- /dev/null
 +++ 
 b/meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
 @@ -0,0 +1,28 @@
 +From 8a884f55bd1527baa82fab68c186ba546273860c Mon Sep 17 00:00:00 2001
 +From: Denys Dmytriyenko de...@ti.com
 +Date: Sun, 6 Apr 2014 19:51:39 -0400
 +Subject: [PATCH] Disable installing header file provided by another package
 +
 +Signed-off-by: Denys Dmytriyenko de...@ti.com
 +
 +Upstream-Status: Inappropriate [ OE specific ]
 +---
 + Makefile | 2 --
 + 1 file changed, 2 deletions(-)
 +
 +diff --git a/Makefile b/Makefile
 +index d66ef26..8e97c6a 100644
 +--- a/Makefile
  b/Makefile
 +@@ -23,8 +23,6 @@ install: modules_install
 + 
 + modules_install:
 + make -C $(KERNEL_DIR) SUBDIRS=`pwd` modules_install
 +-@echo Installing cryptodev.h in $(PREFIX)/usr/include/crypto ...
 +-@install -D crypto/cryptodev.h $(PREFIX)/usr/include/crypto/cryptodev.h
 + 
 + clean:
 + make -C $(KERNEL_DIR) SUBDIRS=`pwd` clean
 +-- 
 +1.9.1
 +
 diff --git 
 a/meta/recipes-kernel/cryptodev/files/0002-In-the-3.13-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch
  
 b/meta/recipes-kernel/cryptodev/files/0002-In-the-3.13-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch
 new file mode 100644
 index 000..c5c7ec7
 --- /dev/null
 +++ 
 b/meta/recipes-kernel/cryptodev/files/0002-In-the-3.13-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch
 @@ -0,0 +1,86 @@
 +From 57b5544de80db85c8955499831fdaa30829db77a Mon Sep 17 00:00:00 2001
 +From: Cosmin Paraschiv cosmin.parasc...@freescale.com
 +Date: Thu, 23 Jan 2014 03:40:00 +0100
 +Subject: [PATCH] In the 3.13-rc1 Linux kernel, the INIT_COMPLETION macro has
 + been replaced with an inline function, reinit_completion [1][2]. We are
 + currently using the 3.13-rc3 Linux kernel, which leads to the following
 + error:
 +
 +cryptlib.c:279:2: error: implicit declaration of function 'INIT_COMPLETION' 
 [-Werror=implicit-function-declaration]
 +  INIT_COMPLETION(cdata-async.result-completion);
 +
 +[1] 
 https://github.com/torvalds/linux/commit/c32f74ab2872994bc8336ed367313da3139350ca
 +[2] 
 https://github.com/torvalds/linux/commit/62026aedaacedbe1ffe94a3599ad4acd8ecdf587
 +
 +Signed-off-by: Cosmin Paraschiv cosmin.parasc...@freescale.com
 +Reviewed-by: Cristian Stoica cristian.sto...@freescale.com
 +Tested-by: Cristian Stoica cristian.sto...@freescale.com
 +Signed-off-by: Horia Geanta horia.gea...@freescale.com
 +Signed-off-by: Phil Sutter p...@nwl.cc
 +
 +Upstream-Status: Backport
 +---
 + cryptlib.c  | 8 
 + cryptodev_int.h | 6 ++
 + 2 files changed, 10 insertions(+), 4 deletions(-)
 +
 +diff --git a/cryptlib.c b/cryptlib.c
 +index 54d5d41..a923c14 100644
 +--- a/cryptlib.c
  b/cryptlib.c
 +@@ -217,7 +217,7 @@ ssize_t cryptodev_cipher_encrypt(struct cipher_data 
 *cdata,
 + {
 + int ret;
 + 
 +-INIT_COMPLETION(cdata-async.result-completion);
 ++reinit_completion(cdata-async.result-completion);
 + 
 + if (cdata-aead == 0) {
 + ablkcipher_request_set_crypt(cdata-async.request,
 +@@ -240,7 +240,7 @@ ssize_t

Re: [OE-core] [PATCH v2] udev-extraconf: update mount.sh to use /run/media instead of /media

2014-04-21 Thread Denys Dmytriyenko 
On Mon, Apr 07, 2014 at 11:22:11PM +0100, Richard Purdie wrote:
 On Mon, 2014-04-07 at 17:05 -0400, Denys Dmytriyenko wrote:
  I understand the timing concern and am fine waiting another week for when 
  1.7 
  window opens.
  
  But I'm slightly confused as to since when OE-Core is concerned about 
  breaking 
  bbappends in other layers? I guess some layers are not created equal, eh? :)
 
 The question is more one of timing. I don't think its reasonable that we
 break things like that between -rc2 and -rc3 of 1.6 without a better
 reason...
 
 I'm even nervous changing the sstate checksums but I think the CONFFILES
 change does warrant that for example.

Is 1.7 window now open? Should I resubmit this patch again? Thanks.

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] u-boot: fix beaglebone boot issue with large kernel images

2014-04-17 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Fix beaglebone boot issue with large kernel images overwriting Device Tree.
See very detailed comments inside the patch.

The original patch is being reviewed upstream and is targeting mainline U-boot
version 2014.07. This is the adaptation of the patch for 2013.07 version we use

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 ...h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch | 74 ++
 meta/recipes-bsp/u-boot/u-boot_2013.07.bb  |  4 +-
 2 files changed, 77 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch

diff --git 
a/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
 
b/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
new file mode 100644
index 000..77e35bb
--- /dev/null
+++ 
b/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
@@ -0,0 +1,74 @@
+From 5701384cea4a829b772bf7a96a74825b58c22385 Mon Sep 17 00:00:00 2001
+From: Denys Dmytriyenko de...@ti.com
+Date: Thu, 17 Apr 2014 12:25:40 -0400
+Subject: [PATCH] am335x_evm.h: Add, use DEFAULT_LINUX_BOOT_ENV environment
+ string
+
+Modified version of the patch currently being reviewed for mainline:
+http://patchwork.ozlabs.org/patch/334861/
+
+To deal with a reoccurring problem properly we need to specify addresses
+for the Linux kernel, Flatted Device Tree and ramdisk that obey the
+constraints within the kernel's Documentation/arm/Booting file but also
+make sure that we relocate things within a valid address range.
+
+Signed-off-by: Denys Dmytriyenko de...@ti.com
+Signed-off-by: Tom Rini tr...@ti.com
+
+Upstream-Status: Pending
+---
+ include/configs/am335x_evm.h | 31 ++-
+ 1 file changed, 26 insertions(+), 5 deletions(-)
+
+diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
+index c5a6d4b..01e32b3 100644
+--- a/include/configs/am335x_evm.h
 b/include/configs/am335x_evm.h
+@@ -54,10 +54,7 @@
+ #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ #ifndef CONFIG_SPL_BUILD
+ #define CONFIG_EXTRA_ENV_SETTINGS \
+-  loadaddr=0x8020\0 \
+-  fdtaddr=0x80F8\0 \
+-  fdt_high=0x\0 \
+-  rdaddr=0x8100\0 \
++  DEFAULT_LINUX_BOOT_ENV \
+   bootdir=/boot\0 \
+   bootfile=uImage\0 \
+   fdtfile=undefined\0 \
+@@ -197,7 +194,31 @@
+ #define CONFIG_SYS_MEMTEST_END(CONFIG_SYS_MEMTEST_START \
+   + (8 * 1024 * 1024))
+ 
+-#define CONFIG_SYS_LOAD_ADDR  0x8100 /* Default load address */
++/*
++ * Our DDR memory always starts at 0x8000 and U-Boot shall have
++ * relocated itself to higher in memory by the time this value is used.
++ * However, set this to a 32MB offset to allow for easier Linux kernel
++ * booting as the default is often used as the kernel load address.
++ */
++#define CONFIG_SYS_LOAD_ADDR  0x8200 /* Default load address */
++
++/*
++ * We setup defaults based on constraints from the Linux kernel, which should
++ * also be safe elsewhere.  We have the default load at 32MB into DDR (for
++ * the kernel), FDT above 128MB (the maximum location for the end of the
++ * kernel), and the ramdisk 512KB above that (allowing for hopefully never
++ * seen large trees).  We say all of this must be within the first 256MB
++ * as that will normally be within the kernel lowmem and thus visible via
++ * bootm_size and we only run on platforms with 256MB or more of memory.
++ */
++#define DEFAULT_LINUX_BOOT_ENV \
++  loadaddr=0x8200\0 \
++  kernel_addr_r=0x8200\0 \
++  fdtaddr=0x8800\0 \
++  fdt_addr_r=0x8800\0 \
++  rdaddr=0x8808\0 \
++  ramdisk_addr_r=0x8808\0 \
++  bootm_size=0x1000\0
+ 
+ #define CONFIG_MMC
+ #define CONFIG_GENERIC_MMC
+-- 
+1.9.2
+
diff --git a/meta/recipes-bsp/u-boot/u-boot_2013.07.bb 
b/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
index 3141a2d..f8a8856 100644
--- a/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
@@ -16,7 +16,9 @@ SRCREV = 62c175fbb8a0f9a926c88294ea9f7e88eb898f6c
 
 PV = v2013.07+git${SRCPV}
 
-SRC_URI = git://git.denx.de/u-boot.git;branch=master
+SRC_URI = git://git.denx.de/u-boot.git;branch=master \
+   
file://0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch \
+
 
 S = ${WORKDIR}/git
 
-- 
1.9.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/6] linux-yocto/3.14: beagleboard black: USB, DRM config tweaks

2014-04-10 Thread Denys Dmytriyenko 
Thanks, Bruce!

The subject says beagleboard but should be beaglebone...


On Thu, Apr 10, 2014 at 11:12:35AM -0400, Bruce Ashfield wrote:
 Importing the meta SRCREV to pick up the following two fixes:
 
   928d7b2ddad0 beaglebone: enhance USB support and enable MUSB modules
   fbe38387ac61 beaglebone: enable DRM for HDMI output
 
 Signed-off-by: Denys Dmytriyenko de...@ti.com
 Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
 ---
  meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 2 +-
  meta/recipes-kernel/linux/linux-yocto_3.14.bb  | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb 
 b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
 index 2a1e20429d8a..a441a53fb95b 100644
 --- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
 +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
 @@ -9,7 +9,7 @@ LINUX_VERSION ?= 3.14
  KMETA = meta
  
  SRCREV_machine ?= 0143c6ebb4a2d63b241df5f608b19f483f7eb9e0
 -SRCREV_meta ?= 8f55bee2403176a50cc0dd41811aa60fcf07243c
 +SRCREV_meta ?= 928d7b2ddad0abc8827055c51ba34225878344a0
  
  PV = ${LINUX_VERSION}+git${SRCPV}
  
 diff --git a/meta/recipes-kernel/linux/linux-yocto_3.14.bb 
 b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
 index b275f2738d8b..7f0ec2b559a3 100644
 --- a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
 +++ b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
 @@ -17,7 +17,7 @@ SRCREV_machine_qemux86 ?= 
 0143c6ebb4a2d63b241df5f608b19f483f7eb9e0
  SRCREV_machine_qemux86-64 ?= 0143c6ebb4a2d63b241df5f608b19f483f7eb9e0
  SRCREV_machine_qemumips64 ?= ccb2a788551a7951563ac44a27175c6f28501008
  SRCREV_machine ?= 0143c6ebb4a2d63b241df5f608b19f483f7eb9e0
 -SRCREV_meta ?= 8f55bee2403176a50cc0dd41811aa60fcf07243c
 +SRCREV_meta ?= 928d7b2ddad0abc8827055c51ba34225878344a0
  
  SRC_URI = 
 git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta
  
 -- 
 1.8.1.2
 
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] export TARGET_LDFLAGS and native sstate

2014-04-10 Thread Denys Dmytriyenko 
On Thu, Apr 10, 2014 at 10:36:07AM -0700, Chris Larson wrote:
 On Thu, Apr 10, 2014 at 9:15 AM, Mike Crowe m...@mcrowe.com wrote:
 
  On Monday 07 April 2014 at 17:49:51 +0100, Mike Crowe wrote:
   On Monday 07 April 2014 at 09:17:38 -0700, Chris Larson wrote:
On Mon, Apr 7, 2014 at 8:53 AM, Mike Crowe m...@mcrowe.com wrote:
   
 We're building for both ARM and MIPS-based MACHINEs in a single
  source
 tree. This seems to result in us compiling (or luckily most of the
  time
 resurrecting from sstate-cache) two different versions of all -native
 packages due to different base hashes.

 It seems that this difference in base hashes is due to the exported
 variable TARGET_LDFLAGS being different between the two CPUs:

  export TARGET_LDFLAGS=-Wl,-O1  -Wl,--as-needed
 ---
  export TARGET_LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu
  -Wl,--as-needed

   
Heh, this i another case of a likely completely unnecessary export.
Software we build expects LDFLAGS to be used, not TARGET_LDFLAGS, so I
can't imagine that anything is using this export. Of course, it's
non-trivial to confirm that this is the case :)
 
  My git archaeology shows that this dates from the very first import from
  svn back in 2005. Back then it looks like it was necessary for
  wpa_supplicant which used it in its defconfig file. This is no longer the
  case.
 
  I didn't look at any other layers.
 
   It did strike me as an odd thing to be exporting. Given the name I
  assumed
   it had something to do with building the toolchain. I notice though that
   the gcc recipes explicitly export LDFLAGS_FOR_TARGET inside tasks based
  on
   TARGET_LDFLAGS anyway so the toolchain should be fine. :)
  
   I'm happy to try our complete build without exporting TARGET_LDFLAGS as a
   first step but I realise that probably wouldn't be enough proof.
 
  I've tested our build without the export in front of TARGET_LDFLAGS in
  bitbake.conf and saw no problems at all so I'm in favour of doing that.
 
  Would a patch for this be acceptable? It does cause the world to be
  rebuilt. :(
 
 
 I'm a fan of this, personally, but you'll likely need to check with folks
 like Richard Purdie for a final call, and this particular fix would have to
 go in post-1.6, into the 1.7 timeframe (1.6 isn't branched yet) since we're

^^^ looks like it just got branched off less than an hour ago...


 in the release candidate phase, and this has inherent risk. So, it might be
 worth pursuing the merge of the workaround with alters TARGET_LDFLAGS in
 native.bbclass to improve sstate reuse for 1.6, then pursue the unexport of
 TARGET_LDFLAGS for 1.7.
 -- 
 Christopher Larson
 clarson at kergoth dot com
 Founder - BitBake, OpenEmbedded, OpenZaurus
 Maintainer - Tslib
 Senior Software Engineer, Mentor Graphics

 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/4] cryptodev-linux: create common .inc file to be shared by module and tests

2014-04-10 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb | 11 ++-
 meta/recipes-kernel/cryptodev/cryptodev_1.6.inc  | 11 +++
 2 files changed, 13 insertions(+), 9 deletions(-)
 create mode 100644 meta/recipes-kernel/cryptodev/cryptodev_1.6.inc

diff --git a/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb
index 320716d..43f58f3 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb
+++ b/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb
@@ -1,13 +1,6 @@
-SUMMARY = A /dev/crypto device driver
-HOMEPAGE = http://cryptodev-linux.org/;
+require cryptodev_${PV}.inc
 
-LICENSE = GPLv2
-LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263
-
-SRC_URI = http://download.gna.org/cryptodev-linux/${BPN}-${PV}.tar.gz;
-
-SRC_URI[md5sum] = eade38998313c25fd7934719cdf8a2ea
-SRC_URI[sha256sum] = 
75f1425c8ea1f8cae523905a5a046a35092327a6152800b0b86efc4e56fb3e2f
+SUMMARY = A /dev/crypto device driver header file
 
 do_compile() {
:
diff --git a/meta/recipes-kernel/cryptodev/cryptodev_1.6.inc 
b/meta/recipes-kernel/cryptodev/cryptodev_1.6.inc
new file mode 100644
index 000..946faac
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/cryptodev_1.6.inc
@@ -0,0 +1,11 @@
+HOMEPAGE = http://cryptodev-linux.org/;
+
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263
+
+SRC_URI = 
http://download.gna.org/cryptodev-linux/cryptodev-linux-${PV}.tar.gz;
+
+SRC_URI[md5sum] = eade38998313c25fd7934719cdf8a2ea
+SRC_URI[sha256sum] = 
75f1425c8ea1f8cae523905a5a046a35092327a6152800b0b86efc4e56fb3e2f
+
+S = ${WORKDIR}/cryptodev-linux-${PV}
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 3/4] cryptodev-module: recipe for out-of-tree cryptodev device driver

2014-04-10 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Depends on cryptodev-linux for providing a header file

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
v2 - add patch to fix INIT_COMPLETION rename in 3.13+ kernels

 .../cryptodev/cryptodev-module_1.6.bb  | 18 +
 ...talling-header-file-provided-by-another-p.patch | 28 +++
 ...-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch | 86 ++
 3 files changed, 132 insertions(+)
 create mode 100644 meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0002-In-the-3.13-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb
new file mode 100644
index 000..df50e5a
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb
@@ -0,0 +1,18 @@
+require cryptodev_${PV}.inc
+
+SUMMARY = A /dev/crypto device driver kernel module
+
+inherit module
+
+# Header file provided by a separate package
+DEPENDS += cryptodev-linux
+
+SRC_URI +=  \
+file://0001-Disable-installing-header-file-provided-by-another-p.patch \
+file://0002-In-the-3.13-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch \
+
+
+EXTRA_OEMAKE='KERNEL_DIR=${STAGING_KERNEL_DIR} PREFIX=${D}'
+
+RCONFLICTS_${PN} = ocf-linux
+RREPLACES_${PN} = ocf-linux
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
 
b/meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
new file mode 100644
index 000..a580fc6
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
@@ -0,0 +1,28 @@
+From 8a884f55bd1527baa82fab68c186ba546273860c Mon Sep 17 00:00:00 2001
+From: Denys Dmytriyenko de...@ti.com
+Date: Sun, 6 Apr 2014 19:51:39 -0400
+Subject: [PATCH] Disable installing header file provided by another package
+
+Signed-off-by: Denys Dmytriyenko de...@ti.com
+
+Upstream-Status: Inappropriate [ OE specific ]
+---
+ Makefile | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index d66ef26..8e97c6a 100644
+--- a/Makefile
 b/Makefile
+@@ -23,8 +23,6 @@ install: modules_install
+ 
+ modules_install:
+   make -C $(KERNEL_DIR) SUBDIRS=`pwd` modules_install
+-  @echo Installing cryptodev.h in $(PREFIX)/usr/include/crypto ...
+-  @install -D crypto/cryptodev.h $(PREFIX)/usr/include/crypto/cryptodev.h
+ 
+ clean:
+   make -C $(KERNEL_DIR) SUBDIRS=`pwd` clean
+-- 
+1.9.1
+
diff --git 
a/meta/recipes-kernel/cryptodev/files/0002-In-the-3.13-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch
 
b/meta/recipes-kernel/cryptodev/files/0002-In-the-3.13-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch
new file mode 100644
index 000..c5c7ec7
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0002-In-the-3.13-rc1-Linux-kernel-the-INIT_COMPLETION-mac.patch
@@ -0,0 +1,86 @@
+From 57b5544de80db85c8955499831fdaa30829db77a Mon Sep 17 00:00:00 2001
+From: Cosmin Paraschiv cosmin.parasc...@freescale.com
+Date: Thu, 23 Jan 2014 03:40:00 +0100
+Subject: [PATCH] In the 3.13-rc1 Linux kernel, the INIT_COMPLETION macro has
+ been replaced with an inline function, reinit_completion [1][2]. We are
+ currently using the 3.13-rc3 Linux kernel, which leads to the following
+ error:
+
+cryptlib.c:279:2: error: implicit declaration of function 'INIT_COMPLETION' 
[-Werror=implicit-function-declaration]
+  INIT_COMPLETION(cdata-async.result-completion);
+
+[1] 
https://github.com/torvalds/linux/commit/c32f74ab2872994bc8336ed367313da3139350ca
+[2] 
https://github.com/torvalds/linux/commit/62026aedaacedbe1ffe94a3599ad4acd8ecdf587
+
+Signed-off-by: Cosmin Paraschiv cosmin.parasc...@freescale.com
+Reviewed-by: Cristian Stoica cristian.sto...@freescale.com
+Tested-by: Cristian Stoica cristian.sto...@freescale.com
+Signed-off-by: Horia Geanta horia.gea...@freescale.com
+Signed-off-by: Phil Sutter p...@nwl.cc
+
+Upstream-Status: Backport
+---
+ cryptlib.c  | 8 
+ cryptodev_int.h | 6 ++
+ 2 files changed, 10 insertions(+), 4 deletions(-)
+
+diff --git a/cryptlib.c b/cryptlib.c
+index 54d5d41..a923c14 100644
+--- a/cryptlib.c
 b/cryptlib.c
+@@ -217,7 +217,7 @@ ssize_t cryptodev_cipher_encrypt(struct cipher_data *cdata,
+ {
+   int ret;
+ 
+-  INIT_COMPLETION(cdata-async.result-completion);
++  reinit_completion(cdata-async.result-completion);
+ 
+   if (cdata-aead == 0) {
+   ablkcipher_request_set_crypt(cdata-async.request,
+@@ -240,7 +240,7 @@ ssize_t cryptodev_cipher_decrypt(struct cipher_data *cdata,
+ {
+   int ret;
+ 
+-  INIT_COMPLETION(cdata-async.result-completion);
++  reinit_completion(cdata-async.result-completion);
+   if (cdata-aead == 0

[OE-core] [PATCH 1/4] cryptodev-linux: move to recipes-kernel to be shared with module and tests

2014-04-10 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 .../openssl = recipes-kernel/cryptodev}/cryptodev-linux_1.6.bb   | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename meta/{recipes-connectivity/openssl = 
recipes-kernel/cryptodev}/cryptodev-linux_1.6.bb (100%)

diff --git a/meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb
similarity index 100%
rename from meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb
rename to meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/4] cryptodev-tests: recipe for cryptodev test suite based on OpenSSL

2014-04-10 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 .../cryptodev/cryptodev-tests_1.6.bb   | 23 
 ...pile-and-install-rules-for-cryptodev-test.patch | 69 ++
 ...ests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch | 29 +
 3 files changed, 121 insertions(+)
 create mode 100644 meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb
new file mode 100644
index 000..efc41ae
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb
@@ -0,0 +1,23 @@
+require cryptodev_${PV}.inc
+
+SUMMARY = A test suite for /dev/crypto device driver
+
+DEPENDS += openssl
+
+SRC_URI +=  \
+file://0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch \
+file://0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch \
+
+
+EXTRA_OEMAKE='KERNEL_DIR=${STAGING_KERNEL_DIR} PREFIX=${D}'
+
+do_compile() {
+   oe_runmake testprogs
+}
+
+do_install() {
+   oe_runmake install_tests
+}
+
+FILES_${PN}-dbg += ${bindir}/tests_cryptodev/.debug
+FILES_${PN} = ${bindir}/tests_cryptodev/*
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch
 
b/meta/recipes-kernel/cryptodev/files/0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch
new file mode 100644
index 000..cb871f6
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch
@@ -0,0 +1,69 @@
+From 1980a8f4779a955e73285e7a0d86549b69bea5c8 Mon Sep 17 00:00:00 2001
+From: Yu Zongchun b40...@freescale.com
+Date: Sun, 28 Apr 2013 14:39:22 +0800
+Subject: [PATCH] Add the compile and install rules for cryptodev tests folder
+
+This is required to install the cryptodev tests folder to rootfs
+
+Signed-off-by: Yu Zongchun b40...@freescale.com
+
+Upstream-Status: Pending
+
+---
+ Makefile   |6 ++
+ tests/Makefile |8 
+ 2 files changed, 14 insertions(+), 0 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 2be8825..4cbb865 100644
+--- a/Makefile
 b/Makefile
+@@ -17,6 +17,9 @@ install:
+   @echo Installing cryptodev.h in /usr/include/crypto ...
+   @install -D crypto/cryptodev.h /usr/include/crypto/cryptodev.h
+ 
++install_tests:
++  make -C tests install DESTDIR=$(PREFIX)
++
+ clean:
+   make -C $(KERNEL_DIR) SUBDIRS=`pwd` clean
+   rm -f $(hostprogs) *~
+@@ -25,6 +28,9 @@ clean:
+ check:
+   KERNEL_DIR=$(KERNEL_DIR) make -C tests check
+ 
++testprogs:
++  KERNEL_DIR=$(KERNEL_DIR) make -C tests testprogs
++
+ FILEBASE = cryptodev-linux-$(VERSION)
+ TMPDIR ?= /tmp
+ OUTPUT = $(FILEBASE).tar.gz
+diff --git a/tests/Makefile b/tests/Makefile
+index 87ca3c7..0488cf6 100644
+--- a/tests/Makefile
 b/tests/Makefile
+@@ -19,6 +19,12 @@ example-async-hmac-objs := async_hmac.o
+ example-async-speed-objs := async_speed.o
+ example-hashcrypt-speed-objs := hashcrypt_speed.c
+ 
++install:
++  install -d  $(DESTDIR)/usr/bin/tests_cryptodev
++  for bin in $(hostprogs); do \
++  install -m 755 $${bin} $(DESTDIR)/usr/bin/tests_cryptodev/; \
++  done
++
+ check: $(hostprogs)
+   ./cipher
+   ./hmac
+@@ -28,6 +34,8 @@ check: $(hostprogs)
+   ./cipher-gcm
+   ./cipher-aead
+ 
++testprogs: $(hostprogs)
++
+ clean:
+   rm -f *.o *~ $(hostprogs)
+ 
+-- 
+1.7.5.4
+
diff --git 
a/meta/recipes-kernel/cryptodev/files/0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch
 
b/meta/recipes-kernel/cryptodev/files/0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch
new file mode 100644
index 000..f5ab8b4
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch
@@ -0,0 +1,29 @@
+From 47ff1eb9bb4f872c1d731b93d334ee5865bf3439 Mon Sep 17 00:00:00 2001
+From: Denys Dmytriyenko de...@ti.com
+Date: Sun, 6 Apr 2014 22:16:30 -0400
+Subject: [PATCH] Fix tests Makefile usage of LDLIBS vs. LDFLAGS
+
+Libraries must come after objects, as link order matters, especially
+when using linker flags like -Wl,--as-needed.
+
+Signed-off-by: Denys Dmytriyenko de...@ti.com
+
+Upstream-Status: Pending
+---
+ tests/Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tests/Makefile b/tests/Makefile
+index cd202af..67c3c83 100644
+--- a/tests/Makefile
 b/tests/Makefile
+@@ -39,5 +39,5 @@ testprogs: $(hostprogs)
+ clean:
+   rm -f *.o *~ $(hostprogs)
+ 
+-${comp_progs}: LDFLAGS += -lssl -lcrypto
++${comp_progs}: LDLIBS += -lssl -lcrypto
+ ${comp_progs}: %: %.o openssl_wrapper.o
+-- 
+1.9.1
+
-- 
1.9.1

Re: [OE-core] [PATCH 3/4] cryptodev-module: recipe for out-of-tree cryptodev device driver

2014-04-10 Thread Denys Dmytriyenko 
On Mon, Apr 07, 2014 at 08:50:39PM -0400, Denys Dmytriyenko wrote:
 On Mon, Apr 07, 2014 at 03:13:14PM -0700, Saul Wold wrote:
  On 04/06/2014 07:29 PM, Denys Dmytriyenko wrote:
  From: Denys Dmytriyenko de...@ti.com
  
  Depends on cryptodev-linux for providing a header file
  
  
  I am seeing failure on the Autobuilder with multilib enabled
  (lib32), I am not sure if this is a multilib issue, but it shows up
  here
 
 Ah, only tested it on 3.12 and 3.13+ requires this patch:
 http://patchwork.ozlabs.org/patch/312943/
 
 Will re-submit shortly...

Sorry for the delay - BBB BSP took priority. I just re-submitted the entire 
set with an updated version of this patch #3, please let me know the results.

-- 
Denys


  NOTE: Running task 14174 of 19826 (ID: 13044, 
  virtual:multilib:lib32:/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/meta/recipes-core/libcgroup/libcgroup_0.41.bb,
   do_configure)
  ERROR: Function failed: do_compile (log file is located at 
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/temp/log.do_compile.19322)
  ERROR: Logfile of failure stored in: 
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/temp/log.do_compile.19322
  Log data follows:
  | DEBUG: Executing shell function do_compile
  | NOTE: make -j 16 
  KERNEL_DIR=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel
   
  PREFIX=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/image
   
  KERNEL_PATH=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel
   
  KERNEL_SRC=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel
   KERNEL_VERSION=3.14.0-yocto-standard CC=i586-poky-linux-gcc  
  LD=i586-poky-linux-ld.bfd  AR=i586-poky-linux-ar
  | make -C 
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel
   SUBDIRS=`pwd` modules
  | make[1]: Entering directory 
  `/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel'
  | make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent 
  make rule.
  |   CC [M]  
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/ioctl.o
  | 
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/ioctl.c:710:21:
   warning: 'is_known_accelerated' defined but not used [-Wunused-function]
  |  static unsigned int is_known_accelerated(struct crypto_tfm *tfm)
  |  ^
  |   CC [M]  
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/main.o
  |   CC [M]  
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/cryptlib.o
  | 
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/cryptlib.c:
   In function 'cryptodev_cipher_encrypt':
  | 
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/cryptlib.c:223:2:
   error: implicit declaration of function 'INIT_COMPLETION' 
  [-Werror=implicit-function-declaration]
  |   INIT_COMPLETION(cdata-async.result-completion);
  |   ^
  | cc1: some warnings being treated as errors
  | make[2]: *** 
  [/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/cryptlib.o]
   Error 1
  | make[1]: *** 
  [_module_/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6]
   Error 2
  | make[1]: Leaving directory 
  `/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel'
  | make: *** [build] Error 2
  | ERROR: oe_runmake failed
  | WARNING: 
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/temp/run.do_compile.19322:1
   exit 1 from
  |   exit 1
  | ERROR: Function failed: do_compile (log file is located at 
  /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/temp/log.do_compile.19322)
  NOTE: recipe cryptodev-module-1.6-r0: task do_compile: Failed
  ERROR: Task 13808 
  (/home/pokybuild/yocto-autobuilder/yocto-slave

Re: [OE-core] meta-toolchain-sdk LDFLAGS fails for ARMv7 (beagleboard)

2014-04-07 Thread Denys Dmytriyenko 
On Mon, Apr 07, 2014 at 10:02:40PM +0200, Ulf Samuelsson wrote:
 Trying to build an SDK for the Beaglebone
 
 $ git clone git://git.yoctoproject.org/poky
 $ cd poky
 $ git checkout -b dora origin/dora
 
 $ . oe-init-build-env
 
 MACHINE is set to beagleboard in local.conf

It's not critical to your case, but in general beagleboard != beaglebone...

And cutting to the chase - U-boot recipe in OE clears CFLAGS, LDFLAGS and 
CPPFLAGS before building it...


 $ ./environment-angstrom-v2013.06
 
 $ bitbake meta-toolchain-sdk
 
 SDK is generated, and installed in /opt/poky/1.5.1 (default)
 
 The toolchain environment file is sourced
 
 Then I try to build U-Boot-13.10 (with a minor patch)
 
 
 $ make am335x_boneblack_config
 
 $ make
 
 After compiling a number of file, the linking of a library fails:
 
 arm-poky-linux-gnueabi-ld.bfd -Wl,-O1 -Wl,--hash-style=gnu
 -Wl,--as-needed   -r -o libcommon.o  cmd_bdinfo.o cmd_boot.o
 cmd_bootm.o cmd_console.o cmd_dfu.o cmd_disk.o cmd_echo.o
 cmd_eeprom.o cmd_exit.o cmd_ext2.o cmd_ext4.o cmd_fat.o cmd_fdt.o
 cmd_fs.o cmd_gpio.o cmd_help.o cmd_i2c.o cmd_itest.o cmd_load.o
 cmd_mem.o cmd_misc.o cmd_mmc.o cmd_net.o cmd_nvedit.o cmd_pcmcia.o
 cmd_sf.o cmd_source.o cmd_spi.o cmd_spl.o cmd_test.o cmd_usb.o
 cmd_version.o cmd_ximg.o command.o console.o dlmalloc.o env_attr.o
 env_callback.o env_common.o env_flags.o env_mmc.o exports.o
 fdt_support.o flash.o hash.o hush.o image-fdt.o image.o main.o
 memsize.o miiphyutil.o s_record.o splash.o stdio.o usb.o usb_hub.o
 usb_storage.o xyzModem.o
 arm-poky-linux-gnueabi-ld.bfd: unrecognized option '-Wl,-O1'
 arm-poky-linux-gnueabi-ld.bfd: use the --help option for usage information
 make[1]: *** [libcommon.o] Fel 1
 make[1]: Lämnar katalogen
 /home/ulf/felabs/sysdev/bootloader/u-boot-2013.10/common
 make: *** [common/libcommon.o] Fel 2
 
 ---
 The environment looks like:
 ---
 export 
 PATH=/opt/poky/1.5.1/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.5.1/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi:$PATH
 export 
 PKG_CONFIG_SYSROOT_DIR=/opt/poky/1.5.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
 export 
 PKG_CONFIG_PATH=/opt/poky/1.5.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/lib/pkgconfig
 export 
 CONFIG_SITE=/opt/poky/1.5.1/site-config-armv7a-vfp-neon-poky-linux-gnueabi
 export CC=arm-poky-linux-gnueabi-gcc  -march=armv7-a
 -mthumb-interwork -mfloat-abi=softfp -mfpu=neon 
 --sysroot=/opt/poky/1.5.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
 export CXX=arm-poky-linux-gnueabi-g++  -march=armv7-a
 -mthumb-interwork -mfloat-abi=softfp -mfpu=neon 
 --sysroot=/opt/poky/1.5.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
 export CPP=arm-poky-linux-gnueabi-gcc -E  -march=armv7-a
 -mthumb-interwork -mfloat-abi=softfp -mfpu=neon 
 --sysroot=/opt/poky/1.5.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
 export AS=arm-poky-linux-gnueabi-as 
 export LD=arm-poky-linux-gnueabi-ld 
 --sysroot=/opt/poky/1.5.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
 export GDB=arm-poky-linux-gnueabi-gdb
 export STRIP=arm-poky-linux-gnueabi-strip
 export RANLIB=arm-poky-linux-gnueabi-ranlib
 export OBJCOPY=arm-poky-linux-gnueabi-objcopy
 export OBJDUMP=arm-poky-linux-gnueabi-objdump
 export AR=arm-poky-linux-gnueabi-ar
 export NM=arm-poky-linux-gnueabi-nm
 export M4=m4
 export TARGET_PREFIX=arm-poky-linux-gnueabi-
 export CONFIGURE_FLAGS=--target=arm-poky-linux-gnueabi
 --host=arm-poky-linux-gnueabi --build=x86_64-linux 
 --with-libtool-sysroot=/opt/poky/1.5.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
 export CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
 export CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types -fpermissive
 export LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
 export CPPFLAGS=
 export OECORE_NATIVE_SYSROOT=/opt/poky/1.5.1/sysroots/x86_64-pokysdk-linux
 export 
 OECORE_TARGET_SYSROOT=/opt/poky/1.5.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
 export OECORE_ACLOCAL_OPTS=-I
 /opt/poky/1.5.1/sysroots/x86_64-pokysdk-linux/usr/share/aclocal
 export OECORE_DISTRO_VERSION=1.5.1
 export OECORE_SDK_VERSION=1.5.1
 export PYTHONHOME=/opt/poky/1.5.1/sysroots/x86_64-pokysdk-linux/usr
 export ARCH=arm
 export CROSS_COMPILE=arm-poky-linux-gnueabi-
 -
 
 Notable is:
 export LD=arm-poky-linux-gnueabi-ld 
 --sysroot=/opt/poky/1.5.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
 export LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
 
 From the error message I see:
 arm-poky-linux-gnueabi-ld.bfd -Wl,-O1 ...
 
 Note that $(CROSS_COMPILE)-ld.bfd is used, not $(CROSS_COMPILE)-ld
 
 so the linker is linking with $(LDFLAGS) which contains switches to
 be passed to the

Re: [OE-core] [PATCH v2] udev-extraconf: update mount.sh to use /run/media instead of /media

2014-04-07 Thread Denys Dmytriyenko 
On Mon, Apr 07, 2014 at 08:49:44AM -0700, Saul Wold wrote:
 On 04/06/2014 03:46 PM, Denys Dmytriyenko wrote:
 ping
 
 
 This change is a little late for 1.6 as we are prepping for the
 final RC this week.  It's kind of an API change since it moves the
 mount location /media, should we be linking /media to /run/media?
 
 There is also an issue with the Freescale PPC BSP, which has a
 bbappend for 1.0, so some coordination with them will be needed.
 
 I can revisit this for 1.7 in a week or so.
 
 Sau!

I understand the timing concern and am fine waiting another week for when 1.7 
window opens.

But I'm slightly confused as to since when OE-Core is concerned about breaking 
bbappends in other layers? I guess some layers are not created equal, eh? :)

-- 
Denys


 On Mon, Mar 31, 2014 at 11:54:11PM -0400, Denys Dmytriyenko wrote:
 From: Denys Dmytriyenko de...@ti.com
 
 This is done to work around the issue of auto-mounting block devices
 (i.e. SD cards) when root filesystem is still in read-only mode and
 creating /media/device mount-points by udev is not possible. That
 is due to udev (/etc/rcS.d/S03udev) getting started earlier than
 checkroot (/etc/rcS.d/S10checkroot.sh) gets a chance to re-mount the
 rootfs as read-write.
 
 Although, canonical FHS specifies /media/device as a mount point
 for removable media devices, the latest 2.3 version was released in
 2004 and since then FreeDesktop/udisks and other tools adopted the
 new /run/media/user/device location. That was done to overcome
 read-only rootfs limitation, since /run is usually a tmpfs mounted
 partition, plus avoid name-clash between users.
 
 For our embedded systems environment we assume single-user operation
 and hence simplify mount point to just /run/media/device. But for
 proper per-user mounting to /run/media/user/device, some sort of
 session management is required along with the tool like udisks, that
 is out of scope of this simple udev-based auto-mounting.
 
 Signed-off-by: Denys Dmytriyenko de...@ti.com
 ---
 v2 - drop PR, bump PV, elaborate on session/user mounting option
 
   meta/recipes-core/udev/udev-extraconf/mount.sh | 14 
  +++---
   .../udev/{udev-extraconf_1.0.bb = udev-extraconf_1.1.bb}  |  2 --
   2 files changed, 7 insertions(+), 9 deletions(-)
   rename meta/recipes-core/udev/{udev-extraconf_1.0.bb = 
  udev-extraconf_1.1.bb} (99%)
 
 diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
 b/meta/recipes-core/udev/udev-extraconf/mount.sh
 index cb57e47..3e4f21f 100644
 --- a/meta/recipes-core/udev/udev-extraconf/mount.sh
 +++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
 @@ -20,7 +20,7 @@ done
   automount() { 
 name=`basename $DEVNAME`
 
 -   ! test -d /media/$name  mkdir -p /media/$name
 +   ! test -d /run/media/$name  mkdir -p /run/media/$name
 # Silent util-linux's version of mounting auto
 if [ x`readlink $MOUNT` = x/bin/mount.util-linux ] ;
 then
 @@ -38,12 +38,12 @@ automount() {
 ;;
 esac
 
 -   if ! $MOUNT -t auto $DEVNAME /media/$name
 +   if ! $MOUNT -t auto $DEVNAME /run/media/$name
 then
 -   #logger mount.sh/automount $MOUNT -t auto $DEVNAME 
 \/media/$name\ failed!
 -   rm_dir /media/$name
 +   #logger mount.sh/automount $MOUNT -t auto $DEVNAME 
 \/run/media/$name\ failed!
 +   rm_dir /run/media/$name
 else
 -   logger mount.sh/automount Auto-mount of [/media/$name] 
 successful
 +   logger mount.sh/automount Auto-mount of [/run/media/$name] 
 successful
 touch /tmp/.automount-$name
 fi
   }
 @@ -60,7 +60,7 @@ rm_dir() {
 
   # No ID_FS_TYPE for cdrom device, yet it should be mounted
   name=`basename $DEVNAME`
 -[ -e /sys/block/$name/device/media ]  media_type=`cat 
 /sys/block/$name/device/media`
 +[ -e /sys/block/$name/device/run/media ]  media_type=`cat 
 /sys/block/$name/device/run/media`
 
   if [ $ACTION = add ]  [ -n $DEVNAME ]  [ -n $ID_FS_TYPE -o 
  $media_type = cdrom ]; then
 if [ -x $PMOUNT ]; then
 @@ -87,5 +87,5 @@ if [ $ACTION = remove ]  [ -x $UMOUNT ]  [ -n 
 $DEVNAME ]; then
 
 # Remove empty directories from auto-mounter
 name=`basename $DEVNAME`
 -   test -e /tmp/.automount-$name  rm_dir /media/$name
 +   test -e /tmp/.automount-$name  rm_dir /run/media/$name
   fi
 diff --git a/meta/recipes-core/udev/udev-extraconf_1.0.bb 
 b/meta/recipes-core/udev/udev-extraconf_1.1.bb
 similarity index 99%
 rename from meta/recipes-core/udev/udev-extraconf_1.0.bb
 rename to meta/recipes-core/udev/udev-extraconf_1.1.bb
 index 3810b28..d69056d 100644
 --- a/meta/recipes-core/udev/udev-extraconf_1.0.bb
 +++ b/meta/recipes-core/udev/udev-extraconf_1.1.bb
 @@ -4,8 +4,6 @@ LICENSE = MIT
   LIC_FILES_CHKSUM = 
  file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
   
  file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
 
 -PR = r16
 -
   SRC_URI =  \
  file://automount.rules

Re: [OE-core] OEDAM updates

2014-04-07 Thread Denys Dmytriyenko 
On Mon, Apr 07, 2014 at 04:01:57PM -0700, Philip Balister wrote:
 Once again, please add yourself (or email Jefro or myself) if you plan
 to attend OEDAM. We have room for about 5-10 more people.
 
 http://www.openembedded.org/wiki/OEDAM
 
 We should also get serious about creating an agenda. Even if you are not
 able to attend please take a look at the agenda and add topics you think
 should be discussed. We'll likely have to review the agenda when we
 start, but now is a good time to air your grievances.

I'm not sure how many will be staying all day Saturday, but can we try to 
group agenda topics so most pressing matters fall on Friday and maybe Saturday 
morning?

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/4] cryptodev-module: recipe for out-of-tree cryptodev device driver

2014-04-07 Thread Denys Dmytriyenko 
On Mon, Apr 07, 2014 at 03:13:14PM -0700, Saul Wold wrote:
 On 04/06/2014 07:29 PM, Denys Dmytriyenko wrote:
 From: Denys Dmytriyenko de...@ti.com
 
 Depends on cryptodev-linux for providing a header file
 
 
 I am seeing failure on the Autobuilder with multilib enabled
 (lib32), I am not sure if this is a multilib issue, but it shows up
 here

Ah, only tested it on 3.12 and 3.13+ requires this patch:
http://patchwork.ozlabs.org/patch/312943/

Will re-submit shortly...


 NOTE: Running task 14174 of 19826 (ID: 13044, 
 virtual:multilib:lib32:/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/meta/recipes-core/libcgroup/libcgroup_0.41.bb,
  do_configure)
 ERROR: Function failed: do_compile (log file is located at 
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/temp/log.do_compile.19322)
 ERROR: Logfile of failure stored in: 
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/temp/log.do_compile.19322
 Log data follows:
 | DEBUG: Executing shell function do_compile
 | NOTE: make -j 16 
 KERNEL_DIR=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel
  
 PREFIX=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/image
  
 KERNEL_PATH=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel
  
 KERNEL_SRC=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel
  KERNEL_VERSION=3.14.0-yocto-standard CC=i586-poky-linux-gcc  
 LD=i586-poky-linux-ld.bfd  AR=i586-poky-linux-ar
 | make -C 
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel
  SUBDIRS=`pwd` modules
 | make[1]: Entering directory 
 `/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel'
 | make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent 
 make rule.
 |   CC [M]  
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/ioctl.o
 | 
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/ioctl.c:710:21:
  warning: 'is_known_accelerated' defined but not used [-Wunused-function]
 |  static unsigned int is_known_accelerated(struct crypto_tfm *tfm)
 |  ^
 |   CC [M]  
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/main.o
 |   CC [M]  
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/cryptlib.o
 | 
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/cryptlib.c:
  In function 'cryptodev_cipher_encrypt':
 | 
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/cryptlib.c:223:2:
  error: implicit declaration of function 'INIT_COMPLETION' 
 [-Werror=implicit-function-declaration]
 |   INIT_COMPLETION(cdata-async.result-completion);
 |   ^
 | cc1: some warnings being treated as errors
 | make[2]: *** 
 [/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6/cryptlib.o]
  Error 1
 | make[1]: *** 
 [_module_/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/cryptodev-linux-1.6]
  Error 2
 | make[1]: Leaving directory 
 `/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/sysroots/qemux86/usr/src/kernel'
 | make: *** [build] Error 2
 | ERROR: oe_runmake failed
 | WARNING: 
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/temp/run.do_compile.19322:1
  exit 1 from
 |   exit 1
 | ERROR: Function failed: do_compile (log file is located at 
 /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/build/tmp/work/qemux86-poky-linux/cryptodev-module/1.6-r0/temp/log.do_compile.19322)
 NOTE: recipe cryptodev-module-1.6-r0: task do_compile: Failed
 ERROR: Task 13808 
 (/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb,
  do_compile) failed with exit code '1'
 NOTE: Running task 14175 of 19826 (ID: 13002, 
 virtual:multilib:lib32:/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-world/build/meta/recipes-devtools/python/python-mako_0.9.1.bb

Re: [OE-core] [PATCH v2] udev-extraconf: update mount.sh to use /run/media instead of /media

2014-04-06 Thread Denys Dmytriyenko 
ping

On Mon, Mar 31, 2014 at 11:54:11PM -0400, Denys Dmytriyenko wrote:
 From: Denys Dmytriyenko de...@ti.com
 
 This is done to work around the issue of auto-mounting block devices
 (i.e. SD cards) when root filesystem is still in read-only mode and
 creating /media/device mount-points by udev is not possible. That
 is due to udev (/etc/rcS.d/S03udev) getting started earlier than
 checkroot (/etc/rcS.d/S10checkroot.sh) gets a chance to re-mount the
 rootfs as read-write.
 
 Although, canonical FHS specifies /media/device as a mount point
 for removable media devices, the latest 2.3 version was released in
 2004 and since then FreeDesktop/udisks and other tools adopted the
 new /run/media/user/device location. That was done to overcome
 read-only rootfs limitation, since /run is usually a tmpfs mounted
 partition, plus avoid name-clash between users.
 
 For our embedded systems environment we assume single-user operation
 and hence simplify mount point to just /run/media/device. But for
 proper per-user mounting to /run/media/user/device, some sort of
 session management is required along with the tool like udisks, that
 is out of scope of this simple udev-based auto-mounting.
 
 Signed-off-by: Denys Dmytriyenko de...@ti.com
 ---
 v2 - drop PR, bump PV, elaborate on session/user mounting option
 
  meta/recipes-core/udev/udev-extraconf/mount.sh | 14 
 +++---
  .../udev/{udev-extraconf_1.0.bb = udev-extraconf_1.1.bb}  |  2 --
  2 files changed, 7 insertions(+), 9 deletions(-)
  rename meta/recipes-core/udev/{udev-extraconf_1.0.bb = 
 udev-extraconf_1.1.bb} (99%)
 
 diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
 b/meta/recipes-core/udev/udev-extraconf/mount.sh
 index cb57e47..3e4f21f 100644
 --- a/meta/recipes-core/udev/udev-extraconf/mount.sh
 +++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
 @@ -20,7 +20,7 @@ done
  automount() {
   name=`basename $DEVNAME`
  
 - ! test -d /media/$name  mkdir -p /media/$name
 + ! test -d /run/media/$name  mkdir -p /run/media/$name
   # Silent util-linux's version of mounting auto
   if [ x`readlink $MOUNT` = x/bin/mount.util-linux ] ;
   then
 @@ -38,12 +38,12 @@ automount() {
   ;;
   esac
  
 - if ! $MOUNT -t auto $DEVNAME /media/$name
 + if ! $MOUNT -t auto $DEVNAME /run/media/$name
   then
 - #logger mount.sh/automount $MOUNT -t auto $DEVNAME 
 \/media/$name\ failed!
 - rm_dir /media/$name
 + #logger mount.sh/automount $MOUNT -t auto $DEVNAME 
 \/run/media/$name\ failed!
 + rm_dir /run/media/$name
   else
 - logger mount.sh/automount Auto-mount of [/media/$name] 
 successful
 + logger mount.sh/automount Auto-mount of [/run/media/$name] 
 successful
   touch /tmp/.automount-$name
   fi
  }
 @@ -60,7 +60,7 @@ rm_dir() {
  
  # No ID_FS_TYPE for cdrom device, yet it should be mounted
  name=`basename $DEVNAME`
 -[ -e /sys/block/$name/device/media ]  media_type=`cat 
 /sys/block/$name/device/media`
 +[ -e /sys/block/$name/device/run/media ]  media_type=`cat 
 /sys/block/$name/device/run/media`
  
  if [ $ACTION = add ]  [ -n $DEVNAME ]  [ -n $ID_FS_TYPE -o 
 $media_type = cdrom ]; then
   if [ -x $PMOUNT ]; then
 @@ -87,5 +87,5 @@ if [ $ACTION = remove ]  [ -x $UMOUNT ]  [ -n 
 $DEVNAME ]; then
   
   # Remove empty directories from auto-mounter
   name=`basename $DEVNAME`
 - test -e /tmp/.automount-$name  rm_dir /media/$name
 + test -e /tmp/.automount-$name  rm_dir /run/media/$name
  fi
 diff --git a/meta/recipes-core/udev/udev-extraconf_1.0.bb 
 b/meta/recipes-core/udev/udev-extraconf_1.1.bb
 similarity index 99%
 rename from meta/recipes-core/udev/udev-extraconf_1.0.bb
 rename to meta/recipes-core/udev/udev-extraconf_1.1.bb
 index 3810b28..d69056d 100644
 --- a/meta/recipes-core/udev/udev-extraconf_1.0.bb
 +++ b/meta/recipes-core/udev/udev-extraconf_1.1.bb
 @@ -4,8 +4,6 @@ LICENSE = MIT
  LIC_FILES_CHKSUM = 
 file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
  
 file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
  
 -PR = r16
 -
  SRC_URI =  \
 file://automount.rules \
 file://mount.sh \
 -- 
 1.9.1
 
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/4] cryptodev-linux: move to recipes-kernel to be shared with module and tests

2014-04-06 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 .../openssl = recipes-kernel/cryptodev}/cryptodev-linux_1.6.bb   | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename meta/{recipes-connectivity/openssl = 
recipes-kernel/cryptodev}/cryptodev-linux_1.6.bb (100%)

diff --git a/meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb
similarity index 100%
rename from meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb
rename to meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/4] cryptodev-module: recipe for out-of-tree cryptodev device driver

2014-04-06 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Depends on cryptodev-linux for providing a header file

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 .../cryptodev/cryptodev-module_1.6.bb  | 15 
 ...talling-header-file-provided-by-another-p.patch | 28 ++
 2 files changed, 43 insertions(+)
 create mode 100644 meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb
new file mode 100644
index 000..fdf07b2
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.6.bb
@@ -0,0 +1,15 @@
+require cryptodev_${PV}.inc
+
+SUMMARY = A /dev/crypto device driver kernel module
+
+inherit module
+
+# Header file provided by a separate package
+DEPENDS += cryptodev-linux
+
+SRC_URI += 
file://0001-Disable-installing-header-file-provided-by-another-p.patch
+
+EXTRA_OEMAKE='KERNEL_DIR=${STAGING_KERNEL_DIR} PREFIX=${D}'
+
+RCONFLICTS_${PN} = ocf-linux
+RREPLACES_${PN} = ocf-linux
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
 
b/meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
new file mode 100644
index 000..a580fc6
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0001-Disable-installing-header-file-provided-by-another-p.patch
@@ -0,0 +1,28 @@
+From 8a884f55bd1527baa82fab68c186ba546273860c Mon Sep 17 00:00:00 2001
+From: Denys Dmytriyenko de...@ti.com
+Date: Sun, 6 Apr 2014 19:51:39 -0400
+Subject: [PATCH] Disable installing header file provided by another package
+
+Signed-off-by: Denys Dmytriyenko de...@ti.com
+
+Upstream-Status: Inappropriate [ OE specific ]
+---
+ Makefile | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index d66ef26..8e97c6a 100644
+--- a/Makefile
 b/Makefile
+@@ -23,8 +23,6 @@ install: modules_install
+ 
+ modules_install:
+   make -C $(KERNEL_DIR) SUBDIRS=`pwd` modules_install
+-  @echo Installing cryptodev.h in $(PREFIX)/usr/include/crypto ...
+-  @install -D crypto/cryptodev.h $(PREFIX)/usr/include/crypto/cryptodev.h
+ 
+ clean:
+   make -C $(KERNEL_DIR) SUBDIRS=`pwd` clean
+-- 
+1.9.1
+
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/4] cryptodev-linux: create common .inc file to be shared by module and tests

2014-04-06 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb | 11 ++-
 meta/recipes-kernel/cryptodev/cryptodev_1.6.inc  | 11 +++
 2 files changed, 13 insertions(+), 9 deletions(-)
 create mode 100644 meta/recipes-kernel/cryptodev/cryptodev_1.6.inc

diff --git a/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb
index 320716d..43f58f3 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb
+++ b/meta/recipes-kernel/cryptodev/cryptodev-linux_1.6.bb
@@ -1,13 +1,6 @@
-SUMMARY = A /dev/crypto device driver
-HOMEPAGE = http://cryptodev-linux.org/;
+require cryptodev_${PV}.inc
 
-LICENSE = GPLv2
-LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263
-
-SRC_URI = http://download.gna.org/cryptodev-linux/${BPN}-${PV}.tar.gz;
-
-SRC_URI[md5sum] = eade38998313c25fd7934719cdf8a2ea
-SRC_URI[sha256sum] = 
75f1425c8ea1f8cae523905a5a046a35092327a6152800b0b86efc4e56fb3e2f
+SUMMARY = A /dev/crypto device driver header file
 
 do_compile() {
:
diff --git a/meta/recipes-kernel/cryptodev/cryptodev_1.6.inc 
b/meta/recipes-kernel/cryptodev/cryptodev_1.6.inc
new file mode 100644
index 000..946faac
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/cryptodev_1.6.inc
@@ -0,0 +1,11 @@
+HOMEPAGE = http://cryptodev-linux.org/;
+
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263
+
+SRC_URI = 
http://download.gna.org/cryptodev-linux/cryptodev-linux-${PV}.tar.gz;
+
+SRC_URI[md5sum] = eade38998313c25fd7934719cdf8a2ea
+SRC_URI[sha256sum] = 
75f1425c8ea1f8cae523905a5a046a35092327a6152800b0b86efc4e56fb3e2f
+
+S = ${WORKDIR}/cryptodev-linux-${PV}
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/4] cryptodev-tests: recipe for cryptodev test suite based on OpenSSL

2014-04-06 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 .../cryptodev/cryptodev-tests_1.6.bb   | 23 
 ...pile-and-install-rules-for-cryptodev-test.patch | 69 ++
 ...ests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch | 29 +
 3 files changed, 121 insertions(+)
 create mode 100644 meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb
new file mode 100644
index 000..efc41ae
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.6.bb
@@ -0,0 +1,23 @@
+require cryptodev_${PV}.inc
+
+SUMMARY = A test suite for /dev/crypto device driver
+
+DEPENDS += openssl
+
+SRC_URI +=  \
+file://0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch \
+file://0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch \
+
+
+EXTRA_OEMAKE='KERNEL_DIR=${STAGING_KERNEL_DIR} PREFIX=${D}'
+
+do_compile() {
+   oe_runmake testprogs
+}
+
+do_install() {
+   oe_runmake install_tests
+}
+
+FILES_${PN}-dbg += ${bindir}/tests_cryptodev/.debug
+FILES_${PN} = ${bindir}/tests_cryptodev/*
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch
 
b/meta/recipes-kernel/cryptodev/files/0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch
new file mode 100644
index 000..cb871f6
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch
@@ -0,0 +1,69 @@
+From 1980a8f4779a955e73285e7a0d86549b69bea5c8 Mon Sep 17 00:00:00 2001
+From: Yu Zongchun b40...@freescale.com
+Date: Sun, 28 Apr 2013 14:39:22 +0800
+Subject: [PATCH] Add the compile and install rules for cryptodev tests folder
+
+This is required to install the cryptodev tests folder to rootfs
+
+Signed-off-by: Yu Zongchun b40...@freescale.com
+
+Upstream-Status: Pending
+
+---
+ Makefile   |6 ++
+ tests/Makefile |8 
+ 2 files changed, 14 insertions(+), 0 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 2be8825..4cbb865 100644
+--- a/Makefile
 b/Makefile
+@@ -17,6 +17,9 @@ install:
+   @echo Installing cryptodev.h in /usr/include/crypto ...
+   @install -D crypto/cryptodev.h /usr/include/crypto/cryptodev.h
+ 
++install_tests:
++  make -C tests install DESTDIR=$(PREFIX)
++
+ clean:
+   make -C $(KERNEL_DIR) SUBDIRS=`pwd` clean
+   rm -f $(hostprogs) *~
+@@ -25,6 +28,9 @@ clean:
+ check:
+   KERNEL_DIR=$(KERNEL_DIR) make -C tests check
+ 
++testprogs:
++  KERNEL_DIR=$(KERNEL_DIR) make -C tests testprogs
++
+ FILEBASE = cryptodev-linux-$(VERSION)
+ TMPDIR ?= /tmp
+ OUTPUT = $(FILEBASE).tar.gz
+diff --git a/tests/Makefile b/tests/Makefile
+index 87ca3c7..0488cf6 100644
+--- a/tests/Makefile
 b/tests/Makefile
+@@ -19,6 +19,12 @@ example-async-hmac-objs := async_hmac.o
+ example-async-speed-objs := async_speed.o
+ example-hashcrypt-speed-objs := hashcrypt_speed.c
+ 
++install:
++  install -d  $(DESTDIR)/usr/bin/tests_cryptodev
++  for bin in $(hostprogs); do \
++  install -m 755 $${bin} $(DESTDIR)/usr/bin/tests_cryptodev/; \
++  done
++
+ check: $(hostprogs)
+   ./cipher
+   ./hmac
+@@ -28,6 +34,8 @@ check: $(hostprogs)
+   ./cipher-gcm
+   ./cipher-aead
+ 
++testprogs: $(hostprogs)
++
+ clean:
+   rm -f *.o *~ $(hostprogs)
+ 
+-- 
+1.7.5.4
+
diff --git 
a/meta/recipes-kernel/cryptodev/files/0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch
 
b/meta/recipes-kernel/cryptodev/files/0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch
new file mode 100644
index 000..f5ab8b4
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0002-Fix-tests-Makefile-usage-of-LDLIBS-vs.-LDFLAGS.patch
@@ -0,0 +1,29 @@
+From 47ff1eb9bb4f872c1d731b93d334ee5865bf3439 Mon Sep 17 00:00:00 2001
+From: Denys Dmytriyenko de...@ti.com
+Date: Sun, 6 Apr 2014 22:16:30 -0400
+Subject: [PATCH] Fix tests Makefile usage of LDLIBS vs. LDFLAGS
+
+Libraries must come after objects, as link order matters, especially
+when using linker flags like -Wl,--as-needed.
+
+Signed-off-by: Denys Dmytriyenko de...@ti.com
+
+Upstream-Status: Pending
+---
+ tests/Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tests/Makefile b/tests/Makefile
+index cd202af..67c3c83 100644
+--- a/tests/Makefile
 b/tests/Makefile
+@@ -39,5 +39,5 @@ testprogs: $(hostprogs)
+ clean:
+   rm -f *.o *~ $(hostprogs)
+ 
+-${comp_progs}: LDFLAGS += -lssl -lcrypto
++${comp_progs}: LDLIBS += -lssl -lcrypto
+ ${comp_progs}: %: %.o openssl_wrapper.o
+-- 
+1.9.1
+
-- 
1.9.1

Re: [OE-core] [dora][PATCH] opkg-utils: Update to latest git master

2014-04-03 Thread Denys Dmytriyenko 
On Tue, Apr 01, 2014 at 02:04:03PM +0100, Paul Barker wrote:
 On 1 April 2014 13:29, Paul Barker p...@paulbarker.me.uk wrote:
  On 1 April 2014 01:58, Denys Dmytriyenko de...@denix.org wrote:
  From: Denys Dmytriyenko de...@ti.com
 
  The latest commit in opkg-utils allows packages created by opkg-build to 
  be read
  by dpkg-deb again.
 
  (Based on OE-Core master rev: 219944af2700ce9dbc425fac384cd32b0a802123,
  but all of the update-alternative fixes from master are skipped)
 
  Signed-off-by: Denys Dmytriyenko de...@ti.com
  Cc: Paul Barker p...@paulbarker.me.uk
  ---
   meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb 
  b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
  index 279cb74..fef0d13 100644
  --- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
  +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
  @@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = 
  file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
   
  file://opkg.py;beginline=1;endline=18;md5=15917491ad6bf7acc666ca5f7cc1e083
   RDEPENDS_${PN} = python python-shell python-io python-math python-crypt 
  python-logging python-fcntl python-subprocess python-pickle 
  python-compression python-textutils python-stringold
   RDEPENDS_${PN}_class-native = 
  -SRCREV = 757a1664a440c60e8126443bf984e4bdf374c327
  +SRCREV = c33b217016ee911718b10c9d57f9912935baf5a9
   PV = 0.1.8+git${SRCPV}
 
   SRC_URI = git://git.yoctoproject.org/opkg-utils \
  --
  1.9.1
 
 
  Personally I would prefer rebasing the existing patch and fixing the
  merge conflict, maintaining the patch author and existing sign offs
  and adding your sign off to the end. I don't know if there's a policy
  on this for Yocto Project.

Of course you would, wouldn't you? :) I'm not looking for any extra credit 
here, but it wasn't trivial to merge the existing commit while backporting to 
dora and re-creating it was much easier. There were past precedents of that, 
where backport fixes were based on the commit, instead of the actual direct 
merge or cherry-pick of it...


  I've Cc'd Robert Yang as he's the stable branch maintainer for Dora as
  per https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance
 
 
 Infact, NACK on this. opkg-utils/Makefile @
 c33b217016ee911718b10c9d57f9912935baf5a9 lists update-alternatives to
 be installed on 'make install'.
 
 If you want just this fix, you need to keep SRCREV as is and add the
 change from c33b217016ee911718b10c9d57f9912935baf5a9 as a new patch
 within oe-core.

Well, I've been using this patch in dora for some time now and it works just 
fine. But I understand there might be a conflict between update-alternatives, 
so one of the possible workarounds would be to remove the new binary from the 
package. Although that would make it even less of a backport and rather a new 
implementation on its own... Anyway, this dpkg-deb strictness is just so 
annoying!

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] alsa-tools: Enable GTK support for X11 and Wayland

2014-04-01 Thread Denys Dmytriyenko 
On Tue, Apr 01, 2014 at 02:08:00PM -0300, Otavio Salvador wrote:
 Signed-off-by: Otavio Salvador ota...@ossystems.com.br
 ---
 This patch depends on the alsa-tools one I sent some minutes ago
 
  meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb 
 b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
 index 4f64a38..fdbe82a 100644
 --- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
 +++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.27.bb
 @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
 file://hdsploader/COPYING;md5=94d55d512a9ba36caa9b7df079bae1
  SRC_URI = ftp://ftp.alsa-project.org/pub/tools/alsa-tools-${PV}.tar.bz2 \
 file://mips_has_no_io_h.patch \
 file://autotools.patch \
 -   ${@base_contains('DISTRO_FEATURES', 'x11', '', 
 'file://makefile_no_gtk.patch', d)}
 +   ${@base_any_contains('DISTRO_FEATURES', 'x11', '', 
 'file://makefile_no_gtk.patch', d)}

What's the reason to use any_contains here?


  SRC_URI[md5sum] = 1ea381d00a6069a98613aa7effa4cb51
  SRC_URI[sha256sum] = 
 6562611b5a6560712f109e09740a9d4fa47296b07ed9590cb44139c5f154ada2
 @@ -20,7 +20,7 @@ inherit autotools-brokensep
  
  EXTRA_OEMAKE += GITCOMPILE_ARGS='--host=${HOST_SYS} --build=${BUILD_SYS} 
 --target=${TARGET_SYS} --with-libtool-sysroot=${STAGING_DIR_HOST} 
 --prefix=${prefix}'
  
 -PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'x11', 'gtk+', '', 
 d)}
 +PACKAGECONFIG ??= ${@base_any_contains('DISTRO_FEATURES', 'x11', 'gtk+', 
 '', d)}

Same here - what's the reason for the change?


  PACKAGECONFIG[gtk+] = ,,gtk+ gtk+3,
  
  # configure.ac/.in doesn't exist so force copy
 -- 
 1.9.1
 
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [dora][PATCH] opkg-utils: Update to latest git master

2014-03-31 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

The latest commit in opkg-utils allows packages created by opkg-build to be read
by dpkg-deb again.

(Based on OE-Core master rev: 219944af2700ce9dbc425fac384cd32b0a802123,
but all of the update-alternative fixes from master are skipped)

Signed-off-by: Denys Dmytriyenko de...@ti.com
Cc: Paul Barker p...@paulbarker.me.uk
---
 meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb 
b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 279cb74..fef0d13 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
file://opkg.py;beginline=1;endline=18;md5=15917491ad6bf7acc666ca5f7cc1e083
 RDEPENDS_${PN} = python python-shell python-io python-math python-crypt 
python-logging python-fcntl python-subprocess python-pickle python-compression 
python-textutils python-stringold
 RDEPENDS_${PN}_class-native = 
-SRCREV = 757a1664a440c60e8126443bf984e4bdf374c327
+SRCREV = c33b217016ee911718b10c9d57f9912935baf5a9
 PV = 0.1.8+git${SRCPV}
 
 SRC_URI = git://git.yoctoproject.org/opkg-utils \
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] udev-extraconf: update mount.sh to use /run/media instead of /media

2014-03-31 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

This is done to work around the issue of auto-mounting block devices
(i.e. SD cards) when root filesystem is still in read-only mode and
creating /media/device mount-points by udev is not possible. That
is due to udev (/etc/rcS.d/S03udev) getting started earlier than
checkroot (/etc/rcS.d/S10checkroot.sh) gets a chance to re-mount the
rootfs as read-write.

Although, canonical FHS specifies /media/device as a mount point
for removable media devices, the latest 2.3 version was released in
2004 and since then FreeDesktop/udisks and other tools adopted the
new /run/media/user/device location. That was done to overcome
read-only rootfs limitation, since /run is usually a tmpfs mounted
partition, plus avoid name-clash between users.

For our embedded systems environment we assume single-user operation
and hence simplify mount point to just /run/media/device. But for
proper per-user mounting to /run/media/user/device, some sort of
session management is required along with the tool like udisks, that
is out of scope of this simple udev-based auto-mounting.

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
v2 - drop PR, bump PV, elaborate on session/user mounting option

 meta/recipes-core/udev/udev-extraconf/mount.sh | 14 +++---
 .../udev/{udev-extraconf_1.0.bb = udev-extraconf_1.1.bb}  |  2 --
 2 files changed, 7 insertions(+), 9 deletions(-)
 rename meta/recipes-core/udev/{udev-extraconf_1.0.bb = udev-extraconf_1.1.bb} 
(99%)

diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index cb57e47..3e4f21f 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -20,7 +20,7 @@ done
 automount() {  
name=`basename $DEVNAME`
 
-   ! test -d /media/$name  mkdir -p /media/$name
+   ! test -d /run/media/$name  mkdir -p /run/media/$name
# Silent util-linux's version of mounting auto
if [ x`readlink $MOUNT` = x/bin/mount.util-linux ] ;
then
@@ -38,12 +38,12 @@ automount() {
;;
esac
 
-   if ! $MOUNT -t auto $DEVNAME /media/$name
+   if ! $MOUNT -t auto $DEVNAME /run/media/$name
then
-   #logger mount.sh/automount $MOUNT -t auto $DEVNAME 
\/media/$name\ failed!
-   rm_dir /media/$name
+   #logger mount.sh/automount $MOUNT -t auto $DEVNAME 
\/run/media/$name\ failed!
+   rm_dir /run/media/$name
else
-   logger mount.sh/automount Auto-mount of [/media/$name] 
successful
+   logger mount.sh/automount Auto-mount of [/run/media/$name] 
successful
touch /tmp/.automount-$name
fi
 }
@@ -60,7 +60,7 @@ rm_dir() {
 
 # No ID_FS_TYPE for cdrom device, yet it should be mounted
 name=`basename $DEVNAME`
-[ -e /sys/block/$name/device/media ]  media_type=`cat 
/sys/block/$name/device/media`
+[ -e /sys/block/$name/device/run/media ]  media_type=`cat 
/sys/block/$name/device/run/media`
 
 if [ $ACTION = add ]  [ -n $DEVNAME ]  [ -n $ID_FS_TYPE -o 
$media_type = cdrom ]; then
if [ -x $PMOUNT ]; then
@@ -87,5 +87,5 @@ if [ $ACTION = remove ]  [ -x $UMOUNT ]  [ -n 
$DEVNAME ]; then

# Remove empty directories from auto-mounter
name=`basename $DEVNAME`
-   test -e /tmp/.automount-$name  rm_dir /media/$name
+   test -e /tmp/.automount-$name  rm_dir /run/media/$name
 fi
diff --git a/meta/recipes-core/udev/udev-extraconf_1.0.bb 
b/meta/recipes-core/udev/udev-extraconf_1.1.bb
similarity index 99%
rename from meta/recipes-core/udev/udev-extraconf_1.0.bb
rename to meta/recipes-core/udev/udev-extraconf_1.1.bb
index 3810b28..d69056d 100644
--- a/meta/recipes-core/udev/udev-extraconf_1.0.bb
+++ b/meta/recipes-core/udev/udev-extraconf_1.1.bb
@@ -4,8 +4,6 @@ LICENSE = MIT
 LIC_FILES_CHKSUM = 
file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
 
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
 
-PR = r16
-
 SRC_URI =  \
file://automount.rules \
file://mount.sh \
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] OE monthy today (?)

2014-03-31 Thread Denys Dmytriyenko 
On Tue, Apr 01, 2014 at 12:04:16AM -0400, Trevor Woerner wrote:
 ...in roughly 12 hours from now?

?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] [RFC] udev-extraconf: update mount.sh to use /run/media instead of /media

2014-03-29 Thread Denys Dmytriyenko 
On Sat, Mar 29, 2014 at 12:17:23PM -0300, Otavio Salvador wrote:
 Hello Denys,
 
 On Fri, Mar 28, 2014 at 6:29 PM, Denys Dmytriyenko de...@denix.org wrote:
  From: Denys Dmytriyenko de...@ti.com
 
  This is done to work around the issue of auto-mounting block devices
  (i.e. SD cards) when root filesystem is still in read-only mode and
  creating /media/device mount-points by udev is not possible. That
  is due to udev (/etc/rcS.d/S03udev) getting started earlier than
  checkroot (/etc/rcS.d/S10checkroot.sh) gets a chance to re-mount the
  rootfs as read-write.
 
  Although, canonical FHS specifies /media/device as a mount point
  for removable media devices, the latest 2.3 version was released in
  2004 and since then FreeDesktop/udisks and other tools adopted the
  new /run/media/user/device location. That was done to overcome
  read-only rootfs limitation, since /run is usually a tmpfs mounted
  partition, plus avoid name-clash between users.
 
 Agreed.
 
  For our embedded systems environment we assume single-user operation
  and hence simplify mount point to just /run/media/device.
 
 Please don't. I have customers using multiple users in an embedded
 device and so I think it is better to adopt udisks standard here
 instead of diverging from it without a reasoning.

I guess I should have phrased it a bit better...

This part is a system-wide automount. It gets to run even when no user is 
logged in. In order to do per-user mounting, some sort of session management 
is required. For example, udisks, we both mentioned, starts along with the 
session, when a user logs in, hence allowing per-user mounts.

Since this approach uses udev and gets triggered on addition or removal of 
block devices, described in the corresponding rules, it happens on system 
level and is not dependant on a session or logged in user. When a session 
based approach is used with udisks, these rules should be disabled though.

The two approaches are rather mutually exclusive, but both are valid. There 
are cases when this system-level automount is desired (e.g. in industrial use 
cases) since there are no users are ever expected to log in or interact with 
the system.

So, this is not meant to replace or provide session-based mounting...


 ...
  diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
  b/meta/recipes-core/udev/udev-extraconf/mount.sh
  index cb57e47..3e4f21f 100644
  --- a/meta/recipes-core/udev/udev-extraconf/mount.sh
  +++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
  @@ -20,7 +20,7 @@ done
   automount() {
  name=`basename $DEVNAME`
 
  -   ! test -d /media/$name  mkdir -p /media/$name
  +   ! test -d /run/media/$name  mkdir -p /run/media/$name
 
 Please see above...
 
 ...
 
  --- a/meta/recipes-core/udev/udev-extraconf_1.0.bb
  +++ b/meta/recipes-core/udev/udev-extraconf_1.0.bb
  @@ -4,7 +4,7 @@ LICENSE = MIT
   LIC_FILES_CHKSUM = 
  file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
   
  file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
 
  -PR = r16
  +PR = r17
 
 Don't change PR; in fact with this change I'd say to move it to 1.1 and drop 
 PR.

I thought about it - either PV or PR needs to change. But I wasn't sure about 
bumping PV...

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/3] Replace ocf-linux with cryptodev-linux

2014-03-28 Thread Denys Dmytriyenko 
On Wed, Mar 26, 2014 at 11:42:39AM -0300, Otavio Salvador wrote:
 Hello Kai,
 
 On Wed, Mar 26, 2014 at 7:15 AM, Kai Kang kai.k...@windriver.com wrote:
  Replace ocf-linux with cryptodev-linux because linux-yocto use 
  cryptodev-linux to implement /dev/crypto.
 
 Thanks for handling it; I was going to address same issue this week so
 we could have it upstreamed and drop the Freescale bbappends for it.

So, we also have a recipe of cryptodev for TI builds. But it's not just a 
header file and we need the actual module to be built and packaged...

I'm rather surprised it was merged so quickly w/o further discussion... :(

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel-arch: Always use ld.bfd to link the kernel

2014-03-28 Thread Denys Dmytriyenko 
On Tue, Apr 23, 2013 at 05:47:29PM +0100, Phil Blundell wrote:
 The kernel's penchant for custom linker scripts means that it doesn't
 generally get on very well with gold.  Make sure we are using the BFD
 linker here no matter what the distro default is set to.
 
 Signed-off-by: Phil Blundell ph...@gnu.org
 ---
  meta/classes/kernel-arch.bbclass |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/meta/classes/kernel-arch.bbclass
 b/meta/classes/kernel-arch.bbclass
 index b3b71ba..4a140eb 100644
 --- a/meta/classes/kernel-arch.bbclass
 +++ b/meta/classes/kernel-arch.bbclass
 @@ -53,6 +53,6 @@ TARGET_AR_KERNEL_ARCH ?= 
  HOST_AR_KERNEL_ARCH ?= ${TARGET_AR_KERNEL_ARCH}
  
  KERNEL_CC = ${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH}
 -KERNEL_LD = ${CCACHE}${HOST_PREFIX}ld ${HOST_LD_KERNEL_ARCH}
 +KERNEL_LD = ${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}
  KERNEL_AR = ${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}

I know this is almost a year-old change.

The question I have is - what should one do when using an external toolchain 
that doesn't have ld.bfd provided? I know these days with gold vs. BFD linker, 
it's common to have ld.bfd, but there could be exceptions...

Should this assignment be conditional, so it's easier to override from 
local.conf or distro?

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/3] Replace ocf-linux with cryptodev-linux

2014-03-28 Thread Denys Dmytriyenko 
On Fri, Mar 28, 2014 at 01:18:32PM -0400, Bruce Ashfield wrote:
 On Fri, Mar 28, 2014 at 1:13 PM, Denys Dmytriyenko de...@denix.org wrote:
  On Wed, Mar 26, 2014 at 11:42:39AM -0300, Otavio Salvador wrote:
  Hello Kai,
 
  On Wed, Mar 26, 2014 at 7:15 AM, Kai Kang kai.k...@windriver.com wrote:
   Replace ocf-linux with cryptodev-linux because linux-yocto use 
   cryptodev-linux to implement /dev/crypto.
 
  Thanks for handling it; I was going to address same issue this week so
  we could have it upstreamed and drop the Freescale bbappends for it.
 
  So, we also have a recipe of cryptodev for TI builds. But it's not just a
  header file and we need the actual module to be built and packaged...
 
 As long as something out of tree can co-exist with in-tree implementations,
 I don't see a problem with an incremental update that builds the module
 as well.

Thanks. So, I already have cryptodev-tests as a separate recipe that builds 
some tests from the same source, as main cryptodev. I guess I can look into 
separating module part into cryptodev-module recipe, which can be optional for 
kernels like linux-yocto that have it already patched in. Will that work?

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/3] Replace ocf-linux with cryptodev-linux

2014-03-28 Thread Denys Dmytriyenko 
On Fri, Mar 28, 2014 at 05:22:14PM +, Richard Purdie wrote:
 On Fri, 2014-03-28 at 13:13 -0400, Denys Dmytriyenko wrote:
  On Wed, Mar 26, 2014 at 11:42:39AM -0300, Otavio Salvador wrote:
   Hello Kai,
   
   On Wed, Mar 26, 2014 at 7:15 AM, Kai Kang kai.k...@windriver.com wrote:
Replace ocf-linux with cryptodev-linux because linux-yocto use 
cryptodev-linux to implement /dev/crypto.
   
   Thanks for handling it; I was going to address same issue this week so
   we could have it upstreamed and drop the Freescale bbappends for it.
  
  So, we also have a recipe of cryptodev for TI builds. But it's not just a 
  header file and we need the actual module to be built and packaged...
  
  I'm rather surprised it was merged so quickly w/o further discussion... :(
 
 From my perspective, the ocf version looked dead and I had several
 people saying this was the right thing to do with nobody saying
 otherwise, both here on list and in some conversations I had with
 people. With the release approaching, it was kind of late to do it
 equally, it did appear to be the right thing to switch to so I got on
 and tested and then merged it.
 
 I don't consider things set in stone, I think we can build upon this
 incrementally.

Thanks. I'll try to work an incremental solution, then, so it works for us and 
doesn't break other use cases - please see my reply to Bruce.

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] cryptodev-linux: add recipe

2014-03-28 Thread Denys Dmytriyenko 
On Wed, Mar 26, 2014 at 06:15:57PM +0800, Kai Kang wrote:
 Yocto kernel linux-yocto uses cryptodev-linux to use device /dev/crypto.
 So add cryptodev-linux which is one alternative of ocf-linux and then
 remove ocf-linux later.

Quick question - is it native-only recipe? Does it expect cryptodev module to 
be patched into kernel? Is this what the above description implies - 
linux-yocto uses cryptodev-linux?

From the looks of it, the recipe only installs a header and doesn't even build 
the out-of-tree module for cryptodev, that cryptodev-linux provides...


 Signed-off-by: Kai Kang kai.k...@windriver.com
 ---
  .../openssl/cryptodev-linux_1.6.bb | 22 
 ++
  1 file changed, 22 insertions(+)
  create mode 100644 meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb
 
 diff --git a/meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb 
 b/meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb
 new file mode 100644
 index 000..320716d
 --- /dev/null
 +++ b/meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb
 @@ -0,0 +1,22 @@
 +SUMMARY = A /dev/crypto device driver
 +HOMEPAGE = http://cryptodev-linux.org/;
 +
 +LICENSE = GPLv2
 +LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263
 +
 +SRC_URI = http://download.gna.org/cryptodev-linux/${BPN}-${PV}.tar.gz;
 +
 +SRC_URI[md5sum] = eade38998313c25fd7934719cdf8a2ea
 +SRC_URI[sha256sum] = 
 75f1425c8ea1f8cae523905a5a046a35092327a6152800b0b86efc4e56fb3e2f
 +
 +do_compile() {
 + :
 +}
 +
 +# Just install cryptodev.h which is the only header file needed to be 
 exported
 +do_install() {
 + install -D ${S}/crypto/cryptodev.h ${D}${includedir}/crypto/cryptodev.h
 +}
 +
 +ALLOW_EMPTY_${PN} = 1
 +BBCLASSEXTEND = native nativesdk
 -- 
 1.8.1.2
 
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] weston : refactor to identify EGL, cairoglesv2 support

2014-03-28 Thread Denys Dmytriyenko 
On Fri, Mar 28, 2014 at 11:02:37AM -0300, Otavio Salvador wrote:
 From: Prabhu Sundararaj prabhu.sundara...@freescale.com
 
 Signed-off-by: Prabhu Sundararaj prabhu.sundara...@freescale.com
 Signed-off-by: Otavio Salvador ota...@ossystems.com.br
 ---
  meta/recipes-graphics/wayland/weston_1.4.0.bb | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)
 
 diff --git a/meta/recipes-graphics/wayland/weston_1.4.0.bb 
 b/meta/recipes-graphics/wayland/weston_1.4.0.bb
 index e0c354d..5213166 100644
 --- a/meta/recipes-graphics/wayland/weston_1.4.0.bb
 +++ b/meta/recipes-graphics/wayland/weston_1.4.0.bb
 @@ -23,13 +23,12 @@ EXTRA_OECONF = --enable-setuid-install \
  --enable-simple-clients \
  --enable-clients \
  --enable-demo-clients-install \
 ---disable-simple-egl-clients \
  --disable-libunwind \
  --disable-rpi-compositor \
  --disable-rdp-compositor
  
  
 -PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms fbdev 
 wayland', '', d)} \
 +PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms fbdev 
 wayland egl', '', d)} \
 ${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} 
 \
 ${@base_contains('DISTRO_FEATURES', 'pam', 'launch', '', 
 d)} \

 @@ -39,7 +38,7 @@ PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 
 'wayland', 'kms fbdev way
  # Weston on KMS
  PACKAGECONFIG[kms] = --enable-drm-compositor,--disable-drm-compositor,drm 
 udev virtual/mesa mtdev
  # Weston on Wayland (nested Weston)
 -PACKAGECONFIG[wayland] = --enable-wayland-compositor,--disable-egl 
 --disable-wayland-compositor,virtual/mesa
 +PACKAGECONFIG[wayland] = 
 --enable-wayland-compositor,--disable-wayland-compositor,virtual/mesa
  # Weston on X11
  PACKAGECONFIG[x11] = 
 --enable-x11-compositor,--disable-x11-compositor,virtual/libx11 libxcb 
 libxcb libxcursor cairo
  # Headless Weston
 @@ -50,6 +49,10 @@ PACKAGECONFIG[fbdev] = 
 --enable-fbdev-compositor,--disable-fbdev-compositor,ude
  PACKAGECONFIG[launch] = 
 --enable-weston-launch,--disable-weston-launch,libpam drm
  # VA-API desktop recorder
  PACKAGECONFIG[vaapi] = 
 --enable-vaapi-recorder,--disable-vaapi-recorder,libva
 +# Weston with EGL support
 +PACKAGECONFIG[egl] = --enable-egl --enable-simple-egl-clients,--disable-egl 
 --disable-simple-egl-clients,virtual/egl
 +# Weston with cairo glesv2 support
 +PACKAGECONFIG[cairo-glesv2] = --with-cairo-glesv2,--with-cairo=image,cairo

Thanks! This was something I was also looking at recently. I'll give it a shot 
in my testing.

-- 
Denys

  do_install_append() {
   # Weston doesn't need the .la files to load modules, so wipe them
 -- 
 1.9.1
 
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] [RFC] udev-extraconf: update mount.sh to use /run/media instead of /media

2014-03-28 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

This is done to work around the issue of auto-mounting block devices
(i.e. SD cards) when root filesystem is still in read-only mode and
creating /media/device mount-points by udev is not possible. That
is due to udev (/etc/rcS.d/S03udev) getting started earlier than
checkroot (/etc/rcS.d/S10checkroot.sh) gets a chance to re-mount the
rootfs as read-write.

Although, canonical FHS specifies /media/device as a mount point
for removable media devices, the latest 2.3 version was released in
2004 and since then FreeDesktop/udisks and other tools adopted the
new /run/media/user/device location. That was done to overcome
read-only rootfs limitation, since /run is usually a tmpfs mounted
partition, plus avoid name-clash between users.

For our embedded systems environment we assume single-user operation
and hence simplify mount point to just /run/media/device.

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 meta/recipes-core/udev/udev-extraconf/mount.sh | 14 +++---
 meta/recipes-core/udev/udev-extraconf_1.0.bb   |  2 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index cb57e47..3e4f21f 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -20,7 +20,7 @@ done
 automount() {  
name=`basename $DEVNAME`
 
-   ! test -d /media/$name  mkdir -p /media/$name
+   ! test -d /run/media/$name  mkdir -p /run/media/$name
# Silent util-linux's version of mounting auto
if [ x`readlink $MOUNT` = x/bin/mount.util-linux ] ;
then
@@ -38,12 +38,12 @@ automount() {
;;
esac
 
-   if ! $MOUNT -t auto $DEVNAME /media/$name
+   if ! $MOUNT -t auto $DEVNAME /run/media/$name
then
-   #logger mount.sh/automount $MOUNT -t auto $DEVNAME 
\/media/$name\ failed!
-   rm_dir /media/$name
+   #logger mount.sh/automount $MOUNT -t auto $DEVNAME 
\/run/media/$name\ failed!
+   rm_dir /run/media/$name
else
-   logger mount.sh/automount Auto-mount of [/media/$name] 
successful
+   logger mount.sh/automount Auto-mount of [/run/media/$name] 
successful
touch /tmp/.automount-$name
fi
 }
@@ -60,7 +60,7 @@ rm_dir() {
 
 # No ID_FS_TYPE for cdrom device, yet it should be mounted
 name=`basename $DEVNAME`
-[ -e /sys/block/$name/device/media ]  media_type=`cat 
/sys/block/$name/device/media`
+[ -e /sys/block/$name/device/run/media ]  media_type=`cat 
/sys/block/$name/device/run/media`
 
 if [ $ACTION = add ]  [ -n $DEVNAME ]  [ -n $ID_FS_TYPE -o 
$media_type = cdrom ]; then
if [ -x $PMOUNT ]; then
@@ -87,5 +87,5 @@ if [ $ACTION = remove ]  [ -x $UMOUNT ]  [ -n 
$DEVNAME ]; then

# Remove empty directories from auto-mounter
name=`basename $DEVNAME`
-   test -e /tmp/.automount-$name  rm_dir /media/$name
+   test -e /tmp/.automount-$name  rm_dir /run/media/$name
 fi
diff --git a/meta/recipes-core/udev/udev-extraconf_1.0.bb 
b/meta/recipes-core/udev/udev-extraconf_1.0.bb
index 3810b28..bae997c 100644
--- a/meta/recipes-core/udev/udev-extraconf_1.0.bb
+++ b/meta/recipes-core/udev/udev-extraconf_1.0.bb
@@ -4,7 +4,7 @@ LICENSE = MIT
 LIC_FILES_CHKSUM = 
file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
 
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
 
-PR = r16
+PR = r17
 
 SRC_URI =  \
file://automount.rules \
-- 
1.8.3.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] openssl: add Aarch64 bie-endian support

2013-10-14 Thread Denys Dmytriyenko 
On Sat, Oct 12, 2013 at 02:59:19PM -0300, Otavio Salvador wrote:
 On Sat, Oct 12, 2013 at 7:17 AM, Fathi Boudra fathi.bou...@linaro.org wrote:
  Signed-off-by: Victor Kamensky victor.kamen...@linaro.org
  Signed-off-by: Fathi Boudra fathi.bou...@linaro.org
 ...
  --- a/meta/recipes-connectivity/openssl/openssl_1.0.1e.bb
  +++ b/meta/recipes-connectivity/openssl/openssl_1.0.1e.bb
  @@ -6,7 +6,7 @@ DEPENDS += ocf-linux
 
   CFLAG += -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
 
  -PR = ${INC_PR}.0
  +PR = ${INC_PR}.1
 
   LIC_FILES_CHKSUM = file://LICENSE;md5=f9a8f968107345e0b75aa8c2ecaa7ec8
 
 Please don't change PR here; this is not need anymore for general use
 (but exceptions).

And please correct the typo in the subject - it's big-endian, not bie-endian. 
Or did you mean bi-endian?

-- 
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [for dylan][PATCH] kernel.bbclass: Correct post(inst|rm) package association

2013-10-11 Thread Denys Dmytriyenko 
On Fri, Oct 11, 2013 at 10:33:03AM +0100, Paul Eggleton wrote:
 On Friday 04 October 2013 23:56:18 Paul Eggleton wrote:
  On Friday 04 October 2013 14:41:16 Denys Dmytriyenko wrote:
   Ping. Is Dylan still alive?
  
  It is yes. I pushed a paule/dylan-next poky-contrib branch the other day
  including this fix but haven't had a chance to run it through the
  autobuilder yet (been busy with 1.5 work). Will try to get it done next
  week.
 
 FYI the patch has now been merged to the dylan branch along with a few other 
 fixes.

Thanks, Paul!

-- 
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [for dylan][PATCH] kernel.bbclass: Correct post(inst|rm) package association

2013-10-04 Thread Denys Dmytriyenko 
Ping. Is Dylan still alive?


On Tue, Sep 24, 2013 at 12:58:20PM -0500, Franklin S. Cooper Jr wrote:
 From: Darren Hart dvh...@linux.intel.com
 
 Fixes [YOCTO #4991]
 
 The kernel image is installed as part of the kernel-image package, but
 the symlink creation/removal via alternatives is being done in
 pkg_post(inst|rm)_kernel-base.
 
 Move the postinst alternatives logic into the kernel-image functions.
 
 Signed-off-by: Darren Hart dvh...@linux.intel.com
 Signed-off-by: Saul Wold s...@linux.intel.com
 ---
  meta/classes/kernel.bbclass |   29 +
  1 files changed, 13 insertions(+), 16 deletions(-)
 
 diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
 index 3320747..c417038 100644
 --- a/meta/classes/kernel.bbclass
 +++ b/meta/classes/kernel.bbclass
 @@ -237,14 +237,6 @@ do_savedefconfig() {
  do_savedefconfig[nostamp] = 1
  addtask savedefconfig after do_configure
  
 -pkg_postinst_kernel-base () {
 - update-alternatives --install /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} 
 ${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} 
 || true
 -}
 -
 -pkg_postrm_kernel-base () {
 - update-alternatives --remove ${KERNEL_IMAGETYPE} 
 ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} || true
 -}
 -
  inherit cml1
  
  EXPORT_FUNCTIONS do_compile do_install do_configure
 @@ -272,14 +264,19 @@ ALLOW_EMPTY_kernel-modules = 1
  DESCRIPTION_kernel-modules = Kernel modules meta package
  
  pkg_postinst_kernel-image () {
 -if [ ! -e $D/lib/modules/${KERNEL_VERSION} ]; then
 - mkdir -p $D/lib/modules/${KERNEL_VERSION}
 -fi
 -if [ -n $D ]; then
 - depmodwrapper -a -b $D ${KERNEL_VERSION}
 -else
 - depmod -a ${KERNEL_VERSION}
 -fi
 + update-alternatives --install /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} 
 ${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} 
 || true
 + if [ ! -e $D/lib/modules/${KERNEL_VERSION} ]; then
 + mkdir -p $D/lib/modules/${KERNEL_VERSION}
 + fi
 + if [ -n $D ]; then
 + depmodwrapper -a -b $D ${KERNEL_VERSION}
 + else
 + depmod -a ${KERNEL_VERSION}
 + fi
 +}
 +
 +pkg_postrm_kernel-image () {
 + update-alternatives --remove ${KERNEL_IMAGETYPE} 
 ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} || true
  }
  
  PACKAGESPLITFUNCS_prepend = split_kernel_packages 
 -- 
 1.7.0.4
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED

2013-09-27 Thread Denys Dmytriyenko 
On Fri, Sep 27, 2013 at 11:06:42AM +0100, Richard Purdie wrote:
 On Fri, 2013-09-27 at 10:20 +0100, Richard Purdie wrote:
  On Thu, 2013-09-26 at 18:40 -0400, Denys Dmytriyenko wrote:
   On Tue, Feb 12, 2013 at 01:36:44PM -0600, Jason Wessel wrote:
If you never use sstate and always build everything from scratch you
will never see this problem.  However, if you use sstate and build
directories that last a long time eventually you can end up with the
scenario where libtool gets a hard coded path in it for sed, and sed
may not exist.  The reason you don't see this problem to often if you
generally build from scratch is that libtool builds before sed and
will pickup the host's /bin/sed.

The way to reproduce the issue is:

bitbake some_image
bitbake -c cleansstate libtool-native
bitbake sed-native
bitbake libtool-native
bitbake -c clean sed-native
bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE

In my case I used modphp, which doesn't exist in the oe-core. You will
end up with a strange looking error like:

| make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
| 
/opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
 line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: 
No such file or directory
   
   Sorry for bringing up this old thread. I'm seeing these and similar 
   errors now 
   (nothing really changed in my setup, but some race got them exposed).
   
   I do see that the proposed patch got merged all the way back in February. 
   But 
   looks like it wasn't enough.
   
   I've just seen this error about missing sysroots/x86_64-linux//bin/sed 
   coming 
   from nativesdk-gettext compilation while calling i686-linux-libtool, i.e. 
   the 
   nativesdk version of libtool. Should be easy to duplicate the below patch 
   for 
   libtool from native to nativesdk recipe.
   
   And another error was from sysroots/x86_64-linux/usr/bin/opkg-build 
   during 
   do_package_write of some other package. Should opkg-utils-native be 
   patched 
   the same?
  
  Was this in master with
  http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=32edeb391f2107bb66b361cdcd4b8d4447731c33
   applied?
 
 To answer my own question, the above introduced a bug since I'd
 forgotten native doesn't use the site files. It probably should use at
 least a minimal one so I've sent out a patch for that.

Richard,

I was getting that on dylan and master, but the above patch was not in yet. 
I'll give this one and the new native site config patch a try. Thanks!

-- 
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED

2013-09-26 Thread Denys Dmytriyenko 
On Tue, Feb 12, 2013 at 01:36:44PM -0600, Jason Wessel wrote:
 If you never use sstate and always build everything from scratch you
 will never see this problem.  However, if you use sstate and build
 directories that last a long time eventually you can end up with the
 scenario where libtool gets a hard coded path in it for sed, and sed
 may not exist.  The reason you don't see this problem to often if you
 generally build from scratch is that libtool builds before sed and
 will pickup the host's /bin/sed.
 
 The way to reproduce the issue is:
 
 bitbake some_image
 bitbake -c cleansstate libtool-native
 bitbake sed-native
 bitbake libtool-native
 bitbake -c clean sed-native
 bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE
 
 In my case I used modphp, which doesn't exist in the oe-core. You will
 end up with a strange looking error like:
 
 | make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
 | 
 /opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
  line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: No 
 such file or directory

Sorry for bringing up this old thread. I'm seeing these and similar errors now 
(nothing really changed in my setup, but some race got them exposed).

I do see that the proposed patch got merged all the way back in February. But 
looks like it wasn't enough.

I've just seen this error about missing sysroots/x86_64-linux//bin/sed coming 
from nativesdk-gettext compilation while calling i686-linux-libtool, i.e. the 
nativesdk version of libtool. Should be easy to duplicate the below patch for 
libtool from native to nativesdk recipe.

And another error was from sysroots/x86_64-linux/usr/bin/opkg-build during 
do_package_write of some other package. Should opkg-utils-native be patched 
the same?

Denys


 The solution is to always use /bin/sed for libtool-native.
 
 Signed-off-by: Jason Wessel jason.wes...@windriver.com
 ---
  .../libtool/libtool-native_2.4.2.bb|3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb 
 b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
 index f12e6a1..18188ef 100644
 --- a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
 +++ b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
 @@ -2,12 +2,13 @@ require libtool-${PV}.inc
  
  DEPENDS = 
  
 -PR = ${INC_PR}.0
 +PR = ${INC_PR}.1
  SRC_URI += file://prefix.patch
  
  inherit native
  
  EXTRA_OECONF =  --with-libtool-sysroot=${STAGING_DIR_NATIVE}
 +CACHED_CONFIGUREVARS += ac_cv_path_SED=/bin/sed
  
  do_configure_prepend () {
   # Remove any existing libtool m4 since old stale versions would break
 -- 
 1.7.1
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] eglibc_2.17.bb: Failure expanding variable SELECTED_OPTIMIZATION[:=]

2013-09-09 Thread Denys Dmytriyenko 
Any ideas or suggestions at this point would be greatly appreciated! Thanks.


On Fri, Sep 06, 2013 at 02:57:41PM -0400, Denys Dmytriyenko wrote:
 Hi,
 
 Has anyone seen this error before? It happens for me quite often, but not 
 always, on Dylan branch during initial parsing:
 
 Parsing recipes...
 ERROR: ExpansionError during parsing 
 .../oe-core/meta/recipes-core/eglibc/eglibc_2.17.bb:
   Failure expanding variable SELECTED_OPTIMIZATION[:=], expression was 
 ${@get_optimization(d)}
   which triggered exception NameError: name 'get_optimization' is not defined
 ERROR: Command execution failed: Exited with 1
 
 
 Looking at the code, I don't see anything suspicious:
 
 # eglibc can't be built without optimization, if someone tries to compile an
 # entire image as -O0, we override it with -O2 here and give a note about it.
 def get_optimization(d):
 selected_optimization = d.getVar(SELECTED_OPTIMIZATION, True)
 if base_contains(SELECTED_OPTIMIZATION, -O0, x, , d) == x:
 bb.note(eglibc can't be built with -O0, -O2 will be used instead.)
 return selected_optimization.replace(-O0, -O2)
 return selected_optimization
 
 SELECTED_OPTIMIZATION := ${@get_optimization(d)}
 
 
 It sounds like by the time SELECTED_OPTIMIZATION tries to make an assignment 
 with immediate var expansion, get_optimization() function is not yet defined.
 
 This happens with high BB_NUM_THREADS and bitbake 1.18. Trying bitbake from 
 master on Dylan gives AttributeError: 'NoneType' object has no attribute 
 'rfind', but that's another story.
 
 Anyone has any clues or suggestions? Thanks.
 
 -- 
 Denys
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] eglibc_2.17.bb: Failure expanding variable SELECTED_OPTIMIZATION[:=]

2013-09-09 Thread Denys Dmytriyenko 
On Mon, Sep 09, 2013 at 04:24:23PM +0100, Richard Purdie wrote:
 On Mon, 2013-09-09 at 09:51 -0400, Denys Dmytriyenko wrote:
  Any ideas or suggestions at this point would be greatly appreciated! Thanks.

Richard,

 I have vague recollections about this from something happening in
 master. Perhaps try with:
 
 http://git.openembedded.org/bitbake/commit/?id=4d50690489ee8dc329a9b0c7bc4ceb29b71e95e9
 
 applied. This might things more deterministic, perhaps always breaking
 or perhaps never.

Ah, good call! Massaging the patch onto 1.18 seems to have solved the parsing 
breakage - it passed 10 out of 10 tries so far. I'll keep testing and run a 
few real builds, but would you be willing to backport it to 1.18? Please let 
me know if you need an updated patch re-submitted. Thanks.


 Have you got two definitions of the get_optimization function?

I grepped through all my layers and eglibc_2.17.inc is the only place where it 
gets defined and used.

-- 
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC][PATCH] mesa-gl: add GL-only Mesa recipe

2013-09-09 Thread Denys Dmytriyenko 
On Mon, Sep 09, 2013 at 04:57:40PM +, Kamble, Nitin A wrote:
 Hi Ross,
   This is a clever way to deal with unnecessary rebuilding of mesa we were 
 seeing earlier. With this mesa-gl, the mesa also need modification to remove 
 gl from the default recipe.
 
 Also looks like there is a need from community for mesa-gl-lib and 
 mesa-gl-headers, as some platforms need just the mesa-gl-headers and not the 
 libs.
 
 Nitin

Ross, Nitin,

This is a great and very welcomed development! This would definitely allow our 
TI machines (and other ARM ones, as you said) to happily co-exist with Mesa 
software rendering.

-- 
Denys


  -Original Message-
  From: openembedded-core-boun...@lists.openembedded.org
  [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
  Of Ross Burton
  Sent: Monday, September 09, 2013 5:27 AM
  To: openembedded-core@lists.openembedded.org
  Subject: [OE-core] [RFC][PATCH] mesa-gl: add GL-only Mesa recipe
  
  Some machines have hardware-specific GL drivers that do EGL and GLES
  (many ARM boards).  Others have their own EGL/GLES drivers and provide a
  Mesa DRI driver (EMGD).  Previously adding Mesa, for software GL/GLX
  rendering in the first case and hardware GLX in the second, involved
  bbappends and changing Mesa to be machine-specific.
  
  By adding a just-GL Mesa the machine definition can combine it with the
  hardware drivers cleanly.
  
  Signed-off-by: Ross Burton ross.bur...@intel.com
  ---
   meta/recipes-graphics/mesa/mesa-gl_9.1.6.bb |5 +
   1 file changed, 5 insertions(+)
   create mode 100644 meta/recipes-graphics/mesa/mesa-gl_9.1.6.bb
  
  diff --git a/meta/recipes-graphics/mesa/mesa-gl_9.1.6.bb b/meta/recipes-
  graphics/mesa/mesa-gl_9.1.6.bb
  new file mode 100644
  index 000..521a830
  --- /dev/null
  +++ b/meta/recipes-graphics/mesa/mesa-gl_9.1.6.bb
  @@ -0,0 +1,5 @@
  +require mesa_${PV}.bb
  +
  +FILESPATH = ${FILE_DIRNAME}/mesa-${PV}:${FILE_DIRNAME}/mesa
  +
  +PACKAGECONFIG ??= dri gl
  --
  1.7.10.4
  
  ___
  Openembedded-core mailing list
  Openembedded-core@lists.openembedded.org
  http://lists.openembedded.org/mailman/listinfo/openembedded-core
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] eglibc_2.17.bb: Failure expanding variable SELECTED_OPTIMIZATION[:=]

2013-09-06 Thread Denys Dmytriyenko 
Hi,

Has anyone seen this error before? It happens for me quite often, but not 
always, on Dylan branch during initial parsing:

Parsing recipes...
ERROR: ExpansionError during parsing 
.../oe-core/meta/recipes-core/eglibc/eglibc_2.17.bb:
  Failure expanding variable SELECTED_OPTIMIZATION[:=], expression was 
${@get_optimization(d)}
  which triggered exception NameError: name 'get_optimization' is not defined
ERROR: Command execution failed: Exited with 1


Looking at the code, I don't see anything suspicious:

# eglibc can't be built without optimization, if someone tries to compile an
# entire image as -O0, we override it with -O2 here and give a note about it.
def get_optimization(d):
selected_optimization = d.getVar(SELECTED_OPTIMIZATION, True)
if base_contains(SELECTED_OPTIMIZATION, -O0, x, , d) == x:
bb.note(eglibc can't be built with -O0, -O2 will be used instead.)
return selected_optimization.replace(-O0, -O2)
return selected_optimization

SELECTED_OPTIMIZATION := ${@get_optimization(d)}


It sounds like by the time SELECTED_OPTIMIZATION tries to make an assignment 
with immediate var expansion, get_optimization() function is not yet defined.

This happens with high BB_NUM_THREADS and bitbake 1.18. Trying bitbake from 
master on Dylan gives AttributeError: 'NoneType' object has no attribute 
'rfind', but that's another story.

Anyone has any clues or suggestions? Thanks.

-- 
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Heads up: _remove in recipe namespace - check your layers

2013-09-02 Thread Denys Dmytriyenko 
On Mon, Sep 02, 2013 at 10:54:20AM +0100, Paul Eggleton wrote:
 Hi all,
 
 With the recent addition of a _remove operator into BitBake in master [1] any 
 use of _remove_ within a name or _remove at the end of a name within recipe 
 namespace (i.e. function and variable names) needs to be changed to avoid 
 unexpected behaviour. This change is now in master and will be in the 
 upcoming 
 release. Please check the layers you maintain and change any instances of 
 these to avoid the use of _remove. You can use the following command to find 
 these (of course ignoring anything that's not in a recipe, bbclass, inc file 
 etc.):
 
   git grep _remove[^a-zA-Z]
 
 In particular I've checked a number of layers that I have fetched locally, 
 and 
 references exist in meta-arago-distro and meta-angstrom, so these will need 
 to 
 be fixed as soon as possible.

Paul,

Thanks for the heads up! While meta-arago is currently based on Dylan, I've
made the necessary change in my layer so it will be ready for the master.
Thanks.

--
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] eglibc-2.17 build breaks with nptl #include nested too deeply

2013-06-05 Thread Denys Dmytriyenko 
Has anyone seen this issue before - my builds are failing with the following:

  from 
../ports/sysdeps/arm/sysdeps/../nptl/pthread_spin_lock.c:23,
  from 
../ports/sysdeps/arm/sysdeps/../nptl/pthread_spin_lock.c:23,
  from ../ports/sysdeps/arm/nptl/pthread_spin_lock.c:23:
../ports/sysdeps/arm/sysdeps/../nptl/pthread_spin_lock.c:23:47: error: #include 
nested too deeply

Google only returns a recent discussion on the Cygwin list:

http://cygwin.1069669.n5.nabble.com/BUG-Ability-to-access-nonexistent-directories-td98708.html

But, I'm building this on Ubuntu 12.04, not Cygwin. Any pointers, while I 
keep digging? Thanks.

-- 
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH dylan, master] Fix meta-toolchain-qte SDK build for x11-less DISTRO

2013-06-05 Thread Denys Dmytriyenko 
Ack, regardless of whether a separate X11DEPENDS variable stays or goes, as we 
had the same fix for our SDKs for some time now (yeah, I'm well behind on 
upstreaming my fixes, sorry).

Acked-by: Denys Dmytriyenko de...@ti.com
Tested-by: Denys Dmytriyenko de...@ti.com

On Wed, Jun 05, 2013 at 09:24:27AM +0200, Nicolas Dechesne wrote:
 When building QTe SDK for a DISTRO that does not have x11 FEATURES,
 building meta-toolchain-qte failed because it unconditionally pulls in
 nativesdk-libx11. The 'culprit' is 
 meta/recipes-qt/qt4/nativesdk-qt4-tools.inc.
 
 The fix is inspired from the following commits:
 
 abf2ab7 dbus: only use x11 if DISTRO_FEATURES has selected it
 ba22cfa cairo: only use x11 if selected in DISTRO_FEATURES
 
 Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
 ---
  meta/recipes-qt/qt4/nativesdk-qt4-tools.inc | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc 
 b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
 index cfc6fd8..3725cac 100644
 --- a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
 +++ b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
 @@ -1,5 +1,6 @@
  DESCRIPTION = SDK tools for Qt/[X11|Mac|Embedded] version 4.x
 -DEPENDS = nativesdk-zlib nativesdk-dbus nativesdk-libx11 qt4-native
 +X11DEPENDS = nativesdk-libx11
 +DEPENDS = nativesdk-zlib nativesdk-dbus qt4-native 
 ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}
  SECTION = libs
  HOMEPAGE = http://qt.nokia.com;
  LICENSE = LGPLv2.1 | GPLv3
 -- 
 1.8.1.2
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] eglibc-2.17 build breaks with nptl #include nested too deeply

2013-06-05 Thread Denys Dmytriyenko 
On Wed, Jun 05, 2013 at 12:04:37PM -0400, Denys Dmytriyenko wrote:
 Has anyone seen this issue before - my builds are failing with the following:
 
   from 
 ../ports/sysdeps/arm/sysdeps/../nptl/pthread_spin_lock.c:23,
   from 
 ../ports/sysdeps/arm/sysdeps/../nptl/pthread_spin_lock.c:23,
   from ../ports/sysdeps/arm/nptl/pthread_spin_lock.c:23:
 ../ports/sysdeps/arm/sysdeps/../nptl/pthread_spin_lock.c:23:47: error: 
 #include nested too deeply
 
 Google only returns a recent discussion on the Cygwin list:
 
 http://cygwin.1069669.n5.nabble.com/BUG-Ability-to-access-nonexistent-directories-td98708.html
 
 But, I'm building this on Ubuntu 12.04, not Cygwin. Any pointers, while I 
 keep digging? Thanks.

Well, a clean build seems to fix it... It's rather unfortunate that 
periodically incremental builds of the master break like that and can't 
recover on their own w/o cleaning up the temp directory.

-- 
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH dylan, master] Fix meta-toolchain-qte SDK build for x11-less DISTRO

2013-06-05 Thread Denys Dmytriyenko 
On Wed, Jun 05, 2013 at 02:43:07PM -0300, Otavio Salvador wrote:
 On Wed, Jun 5, 2013 at 2:23 PM, Nicolas Dechesne 
 nicolas.deche...@linaro.org wrote:
 
 
 
 
  On Wed, Jun 5, 2013 at 7:19 PM, Saul Wold s...@linux.intel.com wrote:
 
  On 06/05/2013 10:12 AM, Otavio Salvador wrote:
 
 
 
 
  On Wed, Jun 5, 2013 at 1:58 PM, Saul Wold s...@linux.intel.com
  mailto:s...@linux.intel.com wrote:
 
  On 06/05/2013 09:32 AM, Nicolas Dechesne wrote:
 
 
  On Wed, Jun 5, 2013 at 6:30 PM, Saul Wold s...@linux.intel.com
  mailto:s...@linux.intel.com
  mailto:s...@linux.intel.com mailto:s...@linux.intel.com
  wrote:
 
   You could just directly put the nativesdk-libx11 in place
  of the
   variable, no need to have the variable there.
 
 
  yes, that's what I had initially, but found it was less easy to
  read...
  with X11DEPENDS it's more 'obvious' that there is something
  special..
  that said, i can make the change if that's really needed.
 
  We do use the X11DEPENDS elsewhere when there are multiple
  dependencies, but I also found cases where we just include the
  dependency directly in the test. I was trying pick a direction:
  single entry no X11DEPENDS, multiple entries use X11DEPENDS.
 
  Comments, flames, ...
 
 
  Yes; I sent this patch in Febuary:
  http://patchwork.openembedded.**org/patch/44759/http://patchwork.openembedded.org/patch/44759/
 
  Please use this one instead of the recent one.
 
 
  Well reading back on that, it looks like I was waiting for an
  EXTRA_OECONF or related change to the autoconf scripts.
 
  Sau!
 
 
  hmm. ok, sorry Otavio, i missed the other patch. I will check on my side
  too about EXTRA_OECONF.
 
 
 Nicolas, don't worry. It is normal to end redoing some stuff.
 
 Last time I checked it had no support in Qt build system; I am not sure if
 it uses or not the host headers (in case they exist) but it needs testing
 to be sure.

I can confirm that it does not link against host X11 when built w/o that 
dependency and nativesdk has no x11 libs/headers. As I previously mentioned, 
we've been using this fix for over 6 months on several releases built on 
different machines w/o problems...

-- 
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] Simplify tune-cortexa*.inc, and add cortex-a5 tuning

2013-06-05 Thread Denys Dmytriyenko 
On Wed, Jun 05, 2013 at 11:52:28AM -0400, Andy Voltz wrote:
 This series puts the common tuning setup in an include and reworks the
 tuning files for each cortex-a* series to use that include. A new variable,
 CORTEX_ID is used to specify which processor is used.
 
 Add a tuning file for the cortex-a5 using this include.

And what about 53, 57 and the newly announced 12? :)

-- 
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH dylan, master] Fix meta-toolchain-qte SDK build for x11-less DISTRO

2013-06-05 Thread Denys Dmytriyenko 
On Wed, Jun 05, 2013 at 05:56:31PM -0300, Otavio Salvador wrote:
 On Wed, Jun 5, 2013 at 5:53 PM, Saul Wold s...@linux.intel.com wrote:
 
  On 06/05/2013 01:10 PM, Otavio Salvador wrote:
 
 
 
 
  On Wed, Jun 5, 2013 at 5:07 PM, Denys Dmytriyenko de...@denix.org
  mailto:de...@denix.org wrote:
 
  On Wed, Jun 05, 2013 at 02:43:07PM -0300, Otavio Salvador wrote:
On Wed, Jun 5, 2013 at 2:23 PM, Nicolas Dechesne 
nicolas.deche...@linaro.org 
  mailto:nicolas.dechesne@**linaro.orgnicolas.deche...@linaro.org
  
 
  wrote:
   



 On Wed, Jun 5, 2013 at 7:19 PM, Saul Wold s...@linux.intel.com
  mailto:s...@linux.intel.com wrote:

 On 06/05/2013 10:12 AM, Otavio Salvador wrote:




 On Wed, Jun 5, 2013 at 1:58 PM, Saul Wold
  s...@linux.intel.com mailto:s...@linux.intel.com
 mailto:s...@linux.intel.com mailto:s...@linux.intel.com
  wrote:

 On 06/05/2013 09:32 AM, Nicolas Dechesne wrote:


 On Wed, Jun 5, 2013 at 6:30 PM, Saul Wold
  s...@linux.intel.com mailto:s...@linux.intel.com
 mailto:s...@linux.intel.com mailto:
  s...@linux.intel.com
 mailto:s...@linux.intel.com
  mailto:s...@linux.intel.com mailto:s...@linux.intel.com
  mailto:s...@linux.intel.com**
 wrote:

  You could just directly put the nativesdk-libx11
  in place
 of the
  variable, no need to have the variable there.


 yes, that's what I had initially, but found it was
  less easy to
 read...
 with X11DEPENDS it's more 'obvious' that there is
  something
 special..
 that said, i can make the change if that's really
  needed.

 We do use the X11DEPENDS elsewhere when there are multiple
 dependencies, but I also found cases where we just
  include the
 dependency directly in the test. I was trying pick a
  direction:
 single entry no X11DEPENDS, multiple entries use
  X11DEPENDS.

 Comments, flames, ...


 Yes; I sent this patch in Febuary:

  http://patchwork.openembedded.org/patch/44759/http://**
  patchwork.openembedded.org/**patch/44759/http://patchwork.openembedded.org/patch/44759/
  

 Please use this one instead of the recent one.


 Well reading back on that, it looks like I was waiting for an
 EXTRA_OECONF or related change to the autoconf scripts.

 Sau!


 hmm. ok, sorry Otavio, i missed the other patch. I will check
  on my side
 too about EXTRA_OECONF.

   
Nicolas, don't worry. It is normal to end redoing some stuff.
   
Last time I checked it had no support in Qt build system; I am
  not sure if
it uses or not the host headers (in case they exist) but it needs
  testing
to be sure.
 
  I can confirm that it does not link against host X11 when built w/o
  that
  dependency and nativesdk has no x11 libs/headers. As I previously
  mentioned,
  we've been using this fix for over 6 months on several releases built
  on
  different machines w/o problems...
 
 
  In this case the patch can be merged 'as is'.
 
 
  I am still concerned about a floating dependency here, imagine the
  following:
 
  Build the toolchain with X11 enabled, nativesdk-libx11 is build, now
  rebuild with X11 disabled, the dependency is gone, but the libraries and
  headers still exist in the sysroot and thus the configure will still enable
  x11 in qte, bad things happen.
 
 
 I expect different distro features to have different build dirs. No?
 
 
  We need to have a disable flag to autotools.
 
 
 The qmake based system does not provide this; so to support it, it will
 need to be a hack ...

I agree with Otavio here - seems like you are after a rare corner case here...

-- 
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv2] u-boot: Add UBOOT_LOCALVERSION to control version string

2013-04-16 Thread Denys Dmytriyenko 
On Tue, Apr 16, 2013 at 11:21:35PM +0100, Richard Purdie wrote:
 On Tue, 2013-04-16 at 11:59 +, Maupin, Chase wrote:
   -Original Message-
   From: Maupin, Chase
   Sent: Thursday, April 11, 2013 8:03 AM
   To: openembedded-core@lists.openembedded.org
   Cc: Maupin, Chase
   Subject: [PATCHv2] u-boot: Add UBOOT_LOCALVERSION to control
   version string
   
   * Add a variable called UBOOT_LOCALVERSION which when set will
 place a version string in the .scmversion file of the u-boot
 sources.  This string will be picked up by the u-boot Makefile
 and will be appended to the u-boot version.  This is done to
 make it easier to identify what revision of the u-boot sources
 are being run.  For example you can use a setting like the
 following to add the short commit id to the u-boot version
 string:
   
   UBOOT_LOCALVERSION = -g${@d.getVar('SRCPV',
   True).partition('+')[2][0:7]}
   
  
  Ping on this patch
 
 These are really enhancements, not bug fixes and are too late for 1.4
 since they came in after the feature freeze.
 
 I'm nervous of them as there have been several iterations and I can't
 easily tell what impact these will have on the different package
 backends, or linux-yocto verses non linux-yocto for example.
 
 Its simply too late and there are other bigger issues I'm worried about.
 I therefore don't want to take this additional risk, sorry.

Richard,

Thanks for the explanation, it's understood.
Do you want to take it after the release? Would you prefer a ping or a new 
submission of this patch?

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][for-danny] kernel bbclass: return to original directory in do_deploy

2013-04-11 Thread Denys Dmytriyenko 
On Thu, Apr 11, 2013 at 12:43:30PM +, Maupin, Chase wrote:
  -Original Message-
  From: Denys Dmytriyenko [mailto:de...@denix.org]
  Sent: Wednesday, April 10, 2013 6:02 PM
  To: Maupin, Chase
  Cc: openembedded-core@lists.openembedded.org
  Subject: Re: [OE-core] [PATCH][for-danny] kernel bbclass: return
  to original directory in do_deploy
  
  Ping.
  
  Ross, is it in your queue for your next danny merge?
 
 I see that one as already being commited to danny

Hmm, where? I don't see it here:

http://cgit.openembedded.org/openembedded-core/log/?h=danny


  On Mon, Mar 18, 2013 at 12:39:19PM -0500, Chase Maupin wrote:
   * During the base kernel_do_deploy function the directory is
 changed to DEPLOYDIR in order to do some cleanup and
  symlinking.
 However, the directory is not changed back to the original
 starting directory ${S} at the end.  For append functions
  this
 means that the starting directory is not ${S} as expected but
 instead ${DEPLOYDIR}.
  
 For functions like the do_deploy_append in
 recipes-kernel/linux/linux-dtb.inc there is an assumption
  that
 you are still in the source directory and not the DEPLOYDIR.
 Without this change the .dtb files are not copied because the
 check for the existence of ${DTS_FILE} which is a relative
 path from the ${S} directory fails.  This means that the .dtb
 files are not copied into the deploy directory and
  subsequently
 the deploy/images directory.
  
 In the log.do_deploy file you will see lines like:
  
   Warning: arch/arm/boot/dts/x.dts is not available!
  
   Signed-off-by: Chase Maupin chase.mau...@ti.com
   ---
meta/classes/kernel.bbclass |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
  
   diff --git a/meta/classes/kernel.bbclass
  b/meta/classes/kernel.bbclass
   index 88ce561..9691c25 100644
   --- a/meta/classes/kernel.bbclass
   +++ b/meta/classes/kernel.bbclass
   @@ -529,6 +529,7 @@ kernel_do_deploy() {
 ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGETYPE}
  
 cp ${COREBASE}/meta/files/deploydir_readme.txt
  ${DEPLOYDIR}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
   + cd -
}
do_deploy[dirs] = ${DEPLOYDIR} ${B}
  
   --
   1.7.0.4
  
  
   ___
   Openembedded-core mailing list
   Openembedded-core@lists.openembedded.org
   http://lists.linuxtogo.org/cgi-
  bin/mailman/listinfo/openembedded-core
 

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel: Add KERNEL_LOCALVERSION to control version string

2013-04-11 Thread Denys Dmytriyenko 
On Thu, Apr 11, 2013 at 08:53:57AM -0400, Bruce Ashfield wrote:
 On Thu, Apr 11, 2013 at 8:44 AM, Maupin, Chase chase.mau...@ti.com wrote:
  -Original Message-
  From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
  Sent: Wednesday, April 10, 2013 7:42 PM
  To: Maupin, Chase
  Cc: Patches and discussions about the oe-core layer
  Subject: Re: [OE-core] [PATCH] kernel: Add KERNEL_LOCALVERSION to
  control version string
 
  On Wed, Apr 10, 2013 at 5:47 PM, Chase Maupin
  chase.mau...@ti.com wrote:
   * Add a variable called KERNEL_LOCALVERSION which when set will
 place a version string in the .scmversion file of the kernel
 sources.  This string will be picked up by the kernel
  Makefile
 and will be appended to the kernel version.  This is done to
 make it easier to identify what revision of the kernel
  sources
 are being run.  For example you can use a setting like the
 following to add the short commit id to the kernel version
 string:
  
   KERNEL_LOCALVERSION = -g${@d.getVar('SRCPV',
  True).partition('+')[2][0:7]}
  
   Signed-off-by: Chase Maupin chase.mau...@ti.com
   ---
meta/classes/kernel.bbclass |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
  
   diff --git a/meta/classes/kernel.bbclass
  b/meta/classes/kernel.bbclass
   index af58887..9757465 100644
   --- a/meta/classes/kernel.bbclass
   +++ b/meta/classes/kernel.bbclass
   @@ -48,6 +48,9 @@ export CMDLINE_CONSOLE =
  console=${@d.getVar(KERNEL_CONSOLE,1) or ttyS0}
  
KERNEL_VERSION = ${@get_kernelversion('${B}')}
  
   +# Setting KERNEL_LOCALVERSION will place a string in the
  .scmversion file
   +# of the kernel tree.  This string will be picked up by the
  build system
   +# of the kernel and appended to the kernel version.
KERNEL_LOCALVERSION ?= 
  
# kernels are generally machine specific
   @@ -210,7 +213,8 @@ kernel_do_configure() {
   # $ scripts/setlocalversion . = +
   # $ make kernelversion = 2.6.37
   # $ make kernelrelease = 2.6.37+
   -   touch ${B}/.scmversion ${S}/.scmversion
   +   echo ${KERNEL_LOCALVERSION}  ${B}/.scmversion
   +   echo ${KERNEL_LOCALVERSION}  ${S}/.scmversion
 
  This would clobber trees that already patch, or otherwise have
  the file in place
  in their source directory.  A test to see if it already exists
  and only echo
  the variable if no one has already set it in their tree would be
  safer.
 
  Good point.  I'll wrap this in a check and submit version 2.  I'll do the 
  same for the U-Boot version as well.
 
 Another option for the kernel is to use a localversion-yocto file. It
 will serve the same purpose and keep us from running afoul of those
 that want scm version to provide a format that is similar to the one
 that the kernel internally generates.
 
 Just a thought. I typically use localversion-foo now for all my
 localversions, and will switch the kernel-yocto over to it in master
 now that all older supported kernels have been pushed off the cliff :)

That would be great once everyone starts using linux-yocto kernels! :) 
Unfortunately that is still not the case...

-- 
Denys

  This will still be overridden by CONFIG_LOCALVERSION, so it is
  safe
  from that angle, but also note that it can be inhibited by
  setting
  # CONFIG_LOCALVERSION_AUTO is not set, in your .config and
  setting LOCALVERSION, but you probably already knew that!
 
  Cheers,
 
  Bruce
 
  
   # Copy defconfig to .config if .config does not exist.
  This allows
   # recipes to manage the .config themselves in
  do_configure_prepend().
   --
   1.7.0.4
  
  
   ___
   Openembedded-core mailing list
   Openembedded-core@lists.openembedded.org
   http://lists.linuxtogo.org/cgi-
  bin/mailman/listinfo/openembedded-core
 
 
 
  --
  Thou shalt not follow the NULL pointer, for chaos and madness
  await
  thee at its end
 
 
 
 --
 Thou shalt not follow the NULL pointer, for chaos and madness await
 thee at its end
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe][meta-oe][PATCH 2/4] xterm: add latest version of xterm

2013-04-10 Thread Denys Dmytriyenko 
On Wed, Apr 10, 2013 at 06:44:21PM -0400, Trevor Woerner wrote:
 On Wed, Apr 10, 2013 at 2:10 PM, Marco koansoftw...@gmail.com wrote:
  Yes, it is copied from meta-openembedded into oe-core
 
 I'm sorry, I thought the [meta-oe] in the subject line implied this
 patch was destined for meta-openembedded, not coming from
 meta-openembedded.

Agree.


 It seems rather confusing that both openembedded-core and
 meta-openembedded use the same mailing list :-)

They are not - meta-openembedded uses the old 
openembedded-de...@lists.openembedded.org list from Classic OE days:
http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/README


 Is openembedded-core sometimes referred to as oe-classic? Or is that
 something else?

That's something else:
http://openembedded.org/wiki/OpenEmbedded-Core


 Do poky and openembedded-core maintain their own meta-hob and
 meta-skeleton components?

http://cgit.openembedded.org/openembedded-core/tree/
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][for-danny] kernel bbclass: return to original directory in do_deploy

2013-04-10 Thread Denys Dmytriyenko 
Ping.

Ross, is it in your queue for your next danny merge?

-- 
Denys


On Mon, Mar 18, 2013 at 12:39:19PM -0500, Chase Maupin wrote:
 * During the base kernel_do_deploy function the directory is
   changed to DEPLOYDIR in order to do some cleanup and symlinking.
   However, the directory is not changed back to the original
   starting directory ${S} at the end.  For append functions this
   means that the starting directory is not ${S} as expected but
   instead ${DEPLOYDIR}.
 
   For functions like the do_deploy_append in
   recipes-kernel/linux/linux-dtb.inc there is an assumption that
   you are still in the source directory and not the DEPLOYDIR.
   Without this change the .dtb files are not copied because the
   check for the existence of ${DTS_FILE} which is a relative
   path from the ${S} directory fails.  This means that the .dtb
   files are not copied into the deploy directory and subsequently
   the deploy/images directory.
 
   In the log.do_deploy file you will see lines like:
 
 Warning: arch/arm/boot/dts/x.dts is not available!
 
 Signed-off-by: Chase Maupin chase.mau...@ti.com
 ---
  meta/classes/kernel.bbclass |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
 index 88ce561..9691c25 100644
 --- a/meta/classes/kernel.bbclass
 +++ b/meta/classes/kernel.bbclass
 @@ -529,6 +529,7 @@ kernel_do_deploy() {
   ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGETYPE}
  
   cp ${COREBASE}/meta/files/deploydir_readme.txt 
 ${DEPLOYDIR}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
 + cd -
  }
  do_deploy[dirs] = ${DEPLOYDIR} ${B}
  
 -- 
 1.7.0.4
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2][for-danny] relocate_sdk.py: allow relocate_sdk.py to work with python 2.4.x

2013-04-01 Thread Denys Dmytriyenko 
From: Jason Wessel jason.wes...@windriver.com

Avoid the chicken / egg problem of an SDK that provides a working
python but requires that version of python to extract itself.  The
RHEL 5.x systems and some other enterprise Linux systems ship with
python 2.4.x as the default python.  We need to at least be able to
extract work executables even if we never use the the host provided
python again.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
 scripts/relocate_sdk.py | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py
index 45d2c24..1d7bbb3 100755
--- a/scripts/relocate_sdk.py
+++ b/scripts/relocate_sdk.py
@@ -55,22 +55,22 @@ def parse_elf_header():
 
 if arch == 32:
 # 32bit
-hdr_struct = struct.Struct(HHILLLIHH)
+hdr_fmt = HHILLLIHH
 hdr_size = 52
 else:
 # 64bit
-hdr_struct = struct.Struct(HHIQQQIHH)
+hdr_fmt = HHIQQQIHH
 hdr_size = 64
 
 e_type, e_machine, e_version, e_entry, e_phoff, e_shoff, e_flags,\
 e_ehsize, e_phentsize, e_phnum, e_shentsize, e_shnum, e_shstrndx =\
-hdr_struct.unpack(elf_header[16:hdr_size])
+struct.unpack(hdr_fmt, elf_header[16:hdr_size])
 
 def change_interpreter(elf_file_name):
 if arch == 32:
-ph_struct = struct.Struct()
+ph_fmt = 
 else:
-ph_struct = struct.Struct(IIQQ)
+ph_fmt = IIQQ
 
  look for PT_INTERP section 
 for i in range(0,e_phnum):
@@ -79,11 +79,11 @@ def change_interpreter(elf_file_name):
 if arch == 32:
 # 32bit
 p_type, p_offset, p_vaddr, p_paddr, p_filesz,\
-p_memsz, p_flags, p_align = ph_struct.unpack(ph_hdr)
+p_memsz, p_flags, p_align = struct.unpack(ph_fmt, ph_hdr)
 else:
 # 64bit
 p_type, p_flags, p_offset, p_vaddr, p_paddr, \
-p_filesz, p_memsz, p_align = ph_struct.unpack(ph_hdr)
+p_filesz, p_memsz, p_align = struct.unpack(ph_fmt, ph_hdr)
 
  change interpreter 
 if p_type == 3:
@@ -104,9 +104,9 @@ def change_interpreter(elf_file_name):
 
 def change_dl_sysdirs():
 if arch == 32:
-sh_struct = struct.Struct(II)
+sh_fmt = II
 else:
-sh_struct = struct.Struct(IIIIQQ)
+sh_fmt = IIIIQQ
 
  read section string table 
 f.seek(e_shoff + e_shstrndx * e_shentsize)
@@ -127,7 +127,7 @@ def change_dl_sysdirs():
 sh_hdr = f.read(e_shentsize)
 
 sh_name, sh_type, sh_flags, sh_addr, sh_offset, sh_size, sh_link,\
-sh_info, sh_addralign, sh_entsize = sh_struct.unpack(sh_hdr)
+sh_info, sh_addralign, sh_entsize = struct.unpack(sh_fmt, sh_hdr)
 
 name = sh_strtab[sh_name:sh_strtab.find(\0, sh_name)]
 
@@ -181,7 +181,7 @@ def change_dl_sysdirs():
 
 # MAIN
 if len(sys.argv)  4:
-exit(-1)
+sys.exit(-1)
 
 new_prefix = sys.argv[1]
 new_dl_path = sys.argv[2]
@@ -196,14 +196,14 @@ for e in executables_list:
 
 try:
 f = open(e, r+b)
-except IOError as ioex:
+except IOError, ioex:
 if ioex.errno == errno.ETXTBSY:
 print(Could not open %s. File used by another process.\nPlease \
   make sure you exit all processes that might use any SDK \
   binaries. % e)
 else:
 print(Could not open %s: %s(%d) % (e, ioex.strerror, ioex.errno))
-exit(-1)
+sys.exit(-1)
 
 arch = get_arch()
 if arch:
-- 
1.8.1.5


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2][for-danny] relocate_sdk.py: Fix corruption of sdk binaries

2013-04-01 Thread Denys Dmytriyenko 
From: Jason Wessel jason.wes...@windriver.com

There are two cases of corruption that the relocate_sdk.py was not correctly
dealing with.

1) SDK Extras should be left alone
   Extra external binaries included in an SDK that were linked against the
   host's version of /usr/lib/ld-so.so should not get a relocation applied.
   In the case that was discovered these were LSB compliant binaries that
   already worked on many hosts.

2) If the interp section is too small generate an error
   In the case of the qemu user code, it was using its own .ld file
   to link the executables which overrides the default in the nativesdk
   binutils.  This generated host executables which had a interp section
   that was too small to relocate.

   Now the relocate_sdk.py will print an error and continue on such that
   the error can be fixed by a developer without having to do the
   difficult task of debugging why it is crashing or not loading correctly.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
 scripts/relocate_sdk.py | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py
index 74bb7a5..45d2c24 100755
--- a/scripts/relocate_sdk.py
+++ b/scripts/relocate_sdk.py
@@ -66,7 +66,7 @@ def parse_elf_header():
 e_ehsize, e_phentsize, e_phnum, e_shentsize, e_shnum, e_shstrndx =\
 hdr_struct.unpack(elf_header[16:hdr_size])
 
-def change_interpreter():
+def change_interpreter(elf_file_name):
 if arch == 32:
 ph_struct = struct.Struct()
 else:
@@ -89,7 +89,16 @@ def change_interpreter():
 if p_type == 3:
 # PT_INTERP section
 f.seek(p_offset)
+# External SDKs with mixed pre-compiled binaries should not get
+# relocated so look for some variant of /lib
+fname = f.read(11)
+if fname.startswith(/lib/) or fname.startswith(/lib64/) or 
fname.startswith(/lib32/) or fname.startswith(/usr/lib32/) or 
fname.startswith(/usr/lib32/) or fname.startswith(/usr/lib64/):
+break
+if (len(new_dl_path) = p_filesz):
+print ERROR: could not relocate %s, interp size = %i and %i 
is needed. % (elf_file_name, p_memsz, len(new_dl_path) + 1)
+break
 dl_path = new_dl_path + \0 * (p_filesz - len(new_dl_path))
+f.seek(p_offset)
 f.write(dl_path)
 break
 
@@ -199,7 +208,7 @@ for e in executables_list:
 arch = get_arch()
 if arch:
 parse_elf_header()
-change_interpreter()
+change_interpreter(e)
 change_dl_sysdirs()
 
  change permissions back 
-- 
1.8.1.5


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH][for-danny] kernel.bbclass: Add missing modules.order and modules.builtins

2013-03-12 Thread Denys Dmytriyenko 
From: Mark Hatle mark.ha...@windriver.com

When running depmod, from kmod, warnings about missing modules.order
and modules.builtins occur.  Looking back it is not clear why these
files were being ignored, other then nobody knew what to do with them.

Add the files into the kernel-base package, if they exist, ensuring
they will always get installed if at least one module is installed.

[ YOCTO #3963 ]

Signed-off-by: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
Signed-off-by: Saul Wold s...@linux.intel.com
---
 meta/classes/kernel.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 88ce561..fd46711 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -108,8 +108,6 @@ kernel_do_install() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
oe_runmake DEPMOD=echo INSTALL_MOD_PATH=${D} modules_install
-   rm -f ${D}/lib/modules/${KERNEL_VERSION}/modules.order
-   rm -f ${D}/lib/modules/${KERNEL_VERSION}/modules.builtin
rm ${D}/lib/modules/${KERNEL_VERSION}/build
rm ${D}/lib/modules/${KERNEL_VERSION}/source
else
@@ -259,6 +257,7 @@ EXPORT_FUNCTIONS do_compile do_install do_configure
 # kernel-image becomes kernel-image-${KERNEL_VERISON}
 PACKAGES = kernel kernel-base kernel-vmlinux kernel-image kernel-dev
 FILES = 
+FILES_kernel-base = /lib/modules/${KERNEL_VERSION}/modules.order 
/lib/modules/${KERNEL_VERSION}/modules.builtin
 FILES_kernel-image = /boot/${KERNEL_IMAGETYPE}*
 FILES_kernel-dev = /boot/System.map* /boot/Module.symvers* /boot/config* 
${KERNEL_SRC_PATH}
 FILES_kernel-vmlinux = /boot/vmlinux*
-- 
1.8.1.5


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH][for-danny] soc-family: fix SOC_FAMILY override order

2013-03-12 Thread Denys Dmytriyenko 
From: Chase Maupin chase.mau...@ti.com

* the current order has SOC_FAMILY settings, which are generic
  settings for a group of devices, overriding the machine specific
  settings.  For example:

  KERNEL_DEVICETREE_ti33x = 
  KERNEL_DEVICETREE_beaglebone = 

  Should yield  when building for the beaglebone because
  that is a more specific device than ti33x.  However, without this
  change the result is that the value is set to  meaning the
  more generic setting overrides the more specific setting.

Signed-off-by: Chase Maupin chase.mau...@ti.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
 meta/conf/machine/include/soc-family.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/soc-family.inc 
b/meta/conf/machine/include/soc-family.inc
index 612039c..0251da0 100644
--- a/meta/conf/machine/include/soc-family.inc
+++ b/meta/conf/machine/include/soc-family.inc
@@ -1,2 +1,2 @@
 # Add SOC_FAMILY to machine overrides so we get access to e.g. 'omap3' and 
'ti335x'
-MACHINEOVERRIDES .= ${@['', ':${SOC_FAMILY}']['${SOC_FAMILY}' != '']}
+MACHINEOVERRIDES =. ${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}
-- 
1.8.1.5


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY override order

2013-03-11 Thread Denys Dmytriyenko 
On Mon, Mar 11, 2013 at 06:03:25PM +, Maupin, Chase wrote:
  -Original Message-
  From: otavio.salva...@gmail.com
  [mailto:otavio.salva...@gmail.com] On Behalf Of Otavio Salvador
  Sent: Monday, March 11, 2013 11:24 AM
  To: Maupin, Chase
  Cc: Denys Dmytriyenko; Patches and discussions about the oe-core
  layer
  Subject: Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY
  override order
  
  On Mon, Mar 11, 2013 at 11:49 AM, Maupin, Chase
  chase.mau...@ti.com wrote:
   -Original Message-
   From: otavio.salva...@gmail.com
   [mailto:otavio.salva...@gmail.com] On Behalf Of Otavio
  Salvador
   Sent: Saturday, March 09, 2013 6:11 AM
   To: Maupin, Chase
   Cc: Denys Dmytriyenko; Patches and discussions about the oe-
  core
   layer
   Subject: Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY
   override order
  
   On Fri, Mar 8, 2013 at 7:16 PM, Maupin, Chase
   chase.mau...@ti.com wrote:
-Original Message-
From: otavio.salva...@gmail.com
[mailto:otavio.salva...@gmail.com] On Behalf Of Otavio
   Salvador
Sent: Friday, March 08, 2013 2:27 PM
To: Denys Dmytriyenko
Cc: Maupin, Chase; Patches and discussions about the oe-
  core
layer
Subject: Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY
override order
   
On Fri, Mar 8, 2013 at 5:06 PM, Denys Dmytriyenko
de...@denix.org wrote:
 On Fri, Mar 08, 2013 at 03:52:57PM -0300, Otavio Salvador
wrote:
 On Fri, Mar 8, 2013 at 2:51 PM, Chase Maupin
chase.mau...@ti.com wrote:
  * the current order has SOC_FAMILY settings, which are
generic
settings for a group of devices, overriding the
  machine
specific
settings.  For example:
 
KERNEL_DEVICETREE_ti33x = 
KERNEL_DEVICETREE_beaglebone = 
 
Should yield  when building for the beaglebone
because
that is a more specific device than ti33x.  However,
without this
change the result is that the value is set to 
meaning the
more generic setting overrides the more specific
   setting.
 
  Signed-off-by: Chase Maupin chase.mau...@ti.com

 Maybe while on that you could look at supporting xx:yy
  as
   SoC
family?
 like am37xx:am3715 ?

 Did you mean am3517? That's a slightly different variant
  of
am35x/omap35x SoC.
   
Yes; sorry ... what I meant was 'am35xx:am3517'
   
 But if you really meant am3715 (as well as am3705, am3725
   and
am3730), then
 those are variants of am37x SoC, just with some
  subsystems,
like SGX or DSP,
 being absent or present. Having those variants handled by
SOC_FAMILY would be
 an overkill. Instead, we've started using
  MACHINE_FEATURES
   to
distinguish
 between those variants of the same SoC, by checking for
   sgx
and/or dsp
 flags there and pulling in needed software components
accordingly.
   
My main concern here is that COMPATIBLE_MACHINE also parses
SOC_FAMILY
however if you have two (as the 'am35xx:am3517') it is
  going
   to
fail;
it could split it and parse it individually.
   
Sorry, I'm not sure if I'm following here.  Are you saying
  you
   would find it useful to have support for a MACHINE to have
  more
   than one SOC_FAMILY?  In the example above I would have
  expected
   that you would have a machine config file for am3517 which has
  an
   SOC_FAMILY of am35xx.  Why would you specify two SOC_FAMILY
   values per machine?
  
   We can have more generic to more specific combinations.
  
Or are you trying to build something like omap3-am35xx-
  am3517
   where you can use omap3 as a more generic setting but still
  use
   am35xx for a slightly more restrictive group that is still
   grouping like parts, and finally you use am3517 for the exact
   part?
  
   Exactly so we avoid duplication stuff to boards or SoCs.
  Another
   example of use: imx - mx6q - mx6.
  
   I see.  This could be of some use and I'll play with it.  This
  should not be required though for this patch since right now I
  want to fix the order issue.  Any objection to the patch as is?
  
  No; not really. I just wanted to ask if you could look at it as
  well
  so we can have it working. It does make things much easier for
  all us.
 
 Sure.  Btw, I noticed a weirdness when looking at this where the 
 COMPATIBLE_MACHINE being evaluated evaulated/matched only has to be a 
 substring of the SOC family to work.  For example if I have:
 
 MACHINE = omap5-evm
 SOC_FAMILY = omap-a15
 COMPATIBLE_MACHINE = omap
 
 Then this will work because omap (the COMPATIBLE_MACHINE) is a substring 
 of SOC_FAMILY (and technically also a substring of omap5-evm)
 
 Even setting COMPATIBLE_MACHINE to omap- will work because that is a 
 substring of omap-a15.  So the match operation is not really precise 
 enough.  I'm wondering if this needs to be changed to do an exact match.

COMPATIBLE_MACHINE is a regular

Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY override order

2013-03-11 Thread Denys Dmytriyenko 
On Mon, Mar 11, 2013 at 02:49:20PM +, Maupin, Chase wrote:
  -Original Message-
  From: otavio.salva...@gmail.com
  [mailto:otavio.salva...@gmail.com] On Behalf Of Otavio Salvador
  Sent: Saturday, March 09, 2013 6:11 AM
  To: Maupin, Chase
  Cc: Denys Dmytriyenko; Patches and discussions about the oe-core
  layer
  Subject: Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY
  override order
  
  On Fri, Mar 8, 2013 at 7:16 PM, Maupin, Chase
  chase.mau...@ti.com wrote:
   -Original Message-
   From: otavio.salva...@gmail.com
   [mailto:otavio.salva...@gmail.com] On Behalf Of Otavio
  Salvador
   Sent: Friday, March 08, 2013 2:27 PM
   To: Denys Dmytriyenko
   Cc: Maupin, Chase; Patches and discussions about the oe-core
   layer
   Subject: Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY
   override order
  
   On Fri, Mar 8, 2013 at 5:06 PM, Denys Dmytriyenko
   de...@denix.org wrote:
On Fri, Mar 08, 2013 at 03:52:57PM -0300, Otavio Salvador
   wrote:
On Fri, Mar 8, 2013 at 2:51 PM, Chase Maupin
   chase.mau...@ti.com wrote:
 * the current order has SOC_FAMILY settings, which are
   generic
   settings for a group of devices, overriding the machine
   specific
   settings.  For example:

   KERNEL_DEVICETREE_ti33x = 
   KERNEL_DEVICETREE_beaglebone = 

   Should yield  when building for the beaglebone
   because
   that is a more specific device than ti33x.  However,
   without this
   change the result is that the value is set to 
   meaning the
   more generic setting overrides the more specific
  setting.

 Signed-off-by: Chase Maupin chase.mau...@ti.com
   
Maybe while on that you could look at supporting xx:yy as
  SoC
   family?
like am37xx:am3715 ?
   
Did you mean am3517? That's a slightly different variant of
   am35x/omap35x SoC.
  
   Yes; sorry ... what I meant was 'am35xx:am3517'
  
But if you really meant am3715 (as well as am3705, am3725
  and
   am3730), then
those are variants of am37x SoC, just with some subsystems,
   like SGX or DSP,
being absent or present. Having those variants handled by
   SOC_FAMILY would be
an overkill. Instead, we've started using MACHINE_FEATURES
  to
   distinguish
between those variants of the same SoC, by checking for
  sgx
   and/or dsp
flags there and pulling in needed software components
   accordingly.
  
   My main concern here is that COMPATIBLE_MACHINE also parses
   SOC_FAMILY
   however if you have two (as the 'am35xx:am3517') it is going
  to
   fail;
   it could split it and parse it individually.
  
   Sorry, I'm not sure if I'm following here.  Are you saying you
  would find it useful to have support for a MACHINE to have more
  than one SOC_FAMILY?  In the example above I would have expected
  that you would have a machine config file for am3517 which has an
  SOC_FAMILY of am35xx.  Why would you specify two SOC_FAMILY
  values per machine?
  
  We can have more generic to more specific combinations.
  
   Or are you trying to build something like omap3-am35xx-am3517
  where you can use omap3 as a more generic setting but still use
  am35xx for a slightly more restrictive group that is still
  grouping like parts, and finally you use am3517 for the exact
  part?
  
  Exactly so we avoid duplication stuff to boards or SoCs. Another
  example of use: imx - mx6q - mx6.
 
 I see.  This could be of some use and I'll play with it.  This should not be 
 required though for this patch since right now I want to fix the order 
 issue.  Any objection to the patch as is?

BTW, this was already pushed:

http://cgit.openembedded.org/openembedded-core/commit/?id=0b836b9d79255a5b2f358fe718c67638f52ecf72

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY override order

2013-03-08 Thread Denys Dmytriyenko 
On Fri, Mar 08, 2013 at 03:52:57PM -0300, Otavio Salvador wrote:
 On Fri, Mar 8, 2013 at 2:51 PM, Chase Maupin chase.mau...@ti.com wrote:
  * the current order has SOC_FAMILY settings, which are generic
settings for a group of devices, overriding the machine specific
settings.  For example:
 
KERNEL_DEVICETREE_ti33x = 
KERNEL_DEVICETREE_beaglebone = 
 
Should yield  when building for the beaglebone because
that is a more specific device than ti33x.  However, without this
change the result is that the value is set to  meaning the
more generic setting overrides the more specific setting.
 
  Signed-off-by: Chase Maupin chase.mau...@ti.com
 
 Maybe while on that you could look at supporting xx:yy as SoC family?
 like am37xx:am3715 ?

Did you mean am3517? That's a slightly different variant of am35x/omap35x SoC.

But if you really meant am3715 (as well as am3705, am3725 and am3730), then 
those are variants of am37x SoC, just with some subsystems, like SGX or DSP, 
being absent or present. Having those variants handled by SOC_FAMILY would be 
an overkill. Instead, we've started using MACHINE_FEATURES to distinguish 
between those variants of the same SoC, by checking for sgx and/or dsp 
flags there and pulling in needed software components accordingly.

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] tune-cortexa15: add tunes for ARM Cortex-A15

2013-03-04 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

http://www.arm.com/products/processors/cortex-a/cortex-a15.php

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 meta/conf/machine/include/tune-cortexa15.inc | 36 
 1 file changed, 36 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa15.inc

diff --git a/meta/conf/machine/include/tune-cortexa15.inc 
b/meta/conf/machine/include/tune-cortexa15.inc
new file mode 100644
index 000..a9a8d0d
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa15.inc
@@ -0,0 +1,36 @@
+DEFAULTTUNE ?= armv7a-neon
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+TUNEVALID[cortexa15] = Enable Cortex-A15 specific processor optimizations
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, cortexa15, 
-mtune=cortex-a15, , d)}
+
+# Little Endian base configs
+AVAILTUNES += cortexa15 cortexa15t cortexa15-neon cortexa15t-neon
+ARMPKGARCH_tune-cortexa15 = cortexa15
+ARMPKGARCH_tune-cortexa15t = cortexa15
+ARMPKGARCH_tune-cortexa15-neon = cortexa15
+ARMPKGARCH_tune-cortexa15t-neon = cortexa15
+TUNE_FEATURES_tune-cortexa15 = ${TUNE_FEATURES_tune-armv7a} cortexa15
+TUNE_FEATURES_tune-cortexa15t = ${TUNE_FEATURES_tune-armv7at} cortexa15
+TUNE_FEATURES_tune-cortexa15-neon = ${TUNE_FEATURES_tune-armv7a-neon} 
cortexa15
+TUNE_FEATURES_tune-cortexa15t-neon = ${TUNE_FEATURES_tune-armv7at-neon} 
cortexa15
+PACKAGE_EXTRA_ARCHS_tune-cortexa15 = ${PACKAGE_EXTRA_ARCHS_tune-armv7a} 
cortexa15-vfp
+PACKAGE_EXTRA_ARCHS_tune-cortexa15t = ${PACKAGE_EXTRA_ARCHS_tune-armv7at} 
cortexa15-vfp cortexa15t2-vfp
+PACKAGE_EXTRA_ARCHS_tune-cortexa15-neon = 
${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon} cortexa15-vfp cortexa15-vfp-neon
+PACKAGE_EXTRA_ARCHS_tune-cortexa15t-neon = 
${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon} cortexa15-vfp cortexa15-vfp-neon 
cortexa15t2-vfp cortexa15t2-vfp-neon
+
+# VFP Tunes
+AVAILTUNES += cortexa15hf cortexa15thf cortexa15hf-neon cortexa15thf-neon
+ARMPKGARCH_tune-cortexa15hf = cortexa15
+ARMPKGARCH_tune-cortexa15thf = cortexa15
+ARMPKGARCH_tune-cortexa15hf-neon = cortexa15
+ARMPKGARCH_tune-cortexa15thf-neon = cortexa15
+TUNE_FEATURES_tune-cortexa15hf ?= ${TUNE_FEATURES_tune-armv7ahf} cortexa15
+TUNE_FEATURES_tune-cortexa15thf ?= ${TUNE_FEATURES_tune-armv7athf} cortexa15
+TUNE_FEATURES_tune-cortexa15hf-neon ?= ${TUNE_FEATURES_tune-armv7ahf-neon} 
cortexa15
+TUNE_FEATURES_tune-cortexa15thf-neon ?= ${TUNE_FEATURES_tune-armv7ahf-neon} 
cortexa15
+PACKAGE_EXTRA_ARCHS_tune-cortexa15hf = ${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} 
cortexa15hf-vfp
+PACKAGE_EXTRA_ARCHS_tune-cortexa15thf = ${PACKAGE_EXTRA_ARCHS_tune-armv7athf} 
cortexa15hf-vfp cortexa15t2hf-vfp
+PACKAGE_EXTRA_ARCHS_tune-cortexa15hf-neon = 
${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon} cortexa15hf-vfp cortexa15hf-vfp-neon
+PACKAGE_EXTRA_ARCHS_tune-cortexa15thf-neon = 
${PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon} cortexa15hf-vfp 
cortexa15hf-vfp-neon cortexa15t2-vfp cortexa15t2hf-vfp-neon
-- 
1.8.1.5


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH][for-danny] scripts/bitbake: Remove all instances of paths to a layer's scripts directory.

2013-02-15 Thread Denys Dmytriyenko 
From: Franklin S. Cooper Jr fcoo...@ti.com

* Currently the assumption is made that only oe-core can include a scripts
  directory.

* However, when other layers create a scripts directory the bitbake script
  freaks out causing a infinite recursive loop until it crashes.

* Simply changing the regular expression to remove all instances of scripts path
  instead of just the first one fixes this problem.

 [Yocto Bug 3872]

Signed-off-by: Franklin S. Cooper Jr fcoo...@ti.com
Signed-off-by: Saul Wold s...@linux.intel.com
---
 scripts/bitbake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/bitbake b/scripts/bitbake
index 79a81ea..ca2bc82 100755
--- a/scripts/bitbake
+++ b/scripts/bitbake
@@ -126,7 +126,7 @@ if [ $needpseudo != 0 -a $buildpseudo -eq 0 ]; then
 fi
 
 OLDPATH=$PATH
-export PATH=`echo $PATH | sed s#[^:]*/scripts:##`
+export PATH=`echo $PATH | sed s#[^:]*/scripts:##g`
 if [ $buildpseudo -gt 0 ]; then
 [ $buildpseudo -eq 1 ]  echo Pseudo is not present but is required, 
building this first before the main build
 [ $buildpseudo -eq 2 ]  echo Pseudo may be out of date, rebuilding 
pseudo before the main build
-- 
1.8.1.2


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH][for-danny] relocate_sdk.py: new interpreter string was not '\0' terminated

2013-02-07 Thread Denys Dmytriyenko 
From: Laurentiu Palcu laurentiu.pa...@intel.com

The problem: SDK binaries were not properly relocated when the SDK
was installed into a path that had a length less than the default one.
Apparently, there were two problems here: the padding was done wrong
(the size of one program header table entry was used instead of the
program section size) and the new padded string was not used at all.

[YOCTO #3655]

Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
 scripts/relocate_sdk.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py
index 637ffe9..74bb7a5 100755
--- a/scripts/relocate_sdk.py
+++ b/scripts/relocate_sdk.py
@@ -89,8 +89,8 @@ def change_interpreter():
 if p_type == 3:
 # PT_INTERP section
 f.seek(p_offset)
-dl_path = new_dl_path + \0 * (e_phentsize - len(new_dl_path))
-f.write(new_dl_path)
+dl_path = new_dl_path + \0 * (p_filesz - len(new_dl_path))
+f.write(dl_path)
 break
 
 def change_dl_sysdirs():
-- 
1.8.1.2


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] nativesdk-qt4-tools: fix DEPENDS, as nativesdk is now prefixed

2013-02-06 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 meta/recipes-qt/qt4/nativesdk-qt4-tools.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc 
b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
index 5ed0e90..cfc6fd8 100644
--- a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
+++ b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
@@ -1,10 +1,10 @@
 DESCRIPTION = SDK tools for Qt/[X11|Mac|Embedded] version 4.x
-DEPENDS = zlib-nativesdk dbus-nativesdk libx11-nativesdk qt4-native
+DEPENDS = nativesdk-zlib nativesdk-dbus nativesdk-libx11 qt4-native
 SECTION = libs
 HOMEPAGE = http://qt.nokia.com;
 LICENSE = LGPLv2.1 | GPLv3
 
-INC_PR = r12
+INC_PR = r13
 
 FILESEXTRAPATHS =. ${FILE_DIRNAME}/qt4-${PV}:
 
-- 
1.8.1.2


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH][danny] nativesdk-qt4-tools: fix DEPENDS, as nativesdk is now prefixed

2013-02-06 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 meta/recipes-qt/qt4/nativesdk-qt4-tools.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc 
b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
index 1199a8a..538436b 100644
--- a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
+++ b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
@@ -1,10 +1,10 @@
 DESCRIPTION = SDK tools for Qt/[X11|Mac|Embedded] version 4.x
-DEPENDS = zlib-nativesdk dbus-nativesdk libx11-nativesdk qt4-native
+DEPENDS = nativesdk-zlib nativesdk-dbus nativesdk-libx11 qt4-native
 SECTION = libs
 HOMEPAGE = http://qt.nokia.com;
 LICENSE = LGPLv2.1 | GPLv3
 
-INC_PR = r12
+INC_PR = r13
 
 FILESEXTRAPATHS =. ${FILE_DIRNAME}/qt4-${PV}:
 
-- 
1.8.1.2


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-ti] building for pandaboard fails fetching u-boot *way* into the build phase

2012-11-20 Thread Denys Dmytriyenko 
On Tue, Nov 20, 2012 at 11:24:20AM -0500, Robert P. J. Day wrote:
 
   i'm sure there's a trivial workaround/explanation for this, but i
 wanted to build the basic meta-ti based build for my panda ES, so i
 started with oe-core and added the meta-ti layer.  then, because of
 some license issues (and based on a quick google search), i added this
 to my local.conf:
 
   BBMASK = meta-ti/recipes-misc
 
 at that point, after selecting pandaboard as the machine, i wanted
 to prefetch everything:
 
 $ bitbake -c fetchall core-image-minimal
 
 which used solely my pre-mirror directory so that didn't take long.
 
   *then*, because i allegedly had fetched everything i needed for the
 build, i edited my site.conf file and added:
 
 BB_NO_NETWORK = 1
 
 which, AIUI, should be perfectly safe since i had just done a
 fetchall.  not so:
 
 ERROR: Function failed: Network access disabled through BB_NO_NETWORK
 but access requested with command git clone --bare --mirror
 git://www.denx.de/git/u-boot.git
 /home/rpjday/y/builds/ti/panda/downloads/git2/www.denx.de.git.u-boot.git
 (for url None)
 ERROR: Logfile of failure stored in:
 /home/rpjday/y/builds/ti/panda/tmp-eglibc/work/pandaboard-oe-linux-gnueabi/u-boot-2011.12-r8/temp/log.do_fetch.29635
 
 hmm ...
 
 $ bitbake -s | grep u-boot
 nativesdk-u-boot-mkimage  :2011.06-r0
 u-boot:2011.12-r8
 u-boot-fw-utils   :2011.06-r1
 u-boot-mkimage:2011.06-r0
 u-boot-mkimage-native :2011.06-r0
 $
 
   ok, now i'm confused.  the above suggests that the version of u-boot
 to be used here is 2011.12-r8, but that was never fetched, and it's
 only now toward the end of the build that the fetch is attempted.
 
   can someone clarify what's happening here?  why did my fetchall
 operation not fetch everything the build was going to need?

Is that because u-boot is not in a standard DEPENDS/RDEPENDS dependency tree, 
but rather in EXTRA_IMAGEDEPENDS list? I'm copying bitbake and oe-core lists, 
as I don't think it's meta-ti specific issue - u-boot recipe looks fine.

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-ti] building for pandaboard fails fetching u-boot *way* into the build phase

2012-11-20 Thread Denys Dmytriyenko 
On Tue, Nov 20, 2012 at 12:34:47PM -0500, Robert P. J. Day wrote:
 On Tue, 20 Nov 2012, Denys Dmytriyenko wrote:
 
  On Tue, Nov 20, 2012 at 11:24:20AM -0500, Robert P. J. Day wrote:
  
 i'm sure there's a trivial workaround/explanation for this, but i
   wanted to build the basic meta-ti based build for my panda ES, so i
   started with oe-core and added the meta-ti layer.  then, because of
   some license issues (and based on a quick google search), i added this
   to my local.conf:
  
 BBMASK = meta-ti/recipes-misc
  
   at that point, after selecting pandaboard as the machine, i wanted
   to prefetch everything:
  
   $ bitbake -c fetchall core-image-minimal
  
   which used solely my pre-mirror directory so that didn't take long.
  
 *then*, because i allegedly had fetched everything i needed for the
   build, i edited my site.conf file and added:
  
   BB_NO_NETWORK = 1
  
   which, AIUI, should be perfectly safe since i had just done a
   fetchall.  not so:
  
   ERROR: Function failed: Network access disabled through BB_NO_NETWORK
   but access requested with command git clone --bare --mirror
   git://www.denx.de/git/u-boot.git
   /home/rpjday/y/builds/ti/panda/downloads/git2/www.denx.de.git.u-boot.git
   (for url None)
   ERROR: Logfile of failure stored in:
   /home/rpjday/y/builds/ti/panda/tmp-eglibc/work/pandaboard-oe-linux-gnueabi/u-boot-2011.12-r8/temp/log.do_fetch.29635
  
   hmm ...
  
   $ bitbake -s | grep u-boot
   nativesdk-u-boot-mkimage  :2011.06-r0
   u-boot:2011.12-r8
   u-boot-fw-utils   :2011.06-r1
   u-boot-mkimage:2011.06-r0
   u-boot-mkimage-native :2011.06-r0
   $
  
 ok, now i'm confused.  the above suggests that the version of u-boot
   to be used here is 2011.12-r8, but that was never fetched, and it's
   only now toward the end of the build that the fetch is attempted.
  
 can someone clarify what's happening here?  why did my fetchall
   operation not fetch everything the build was going to need?
 
  Is that because u-boot is not in a standard DEPENDS/RDEPENDS
  dependency tree, but rather in EXTRA_IMAGEDEPENDS list? I'm copying
  bitbake and oe-core lists, as I don't think it's meta-ti specific
  issue - u-boot recipe looks fine.
 
   good question ... for which i don't know the answer.  to make sure
 this is reproducible, i blew everything away and started from scratch
 with a new panda build.  here's my bblayers.conf:
 
   but when i do a fetchall, i don't get u-boot_2011.12.  only when i
 try to build a core-image-minimal does the build fail toward the end
 trying to fetch u-boot_2011.12.  here's the layering info:
 
 i'm sure i'm just doing something silly, but i've never run into the
 situation where a fetchall doesn't actually fetch absolutely
 everything that's needed for the build.

Try adding CORE_IMAGE_EXTRA_INSTALL=u-boot somewhere, like local.conf and 
if that fixes your usecase, it has to be a bug with bitbake forgetting to 
pre-fetch machine's specific EXTRA_IMAGEDEPENDS - file a bug then.

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] dbus: only use x11 if DISTRO_FEATURES has selected it

2012-10-24 Thread Denys Dmytriyenko 
On Fri, Aug 12, 2011 at 04:59:43PM +0100, Phil Blundell wrote:
 This makes it possible to include dbus in a non-X11-equipped DISTRO.

I have a follow up question on this old change...


 Signed-off-by: Phil Blundell ph...@gnu.org
 ---
  meta/recipes-core/dbus/dbus.inc |7 ---
  1 files changed, 4 insertions(+), 3 deletions(-)
 
 diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
 index 6b76cba..a8ecda8 100644
 --- a/meta/recipes-core/dbus/dbus.inc
 +++ b/meta/recipes-core/dbus/dbus.inc
 @@ -5,7 +5,8 @@ SECTION = base
  LICENSE = AFL-2 | GPLv2+
  LIC_FILES_CHKSUM = file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
  
 file://dbus/dbus.h;firstline=6;endline=20;md5=6eea2e0c7750dd8e620dcb1437312fa5
 -DEPENDS = expat virtual/libintl virtual/libx11 libsm
 +X11DEPENDS = virtual/libx11 libsm
 +DEPENDS = expat virtual/libintl ${@base_contains('DISTRO_FEATURES', 'x11', 
 '${X11DEPENDS}', '', d)}
  DEPENDS_virtclass-native = expat-native virtual/libintl-native
  DEPENDS_virtclass-nativesdk = expat-nativesdk virtual/libintl-nativesdk 
 virtual/libx11

Would there be any objections extending this DISTRO check to nativesdk as 
well?

-- 
Denys


  
 @@ -22,7 +23,7 @@ CONFFILES_${PN} = ${sysconfdir}/dbus-1/system.conf 
 ${sysconfdir}/dbus-1/session
  
  DEBIANNAME_${PN} = dbus-1
  
 -PACKAGES =+ ${PN}-lib ${PN}-x11 ${PN}-systemd
 +PACKAGES =+ ${PN}-lib ${PN}-systemd ${@base_contains('DISTRO_FEATURES', 
 'x11', '${PN}-x11', '', d)}
  
  FILES_${PN}-x11 = ${bindir}/dbus-launch
  RDEPENDS_${PN}-x11 = ${PN}
 @@ -73,7 +74,7 @@ pkg_postinst_dbus() {
   fi
  }
  
 -EXTRA_OECONF_X = --with-x
 +EXTRA_OECONF_X = ${@base_contains('DISTRO_FEATURES', 'x11', '--with-x', 
 '--without-x', d)}
  EXTRA_OECONF_X_virtclass-native = --without-x
  
  EXTRA_OECONF = --disable-tests \
 -- 
 1.7.4.1
 
 
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] Add more tunes for new ARM processors Cortex-A15 and Cortex-A7

2012-10-19 Thread Denys Dmytriyenko 
On Fri, Oct 19, 2012 at 10:44:32AM +0200, Martin Jansa wrote:
 On Thu, Oct 18, 2012 at 06:51:56PM -0400, Denys Dmytriyenko wrote:
  From: Denys Dmytriyenko de...@ti.com
  
  The patchset adds 2 more standard tune files for the new ARM MPCore 
  (multicore)
  processors Cortex-A15 and Cortex-A7, as per:
  
  http://www.arm.com/products/processors/cortex-a/cortex-a15.php
  http://www.arm.com/products/processors/cortex-a/cortex-a7.php
 
 Please check this patchset 
 http://lists.linuxtogo.org/pipermail/openembedded-core/2012-October/030759.html

Yes, I've seen that patchset. Unfortunately it's still in the queue and is 
going through implementation iterations. Once it gets into OE-Core, I'd be 
happy to update my tune files with the corresponding ARMPKGARCH and 
DEFAULTTUNE changes. But I don't think that tune rework patchset should block 
new tune files, as they don't break anything and adhere to the existing 
framework. Thanks.

-- 
Denys


  Denys Dmytriyenko (2):
tune-cortexa15: add tunes for ARM Cortex-A15
tune-cortexa7: add tunes for ARM Cortex-A7
  
   meta/conf/machine/include/tune-cortexa15.inc | 24 
   meta/conf/machine/include/tune-cortexa7.inc  | 24 
   2 files changed, 48 insertions(+)
   create mode 100644 meta/conf/machine/include/tune-cortexa15.inc
   create mode 100644 meta/conf/machine/include/tune-cortexa7.inc
  
  -- 
  1.7.12.3
  
  
  ___
  Openembedded-core mailing list
  Openembedded-core@lists.openembedded.org
  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
 
 -- 
 Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] tune-cortexa7: add tunes for ARM Cortex-A7

2012-10-18 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

http://www.arm.com/products/processors/cortex-a/cortex-a7.php

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 meta/conf/machine/include/tune-cortexa7.inc | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa7.inc

diff --git a/meta/conf/machine/include/tune-cortexa7.inc 
b/meta/conf/machine/include/tune-cortexa7.inc
new file mode 100644
index 000..8e41139
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa7.inc
@@ -0,0 +1,24 @@
+DEFAULTTUNE ?= cortexa7-neon
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+TUNEVALID[cortexa7] = Enable Cortex-A7 specific processor optimizations
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, cortexa7, 
-mtune=cortex-a7, , d)}
+
+# Little Endian base configs
+AVAILTUNES += cortexa7 cortexa7t cortexa7-neon
+TUNE_FEATURES_tune-cortexa7 = ${TUNE_FEATURES_tune-armv7a} cortexa7
+TUNE_FEATURES_tune-cortexa7t = ${TUNE_FEATURES_tune-armv7at} cortexa7
+TUNE_FEATURES_tune-cortexa7-neon = ${TUNE_FEATURES_tune-armv7a-neon} cortexa7
+PACKAGE_EXTRA_ARCHS_tune-cortexa7 = ${PACKAGE_EXTRA_ARCHS_tune-armv7a}
+PACKAGE_EXTRA_ARCHS_tune-cortexa7t = ${PACKAGE_EXTRA_ARCHS_tune-armv7at}
+PACKAGE_EXTRA_ARCHS_tune-cortexa7-neon = 
${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon}
+
+# VFP Tunes
+AVAILTUNES += cortexa7hf cortexa7thf cortexa7hf-neon
+TUNE_FEATURES_tune-cortexa7hf ?= ${TUNE_FEATURES_tune-armv7ahf} cortexa7
+TUNE_FEATURES_tune-cortexa7thf ?= ${TUNE_FEATURES_tune-armv7athf} cortexa7
+TUNE_FEATURES_tune-cortexa7hf-neon ?= ${TUNE_FEATURES_tune-armv7ahf-neon} 
cortexa7
+PACKAGE_EXTRA_ARCHS_tune-cortexa7hf = ${PACKAGE_EXTRA_ARCHS_tune-armv7ahf}
+PACKAGE_EXTRA_ARCHS_tune-cortexa7thf = ${PACKAGE_EXTRA_ARCHS_tune-armv7athf}
+PACKAGE_EXTRA_ARCHS_tune-cortexa7hf-neon = 
${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon}
-- 
1.7.12.3


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/2] Add more tunes for new ARM processors Cortex-A15 and Cortex-A7

2012-10-18 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

The patchset adds 2 more standard tune files for the new ARM MPCore (multicore)
processors Cortex-A15 and Cortex-A7, as per:

http://www.arm.com/products/processors/cortex-a/cortex-a15.php
http://www.arm.com/products/processors/cortex-a/cortex-a7.php

Denys Dmytriyenko (2):
  tune-cortexa15: add tunes for ARM Cortex-A15
  tune-cortexa7: add tunes for ARM Cortex-A7

 meta/conf/machine/include/tune-cortexa15.inc | 24 
 meta/conf/machine/include/tune-cortexa7.inc  | 24 
 2 files changed, 48 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa15.inc
 create mode 100644 meta/conf/machine/include/tune-cortexa7.inc

-- 
1.7.12.3


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] tune-cortexa15: add tunes for ARM Cortex-A15

2012-10-18 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

http://www.arm.com/products/processors/cortex-a/cortex-a15.php

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 meta/conf/machine/include/tune-cortexa15.inc | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa15.inc

diff --git a/meta/conf/machine/include/tune-cortexa15.inc 
b/meta/conf/machine/include/tune-cortexa15.inc
new file mode 100644
index 000..690e934
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa15.inc
@@ -0,0 +1,24 @@
+DEFAULTTUNE ?= cortexa15-neon
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+TUNEVALID[cortexa15] = Enable Cortex-A15 specific processor optimizations
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, cortexa15, 
-mtune=cortex-a15, , d)}
+
+# Little Endian base configs
+AVAILTUNES += cortexa15 cortexa15t cortexa15-neon
+TUNE_FEATURES_tune-cortexa15 = ${TUNE_FEATURES_tune-armv7a} cortexa15
+TUNE_FEATURES_tune-cortexa15t = ${TUNE_FEATURES_tune-armv7at} cortexa15
+TUNE_FEATURES_tune-cortexa15-neon = ${TUNE_FEATURES_tune-armv7a-neon} 
cortexa15
+PACKAGE_EXTRA_ARCHS_tune-cortexa15 = ${PACKAGE_EXTRA_ARCHS_tune-armv7a}
+PACKAGE_EXTRA_ARCHS_tune-cortexa15t = ${PACKAGE_EXTRA_ARCHS_tune-armv7at}
+PACKAGE_EXTRA_ARCHS_tune-cortexa15-neon = 
${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon}
+
+# VFP Tunes
+AVAILTUNES += cortexa15hf cortexa15thf cortexa15hf-neon
+TUNE_FEATURES_tune-cortexa15hf ?= ${TUNE_FEATURES_tune-armv7ahf} cortexa15
+TUNE_FEATURES_tune-cortexa15thf ?= ${TUNE_FEATURES_tune-armv7athf} cortexa15
+TUNE_FEATURES_tune-cortexa15hf-neon ?= ${TUNE_FEATURES_tune-armv7ahf-neon} 
cortexa15
+PACKAGE_EXTRA_ARCHS_tune-cortexa15hf = ${PACKAGE_EXTRA_ARCHS_tune-armv7ahf}
+PACKAGE_EXTRA_ARCHS_tune-cortexa15thf = ${PACKAGE_EXTRA_ARCHS_tune-armv7athf}
+PACKAGE_EXTRA_ARCHS_tune-cortexa15hf-neon = 
${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon}
-- 
1.7.12.3


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] [PATCH] SDK: allow SDK path of various level

2012-10-16 Thread Denys Dmytriyenko 
On Tue, Oct 16, 2012 at 01:37:17PM +, Fabien Proriol wrote:
 In the previous version, tar extraction use the --strip-component
 option with 4 hard coded value.
 If we set another SDKPATH, with a different depth, the sdk installation
 fails.
 
 This patch computes the level from the SDKPATH value.

Thanks! That's part of the problem I was having lately. Although, I think this 
patch should go to OE-Core list instead...

Do you also see the problem building gcc-cross-initial/intermediate 
complaining about missing headers from sysroot (it loses -nativesdk suffix 
for some reason, when looking for the system headers), when building with the 
new SDKPATH/SDK_NAME? I believe there's some path hardcoded somewhere in the 
gcc/cross recipes, but I wasn't able to debug it yet...

-- 
Denys


 Signed-off-by: Fabien Proriol fabien.pror...@jdsu.com
 ---
  meta/classes/populate_sdk_base.bbclass |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/meta/classes/populate_sdk_base.bbclass 
 b/meta/classes/populate_sdk_base.bbclass
 index 6eb6726..971adfc 100644
 --- a/meta/classes/populate_sdk_base.bbclass
 +++ b/meta/classes/populate_sdk_base.bbclass
 @@ -117,6 +117,7 @@ fakeroot create_shar() {
  #!/bin/bash
  
  DEFAULT_INSTALL_DIR=${SDKPATH}
 +COMPONENTS_LEN=$(echo .${SDKPATH} | sed s/\// /g | wc -w)
  
  printf Enter target directory for SDK (default: $DEFAULT_INSTALL_DIR): 
  read target_sdk_dir
 @@ -153,7 +154,7 @@ fi
  payload_offset=$(($(grep -na -m1 ^MARKER:$ $0|cut -d':' -f1) + 1))
  
  printf Extracting SDK...
 -tail -n +$payload_offset $0| tar xj --strip-components=4 -C $target_sdk_dir
 +tail -n +$payload_offset $0| tar xj --strip-components=$COMPONENTS_LEN -C 
 $target_sdk_dir
  echo done
  
  printf Setting it up...
 -- 
 1.7.8.6
 
 ___
 Openembedded-devel mailing list
 openembedded-de...@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH][denzil] openjade-native: fix undefined Getopts error, use std namespace

2012-10-02 Thread Denys Dmytriyenko 
From: Dennis Lan dennis.y...@gmail.com

Using Gentoo Linux as the build host, it fails without this patch
Use Getopt::Std in place of getopts.pl.

https://bugs.gentoo.org/show_bug.cgi?id=420083

which following error:
/usr/bin/perl -w ./../msggen.pl -l jstyleModule InterpreterMessages.msg
/usr/bin/perl -w ./../msggen.pl -l jstyleModule DssslAppMessages.msg
Undefined subroutine main::Getopts called at ./../msggen.pl line 22.
make[2]: *** [InterpreterMessages.h] Error 2
make[2]: *** Waiting for unfinished jobs
Undefined subroutine main::Getopts called at ./../msggen.pl line 22.
make[2]: *** [DssslAppMessages.h] Error 2

(from OE-Core rev 169a89b10817b742c063fcd76721e4dbbcca6199)

Signed-off-by: Dennis Lan dennis.y...@gmail.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
 .../openjade/openjade-1.3.2/msggen.pl.patch|   44 
 .../openjade/openjade-native_1.3.2.bb  |3 +-
 2 files changed, 46 insertions(+), 1 deletions(-)
 create mode 100644 
meta/recipes-devtools/openjade/openjade-1.3.2/msggen.pl.patch

diff --git a/meta/recipes-devtools/openjade/openjade-1.3.2/msggen.pl.patch 
b/meta/recipes-devtools/openjade/openjade-1.3.2/msggen.pl.patch
new file mode 100644
index 000..b47fd46
--- /dev/null
+++ b/meta/recipes-devtools/openjade/openjade-1.3.2/msggen.pl.patch
@@ -0,0 +1,44 @@
+commit fcc5b94f118495b1a467edcda6c6f631691c3f69
+Author: Dennis Lan dennis.y...@gmail.com
+Date:   Tue Jul 3 09:25:42 2012 +0800
+
+openjade: fix undefined Getopts error, use std namespace
+
+Using Gentoo Linux as the build host, it fails without this patch
+Use Getopt::Std in place of getopts.pl.
+
+Upstream-Status: Inappropriate [no upstream]
+Original-Author-By: Mike Gilbert flop...@gentoo.org
+Signed-off-by: Dennis Lan dennis.y...@gmail.com
+
+diff --git a/msggen.pl b/msggen.pl
+index 0c33968..2ee3f66 100644
+--- a/msggen.pl
 b/msggen.pl
+@@ -4,6 +4,7 @@
+ # See the file COPYING for copying permission.
+ 
+ use POSIX;
++use Getopt::Std;
+ 
+ # Package and version.
+ $package = 'openjade';
+@@ -18,8 +19,7 @@ $gen_c = 0;
+ undef $opt_l;
+ undef $opt_p;
+ undef $opt_t;
+-do 'getopts.pl';
+-Getopts('l:p:t:');
++getopts('l:p:t:');
+ $module = $opt_l;
+ $pot_file = $opt_p;
+ 
+@@ -72,7 +72,7 @@ while (DEF) {
+ else {
+   $field[0] =~ /^[IWQXE][0-9]$/ || error(invalid first field);;
+   $type[$num] = substr($field[0], 0, 1);
+-  $argc = int(substr($field[0], 1, 1));
++  $argc = substr($field[0], 1, 1);
+ }
+ $nargs[$num] = $argc;
+ $field[1] =~ /^[a-zA-Z_][a-zA-Z0-9_]+$/ || error(invalid tag);
diff --git a/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb 
b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
index 5b29c1f..a539c35 100644
--- a/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
+++ b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
@@ -7,13 +7,14 @@ SECTION = base
 LICENSE = BSD
 LIC_FILES_CHKSUM = file://COPYING;md5=641ff1e4511f0a87044ad42f87cb1045
 
-PR = r4
+PR = r5
 
 DEPENDS = opensp-native sgml-common-native
 RDEPENDS_${PN} = sgml-common-native
 
 SRC_URI = ${SOURCEFORGE_MIRROR}/openjade/openjade-${PV}.tar.gz \
file://makefile.patch \
+   file://msggen.pl.patch \
file://reautoconf.patch \
   file://user-declared-default-constructor.patch
 
-- 
1.7.8.6


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH][denzil] openssl: add deprecated and unmaintained find.pl from perl-5.14 to fix perlpath.pl

2012-10-02 Thread Denys Dmytriyenko 
From: Martin Jansa martin.ja...@gmail.com

* openembedded-core/meta/recipes-connectivity/openssl/openssl.inc
*
* is using perlpath.pl:
*
*   do_configure () {
*   cd util
*   perl perlpath.pl ${STAGING_BINDIR_NATIVE}
*   ...
*
* and perlpath.pl is using find.pl:
* openssl-1.0.0i/util/perlpath.pl:
*   #!/usr/local/bin/perl
*   #
*   # modify the '#!/usr/local/bin/perl'
*   # line in all scripts that rely on perl.
*   #
*
*   require find.pl;
*   ...
*
* which was removed in perl-5.16.0 and marked as deprecated and
* unmaintained in 5.14 and older:
* /tmp/usr/lib/perl5/5.14.2/find.pl:
*   warn Legacy library @{[(caller(0))[6]]} will be removed from the Perl
*   core distribution in the next major release. Please install it from the
*   CPAN distribution Perl4::CoreLibs. It is being used at @{[(caller)[1]]},
*   line @{[(caller)[2]]}.\n;
*
*   # This library is deprecated and unmaintained. It is included for
*   # compatibility with Perl 4 scripts which may use it, but it will be
*   # removed in a future version of Perl. Please use the File::Find module
*   # instead.

(from OE-Core rev c09bf5d177a7ecd2045ef7e13fff4528137a9775)

Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
 .../openssl/openssl-1.0.0i/find.pl | 54 ++
 .../recipes-connectivity/openssl/openssl_1.0.0i.bb |  7 ++-
 2 files changed, 60 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-connectivity/openssl/openssl-1.0.0i/find.pl

diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0i/find.pl 
b/meta/recipes-connectivity/openssl/openssl-1.0.0i/find.pl
new file mode 100644
index 000..8e1b42c
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl-1.0.0i/find.pl
@@ -0,0 +1,54 @@
+warn Legacy library @{[(caller(0))[6]]} will be removed from the Perl core 
distribution in the next major release. Please install it from the CPAN 
distribution Perl4::CoreLibs. It is being used at @{[(caller)[1]]}, line 
@{[(caller)[2]]}.\n;
+
+# This library is deprecated and unmaintained. It is included for
+# compatibility with Perl 4 scripts which may use it, but it will be
+# removed in a future version of Perl. Please use the File::Find module
+# instead.
+
+# Usage:
+#  require find.pl;
+#
+#  find('/foo','/bar');
+#
+#  sub wanted { ... }
+#  where wanted does whatever you want.  $dir contains the
+#  current directory name, and $_ the current filename within
+#  that directory.  $name contains $dir/$_.  You are cd'ed
+#  to $dir when the function is called.  The function may
+#  set $prune to prune the tree.
+#
+# For example,
+#
+#   find / -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune
+#
+# corresponds to this
+#
+#  sub wanted {
+#  /^\.nfs.*$/ 
+#  (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)) 
+#  int(-M _)  7 
+#  unlink($_)
+#  ||
+#  ($nlink || (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_))) 
+#  $dev  0 
+#  ($prune = 1);
+#  }
+#
+# Set the variable $dont_use_nlink if you're using AFS, since AFS cheats.
+
+use File::Find ();
+
+*name  = *File::Find::name;
+*prune = *File::Find::prune;
+*dir   = *File::Find::dir;
+*topdir= *File::Find::topdir;
+*topdev= *File::Find::topdev;
+*topino= *File::Find::topino;
+*topmode   = *File::Find::topmode;
+*topnlink  = *File::Find::topnlink;
+
+sub find {
+File::Find::find(\wanted, @_);
+}
+
+1;
diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb 
b/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb
index ca15a38..c233ba1 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb
@@ -6,7 +6,7 @@ DEPENDS += ocf-linux
 
 CFLAG += -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
 
-PR = ${INC_PR}.2
+PR = ${INC_PR}.3
 
 LIC_FILES_CHKSUM = file://LICENSE;md5=f9a8f968107345e0b75aa8c2ecaa7ec8
 
@@ -29,6 +29,7 @@ SRC_URI += file://configure-targets.patch \
 file://debian/no-symbolic.patch \
 file://debian/debian-targets.patch \
 file://openssl_fix_for_x32.patch \
+file://find.pl \

 
 SRC_URI[md5sum] = b4df9c11af454fd68178c85a1d5f328f
@@ -43,3 +44,7 @@ FILES_${PN}-engines = ${libdir}/ssl/engines/*.so 
${libdir}/engines
 FILES_${PN}-engines-dbg = ${libdir}/ssl/engines/.debug
 
 PARALLEL_MAKEINST = 
+
+do_configure_prepend() {
+  cp ${WORKDIR}/find.pl ${S}/util/find.pl
+}
-- 
1.7.12


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] lib/oe/lsb: Add basic LSB functions

2012-07-30 Thread Denys Dmytriyenko 
On Sat, Jul 28, 2012 at 10:58:16AM +0100, Jack Mitchell wrote:
 On 28/07/2012 10:37, Martin Jansa wrote:
 On Sat, Jul 28, 2012 at 11:16:14AM +0200, Martin Jansa wrote:
 by installing lsb_release. Archlinux 64.
 
 Should it check to see if it installed first and error otherwise? It
 looks like it tries to do it here:
 
 +try:
 +output, err = bb.process.run(['lsb_release', '-a'], stderr=PIPE)
 +except bb.process.CmdError as exc:
 +return
 
 
 but it must be missing something.
 
 Same here, interesting is that it failed only during 2nd build, 1st
 with this commit applied finished fine.
 
 Ah no, it was there also first time I've overlooked it as it's not
 fatal.
 
 
 It was fatal for me as it trashed my sstate folder naming and then
 refused to build some packages. The directory in my sstate was
 created as:
 
 ${NATIVELSBSTRING}
 
 Then when Bitbake tried to use shared state it expanded
 NATIVELSBSTRING to nothing and failed.

I have the same issue here - Gentoo/64. Can we get it fixed in the master, 
please? Thanks.

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-ti] massive fallout after updates / was (no subject)

2012-06-21 Thread Denys Dmytriyenko 
On Fri, Jun 22, 2012 at 12:11:46AM +0200, Andreas Müller wrote:
 On Thu, Jun 21, 2012 at 11:36 PM, Andreas Müller
 schnitzelt...@googlemail.com wrote:
  after updating all my repos (angstrom+few extra layers) I get
 
 The error seems to be caused by meta-ti. When removed, parsing works
 as expected. By re-including I get now:
 
 ERROR: ExpansionError during parsing
 /home/Superandy/data/oe-core/sources/meta-ti/recipes-ti/gstreamer-ti/gstreamer-ti_svn.bb:
 Failure expanding variable FILESPATH, expression was
 ${@base_set_filespath([
 /home/Superandy/data/oe-core/sources/meta-ti/recipes-ti/gstreamer-ti/gstreamer-ti-svnr962-r85+${MACHINE_KERNEL_PR},

Could be caused by MACHINE_KERNEL_PR being undefined... What machine you are 
building for?

-- 
Denys


 /home/Superandy/data/oe-core/sources/meta-ti/recipes-ti/gstreamer-ti/gstreamer-ti-svnr962,
 /home/Superandy/data/oe-core/sources/meta-ti/recipes-ti/gstreamer-ti/gstreamer-ti,
 /home/Superandy/data/oe-core/sources/meta-ti/recipes-ti/gstreamer-ti/gstreamer-ti-svnr962,
 /home/Superandy/data/oe-core/sources/meta-ti/recipes-ti/gstreamer-ti/gstreamer-ti,
 /home/Superandy/data/oe-core/sources/meta-ti/recipes-ti/gstreamer-ti/files,
 /home/Superandy/data/oe-core/sources/meta-ti/recipes-ti/gstreamer-ti
 ], d)} which triggered exception SyntaxError: EOL while scanning
 string literal (FILESPATH, line 1)
 ERROR: No recipes available for:
   
 /home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
   
 /home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
   
 /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-kernel/linux/linux-yocto_3.2.bbappend
   
 /home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-kernel/linux/linux-yocto_3.2.bbappend
   
 /home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto_3.2.bbappend
   
 /home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-kernel/linux/linux-yocto_3.2.bbappend
   ..
 
 Andreas
 ___
 meta-ti mailing list
 meta...@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/meta-ti
 


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-ti] massive fallout after updates / was (no subject)

2012-06-21 Thread Denys Dmytriyenko 
On Fri, Jun 22, 2012 at 01:34:54AM +0200, Andreas Müller wrote:
 On Fri, Jun 22, 2012 at 1:02 AM, Denys Dmytriyenko de...@denix.org wrote:
 No need to understand everything: By removing require linux-tools.inc
 (the fastest patch I ever had :) I can now build again.
 
 @layer maintainers: removing
 
 require linux-tools.inc
 
 should be taken into consideration

Thanks!

-- 
Denys


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] pulseaudio: fix typo in the patch name, pulseaudo - pulseaudio

2012-06-05 Thread Denys Dmytriyenko 
From: Denys Dmytriyenko de...@ti.com

No PR bump is needed.

Signed-off-by: Denys Dmytriyenko de...@ti.com
---
 .../pulseaudio/pulseaudio_fix_for_x32.patch|  238 
 .../pulseaudio/pulseaudo_fix_for_x32.patch |  238 
 .../pulseaudio/pulseaudio_1.1.bb   |2 +-
 3 files changed, 239 insertions(+), 239 deletions(-)
 create mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/pulseaudio_fix_for_x32.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/pulseaudo_fix_for_x32.patch

diff --git 
a/meta/recipes-multimedia/pulseaudio/pulseaudio/pulseaudio_fix_for_x32.patch 
b/meta/recipes-multimedia/pulseaudio/pulseaudio/pulseaudio_fix_for_x32.patch
new file mode 100644
index 000..b68ac5b
--- /dev/null
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio/pulseaudio_fix_for_x32.patch
@@ -0,0 +1,238 @@
+Upstream-Status: Pending
+
+This patch makes assembly syntax compatible to the x32 toolchain.
+
+This fixes these kinds of compilations errors with x32 gcc.
+| pulsecore/svolume_mmx.c: Assembler messages:
+| pulsecore/svolume_mmx.c:107: Error: `(%esi,%rdi,4)' is not a valid 
base/index expression
+| pulsecore/svolume_mmx.c:135: Error: `(%esi,%rdi,4)' is not a valid 
base/index expression
+| pulsecore/svolume_mmx.c:161: Error: `(%esi,%rdi,4)' is not a valid 
base/index expression
+| pulsecore/svolume_mmx.c:162: Error: `8(%esi,%rdi,4)' is not a valid 
base/index expression
+| pulsecore/svolume_mmx.c:180: Error: `(%esi,%rdi,4)' is not a valid 
base/index expression
+| pulsecore/svolume_mmx.c:210: Error: `(%esi,%rdi,4)' is not a valid 
base/index expression
+| pulsecore/svolume_mmx.c:244: Error: `(%esi,%rdi,4)' is not a valid 
base/index expression
+| pulsecore/svolume_mmx.c:245: Error: `8(%esi,%rdi,4)' is not a valid 
base/index expression
+| make[3]: *** [libpulsecore_1.1_la-svolume_mmx.lo] Error 1
+
+Orignally these assembly lines are written for x86_64 ABI, now they are also 
compatible with
+X32 ABI.
+
+Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com 2011/12/03
+Index: pulseaudio-1.1/src/pulsecore/svolume_mmx.c
+===
+--- pulseaudio-1.1.orig/src/pulsecore/svolume_mmx.c
 pulseaudio-1.1/src/pulsecore/svolume_mmx.c
+@@ -107,7 +107,7 @@ static void pa_volume_s16ne_mmx(int16_t 
+  test $1, %2   \n\t /* check for odd samples */
+  je 2f \n\t
+ 
+- movd (%1, %3, 4), %%mm0   \n\t /* |  v0h  |  v0l  | */
++ movd (%q1, %3, 4), %%mm0   \n\t /* |  v0h  |  v0l  | */
+  movw (%0), %w4\n\t /* ..  |  p0   | */
+  movd %4, %%mm1\n\t
+ VOLUME_32x16 (%%mm1, %%mm0)
+@@ -122,7 +122,7 @@ static void pa_volume_s16ne_mmx(int16_t 
+  je 4f \n\t
+ 
+ 3: \n\t /* do samples in groups of 2 */
+- movq (%1, %3, 4), %%mm0   \n\t /* |  v1h  |  v1l  |  v0h  |  
v0l  | */
++ movq (%q1, %3, 4), %%mm0   \n\t /* |  v1h  |  v1l  |  v0h  |  
v0l  | */
+  movd (%0), %%mm1  \n\t /*  .. |   p1  |  
p0   | */
+ VOLUME_32x16 (%%mm1, %%mm0)
+  movd %%mm0, (%0)  \n\t /*  .. | p1*v1 | 
p0*v0 | */
+@@ -135,8 +135,8 @@ static void pa_volume_s16ne_mmx(int16_t 
+  je 6f \n\t
+ 
+ 5: \n\t /* do samples in groups of 4 */
+- movq (%1, %3, 4), %%mm0   \n\t /* |  v1h  |  v1l  |  v0h  |  
v0l  | */
+- movq 8(%1, %3, 4), %%mm2  \n\t /* |  v3h  |  v3l  |  v2h  |  
v2l  | */
++ movq (%q1, %3, 4), %%mm0   \n\t /* |  v1h  |  v1l  |  v0h  |  
v0l  | */
++ movq 8(%q1, %3, 4), %%mm2  \n\t /* |  v3h  |  v3l  |  v2h  |  
v2l  | */
+  movd (%0), %%mm1  \n\t /*  .. |   p1  |  
p0   | */
+  movd 4(%0), %%mm3 \n\t /*  .. |   p3  |  
p2   | */
+ VOLUME_32x16 (%%mm1, %%mm0)
+@@ -180,7 +180,7 @@ static void pa_volume_s16re_mmx(int16_t 
+  test $1, %2   \n\t /* check for odd samples */
+  je 2f \n\t
+ 
+- movd (%1, %3, 4), %%mm0   \n\t /* |  v0h  |  v0l  | */
++ movd (%q1, %3, 4), %%mm0   \n\t /* |  v0h  |  v0l  | */
+  movw (%0), %w4\n\t /* ..  |  p0   | */
+  rorw $8, %w4  \n\t
+  movd %4, %%mm1\n\t
+@@ -197,7 +197,7 @@ static void pa_volume_s16re_mmx(int16_t 
+  je 4f \n\t
+ 
+ 3: \n\t /* do samples in groups of 2 */
+- movq (%1, %3, 4), %%mm0   \n\t /* |  v1h  |  v1l  |  v0h  |  
v0l  | */
++ movq (%q1, %3, 4), %%mm0   \n\t /* |  v1h  |  v1l  |  v0h  |  
v0l  | */
+  movd (%0

Re: [OE-core] [oe] Fwd: Linuxtag 2012

2012-05-16 Thread Denys Dmytriyenko 
On Thu, May 17, 2012 at 03:18:26AM +0200, Henning Heinold wrote:
 On Tue, May 15, 2012 at 11:34:15PM +0200, Florian Boor wrote:
  Hi all,
  
  Am 10.05.2012 23:41, schrieb Philip Balister:
   I encourage anyone involved in OpenEmbedded who can get to Linuxtag for
   even a day to help it. It is a really fun time, and Berlin is a really
   nice place to visit.
  
  unluckily there was not much of feedback so far :-(
  We have a deadline for ordering exhibitor passes ending tomorrow 6pm. It 
  makes
  sense to have a two or three of us with these in order to be able to enter 
  the
  buildings before the visitors.
  
   We encourage people to bring devices that are made with OpenEmbedded and
   related technology to show off at the stand.
  
  I want to emphasize this one more time. It is very unlikely that I will be 
  able
  to make it there and if I do not get a few people together who will man the
  booth I will have to cancel our presence there :-(.
  
  Greetings
  
  Florian
 
 Hi,
 
 my second son was born today, so I can not make any promise for the linuxtag.

Congratulations!

PS. I'm also cannot go to Linuxtag for several different reasons...

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-openembedded] [PATCH] networkmanager: silence systemd bbclass WARNING.

2012-05-04 Thread Denys Dmytriyenko 
On Fri, May 04, 2012 at 11:15:33AM +0200, Elvis Dowson wrote:
 This patch fixes WARNING: /tool/yocto/meta-openembedded/meta-oe/

This is not the right mailing list for patches addressed to meta-oe. As I 
recall, I told you to submit to openembedded-devel, but not here. Sorry if it 
got you confused...


 recipes-connectivity/networkmanager/networkmanager_0.9.2.0.bb:
 it is recommended to set SYSTEMD_PACKAGES as existing-package-systemd
 
 Signed-off-by: Elvis Dowson elvis.dow...@gmail.com
 ---
 .../networkmanager/networkmanager_0.9.2.0.bb   |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git 
 a/meta-oe/recipes-connectivity/networkmanager/networkmanager_0.9.2.0.bb 
 b/meta-oe/recipes-connectivity/networkmanager/networkmanager_0.9.2.0.bb
 index 474d98a..478d61e 100644
 --- a/meta-oe/recipes-connectivity/networkmanager/networkmanager_0.9.2.0.bb
 +++ b/meta-oe/recipes-connectivity/networkmanager/networkmanager_0.9.2.0.bb
 @@ -54,7 +54,7 @@ do_install_append () {
   install -d ${D}/etc/NetworkManager/VPN
 }
 
 -SYSTEMD_PACKAGES = ${PN}
 +SYSTEMD_PACKAGES = ${PN}-systemd

That might be an overkill. I'm personally not yet very familiar with all the 
systemd specifics and not clear when to create ${PN}-systemd subpackage and 
when to just silence the warning...

-- 
Denys


 SYSTEMD_SERVICE = NetworkManager.service
 
 PACKAGES =+ libnmutil libnmglib libnmglib-vpn ${PN}-tests 
 -- 
 1.7.9.5
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] How to fix warning: set SYSTEMD_PACKAGES as existing-package-systemd

2012-05-04 Thread Denys Dmytriyenko 
On Fri, May 04, 2012 at 08:09:39PM +0200, Elvis Dowson wrote:
 Hi Koen,
 
 I bumped the PR, but still get the warning message. How is the warning for 
 this specific package linked to its dependents. The warning looks localized 
 to the lighttpd_1.4.30.bb recipe.
 
 If you can tell me how to fix it, I'll do it and send a patch.

You are trying to fix it in oe-core/poky layer, where it doesn't use systemd. 
There is a .bbappend in meta-oe for that. In fact, here's what I told you 
yesterday:

 WARNING: 
 /tool/yocto/meta-openembedded/meta-oe/recipes-connectivity/networkmanager/networkmanager_0.9.2.0.bb:
  it is recommended to set SYSTEMD_PACKAGES as existing-package-systemd
 WARNING: /tool/yocto/poky/meta/recipes-extended/lighttpd/lighttpd_1.4.30.bb: 
 it is recommended to set SYSTEMD_PACKAGES as existing-package-systemd

For these 2 please report them on openembedded-devel mailing list, where
meta-oe things are being discussed. The last warning is confisuing, as it
reports the recipe is in poky/oe-core, but it actually comes from the
corresponding .bbappend in meta-oe.

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-openembedded] [PATCH] networkmanager: silence systemd bbclass WARNING.

2012-05-04 Thread Denys Dmytriyenko 
On Fri, May 04, 2012 at 11:39:16AM -0700, Khem Raj wrote:
 On Fri, May 4, 2012 at 10:39 AM, Elvis Dowson elvis.dow...@gmail.com wrote:
 
 
  Me neither :-) ,... but this is what the warning message, suggested be done.
 
  It fixed the warning for networkmanager, though.
 
 If you have sysvinit scripts for this package then it makes sense to
 have this renamed package otherwise leave it out. I think warning is
 harmless in this case

And there's a knob for that:

+NATIVE_SYSTEMD_SUPPORT = 1

But use it wisely! :)

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bdwgc: Set ARM_INSTRUCTION_SET to arm

2012-04-19 Thread Denys Dmytriyenko 
On Thu, Apr 19, 2012 at 12:20:39PM +0200, Ken Werner wrote:
 The bdwgc recipe uses a version of libatomic that fails when building in Thumb
 mode. This has been fixed upstream already. The
 pulseaudio/libatomics-ops_1.2.bb has the same issue and sets the
 ARM_INSTRUCTION_SET to arm (probably until a new version gets pulled in).
 This patch applies the same workaround to the bdwgc/bdwgc_20110107.bb recipe.
 
 Signed-off-by: Ken Werner ken.wer...@linaro.org

Acked-by: Denys Dmytriyenko de...@ti.com


 ---
  meta/recipes-support/bdwgc/bdwgc_20110107.bb |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/meta/recipes-support/bdwgc/bdwgc_20110107.bb 
 b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
 index 327e59b..bc7b613 100644
 --- a/meta/recipes-support/bdwgc/bdwgc_20110107.bb
 +++ b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
 @@ -33,5 +33,7 @@ PR = r1
  
  S = ${WORKDIR}/bdwgc
  
 +ARM_INSTRUCTION_SET = arm
 +
  inherit autotools
  BBCLASSEXTEND = native nativesdk
 -- 
 1.7.5.4
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] meta-chromium

2012-04-17 Thread Denys Dmytriyenko 
On Tue, Apr 17, 2012 at 10:40:28PM +0200, Eric B?nard wrote:
 Hi,
 
 we have pushed the begining of our (Eukr?a Electromatique's team and
 especially Denis) work to get Chromium to build with OpenEmbedded Core
 to : git://github.com/eukrea/meta-chromium.git
 https://github.com/eukrea/meta-chromium
 
 For the moment it's only tested on ARMv7 platforms (i.MX515 and i.MX535
 based) where it seems robust and quite fast on most of the HTML5 tests
 we ran (only WebGL doesn't yet work).
 
 Feel free to send patches to improve the recipes and add support for
 other platforms.
 
 TODO :
 - enable WebGL with OpenGL ES support
 - support other platforms than armv7
 - merge with meta-mozilla to create a meta-browser layer

Eric, Denis,

Great news! Thanks for your work!

-- 
Denys


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Fwd: ARM hard-float linker path - consensus

2012-04-13 Thread Denys Dmytriyenko 
On Fri, Apr 13, 2012 at 11:11:02AM -0700, Khem Raj wrote:
 FYI this will impact us in coming time. If someone has questions
 please bring it up

While it's a slightly unexpected outcome (/lib/ld-linux-armhf.so.3) it's still 
good to see some agreement here.

Do we want to make the necessary toolchain changes right away, or wait for 
them to propagate from upstream?

-- 
Denys


 -- Forwarded message --
 From: Steve McIntyre steve.mcint...@linaro.org
 Date: Fri, Apr 13, 2012 at 10:37 AM
 Subject: ARM hard-float linker path - consensus
 To: cross-dis...@lists.linaro.org
 Cc: libc-po...@sourceware.org, gcc-patc...@gcc.gnu.org
 
 
 Hi folks,
 
 As promised, here's minutes from the call we had this
 afternoon. Spoiler: the result we've agreed is
 
  /lib/ld-linux-armhf.so.3
 
 And here's a transcription of the minutes from
 
  https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
 
 
 
 Meeting: 13th April 2012, 15:00 UTC
 
 Agenda
 --
 
  * Debian/Ubuntu have so far built using 
 /lib/arm-linux-gnueabihf/ld-linux.so.3
  * Some other distros (Fedora, OpenSUSE) are still using
 /lib/ld-linux.so.3 option which matches the older soft-float ABI
  * Some people are proposing /libhf/ld-linux.so.3 or
 /libhfp/ld-linux.so.3 (multilib)
  * Some people proposed /lib/ld-arm-linux-gnueabihf.so.3 (similar to
 x86_64, libs still in /lib, from Michael Hope)
  * What should we do as a community?
 
 Present
 ---
 
 Name               Affiliations
 
 Steve McIntyre     ARM, Debian, Linaro
 Wookey             ARM, Debian, Linaro
 Richard Earnshaw   ARM, gcc
 Jeff Law           Fedora, Red Hat, gcc, glibc
 Jon Masters        Fedora, Red Hat
 Andrew Haley       Fedora, Red Hat, gcc
 Andreas Jaeger     SUSE, openSUSE, glibc
 Carlos O'Donnell   Mentor, gcc
 Steve Langasek     Canonical, Ubuntu, Debian
 Dann Frazier       Canonical, Ubuntu, Debian
 Adam Conrad        Canonical, Ubuntu, Debian
 Matthias Klose     Canonical, Ubuntu, Debian
 Mike Frysinger     Gentoo
 Dennis Gilmore     Fedora, Red Hat
 
 Discussion
 --
 
 We started with a couple of questions up front to establish the
 grounds for discussion:
 
  * We believed that decision makers were present for all the important
   parties, i.e. all the arm hard-float distros, plus toolchain
   developers. This meant that a decision taken at the meeting could
   be implemented without needing further arguments/negotiations.
 
  * All the people present understood the importance of cross-distro
   binary compatibility, and they all wanted it. This led to agreement
   that we needed to agree on a standard path for the runtime linker
   for ARM hard-float Linux binaries.
 
 Debian and Ubuntu had so far been using the multi-arch path of
 /lib/arm-linux-gnueabihf/ld-linux.so.3. Fedora and OpenSUSE were thus
 far using /lib/ld-linux.so.3, the same as the soft-float ABI. Others
 had proposed alternative paths such as /libhf/ld-linux.so.3 or
 /libhfp/ld-linux.so.3 (multilib) or
 /lib/ld-arm-linux-gnueabihf.so.3. Discussion showed that none of these
 were found to be universally acceptable.
 
 Two parties were likely to be soon affected by an agreement here:
 
 1. Ubuntu 12.04 (releasing with armhf in ~2 weeks)
 
 Adam/Steve L agreed that all efforts would be put in to switch the
 compilers in Ubuntu to a new path before release. Default things like
 gcc would be correct, but less common tools might still be targetting
 the old path /lib/arm-linux-gnueabihf/ld-linux.so. at release. They
 could be fixed in the longer term and would not stop progress here.
 
 2. Mentor (Codebench due for release in ~1 week)
 
 Carlos mentioned this - Codebench has been using /lib/ld-linux.so.3
 for hard-float binaries for some time and it was too late to change
 that for this upcoming release. Next release due in October. Suggested
 and accepted that this should be mentioned in release notes: if people
 want to use Codebench on some systems (Debian/Ubuntu and derivatives),
 they'll need to tweak their system setup. He may be able to do the
 linker change and rebuild in a point release in a few weeks.
 
 It was briefly suggested that the soft-float linker should be renamed
 away from /lib/ld-linux.so.3 as well at this time, but that idea was
 quickly shot down.
 
 Proposal #1: /lib/ld-armhf.so.3       (not generally liked)
 
 Proposal #2: /lib/ld-linux-armhf.so.3 (not favourite, but considered
                                       an acceptable compromise by all)
 
 No need to go any further.
 
 Conclusion
 --
 
 All the people in the meeting agreed: the new runtime linker path for
 ARM hard-float Linux binaries was to be
 
 /lib/ld-linux-armhf.so.3
 
 ACTION: People at the meeting to present this decision to their
        companies / communities and get the appropriate changes made.
 
 Further discussion
 --
 
 General unhappiness with the mess that led to this meeting. Future
 planning needs to be

Re: [OE-core] Yocto Project 1.2 M4 schedule

2012-04-12 Thread Denys Dmytriyenko 
On Thu, Apr 12, 2012 at 04:39:52PM +0200, Koen Kooi wrote:
 
 We can't do worse than fedora: 
 http://lists.fedoraproject.org/pipermail/announce/2012-February/003044.html

Are you suggesting we adopt a new Unhealthy snacks or Junk food versioning 
schema? :)

-- 
Denys

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

<    3   4   5   6   7   8   9   >