Re: [OE-core] [PATCH 2/8] busybox: add support for CONFIG_FEATURE_INDIVIDUAL
On Fri, Jun 7, 2013 at 3:13 AM, qi.c...@windriver.com wrote: From: Chen Qi qi.c...@windriver.com Previously, if CONFIG_FEATURE_INDIVIDUAL was enabled for busybox, yocto-based systems could start correctly. This is because if busybox is built as individual apps, '/bin/busybox' may not be present, so setting the default ALTERNATIVE_TARGET to '/bin/busybox' is not appropriate and could lead to errors. This patch fixes this problem by checking the existence of '/bin/busybox' before setting the ALTERNATIVE_TARGET to '/bin/busybox'. After this change, if busybox is built as individual apps, we'll have links like '/bin/ls - /bin/ls.busybox', otherwise, we'll have links like '/bin/ls - /bin/busybox'. Note there's a grep expression change in this patch. The old expression doesn't work well, it has an unwanted underscore, so I changed it to make it work. [YOCTO #4570] Signed-off-by: Chen Qi qi.c...@windriver.com Please rework 1/8 and reduce the changes here. This will be easier to test and review this way. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OE-Core and Bitbake wrapper changes (min 2.7.3 python version)
On Fri, Jun 7, 2013 at 7:47 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: Its not secret that I hate the current bitbake wrapper script and want to remove it for 101 different reasons. I now have code which removes the need for the double execution of bitbake which was the only fundamental reason we had it. The question therefore remains, what to do with the other pieces of the wrapper, specifically the tar and git versions checks. As a reminder for those who don't remember the problem here, the git version is checked since we use certain parameters in the git fetcher which need certain versions of git and git is in ASSUME_PROVIDED these days. Its possible to trigger git operations at part time to resolve revisions. tar is even more ugly since the wrong version has issues extracting sstate archives. These issues mean injecting building them into the dependency chain at the right point is hard. Personally, I think we carry around a bit too much legacy these days and its starting to hurt us. I would therefore like to propose that we take this opportunity to do some spring cleaning and simply error on: * broken tar versions * too old versions of git * python 2.7.3 The python version check would move to the oe-init-build-env script, the git/tar versions to sanity.bbclass. The recommendation for anyone with these older versions would be to install our standalone tools tarball which would have python 2.7.3 and working versions of tar/git. The reason for the python version change is so we can embrace the unittest improvements in 2.7 and drop all of the workarounds for pre 2.7.3 bugs in bitbake. This starts to move us towards python 3, if this tarball works well, we'd use the same approach to move to python 3. Any objections? I fully agree in error on these situations and providing a workaround solution for old host systems seems perfect. This would clean a good amount of legacy code and I also agree it is the way to go. So count me as a supporter for it :) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/8] busybox: remove the postinst part of the recipe
On Fri, Jun 7, 2013 at 11:10 PM, ChenQi qi.c...@windriver.com wrote:
On 06/07/2013 08:32 PM, Otavio Salvador wrote:
On Fri, Jun 7, 2013 at 3:13 AM, qi.c...@windriver.com wrote:
From: Chen Qi qi.c...@windriver.com
Remove the pkg_postinst_${PN} from this recipe, as it's redundant.
It basically wants to do the same thing as the update-alternatives
does. But it doesn't do it well.
Signed-off-by: Chen Qi qi.c...@windriver.com
Instead of removing it, please convert it here for update-alternatives
so it keeps working on this commit and allow bisect in future if need.
Hi Otavio,
Thanks for your review and comments.
Sorry but I don't understand it :(
What do you mean by convert it for update-alternatives?
Could you please give me a little more explanation?
Yes, add the update-alternatives support here as well so we can remove the
postinst and add the new code in same patch; it allows for bisect :)
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] sstate.bbclass: kill MIRRORS and FILESPATH to speed up fetching
On Mon, Jun 10, 2013 at 5:46 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com The default FILESPATH isn't really of use, as we don't expect to find sstate archives buried in layer recipe directories, and the default MIRRORS is intended for use for fetching SRC_URI, not sstate. Signed-off-by: Christopher Larson chris_lar...@mentor.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] sstate.bbclass: fetch archive+siginfo in a single pstaging_fetch
On Mon, Jun 10, 2013 at 5:46 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com This avoids unnecessary duplication of setup. The only visible change in behavior will be the case if siginfo exists and the archive does not, in which case it'll redownload both, but this doesn't seem unresasonable to me, particularly since the archive is downloaded first, making this case particularly unlikely. Signed-off-by: Christopher Larson chris_lar...@mentor.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] sstate.bbclass: brute force silence fetch errors
On Mon, Jun 10, 2013 at 5:46 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com bb.fetch2.Fetcher.download() prints any fetch errors that come from the underlying fetcher, rather than letting the caller do so, which means there's no way to silence the fetch error messages without manipulating the loggers. So we do so. The reason for doing this is that the user doesn't care if we failed to fetch an sstate archive, the failure mode is just to rerun the real task anyway. Signed-off-by: Christopher Larson chris_lar...@mentor.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] copyleft_compliance: set 'dirs' flag on task
On Mon, Jun 10, 2013 at 5:46 PM, Christopher Larson kerg...@gmail.comwrote:
From: Christopher Larson chris_lar...@mentor.com
Without this, due to bitbake defaulting to ${B}, it's possible to get ${S}
inadvertantly created before do_unpack, breaking the unpack of git sources,
which expect the destination to not exist.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
Reviewed-by: Otavio Salvador ota...@ossystems.com.br
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] packagegroup-core-tools-profile: don't exclude mips
On Mon, Jun 10, 2013 at 5:46 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com Now that liburcu supports mips, this packagegroup can pull in lttng software on that architecture. Signed-off-by: Christopher Larson chris_lar...@mentor.com Your commit log say's nothing about babeltrace. I think it'd be good to add it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] avahi: inherit python classes, use PACKAGECONFIG
On Mon, Jun 10, 2013 at 5:46 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com Without using our python classes and having appropriate dependencies, the build is nondeterministic, and whether a python-avahi package is produced will vary depending on the host environment, yet avahi-discover is always produced, and it depends on python-avahi. Signed-off-by: Christopher Larson chris_lar...@mentor.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br This could be backported for 1.4.2 I think; Paul? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] packagegroup-base-vfat: include dosfsprogs
On Mon, Jun 10, 2013 at 5:47 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com The ext2 group includes e2fsprogs, so this is consistent and should be appropriate, I think. Signed-off-by: Christopher Larson chris_lar...@mentor.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] license.bbclass: include all licenses in the manifest
On Mon, Jun 10, 2013 at 5:46 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com When we don't have a generic license file for the license in question, we can warn, but we should still include it in the manifest, otherwise the manifest doesn't reflect reality. Failing to include a license listed in the recipe in the manifest can't be allowed. Signed-off-by: Christopher Larson chris_lar...@mentor.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] insane.bbclass: quiet package errors not in *_QA
On Mon, Jun 10, 2013 at 5:47 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com Currently, if a package QA type from package.bbclass is not listed in ERROR_QA, it gets shown, regardless of whether it's in WARN_QA. This differs from the behavior of the rest of the QA handling (which doesn't call package_qa_handle_error at all if it's in neither _QA variable), and is nonintuitive. Change this to use bb.note() if it's listed neither in ERROR_QA nor WARN_QA, so it ends up in the task logs, but doesn't clutter up the user's output. Signed-off-by: Christopher Larson chris_lar...@mentor.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] connman: use PACKAGECONFIG for WISPr support
On Mon, Jun 10, 2013 at 5:47 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com Signed-off-by: Christopher Larson chris_lar...@mentor.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br This seems safe for backporting to 1.4.2 and would allow for more control on connman build; Paul? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/4] packagegroup-core-tools-profile: don't exclude mips
On Mon, Jun 10, 2013 at 8:15 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com Now that liburcu supports mips, this packagegroup can pull in lttng recipes (lttng-ust, lttng-tools, lttng-modules, babeltrace) on that architecture as it does for the others. Signed-off-by: Christopher Larson chris_lar...@mentor.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 4/4] license.bbclass: include all licenses in the manifest
On Mon, Jun 10, 2013 at 8:15 PM, Christopher Larson kerg...@gmail.comwrote: From: Christopher Larson chris_lar...@mentor.com When we don't have a generic license file for the license in question, we can warn, but we should still include it in the manifest, otherwise the manifest doesn't reflect reality. Failing to include a license listed in the recipe in the manifest can't be allowed. Signed-off-by: Christopher Larson chris_lar...@mentor.com Reviewed-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tune-cortexa*.inc: fix tunings for cortex a5, a7, a8, a9, a15 machines.
On Wed, Jun 12, 2013 at 1:38 PM, Andy Voltz andy.vo...@timesys.com wrote: Using CORTEX_ID variable reference in the tuning overrides did not work. This reverts those changes, and adds a tuning file for the cortex-a5. Revert tune-cortexa5.inc: Add tune file for cortex-a5 Revert tune-cortexa.inc: create a common include for cortex-a armv7a tuning Signed-off-by: Andy Voltz andy.vo...@timesys.com Thanks for fixing this. Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oe-buildenv-internal: Preserve/Unset and Restore TERM
On Fri, Jun 14, 2013 at 5:48 PM, Saul Wold s...@linux.intel.com wrote: Having a value in TERM that is not recognized by the nativesdk can cause potential escape sequences appearing in the output stream, the can be seen on Ubuntu with TERM=xterm-256color. Unsetting TERM allows for consistent results in the python output. Also, don't exit, use return, otherwise the shell exits and get no error information. [YOCTO #4732] Signed-off-by: Saul Wold s...@linux.intel.com Please split the fix and get the exit/return fix applied. While on that, ensure the errors are send to 2 as done in other error messages. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] opkg: put libopkg header files into libopkg-dev
On Sun, Jun 16, 2013 at 9:22 PM, Paul Barker p...@paulbarker.me.uk wrote: The header files for libopkg belong in the package libopkg-dev rather than opkg-dev where they are placed by default. Signed-off-by: Paul Barker p...@paulbarker.me.uk Reviewed-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 1/9] busybox: remove the postinst part of the recipe
On Mon, Jun 17, 2013 at 2:49 AM, qi.c...@windriver.com wrote:
From: Chen Qi qi.c...@windriver.com
Remove the pkg_postinst_${PN} from this recipe, as it's redundant.
It basically wants to do the same thing as the update-alternatives
does. But it doesn't do it well.
Signed-off-by: Chen Qi qi.c...@windriver.com
Most of patch 1 and 2 should be merged; here you should drop the
postinst and convert these to the update-alternative way so we don't
have the tree broken after this patch and allow for bisect to be
used.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 1/9] busybox: remove the postinst part of the recipe
On Mon, Jun 17, 2013 at 10:37 PM, ChenQi qi.c...@windriver.com wrote:
On 06/18/2013 01:52 AM, Otavio Salvador wrote:
On Mon, Jun 17, 2013 at 2:49 AM, qi.c...@windriver.com wrote:
From: Chen Qi qi.c...@windriver.com
Remove the pkg_postinst_${PN} from this recipe, as it's redundant.
It basically wants to do the same thing as the update-alternatives
does. But it doesn't do it well.
Signed-off-by: Chen Qi qi.c...@windriver.com
Most of patch 1 and 2 should be merged; here you should drop the
postinst and convert these to the update-alternative way so we don't
have the tree broken after this patch and allow for bisect to be
used.
Hi Otavio,
Maybe there's some misunderstanding here.
To be clear, patch 1 and patch 2 do two different things.
Patch 1 removes postinst, it has nothing to do with patch 2, which fix
busybox.inc to support the FEATURE_INDIVIDUAL.
And after this patch (patch 1), the tree is not broken. The busybox still
works as it has been working so far.
[
And I just did a simple test to confirm this. On the lastest master, I
removed the postinst part of busybox.inc, and built a core-image-minimal, it
worked out well. Here's some output.
root@qemuarm:~# ls -l /bin/ | grep busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 ash - /bin/busybox
-rwsr-xr-x1 root root556824 Jun 18 01:27 busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 cat - /bin/busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 chattr -
/bin/busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 chgrp -
/bin/busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 chmod -
/bin/busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 chown -
/bin/busybox
lrwxrwxrwx1 root root12 Jun 18 01:31 cp - /bin/busybox
]
Oh I see.
So I have no objection for the patch :-)
Thanks by letting me know.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] Utilizing LAYERVERSION_ to identify breaking changes to a layer
On Thu, Jun 20, 2013 at 7:56 PM, Flanagan, Elizabeth elizabeth.flana...@intel.com wrote: I know I've run into this issue and I'm going to bet that other folks have as well. When running some sort of continuous integration system (in my case, yocto-autobuilder), I need to build to at least two releases back. The problem is, sometimes, local.conf and bblayers.conf requirements change, for example, a layer needs a BBMASK for the prior release but can't have it for the current one or a layer gets split so that I need to add two directories to BBLAYERS as opposed to just the one that I used a few commits back. I currently have no great way of figuring that out and it has causes immense amounts of pain. I am sorry but I didn't follow what it will help. Can you please provide an example? I always thought the right way to handle it is to have a branch... -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GCC 4.8 Issues with fsl-ppc and fsl-arm (e5000)
On Tue, Jun 25, 2013 at 2:42 PM, Khem Raj raj.k...@gmail.com wrote: On Jun 25, 2013, at 10:07 AM, Saul Wold s...@linux.intel.com wrote: Guys, There is a continuing failure on the auto-builder with the 4.8 version of GCC for the fsl-ppc and fsl-arm BSPs. This is currently holding oe-core back from updating GCC to 4.8, which we want to do soon so that we have get any other issues worked out that might come up. First of all these are not reference BSPs for OE-Core so this should not be a hold off if its urgent and we still have 4.7 gcc in OE-Core But its nicer if they worked. These seem to be ICE issues can get bee seen in the following log files: http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-arm/builds/148/steps/Building%20Images/logs/stdio perf is tied to kernel, it works fine with linux-yocto, what kernel is used for imx53qsb ? a preprocessed callchain.c will be helpful. http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_11.09.01 If you provide me the command I should do, I can get it. Or Saul might get it from autobuilder as well. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] alsa-tools: Pass ACLOCAL_FLAGS so aclocal uses the right params
The compile step ends regenerating the configure scripts included in
the source subdirs, for it to properly work we need to pass the
ACLOCAL_FLAGS or the .m4 files won't be found.
,[ Build error ]
| ./ac3dec
| aclocal: warning: autoconf input should be named 'configure.ac', not
'configure.in'
| configure.in:18: warning: macro 'AM_PATH_ALSA' not found in library
| automake: warning: autoconf input should be named 'configure.ac', not
'configure.in'
| configure.in:9: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are
deprecated. For more info, see:
| configure.in:9:
http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_INIT_AUTOMAKE-invocation
| automake: warning: autoconf input should be named 'configure.ac', not
'configure.in'
| test/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or
'*_CPPFLAGS')
| configure.in:18: error: possibly undefined macro: AM_PATH_ALSA
| If this token and others are legitimate, please use m4_pattern_allow.
| See the Autoconf documentation.
| make: *** [all] Error 1
| ERROR: oe_runmake failed
`
Reported-by: Rogerio Nunes rogerio.nu...@freescale.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-multimedia/alsa/alsa-tools_1.0.26.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.26.1.bb
b/meta/recipes-multimedia/alsa/alsa-tools_1.0.26.1.bb
index 24af545..a18cb46 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.26.1.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.26.1.bb
@@ -33,7 +33,7 @@ do_configure () {
do_compile_prepend () {
#Automake dir is not correctly detected in cross compilation case
export AUTOMAKE_DIR=${STAGING_DATADIR_NATIVE}/$(ls
${STAGING_DATADIR_NATIVE} | grep automake)
-export ACLOCAL=aclocal --system-acdir=${ACLOCALDIR}/
+export ACLOCAL_FLAGS=--system-acdir=${ACLOCALDIR}/
}
FILES_${PN} += ${datadir}/ld10k1
--
1.8.3.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] alsa-tools: Pass ACLOCAL_FLAGS so aclocal uses the right params
On Tue, Jun 25, 2013 at 2:56 PM, Otavio Salvador ota...@ossystems.com.br wrote: The compile step ends regenerating the configure scripts included in the source subdirs, for it to properly work we need to pass the ACLOCAL_FLAGS or the .m4 files won't be found. ,[ Build error ] | ./ac3dec | aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in' | configure.in:18: warning: macro 'AM_PATH_ALSA' not found in library | automake: warning: autoconf input should be named 'configure.ac', not 'configure.in' | configure.in:9: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see: | configure.in:9: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_INIT_AUTOMAKE-invocation | automake: warning: autoconf input should be named 'configure.ac', not 'configure.in' | test/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS') | configure.in:18: error: possibly undefined macro: AM_PATH_ALSA | If this token and others are legitimate, please use m4_pattern_allow. | See the Autoconf documentation. | make: *** [all] Error 1 | ERROR: oe_runmake failed ` Reported-by: Rogerio Nunes rogerio.nu...@freescale.com Signed-off-by: Otavio Salvador ota...@ossystems.com.br Paul, Can you please consider it for dylan? I am using it in master and dylan for some time without issues and it does address the build failure for me. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GCC 4.8 Issues with fsl-ppc and fsl-arm (e5000)
On Tue, Jun 25, 2013 at 3:00 PM, Khem Raj raj.k...@gmail.com wrote: On Jun 25, 2013, at 10:46 AM, Otavio Salvador ota...@ossystems.com.br wrote: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_11.09.01 hmm 2.6.35 If you provide me the command I should do, I can get it. Or Saul might get it from autobuilder as well. something like below. Replace the paths to your tmpdir appropriately in below cmd ( e.g. /builds1/angstrom/build/tmp-angstrom_next-eglibc/work/beaglebone-angstrom-linux-gnueabi might be something else for you and also compiler name and sysroot) cd into kernel srcdir in staging tmp/sysroots/beaglebone/usr/src/kernel/tools/perf arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/qemuarm -O2 -pipe -g -feliminate-unused-debug-types -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iutil/include -Iarch/arm/include -I/builds1/angstrom/build/tmp-angstrom_next-eglibc/work/beaglebone-angstrom-linux-gnueabi/perf/1.0-r8/perf-1.0/arch/arm/include/generated/uapi -I/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/beaglebone/usr/src/kernel/arch/arm/include/uapi -I/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/beaglebone/usr/src/kernel/arch/arm/include -I/builds1/angstrom/build/tmp-angstrom_next-eglibc/work/beaglebone-angstrom-linux-gnueabi/perf/1.0-r8/perf-1.0/include/generated/uapi -I/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/beaglebone/usr/src/kernel/include/uapi -I/builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/beaglebone/usr/s rc/kernel/include -I/builds1/angstrom/build/tmp-angstrom_next-eglibc/work/beaglebone-angstrom-linux-gnueabi/perf/1.0-r8/perf-1.0/util -Iutil -I. -I../lib/traceevent/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -I/builds1/angstrom/build/tmp-angstrom_next-eglibc/work/beaglebone-angstrom-linux-gnueabi/perf/1.0-r8/perf-1.0/ -DLIBELF_SUPPORT -DLIBELF_MMAP -I=/usr/include/slang -DNEWT_SUPPORT -DHAVE_ON_EXIT -DBACKTRACE_SUPPORT util/callchain.c -E -dD -o callchain.i and send me callchain.i Do I need to run it using 4.8 or 4.7 should be enough? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] eglibc (would be 2.18) recipes
On Wed, Jun 26, 2013 at 6:06 PM, Khem Raj raj.k...@gmail.com wrote: Hi All I have put together eglibc recipes for upcoming 2.18 release and pushed to a contrib tree here http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/eglibc-2.18 They built angstrom/systemd-images fine and booted OK on all supported qemu machines on OE-Core Please test them out in your configurations and machines and provide feedback, lets weed out the issue early Could you also make a tree based on poky? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/8] Proposed implementation of a new runtime tests framework
On Fri, Jun 28, 2013 at 7:04 AM, Stefan Stanacar stefanx.stana...@intel.com wrote: ... There are some areas for improvement/limitations right now: - a better way of getting the list of installed packages in a image - qemu is started with the -snapshot option, we should create a copy of the original rootfs instead. - when using TEST_SUITES = auto there is no dependency at all between tests (rpm would run before ssh test), so better use TEST_SUITES = ping ssh auto - better logging and error reporting for qemu problems (runqemu erros, qemu doesn't start, etc) - more helper methods for tests - others I can't think of right now :) Did you think about adding something like an overidable set of hooks which starts, setup image and shutdown the machine? This would allow same framework to be used for real hardware test. Regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] buildhistory: Record size of installed package not compressed archive
On Sat, Jun 29, 2013 at 10:36 PM, Martin Jansa martin.ja...@gmail.com wrote: * usually it's more important to know how much space will each package take on target device then size of compressed package Signed-off-by: Martin Jansa martin.ja...@gmail.com I fully agree; this is a more useful information indeed. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] lttng-ust: Update to 2.2.0 based release
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
.../lttng-ust/build-Fix-out-of-tree-build.patch| 28 ++
.../{lttng-ust_2.1.2.bb = lttng-ust_2.2.0.bb} | 6 ++---
2 files changed, 31 insertions(+), 3 deletions(-)
create mode 100644
meta/recipes-kernel/lttng/lttng-ust/build-Fix-out-of-tree-build.patch
rename meta/recipes-kernel/lttng/{lttng-ust_2.1.2.bb = lttng-ust_2.2.0.bb}
(89%)
diff --git
a/meta/recipes-kernel/lttng/lttng-ust/build-Fix-out-of-tree-build.patch
b/meta/recipes-kernel/lttng/lttng-ust/build-Fix-out-of-tree-build.patch
new file mode 100644
index 000..cc3220a
--- /dev/null
+++ b/meta/recipes-kernel/lttng/lttng-ust/build-Fix-out-of-tree-build.patch
@@ -0,0 +1,28 @@
+From d5a822fbeaec69e86c6af1f0ab8db0ff030f6678 Mon Sep 17 00:00:00 2001
+From: Otavio Salvador ota...@ossystems.com.br
+Date: Tue, 2 Jul 2013 10:25:06 -0300
+Subject: [PATCH] build: Fix out-of-tree build
+
+To allow out-of-tree build, we need to include top_buildir in include
+directories or the generated config header won't be found.
+
+Upstream-Status: Pending
+
+Signed-off-by: Otavio Salvador ota...@ossystems.com.br
+---
+ liblttng-ust-comm/Makefile.am | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/liblttng-ust-comm/Makefile.am b/liblttng-ust-comm/Makefile.am
+index 2ae997c..065dbbf 100644
+--- a/liblttng-ust-comm/Makefile.am
b/liblttng-ust-comm/Makefile.am
+@@ -1,4 +1,4 @@
+-AM_CPPFLAGS = -I$(top_srcdir)/include
++AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include
+
+ noinst_LTLIBRARIES = liblttng-ust-comm.la
+
+--
+1.8.3.1
+
diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.1.2.bb
b/meta/recipes-kernel/lttng/lttng-ust_2.2.0.bb
similarity index 89%
rename from meta/recipes-kernel/lttng/lttng-ust_2.1.2.bb
rename to meta/recipes-kernel/lttng/lttng-ust_2.2.0.bb
index 93852b0..d03f207 100644
--- a/meta/recipes-kernel/lttng/lttng-ust_2.1.2.bb
+++ b/meta/recipes-kernel/lttng/lttng-ust_2.2.0.bb
@@ -17,13 +17,13 @@ RPROVIDES_${PN} = lttng2-ust
RREPLACES_${PN} = lttng2-ust
RCONFLICTS_${PN} = lttng2-ust
-SRCREV = 3f7a0876566a432ad2cc2b27a2725641e36da92d
-PV = 2.1.2
-PR = r0
+SRCREV = cfaee541fea7f5760b5501913c6902f5e4da9dba
+PV = 2.2.0
PE = 2
SRC_URI = git://git.lttng.org/lttng-ust.git;protocol=git \
file://depends-liblttng-ust-tracepoin.patch \
+ file://build-Fix-out-of-tree-build.patch \
S = ${WORKDIR}/git
--
1.8.3.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] lttng-tools: Update to 2.2.0 based release
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
.../lttng/{lttng-tools_2.1.0.bb = lttng-tools_2.2.0.bb} | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
rename meta/recipes-kernel/lttng/{lttng-tools_2.1.0.bb =
lttng-tools_2.2.0.bb} (92%)
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.1.0.bb
b/meta/recipes-kernel/lttng/lttng-tools_2.2.0.bb
similarity index 92%
rename from meta/recipes-kernel/lttng/lttng-tools_2.1.0.bb
rename to meta/recipes-kernel/lttng/lttng-tools_2.2.0.bb
index e7ce7fc..e664d85 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.1.0.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.2.0.bb
@@ -11,9 +11,8 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=01d7fc4496aacf37d90df90b90b0cac1 \
DEPENDS = liburcu popt lttng-ust
-SRCREV = 917f768512b5d336d553b801f6c5308d90252a89
-PV = v2.1.0
-PR = r0
+SRCREV = eff0b2c38d24092c41bbb51926ac4e3b8c6acb83
+PV = v2.2.0
SRC_URI = git://git.lttng.org/lttng-tools.git;protocol=git
--
1.8.3.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] babeltrace: Update to 1.1.1 based release
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/recipes-kernel/lttng/{babeltrace_1.1.0.bb = babeltrace_1.1.1.bb} | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
rename meta/recipes-kernel/lttng/{babeltrace_1.1.0.bb = babeltrace_1.1.1.bb}
(91%)
diff --git a/meta/recipes-kernel/lttng/babeltrace_1.1.0.bb
b/meta/recipes-kernel/lttng/babeltrace_1.1.1.bb
similarity index 91%
rename from meta/recipes-kernel/lttng/babeltrace_1.1.0.bb
rename to meta/recipes-kernel/lttng/babeltrace_1.1.1.bb
index dd7e056..8aa3ae1 100644
--- a/meta/recipes-kernel/lttng/babeltrace_1.1.0.bb
+++ b/meta/recipes-kernel/lttng/babeltrace_1.1.1.bb
@@ -10,9 +10,8 @@ inherit autotools
DEPENDS = glib-2.0 util-linux popt
-SRCREV = c99b1910bea848e8f0ae5641bb63b8f4f84f3ec0
+SRCREV = a386e24609752742b100120db6798d311fab512a
PV = 1.1+git${SRCPV}
-PR = r0
SRC_URI = git://git.efficios.com/babeltrace.git;protocol=git
--
1.8.3.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] lttng-modules: Update to 2.2.0 based release
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
...modules-replace-KERNELDIR-with-KERNEL_SRC.patch | 66 +-
...tng-modules_2.1.1.bb = lttng-modules_2.2.0.bb} | 5 +-
2 files changed, 55 insertions(+), 16 deletions(-)
rename meta/recipes-kernel/lttng/{lttng-modules_2.1.1.bb =
lttng-modules_2.2.0.bb} (90%)
diff --git
a/meta/recipes-kernel/lttng/lttng-modules/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
b/meta/recipes-kernel/lttng/lttng-modules/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
index aa24171..30f825c 100644
---
a/meta/recipes-kernel/lttng/lttng-modules/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
+++
b/meta/recipes-kernel/lttng/lttng-modules/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
@@ -7,35 +7,75 @@ build and install lttng-modules, we do this replacement for
it as-is.
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
- Makefile |7 +++
- 1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
-index 5ac13d7..25caad5 100644
+index a9d1cb1..c1b65b9 100644
--- a/Makefile
+++ b/Makefile
-@@ -38,17 +38,16 @@ obj-m += lib/
+@@ -43,19 +43,19 @@ obj-m += lib/
+ endif # CONFIG_TRACEPOINTS
+
+ else # KERNELRELEASE
+- KERNELDIR ?= /lib/modules/$(shell uname -r)/build
++ KERNEL_SRC ?= /lib/modules/$(shell uname -r)/build
+ PWD := $(shell pwd)
+ CFLAGS = $(EXTCFLAGS)
+
+ default:
+- $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
++ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules
+
+ modules_install:
+- $(MAKE) -C $(KERNELDIR) M=$(PWD) modules_install
++ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules_install
+
+ clean:
+- $(MAKE) -C $(KERNELDIR) M=$(PWD) clean
++ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) clean
+
+ %.i: %.c
+- $(MAKE) -C $(KERNELDIR) M=$(PWD) $@
++ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) $@
+ endif # KERNELRELEASE
+diff --git a/README b/README
+index 8c5dd46..6bd3334 100644
+--- a/README
b/README
+@@ -27,8 +27,8 @@ access to your full kernel source tree), and use:
+ If you need to specify the target directory to the kernel you want to build
+ against, use:
+
+-% KERNELDIR=path_to_kernel_dir make
+-# KERNELDIR=path_to_kernel_dir make modules_install
++% KERNEL_SRC=path_to_kernel_dir make
++# KERNEL_SRC=path_to_kernel_dir make modules_install
+ # depmod -a kernel_version
+
+ Use lttng-tools to control the tracer. LTTng tools should automatically load
+diff --git a/probes/Makefile b/probes/Makefile
+index 225803c..3449866 100644
+--- a/probes/Makefile
b/probes/Makefile
+@@ -212,18 +212,18 @@ endif
endif
-
+
else
- KERNELDIR ?= /lib/modules/$(shell uname -r)/build
++ KERNEL_SRC ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
CFLAGS = $(EXTCFLAGS)
-
+
default:
- $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
+ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules
-
+
modules_install:
- $(MAKE) -C $(KERNELDIR) M=$(PWD) modules_install
+ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules_install
-
+ /sbin/depmod -a
+
clean:
- $(MAKE) -C $(KERNELDIR) M=$(PWD) clean
+ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) clean
-
+
endif
---
-1.7.5.4
-
diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.1.1.bb
b/meta/recipes-kernel/lttng/lttng-modules_2.2.0.bb
similarity index 90%
rename from meta/recipes-kernel/lttng/lttng-modules_2.1.1.bb
rename to meta/recipes-kernel/lttng/lttng-modules_2.2.0.bb
index 700c4c5..7926d12 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.1.1.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.2.0.bb
@@ -10,9 +10,8 @@ DEPENDS = virtual/kernel
inherit module
-SRCREV = b374c356eb4827b68754d68adc0f1c94b5de9faa
-PV = 2.1.1
-PR = r0
+SRCREV = 1b26381c19dd2d9fa41f52d8dc13b15b8dd32c7c
+PV = 2.2.0
SRC_URI = git://git.lttng.org/lttng-modules.git;protocol=git \
file://lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
--
1.8.3.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GCC 4.8 Issues with fsl-ppc and fsl-arm (e5000)
On Tue, Jul 2, 2013 at 11:28 AM, Saul Wold s...@linux.intel.com wrote: Any updates on this issue? This is outside my skills :-) Khem did you have time to look at Saul file? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GCC 4.8 Issues with fsl-ppc and fsl-arm (e5000)
On Tue, Jul 2, 2013 at 11:54 AM, Khem Raj raj.k...@gmail.com wrote: On Jul 2, 2013, at 7:47 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Tue, Jul 2, 2013 at 11:28 AM, Saul Wold s...@linux.intel.com wrote: Any updates on this issue? This is outside my skills :-) Khem did you have time to look at Saul file? issue is narrowed down but fix is not coming soon. disable using neon for perf recipes on that old kernel see http://gcc.gnu.org/bugzilla/PR57748 I made a patch with this and will push it to master-next for test. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qt4: disable qmeegographicssystemhelper
On Wed, Jul 3, 2013 at 2:04 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: We don't want this enabled just because we have EGL and OpenGL ES 2.0 enabled. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com Agreed; maybe this could be considered for dylan as well? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Using OpenEmbedded for customized builds
On Thu, Jul 4, 2013 at 2:34 AM, Holger Hans Peter Freyther hol...@moiji-mobile.com wrote: Good Morning, we have a basic product and build the images for it using OpenEmbedded. Some customers require the installation of additional packages, or even the modification of some of the installed ones. The current approach would be to build one VM per customer but that doesn't really scale. I think somehow I want to end up with having my base/generic buuld and a way to put additional ipk's into a customer directory. So something likes this: base-build/tmp/deploy/ipk/ armv5te/ machine/ customer1/ armv5te/ ... customer2/ armv5te/ customer3/ or base-build/tmp/... customer1-build/tmp/deploy/ipk/... In both cases the customer should only include the packages that were built for the customer. All the 'base' packages should be taken/used from the base built. I could indicate for which customer I build by setting an environment variable? For a corner case, e.g. if I change the SRCREV and re-build with a customer flag set, this package should still go to the customer directory. Can this be already modeled? Do you have any idea how this could be done? Currently I did this using MACHINEOVERRIDE and I made a machine which is reused for each customer. So I have a single kernel and machine setup but customer aliases which I can use to control the system in the image and like. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/8] util-linux: disable runuser by default since it depends on PAM
On Wed, Jul 3, 2013 at 7:26 PM, Saul Wold s...@linux.intel.com wrote: util-linux's configure checks for pam_misc.h and if it finds it will enable runuser, there was a case where it was found via shared state and then got rebuilt. This makes the build more deterministic. Signed-off-by: Saul Wold s...@linux.intel.com Please make this as a PACKAGECONFIG and add it if pam feature is enabled. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/8] packagegroup-core-basic: Only build libpam if it's enabled
On Thu, Jul 4, 2013 at 7:37 AM, Burton, Ross ross.bur...@intel.com wrote:
On 3 July 2013 23:26, Saul Wold s...@linux.intel.com wrote:
util-linux will check for the exisitance of pam header files and change what
is
built, so only build libpam when pam is enabled for DISTRO_FEATURES
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-extended/packagegroups/packagegroup-core-basic.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/packagegroups/packagegroup-core-basic.bb
b/meta/recipes-extended/packagegroups/packagegroup-core-basic.bb
index c73d173..03dabbf 100644
--- a/meta/recipes-extended/packagegroups/packagegroup-core-basic.bb
+++ b/meta/recipes-extended/packagegroups/packagegroup-core-basic.bb
@@ -104,7 +104,7 @@ RDEPENDS_packagegroup-core-multiuser = \
cracklib \
gzip \
libuser \
-libpam \
+${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)} \
shadow \
sudo \
Do we even need to mention libpam in here? If pam is enabled, shadow
will have a runtime dependency on it.
Agreed :-)
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qt4: disable qmeegographicssystemhelper
On Thu, Jul 4, 2013 at 10:20 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Thursday 04 July 2013 10:10:52 Otavio Salvador wrote: On Wed, Jul 3, 2013 at 2:04 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: We don't want this enabled just because we have EGL and OpenGL ES 2.0 enabled. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com Agreed; maybe this could be considered for dylan as well? Sounds reasonable to me; once it's merged to master I will include it in my queue for dylan. To be honest it would be nice if it were fixed properly upstream; building it based on the conditional given seems wrong. I fully agree but until it is fixed (if it is ever fixed) your patch seems the way to go! :-) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V6 2/3] useradd.bbclass: code refactor
On Wed, Jul 17, 2013 at 3:08 AM, qi.c...@windriver.com wrote: From: Chen Qi qi.c...@windriver.com The basic functions have moved to useradd_base.bbclass. So this class only needs to inherit useradd_base.bbclass and use the functions defined there. The reason is to avoid code duplication with extrausers.bbclass. [YOCTO #4074] Signed-off-by: Chen Qi qi.c...@windriver.com I think this patch (2) should be squashed onto patch 1; so it easy git bisect in case we're trying to figure out a regression. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/40] Review and ACK
On Thu, Jul 18, 2013 at 6:43 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 17 July 2013 23:34:31 Saul Wold wrote: .. Roy.Li (1): dpkg: backport a patch to support mipsn32el and mips64el Not sure if case is a big issue for Upstream-Status values but this one has Upstream-Status: BackPort. Please fix it otherwise automatic tracking of this will be harder in future. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] No package 'cairo' found for GTK+
On Thu, Jul 18, 2013 at 10:13 AM, Burton, Ross ross.bur...@intel.com wrote: On 18 July 2013 13:33, Daiane Angolini daiane.l...@gmail.com wrote: I'm facing the following error. Anyone know what I should try in order | configure: error: Package requirements (glib-2.0 = 2.28.0atk = 1.29.2pango = 1.20cairo = 1.6gdk-pixbuf-2.0 = 2.21.0) were not met: | | No package 'cairo' found cairo is a build dependency on GTK+, so I'd recommend having a look at the config.log file it generated and see if that has any hints. Well, the error seems very clear. cairo pkgconfig is not found. Did you build GTK lately Ross? (also, this is best discussed on the support list at yocto@) I don't agree. This is a build failure and this works in previous revisions of OE-Core/Poky so it is clearly a regression. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mesa: upgrade to 9.1.5
On Thu, Jul 18, 2013 at 11:18 AM, Jonathan Liu net...@gmail.com wrote:
Signed-off-by: Jonathan Liu net...@gmail.com
---
.../0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch | 0
.../0005-llvmpipe-remove-the-power-of-two-sizeof-struct-cmd_b.patch | 0
meta/recipes-graphics/mesa/mesa.inc | 2 +-
meta/recipes-graphics/mesa/{mesa_9.1.3.bb = mesa_9.1.5.bb} | 4
++--
4 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-graphics/mesa/{mesa-9.1.3 =
mesa-9.1.5}/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch (100%)
rename meta/recipes-graphics/mesa/{mesa-9.1.3 =
mesa-9.1.5}/0005-llvmpipe-remove-the-power-of-two-sizeof-struct-cmd_b.patch
(100%)
rename meta/recipes-graphics/mesa/{mesa_9.1.3.bb = mesa_9.1.5.bb} (79%)
diff --git
a/meta/recipes-graphics/mesa/mesa-9.1.3/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
b/meta/recipes-graphics/mesa/mesa-9.1.5/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
similarity index 100%
rename from
meta/recipes-graphics/mesa/mesa-9.1.3/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
rename to
meta/recipes-graphics/mesa/mesa-9.1.5/0003-EGL-Mutate-NativeDisplayType-depending-on-config.patch
diff --git
a/meta/recipes-graphics/mesa/mesa-9.1.3/0005-llvmpipe-remove-the-power-of-two-sizeof-struct-cmd_b.patch
b/meta/recipes-graphics/mesa/mesa-9.1.5/0005-llvmpipe-remove-the-power-of-two-sizeof-struct-cmd_b.patch
similarity index 100%
rename from
meta/recipes-graphics/mesa/mesa-9.1.3/0005-llvmpipe-remove-the-power-of-two-sizeof-struct-cmd_b.patch
rename to
meta/recipes-graphics/mesa/mesa-9.1.5/0005-llvmpipe-remove-the-power-of-two-sizeof-struct-cmd_b.patch
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index ada1170..4f93b90 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -87,7 +87,7 @@ do_install_append () {
rm -f ${D}${libdir}/gallium-pipe/*.la
rm -f ${D}${libdir}/gbm/*.la
-# it was packaged in libdricore9.1.3-1 and preventing upgrades when
debian.bbclass was used
+# it was packaged in libdricore and preventing upgrades when
debian.bbclass was used
rm -f ${D}${sysconfdir}/drirc
}
This seem not related to the upgrade patch.
diff --git a/meta/recipes-graphics/mesa/mesa_9.1.3.bb
b/meta/recipes-graphics/mesa/mesa_9.1.5.bb
similarity index 79%
rename from meta/recipes-graphics/mesa/mesa_9.1.3.bb
rename to meta/recipes-graphics/mesa/mesa_9.1.5.bb
index a7ccbe6..49fa5dd 100644
--- a/meta/recipes-graphics/mesa/mesa_9.1.3.bb
+++ b/meta/recipes-graphics/mesa/mesa_9.1.5.bb
@@ -8,7 +8,7 @@ SRC_URI =
ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2 \
file://0005-llvmpipe-remove-the-power-of-two-sizeof-struct-cmd_b.patch \
-SRC_URI[md5sum] = 952ccd03547ed72333b64e1746cf8ada
-SRC_URI[sha256sum] =
8d5dac2202d0355bff5cfd183582ec8167d1d1227b7bb7a669acecbeaa52d766
+SRC_URI[md5sum] = 4ed2af5943141a85a21869053a2fc2eb
+SRC_URI[sha256sum] =
89ea0d1afd90a87dab253777bfe414820c4aa3890add1487ca2b49f6b3e194fd
S = ${WORKDIR}/Mesa-${PV}
--
1.8.3.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 01/11] rt-tests: add PV variable into recipe
On Thu, Jul 18, 2013 at 11:16 AM, Emilia Ciobanu emilia.maria.silvia.ciob...@intel.com wrote: Git packages should include git token inside the PV variable. Signed-off-by: Emilia Ciobanu emilia.maria.silvia.ciob...@intel.com I agree with the fix but it'd be better if you made it clear you're including Git revision into PV; the PV variable addition is just a consequence, not the goal. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] directfb: don't patch pkg-config files
On Fri, Jul 19, 2013 at 11:46 AM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Fri, Jul 19, 2013 at 10:39 AM, André Draszik andre.dras...@linaro.org wrote: We are currently getting build failures of projects that rely on being able to access DirectFB's internal include directories, as returned via pkg-config, since the include paths returned by pkg-config are incomplete. The reason for that is the patch that is being removed with this change. It modified the cflags returned by pkg-config in an incorrect way, causing us to miss important include paths: For reference, pkg-config output with incorrect patch applied: ad@bril0118 #513 ~ pkg-config --cflags directfb-internal -D_GNU_SOURCE -D_REENTRANT -Ibuilddir/tmp/sysroots/machine/usr/include/directfb -Ibuilddir/tmp/sysroots/machine/usr/include Now, with the incorrect patch removed, the output is as expected: ad@bril0118 #514 ~ pkg-config --cflags directfb-internal -D_GNU_SOURCE -D_REENTRANT -Ibuilddir/tmp/sysroots/machine/usr/include/directfb-internal -Ibuilddir/tmp/sysroots/machine/usr/include/directfb Overall, the removed patch is not needed - pkg-config does the right thing these days and we can simply use the correctly working upstream versions of all DirectFB .pc files. Signed-off-by: André Draszik andre.dras...@linaro.org i reviewed and tested this patch against a QT4e image build. it looks good to me, and that offending patch being removed seems to come from quite ancient stuff. Tested-by: Nicolas Dechesne nicolas.deche...@linaro.org any chance this can get into 'dylan', too? Paul, I think it is your business ;-) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Mesa issues in Freescale ARM Builds
On Sat, Jul 20, 2013 at 12:01 PM, Saul Wold s...@linux.intel.com wrote: Hi Jonathan, Martin, Freescale Folks: You both have been recently modifying the mesa recipes, it seems to have triggered some build failures on the nightly-fsl-arm builds in master. I am going to build MUT today with Jonathan's change, so we might have failures there also. ERROR: Multiple .bb files are due to be built which each provide mesa (/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta/recipes-graphics/mesa/mesa_git.bb /srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta/recipes-graphics/mesa/mesa_9.1.3.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide virtual/libgles1 (/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta/recipes-graphics/mesa/mesa_git.bb /srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta-fsl-arm/recipes-graphics/amd-gpu-x11-bin/amd-gpu-x11-bin-mx51_11.09.01.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide virtual/libgles2 (/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta/recipes-graphics/mesa/mesa_git.bb /srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta-fsl-arm/recipes-graphics/amd-gpu-x11-bin/amd-gpu-x11-bin-mx51_11.09.01.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide virtual/egl (/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta/recipes-graphics/mesa/mesa_git.bb /srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta-fsl-arm/recipes-graphics/amd-gpu-x11-bin/amd-gpu-x11-bin-mx51_11.09.01.bb). This usually means one provides something the other doesn't and should. and NOTE: recipe mesa-2_9.1.3-r0: task do_package_write_ipk: Started NOTE: recipe mesa-2_9.1.3-r0: task do_package_write_rpm: Started NOTE: recipe mesa-2_9.1.3-r0: task do_package_write_deb: Started ERROR: Recipe mesa is trying to change PR from 'r0' to 'r9.0'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir. ERROR: Function failed: read_subpackage_metadata ERROR: Recipe mesa is trying to change PR from 'r0' to 'r9.0'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir. ERROR: Function failed: read_subpackage_metadata ERROR: Logfile of failure stored in: /srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/build/tmp/work/imx53qsb-poky-linux-gnueabi/mesa/2_9.1.3-r0/temp/log.do_package_write_ipk.14976 NOTE: recipe mesa-2_9.1.3-r0: task do_package_write_ipk: Failed ERROR: Recipe mesa is trying to change PR from 'r0' to 'r9.0'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir. ERROR: Function failed: read_subpackage_metadata ERROR: Logfile of failure stored in: /srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/build/tmp/work/imx53qsb-poky-linux-gnueabi/mesa/2_9.1.3-r0/temp/log.do_package_write_rpm.14930 NOTE: recipe mesa-2_9.1.3-r0: task do_package_write_rpm: Failed ERROR: Task 3724 (/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta/recipes-graphics/mesa/mesa_9.1.3.bb, do_package_write_rpm) failed with exit code '1' ERROR: Task 3722 (/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta/recipes-graphics/mesa/mesa_9.1.3.bb, do_package_write_ipk) failed with exit code '1' ERROR: Logfile of failure stored in: /srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/build/tmp/work/imx53qsb-poky-linux-gnueabi/mesa/2_9.1.3-r0/temp/log.do_package_write_deb.14949 NOTE: recipe mesa-2_9.1.3-r0: task do_package_write_deb: Failed ERROR: Task 3723 (/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/nightly-fsl-arm/build/meta/recipes-graphics/mesa/mesa_9.1.3.bb, do_package_write_deb) failed with exit code '1' This is strange since it seems to be picking up the git recipe and the version one, maybe due to the above error. I think I know what is going on. I will give a try in a fix here and send. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Handle of kernels which need dtc_cpp use
Hello, I need to use one kernel which uses dtc_cpp. So for now I ended duplicating all linux-dtc.inc file for it. Does someone have a better option? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Handle of kernels which need dtc_cpp use
On Mon, Jul 22, 2013 at 9:29 AM, André Draszik andre.dras...@linaro.org wrote:
Hi,
I am using the attached.
To use DTC+CPP, instead of giving the full path
arch/${ARCH}/boot/dts/filename, you only have to specify filename in
KERNEL_DEVICETREE.
This was done to stay compatible with existing build rules, but I don't
know if this would work for the case ${ARCH} != arm
I tried to apply this on master and it failed. Can you please rebase
this? This does look like the way to go.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Handle of kernels which need dtc_cpp use
On Mon, Jul 22, 2013 at 9:39 AM, André Draszik andre.dras...@linaro.org wrote: Attached, but untested, as I'm not in a position to test master at the moment. If I change the machine to have the filename.dtb, without the fullpath, it works fine. Can you send this for review? I think it'd be good to have more feedback on this. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-dtb: allow to build dtb using support from kernel
of
the compile phase (i.e. is there a dtb already), and keep the checking on the
existence of the DTS in as few places as possible. In particular, since there
should still be an opt-out flag, having as few touches as possible is better.
+ if [ ! -f arch/${ARCH}/boot/dts/${DTS_FILE}
]; then
+ echo Warning: ${DTS_FILE} is not
available!
+ continue
+ fi
+
+ install -m 0644
arch/${ARCH}/boot/${DTS_BASE_NAME}.dtb
${D}/boot/devicetree-${DTB_SYMLINK_NAME}.dtb
+ continue
+ fi
+ dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o
${DTS_BASE_NAME}.dtb ${DTS_FILE}
+ install -m 0644 ${DTS_BASE_NAME}.dtb
${D}/boot/devicetree-${DTB_SYMLINK_NAME}.dtb
done
fi
}
@@ -30,15 +68,28 @@ do_install_append() {
do_deploy_append() {
if test -n ${KERNEL_DEVICETREE}; then
for DTS_FILE in ${KERNEL_DEVICETREE}; do
+ DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F .
'{print $1}'`
if [ ! -f ${DTS_FILE} ]; then
- echo Warning: ${DTS_FILE} is not available!
- continue
+ if [ ! -f arch/${ARCH}/boot/dts/${DTS_FILE}
]; then
+ echo Warning: ${DTS_FILE} is not
available!
+ continue
+ fi
+
+ # standard build using kbuild
+ echo Info: standard kbuild for device tree
blob
fi
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F .
'{print $1}'`
+
DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME}
| sed s/${MACHINE}/${DTS_BASE_NAME}/g`
+
install -d ${DEPLOYDIR}
- install -m 0644 ${B}/${DTS_BASE_NAME}
${DEPLOYDIR}/${DTB_NAME}.dtb
+
+ if [ -f arch/${ARCH}/boot/dts/${DTS_FILE} ]; then
This should really be testing on the dtb, not the DTS. We could also
have a single install
line, if any testing is done at the top of the routine and a single
variable set to point to
the dtb, wherever it may be.
Cheers,
Bruce
+ install -m 0644
${B}/arch/${ARCH}/boot/${DTS_BASE_NAME}.dtb ${DEPLOYDIR}/${DTB_NAME}.dtb
+ else
+ install -m 0644 ${B}/${DTS_BASE_NAME}.dtb
${DEPLOYDIR}/${DTB_NAME}.dtb
+ fi
+
cd ${DEPLOYDIR}
ln -sf ${DTB_NAME}.dtb ${DTB_SYMLINK_NAME}.dtb
cd -
--
1.8.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/27] Ready for Pull after final ACK
On Mon, Jul 22, 2013 at 2:12 PM, Saul Wold s...@linux.intel.com wrote: Richard, This has been trimmed and reviewed, please wait for Paul and Ross (traveling) final ACKs. ** Reminder to BSP Maintainers - Please update your mesa .bbappends *** ** I will send email when RP has pulled, please keep me posted on your branches ** Thanks Sau! Once it is merged I update meta-fsl-arm. Thanks for letting me know about it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: meta-ro-rootfs approach and volatiles vs tmpfiles.d
On Wed, Jul 24, 2013 at 7:34 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Jul 24, 2013 at 2:51 PM, Otavio Salvador ota...@ossystems.com.br wrote: On Wed, Jul 24, 2013 at 3:54 PM, Chris Larson clar...@kergoth.com wrote: ... The standalone systemd-tmpfiles recipe I've created has a fairly small set of dependencies: intltool-native, dbus, libcap. Given this, I'd like to propose transitioning away from populate-volatiles to systemd-tmpfiles, even for non-systemd images. I think that the update-tmpfiles shell script may be of use in a transition, but before we even begin discussing a transition path, I'd like to request comments on the notion of moving to it at all. I think it shouldn't be hard to make an C app or script which could parse systemd-tmpfiles and use this for non-systemd systems. What do you think? I considered this too, but systemd-tmpfiles supports quite a lot more than volatiles, for example restoring selinux labels. Maybe that sounds fun to you, but it sounded like more trouble than it was worth to me, given systemd-tmpfiles can be used without systemd :) But yes, it's definitely another option to consider. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: meta-ro-rootfs approach and volatiles vs tmpfiles.d
On Wed, Jul 24, 2013 at 7:34 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Jul 24, 2013 at 2:51 PM, Otavio Salvador ota...@ossystems.com.br wrote: On Wed, Jul 24, 2013 at 3:54 PM, Chris Larson clar...@kergoth.com wrote: ... The standalone systemd-tmpfiles recipe I've created has a fairly small set of dependencies: intltool-native, dbus, libcap. Given this, I'd like to propose transitioning away from populate-volatiles to systemd-tmpfiles, even for non-systemd images. I think that the update-tmpfiles shell script may be of use in a transition, but before we even begin discussing a transition path, I'd like to request comments on the notion of moving to it at all. I think it shouldn't be hard to make an C app or script which could parse systemd-tmpfiles and use this for non-systemd systems. What do you think? I considered this too, but systemd-tmpfiles supports quite a lot more than volatiles, for example restoring selinux labels. Maybe that sounds fun to you, but it sounded like more trouble than it was worth to me, given systemd-tmpfiles can be used without systemd :) But yes, it's definitely another option to consider. Sorry, pressed the send button too fast ... I understand but I think we could solve the tmp files issue only; people using sysv are expected to solve all those other issues in another way so it is not a regression for them. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
This allow the addition and removal of distro features easily. To add
a feature, use:
EXTRA_DISTRO_FEATURES += wayland
and to remove, use '~' prefix, as:
EXTRA_DISTRO_FEATURES += ~x11
This code has been mostly copied from Mentor Graphics public layer but
changed the variable name for a more descriptive name. The original
code can be seen at user_feature.bbclass at:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/base.bbclass | 4
meta/lib/oe/utils.py | 20
2 files changed, 24 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 9c92e0b..83f6458 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -298,6 +298,9 @@ def buildcfg_neededvars(d):
if pesteruser:
bb.fatal('The following variable(s) were not set: %s\nPlease set them
directly, or choose a MACHINE or DISTRO that sets them.' % ',
'.join(pesteruser))
+EXTRA_DISTRO_FEATURES ?=
+EXTRA_DISTRO_FEATURES[type] = list
+
addhandler base_eventhandler
base_eventhandler[eventmask] = bb.event.ConfigParsed bb.event.BuildStarted
python base_eventhandler() {
@@ -307,6 +310,7 @@ python base_eventhandler() {
preferred_ml_updates(e.data)
oe.utils.features_backfill(DISTRO_FEATURES, e.data)
oe.utils.features_backfill(MACHINE_FEATURES, e.data)
+oe.utils.extra_distro_features(e.data)
if isinstance(e, bb.event.BuildStarted):
localdata = bb.data.createCopy(e.data)
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 82987e8..9e82801 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -117,6 +117,26 @@ def features_backfill(var,d):
if addfeatures:
d.appendVar(var, + .join(addfeatures))
+def extra_distro_features(d):
+import oe.data
+
+extra_features = oe.data.typed_value('EXTRA_DISTRO_FEATURES', d)
+if not extra_features:
+return
+
+d.finalize()
+
+distro_features = d.getVar('DISTRO_FEATURES', True).split()
+for feature in extra_features:
+if feature.startswith('~'):
+feature = feature[1:]
+if feature in distro_features:
+distro_features.remove(feature)
+else:
+if feature not in distro_features:
+distro_features.append(feature)
+
+d.setVar('DISTRO_FEATURES', ' '.join(distro_features))
def packages_filter_out_system(d):
--
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] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
Hello Eric and Rogerio, On Mon, Jul 29, 2013 at 7:26 PM, Otavio Salvador ota...@ossystems.com.br wrote: This allow the addition and removal of distro features easily. To add a feature, use: EXTRA_DISTRO_FEATURES += wayland and to remove, use '~' prefix, as: EXTRA_DISTRO_FEATURES += ~x11 This code has been mostly copied from Mentor Graphics public layer but changed the variable name for a more descriptive name. The original code can be seen at user_feature.bbclass at: http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor Signed-off-by: Otavio Salvador ota...@ossystems.com.br I have submitted a patch for OE-Core to address this hardness to add/remove distro features. It is based in user_features.bbclass from Metro Graphics but I changed it to fit better in base.bbclass. Please give it a try and comment if you have a better alternative solution for this problem. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
On Tue, Jul 30, 2013 at 7:59 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Monday 29 July 2013 19:26:27 Otavio Salvador wrote: This allow the addition and removal of distro features easily. To add a feature, use: EXTRA_DISTRO_FEATURES += wayland and to remove, use '~' prefix, as: EXTRA_DISTRO_FEATURES += ~x11 This code has been mostly copied from Mentor Graphics public layer but changed the variable name for a more descriptive name. 1) Isn't this just adding list subtraction via the back door, which Richard has already argued against (mostly because the interaction between it and _append/_prepend will be hard to predict)? We call it and /finalize/ the database so it has _append/_prepend resolved before mangling the list. 2) Why not just set DISTRO_FEATURES to contain just the items you want in your distro configuration instead of trying to add and subtract from some previous value? What if the previous value changes in a way that no longer fits your desired configuration? Surely it is better to just be explicit. To make this, we cannot reuse Poky distro for example as it /unconditionally/ appends to DISTRO_FEATURES. Besides it is easier for test to be able to override it using local.conf. For products I agree we'll end adding a distro to make it reprodicable but for development stage this trick makes life much easier. 3) Even if we were to add this here wouldn't users expect this to work in all such variables and not just DISTRO_FEATURES? I did this for DISTRO_FEATURES and I don't think it is good to have this for all vars. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
On Tue, Jul 30, 2013 at 9:14 AM, Phil Blundell p...@pbcl.net wrote: On Tue, 2013-07-30 at 09:00 -0300, Otavio Salvador wrote: To make this, we cannot reuse Poky distro for example as it /unconditionally/ appends to DISTRO_FEATURES. Besides it is easier for test to be able to override it using local.conf. For products I agree we'll end adding a distro to make it reprodicable but for development stage this trick makes life much easier. Surely for one-off tests you can just write out the whole intended value of DISTRO_FEATURES in your local.conf. It doesn't seem as though this variable is unwieldy enough that it really needs mechanical handling. As for poky appending to DISTRO_FEATURES rather than just setting it, that sounds like it's arguably a bug in poky and you should perhaps take it up with those guys. Of course, they might take the view that poky itself is meant to be determining what DISTRO_FEATURES it wants and they don't want to support or encourage random frobbing of flags by third parties, and I think that'd be an understandable position. We call it and /finalize/ the database so it has _append/_prepend resolved before mangling the list. That seems a bit unwholesome in itself. Are you sure there are no potential bad consequences from calling finalize() there? No; I am not sure. What I know is it has been being used by meta-metro and O.S. Systems distribution without issues for a while and it solves the problem I have. Adding /full/ distro features list is ugly and easy to get wrong. This seems much better for user IMO. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] lttng-* 2.2.x point release updates
On Tue, Jul 30, 2013 at 5:09 PM, paul_woege...@mentor.com wrote: Hi Otavio, Hi Paul, The patch below updates LTTng and related packages to the latest point releases. Thanks by working on this but please send one patch for each recipe and follow the process documented at: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Thanks in advance :-) Best regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
On Tue, Jul 30, 2013 at 1:05 PM, Phil Blundell p...@pbcl.net wrote: On Tue, 2013-07-30 at 10:43 -0500, Mark Hatle wrote: That only filters out recommendations though. A good example is some x86 packagegroups have a requirement of 'vte'. It turns out a class of end users don't want 'vte'. And they have no easy way to remove it. Telling them to generate a new image, with a custom IMAGE_INSTALL value that includes everything except 'vte' doesn't make sense to them. I'm not familiar with the particular example that you mentioned, but it sounds as though the packagegroups in question ought to be recommending vte rather than depending on it. I think this is probably true for packagegroup dependencies in general in fact. The intended semantics of RDEPENDS are that anything named in that list is absolutely required for correct operation and can't be removed without breaking the functionality of the package that's doing the depending. Things that are desirable but not absolutely necessary should be in RRECOMMENDS (and can be suppressed with BAD_RECOMMENDATIONS), and things which are entirely optional but might be nice to have should be in RSUGGESTS. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
On Tue, Jul 30, 2013 at 1:05 PM, Phil Blundell p...@pbcl.net wrote: On Tue, 2013-07-30 at 10:43 -0500, Mark Hatle wrote: That only filters out recommendations though. A good example is some x86 packagegroups have a requirement of 'vte'. It turns out a class of end users don't want 'vte'. And they have no easy way to remove it. Telling them to generate a new image, with a custom IMAGE_INSTALL value that includes everything except 'vte' doesn't make sense to them. I'm not familiar with the particular example that you mentioned, but it sounds as though the packagegroups in question ought to be recommending vte rather than depending on it. I think this is probably true for packagegroup dependencies in general in fact. The intended semantics of RDEPENDS are that anything named in that list is absolutely required for correct operation and can't be removed without breaking the functionality of the package that's doing the depending. Things that are desirable but not absolutely necessary should be in RRECOMMENDS (and can be suppressed with BAD_RECOMMENDATIONS), and things which are entirely optional but might be nice to have should be in RSUGGESTS. I think we're getting off-topic here. I think we ought to focus in distro-features discussion here and handle package installs in another thread. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gst-plugins-gl: add explicit dependency on libpng
On Tue, Jul 30, 2013 at 6:01 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com Acked-by: Otavio Salvador ota...@ossystems.com.br Paul, can you queue this for dylan next update? Regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
This allow the addition and removal of distro features easily. To add
a feature, use:
EXTRA_DISTRO_FEATURES += wayland
and to remove, use '~' prefix, as:
EXTRA_DISTRO_FEATURES += ~x11
This code has been mostly copied from Mentor Graphics public layer but
changed the variable name for a more descriptive name. The original
code can be seen at user_feature.bbclass at:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes for v2:
- Use data copy to fix wrong prepend/append expanding.
meta/classes/base.bbclass | 4
meta/lib/oe/utils.py | 21 +
2 files changed, 25 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 9c92e0b..83f6458 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -298,6 +298,9 @@ def buildcfg_neededvars(d):
if pesteruser:
bb.fatal('The following variable(s) were not set: %s\nPlease set them
directly, or choose a MACHINE or DISTRO that sets them.' % ',
'.join(pesteruser))
+EXTRA_DISTRO_FEATURES ?=
+EXTRA_DISTRO_FEATURES[type] = list
+
addhandler base_eventhandler
base_eventhandler[eventmask] = bb.event.ConfigParsed bb.event.BuildStarted
python base_eventhandler() {
@@ -307,6 +310,7 @@ python base_eventhandler() {
preferred_ml_updates(e.data)
oe.utils.features_backfill(DISTRO_FEATURES, e.data)
oe.utils.features_backfill(MACHINE_FEATURES, e.data)
+oe.utils.extra_distro_features(e.data)
if isinstance(e, bb.event.BuildStarted):
localdata = bb.data.createCopy(e.data)
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 82987e8..b2e65a4 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -117,6 +117,27 @@ def features_backfill(var,d):
if addfeatures:
d.appendVar(var, + .join(addfeatures))
+def extra_distro_features(d):
+import oe.data
+
+l = d.createCopy()
+l.finalize()
+
+extra_features = oe.data.typed_value('EXTRA_DISTRO_FEATURES', l)
+if not extra_features:
+return
+
+distro_features = l.getVar('DISTRO_FEATURES', True).split()
+for feature in extra_features:
+if feature.startswith('~'):
+feature = feature[1:]
+if feature in distro_features:
+distro_features.remove(feature)
+else:
+if feature not in distro_features:
+distro_features.append(feature)
+
+d.setVar('DISTRO_FEATURES', ' '.join(distro_features))
def packages_filter_out_system(d):
--
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 v2] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
On Tue, Jul 30, 2013 at 10:11 PM, Otavio Salvador ota...@ossystems.com.br wrote: This allow the addition and removal of distro features easily. To add a feature, use: EXTRA_DISTRO_FEATURES += wayland and to remove, use '~' prefix, as: EXTRA_DISTRO_FEATURES += ~x11 This code has been mostly copied from Mentor Graphics public layer but changed the variable name for a more descriptive name. The original code can be seen at user_feature.bbclass at: http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor Signed-off-by: Otavio Salvador ota...@ossystems.com.br Both does not work for all cases. I am still checking why. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
On Wed, Jul 31, 2013 at 5:51 AM, Burton, Ross ross.bur...@intel.com wrote: On 31 July 2013 02:11, Otavio Salvador ota...@ossystems.com.br wrote: This allow the addition and removal of distro features easily. To add a feature, use: EXTRA_DISTRO_FEATURES += wayland and to remove, use '~' prefix, as: EXTRA_DISTRO_FEATURES += ~x11 I'm not sure I like the use of extra and remove, as they're contradictory. It's too early to come up with a better suggestion though. :( I agree but I couldn't also come up with better name for this. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
This allow the addition and removal of distro features easily. To add
a feature, use:
EXTRA_DISTRO_FEATURES += wayland
and to remove, use '~' prefix, as:
EXTRA_DISTRO_FEATURES += ~x11
This code has been mostly copied from Mentor Graphics public layer but
changed the variable name for a more descriptive name. The original
code can be seen at user_feature.bbclass at:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes for v3:
- Drop _prepend/_append flags from DISTRO_FEATURES to avoid the re-add
meta/classes/base.bbclass | 4
meta/lib/oe/utils.py | 25 +
2 files changed, 29 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 9c92e0b..83f6458 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -298,6 +298,9 @@ def buildcfg_neededvars(d):
if pesteruser:
bb.fatal('The following variable(s) were not set: %s\nPlease set them
directly, or choose a MACHINE or DISTRO that sets them.' % ',
'.join(pesteruser))
+EXTRA_DISTRO_FEATURES ?=
+EXTRA_DISTRO_FEATURES[type] = list
+
addhandler base_eventhandler
base_eventhandler[eventmask] = bb.event.ConfigParsed bb.event.BuildStarted
python base_eventhandler() {
@@ -307,6 +310,7 @@ python base_eventhandler() {
preferred_ml_updates(e.data)
oe.utils.features_backfill(DISTRO_FEATURES, e.data)
oe.utils.features_backfill(MACHINE_FEATURES, e.data)
+oe.utils.extra_distro_features(e.data)
if isinstance(e, bb.event.BuildStarted):
localdata = bb.data.createCopy(e.data)
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 82987e8..db468cb 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -117,6 +117,31 @@ def features_backfill(var,d):
if addfeatures:
d.appendVar(var, + .join(addfeatures))
+def extra_distro_features(d):
+import oe.data
+
+l = d.createCopy()
+l.finalize()
+
+extra_features = oe.data.typed_value('EXTRA_DISTRO_FEATURES', l)
+if not extra_features:
+return
+
+distro_features = l.getVar('DISTRO_FEATURES', True).split()
+for feature in extra_features:
+if feature.startswith('~'):
+feature = feature[1:]
+if feature in distro_features:
+distro_features.remove(feature)
+else:
+if feature not in distro_features:
+distro_features.append(feature)
+
+# Avoid readding the removed features later
+d.delVarFlag(DISTRO_FEATURES, _append)
+d.delVarFlag(DISTRO_FEATURES, _prepend)
+
+d.setVar('DISTRO_FEATURES', ' '.join(distro_features))
def packages_filter_out_system(d):
--
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 v2] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
On Wed, Jul 31, 2013 at 8:47 AM, Phil Blundell p...@pbcl.net wrote: On Tue, 2013-07-30 at 22:11 -0300, Otavio Salvador wrote: +l = d.createCopy() +l.finalize() Doesn't this mean you're now going to get the overrides applied twice? It seems as though making a copy here kind of defeats the point of calling finalize() in the first place. I sent a v3 which fixes the issue. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master, dylan][PATCH] packagegroup-core-tools-testapps: isolate x11 dependent tools
On Wed, Jul 31, 2013 at 6:15 PM, ronu...@gmail.com wrote: From: Rogerio Nunes rogerio.nu...@freescale.com This patch groups x11 dependent tools in a separete variable, and when DISTRO_FEATURES does not contain x11, this group is not included in the package RDEPENDS. Signed-off-by: Rogerio Nunes rogerio.nu...@freescale.com Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
On Thu, Aug 1, 2013 at 4:37 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2013-07-31 at 12:13 -0300, Otavio Salvador wrote: ... +# Avoid readding the removed features later +d.delVarFlag(DISTRO_FEATURES, _append) +d.delVarFlag(DISTRO_FEATURES, _prepend) I quite clearly said this was a hack to allow you to see what the problem was with the code and that it was *not* an acceptable change to go into the core. I don't see any mention of that now and that is a little frustrating to see this being proposed as a patch. I forgot to add it to commit log, sorry. The idea was to send the working code so people using it could use a valid one. I understand we need to find a better solution for this but I am clueless about where to look. I can work in another solution if someone can tell me what needs to be done. I looked at bb.data_smart code and didn't find any other way to fix this. The finalize code would be the other place I can think about changing. Any hint? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
On Thu, Aug 1, 2013 at 10:08 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2013-08-01 at 09:19 -0300, Otavio Salvador wrote: On Thu, Aug 1, 2013 at 4:37 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2013-07-31 at 12:13 -0300, Otavio Salvador wrote: ... +# Avoid readding the removed features later +d.delVarFlag(DISTRO_FEATURES, _append) +d.delVarFlag(DISTRO_FEATURES, _prepend) I quite clearly said this was a hack to allow you to see what the problem was with the code and that it was *not* an acceptable change to go into the core. I don't see any mention of that now and that is a little frustrating to see this being proposed as a patch. I forgot to add it to commit log, sorry. The idea was to send the working code so people using it could use a valid one. I understand we need to find a better solution for this but I am clueless about where to look. I can work in another solution if someone can tell me what needs to be done. I looked at bb.data_smart code and didn't find any other way to fix this. The finalize code would be the other place I can think about changing. Any hint? Using existing API, did you try just d.delVar(DISTRO_FEATURES) and then setting it again? Unlike the above, that doesn't assume any knowledge of bitbake internals. Works like a charm. I will send v4 with this one. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
This allow the addition and removal of distro features easily. To add
a feature, use:
EXTRA_DISTRO_FEATURES += wayland
and to remove, use '~' prefix, as:
EXTRA_DISTRO_FEATURES += ~x11
This code has been mostly copied from Mentor Graphics public layer but
changed the variable name for a more descriptive name. The original
code can be seen at user_feature.bbclass at:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v4:
- Drop _prepend/_append hack and remove/add DISTRO_FEATURES (thanks to
RP for the tip).
Changes in v3:
- Drop _prepend/_append flags from DISTRO_FEATURES to avoid the re-add
Changes in v2:
- Use data copy to fix wrong prepend/append expanding.
meta/classes/base.bbclass | 4
meta/lib/oe/utils.py | 24
2 files changed, 28 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 9c92e0b..83f6458 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -298,6 +298,9 @@ def buildcfg_neededvars(d):
if pesteruser:
bb.fatal('The following variable(s) were not set: %s\nPlease set them
directly, or choose a MACHINE or DISTRO that sets them.' % ',
'.join(pesteruser))
+EXTRA_DISTRO_FEATURES ?=
+EXTRA_DISTRO_FEATURES[type] = list
+
addhandler base_eventhandler
base_eventhandler[eventmask] = bb.event.ConfigParsed bb.event.BuildStarted
python base_eventhandler() {
@@ -307,6 +310,7 @@ python base_eventhandler() {
preferred_ml_updates(e.data)
oe.utils.features_backfill(DISTRO_FEATURES, e.data)
oe.utils.features_backfill(MACHINE_FEATURES, e.data)
+oe.utils.extra_distro_features(e.data)
if isinstance(e, bb.event.BuildStarted):
localdata = bb.data.createCopy(e.data)
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 82987e8..0c9dde0 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -117,6 +117,30 @@ def features_backfill(var,d):
if addfeatures:
d.appendVar(var, + .join(addfeatures))
+def extra_distro_features(d):
+import oe.data
+
+l = d.createCopy()
+l.finalize()
+
+extra_features = oe.data.typed_value('EXTRA_DISTRO_FEATURES', l)
+if not extra_features:
+return
+
+distro_features = l.getVar('DISTRO_FEATURES', True).split()
+for feature in extra_features:
+if feature.startswith('~'):
+feature = feature[1:]
+if feature in distro_features:
+distro_features.remove(feature)
+else:
+if feature not in distro_features:
+distro_features.append(feature)
+
+# Avoid readding the removed features later
+d.delVar(DISTRO_FEATURES)
+
+d.setVar('DISTRO_FEATURES', ' '.join(distro_features))
def packages_filter_out_system(d):
--
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] list-packageconfig-flag.py: add a script to list all PACKAGECONFIG's flags
On Thu, Aug 1, 2013 at 8:04 AM, Hongxu Jia hongxu@windriver.com wrote:
list-packageconfig-flag.py will walk the METADIR and collect recipes which
have PACKAGECONFIG's flags.
The default display is to list recipes which have PACKAGECONFIG's flags in
METADIR. If option '-f' is used, it will list PACKAGECONFIG's flags and all
affected recipes in METADIR
EXAMPLE:
list-packageconfig-flag.py poky/meta poky/meta-yocto
RECIPE NAME PACKAGECONFIG's flag
=
libarchive_2.8.5.bb acl xattr largefile zlib bz2 xz openssl libxml2 expat
strace_4.8.bblibaio acl
connman.inc wifi bluetooth 3g tist openvpn vpnc l2tp pptp wispr
list-packageconfig-flag.py -f poky/meta poky/meta-yocto
PACKAGECONFIG's flag RECIPE NAME
speexgstreamer1.0-plugins-good.inc
keyutils rpm_5.4.9.bb
gallium-egl mesa.inc
[YOCTO #4368]
Signed-off-by: Hongxu Jia hongxu@windriver.com
Cool! :-)
scripts/contrib/list-packageconfig-flag.py | 180
+
I'd drop .py extension and use +x permission.
1 file changed, 180 insertions(+)
create mode 100755 scripts/contrib/list-packageconfig-flag.py
diff --git a/scripts/contrib/list-packageconfig-flag.py
b/scripts/contrib/list-packageconfig-flag.py
new file mode 100755
index 000..7a5568f
--- /dev/null
+++ b/scripts/contrib/list-packageconfig-flag.py
@@ -0,0 +1,180 @@
+#!/usr/bin/env python
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software Foundation.
+#
+# Copyright (C) 2013 Wind River Systems, Inc.
+#
+# list recipes which have PACKAGECONFIG's flags in METADIR
+# list PACKAGECONFIG's flags and all affected recipes in METADIR
+#
+
+import sys
+import getopt
+import os
+import re
+
+usage_body = ''' list recipes which have PACKAGECONFIG's flags in METADIR
+
+OPTION:
+ -h, --help display this help and exit
+ -f, --flag list PACKAGECONFIG's flags and all affected recipes in METADIR
+
+EXAMPLE:
+list-packageconfig-flag.py poky/meta poky/meta-yocto
+list-packageconfig-flag.py -f poky/meta poky/meta-yocto
+'''
+
+def usage():
+print 'Usage: %s [OPTION] [METADIR]...' % os.path.basename(sys.argv[0])
+print usage_body
+
+def parse_recipe(recipe):
+''' Parse a recipe to collect PACKAGECONFIG's flags '''
+prog = re.compile(r' *PACKAGECONFIG\[(?Pflag.*)\] *=.*')
+try:
+r = open(recipe)
+except IOError as (errno, strerror):
+print sys.stderr, 'WARNING: Failed to open recipe', recipe
+
+flaglist = []
+for line in r:
+# Strip any comments from the line
+line = line.rsplit('#')[0]
+m = prog.match(line)
+if m:
+flaglist.append(m.group('flag'))
+r.close()
+
+return flaglist
+
+def process_recipes(metadir):
+''' Collect recipes which have PACKAGECONFIG's flags in METADIR '''
+# recipesdict = {'recipe': ['flag1', 'flag2',...]}
+recipesdict = {}
+for root,dirs,files in os.walk(metadir):
+for name in files:
+if name.find(.bb) = 0 or name.find(.inc) = 0:
+flaglist = parse_recipe(os.path.join(root,name))
+if flaglist:
+recipesdict[name] = flaglist
+
+return recipesdict
In case a PACKAGECONFIG is add by a class. I think this case is missing here.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][V2] u-boot: state the MACHINE when skipping u-boot
On Thu, Aug 1, 2013 at 1:38 PM, Laszlo Papp lp...@kde.org wrote: On Thu, Aug 1, 2013 at 5:35 PM, Burton, Ross ross.bur...@intel.com wrote: On 1 August 2013 17:33, Laszlo Papp lp...@kde.org wrote: I'm not sure what you meant here. Do you mean a situation where the local.conf says MACHINE=foo and the user also sets MACHINE=foo in the environment? Yes. But there's nothing wrong with the user doing that at all. Why do you think compilers warn in such use cases? Because they cannot know if you are doing something silly, or something unintentional. It might just well be that the user wanted to type something else, but got confused in which case he might get a hard to debug issue later, or even if not hard, it is additional issue due to his. Please provide the message you preferred so it can be seen and discussed. An example might make it easier to get what you really mean. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][V2] u-boot: state the MACHINE when skipping u-boot
On Thu, Aug 1, 2013 at 2:09 PM, Laszlo Papp lp...@kde.org wrote: On Thu, Aug 1, 2013 at 6:02 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: I'm afraid this is not practical. The ability to specify the value for MACHINE and other variables from the external environment is not just there for folks running bitbake manually from the command line, but also external scripts as well, and they could quite legitimately set it to the same value that has been specified in the configuration file and showing a warning in that case would be undesirable. Oh yeah, it cannot happen with compiler outputs the same way? Answer is: it can. You can add another feature later though if you wish to suppress warnings. That makes sense to me. It makes sense to not add the warning. Too many warnings just confuse users and does not provide anything useful as users just ignore them in the end. I'm not sure I understand the value of showing this warning in any case. The system is not going to do anything that the user won't expect - the user specified the value of MACHINE on the command line and that's the value that is being used. The fact that it is the same as what's in the configuration file is incidental. Have you used gcc, clang, etc? Do you have experience with warnings in general? They are there in certain cases because the programmer may have or probably made a mistake. It is a lot easier to figure out at that time than debugging very hard later... sarcarsm I am sure we all in Yocto community NEVER used GCC/CLang... /sarcarsm Did you EVER read your own messages? Please do. Actually, it is even getting more serious in your script case where it would be totally hidden by the script if it is not logging properly, and you would only realize an issue later. Surely, we all copy paste wrong on a daily basis, and we also write foo instead fow and bar at times. So, I do not follow your comment. Nothing to reinvent the wheel here, just follow the general practice that other software developers have figured out along the decades. That's the point; we are folloing Yocto general practice and doing it different here won't help. Just confuse. Regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] distro_features_check.bbclass: Allow checking of required/conflicting features
This add support to list required/confliting distro features for a
recipe; this avoids user mistake when building recipes/images which
would not work depending on DISTRO_FEATURES option set.
Adding:
,[ Use example ]
| inherit distro_features_check
|
| REQUIRED_DISTRO_FEATURES = x11
| CONFLICT_DISTRO_FEATURES_mx6 = wayland
`
In the image recipe allow us to make clear to user that this image
needs X11 and /cannot/ be build with Wayland support in i.MX6
platforms, for example.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v3:
- Move code from base.bbclass to distro_features_check.bbclass
- Rework code
- Rework commit log
Changes in v2:
- Rename to REQUIRED_DISTRO_FEATURES;
- Remove spurious bb.note;
- Rewrote error message;
meta/classes/distro_features_check.bbclass | 28
1 file changed, 28 insertions(+)
create mode 100644 meta/classes/distro_features_check.bbclass
diff --git a/meta/classes/distro_features_check.bbclass
b/meta/classes/distro_features_check.bbclass
new file mode 100644
index 000..61b11b7
--- /dev/null
+++ b/meta/classes/distro_features_check.bbclass
@@ -0,0 +1,28 @@
+# Allow checking of required and conflicting DISTRO_FEATURES
+#
+# REQUIRED_DISTRO_FEATURES: ensure every item on this list is included
+# in DISTRO_FEATURES.
+# CONFLICT_DISTRO_FEATURES: ensure no item in this list is included in
+# DISTRO_FEATURES.
+#
+# Copyright 2013 (C) O.S. Systems Software LTDA.
+
+python () {
+required_distro_features = d.getVar('REQUIRED_DISTRO_FEATURES', True)
+if required_distro_features:
+required_distro_features = required_distro_features.split()
+distro_features = (d.getVar('DISTRO_FEATURES', True) or ).split()
+for f in required_distro_features:
+if f in distro_features:
+break
+else:
+raise bb.parse.SkipPackage(missing required distro feature %s
(not in DISTRO_FEATURES) % required_distro_features)
+
+conflict_distro_features = d.getVar('CONFLICT_DISTRO_FEATURES', True)
+if conflict_distro_features:
+conflict_distro_features = conflict_distro_features.split()
+distro_features = (d.getVar('DISTRO_FEATURES', True) or ).split()
+for f in conflict_distro_features:
+if f in distro_features:
+raise bb.parse.SkipPackage(conflicting distro feature %s (in
DISTRO_FEATURES) % conflict_distro_features)
+}
--
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] list-packageconfig-flag.py: add a script to list all PACKAGECONFIG's flags
On Thu, Aug 1, 2013 at 10:50 PM, Hongxu Jia hongxu@windriver.com wrote:
On 08/02/2013 12:46 AM, Otavio Salvador wrote:
On Thu, Aug 1, 2013 at 8:04 AM, Hongxu Jia hongxu@windriver.com
wrote:
list-packageconfig-flag.py will walk the METADIR and collect recipes
which
have PACKAGECONFIG's flags.
The default display is to list recipes which have PACKAGECONFIG's flags
in
METADIR. If option '-f' is used, it will list PACKAGECONFIG's flags and
all
affected recipes in METADIR
EXAMPLE:
list-packageconfig-flag.py poky/meta poky/meta-yocto
RECIPE NAME PACKAGECONFIG's flag
=
libarchive_2.8.5.bb acl xattr largefile zlib bz2 xz openssl libxml2
expat
strace_4.8.bblibaio acl
connman.inc wifi bluetooth 3g tist openvpn vpnc l2tp pptp wispr
list-packageconfig-flag.py -f poky/meta poky/meta-yocto
PACKAGECONFIG's flag RECIPE NAME
speexgstreamer1.0-plugins-good.inc
keyutils rpm_5.4.9.bb
gallium-egl mesa.inc
[YOCTO #4368]
Signed-off-by: Hongxu Jia hongxu@windriver.com
Cool! :-)
scripts/contrib/list-packageconfig-flag.py | 180
+
I'd drop .py extension and use +x permission.
Most scripts in scripts/contrib have '.py' or '.sh' extension, is it the
rule to be followed or not?
I'd prefer to not have the .py and .sh extensions. The script language
is a technical detail and it does not seem important to be evident.
But I'd say for now, keep it and we can change it in a later patch.
It looks like the following 'new file mode 10755' means +x permission is
used.
Missed.
1 file changed, 180 insertions(+)
create mode 100755 scripts/contrib/list-packageconfig-flag.py
diff --git a/scripts/contrib/list-packageconfig-flag.py
b/scripts/contrib/list-packageconfig-flag.py
new file mode 100755
index 000..7a5568f
--- /dev/null
+++ b/scripts/contrib/list-packageconfig-flag.py
@@ -0,0 +1,180 @@
+#!/usr/bin/env python
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
Foundation.
+#
+# Copyright (C) 2013 Wind River Systems, Inc.
+#
+# list recipes which have PACKAGECONFIG's flags in METADIR
+# list PACKAGECONFIG's flags and all affected recipes in METADIR
+#
+
+import sys
+import getopt
+import os
+import re
+
+usage_body = ''' list recipes which have PACKAGECONFIG's flags in
METADIR
+
+OPTION:
+ -h, --help display this help and exit
+ -f, --flag list PACKAGECONFIG's flags and all affected recipes in
METADIR
+
+EXAMPLE:
+list-packageconfig-flag.py poky/meta poky/meta-yocto
+list-packageconfig-flag.py -f poky/meta poky/meta-yocto
+'''
+
+def usage():
+print 'Usage: %s [OPTION] [METADIR]...' %
os.path.basename(sys.argv[0])
+print usage_body
+
+def parse_recipe(recipe):
+''' Parse a recipe to collect PACKAGECONFIG's flags '''
+prog = re.compile(r' *PACKAGECONFIG\[(?Pflag.*)\] *=.*')
+try:
+r = open(recipe)
+except IOError as (errno, strerror):
+print sys.stderr, 'WARNING: Failed to open recipe', recipe
+
+flaglist = []
+for line in r:
+# Strip any comments from the line
+line = line.rsplit('#')[0]
+m = prog.match(line)
+if m:
+flaglist.append(m.group('flag'))
+r.close()
+
+return flaglist
+
+def process_recipes(metadir):
+''' Collect recipes which have PACKAGECONFIG's flags in METADIR '''
+# recipesdict = {'recipe': ['flag1', 'flag2',...]}
+recipesdict = {}
+for root,dirs,files in os.walk(metadir):
+for name in files:
+if name.find(.bb) = 0 or name.find(.inc) = 0:
+flaglist = parse_recipe(os.path.join(root,name))
+if flaglist:
+recipesdict[name] = flaglist
+
+return recipesdict
In case a PACKAGECONFIG is add by a class. I think this case is missing
here.
Agree, sorry for the missing, I will add it.
Thanks.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http
Re: [OE-core] [PATCH] gcc-4.8: Fix meta-fsl-arm iperf build issue
On Thu, Aug 1, 2013 at 7:07 PM, Khem Raj raj.k...@gmail.com wrote: This should fix the problem seen where gcc ICE was happening when compiling iperf with older 2.6.x kernel In fact it is 'perf', not iperf ;-) Test this patch by reverting below commit in meta-fsl-arm commit daf582c93a7283fb0af3b25fe2ada48f4c9985c4 Author: Otavio Salvador ota...@ossystems.com.br Date: Tue Jul 2 11:52:51 2013 -0300 perf: Disable FPU tune for i.MX5 SoCs to workaround GCC ICE Signed-off-by: Khem Raj raj.k...@gmail.com CC: Otavio Salvador ota...@ossystems.com.br Tested-by: Otavio Salvador ota...@ossystems.com.br Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] distro_features_check.bbclass: Allow checking of required/conflicting features
On Fri, Aug 2, 2013 at 6:16 PM, Chris Larson clar...@kergoth.com wrote: On Thu, Aug 1, 2013 at 3:13 PM, Otavio Salvador ota...@ossystems.com.br wrote: This add support to list required/confliting distro features for a recipe; this avoids user mistake when building recipes/images which would not work depending on DISTRO_FEATURES option set. Adding: ,[ Use example ] | inherit distro_features_check | | REQUIRED_DISTRO_FEATURES = x11 | CONFLICT_DISTRO_FEATURES_mx6 = wayland I wonder if it would be worth doing this like PNBLACKLIST to let the recipe provide its reasoning as a message, or if that would add too much overhead. I don't know enough about this use case, but something to consider if it hasn't been already. I did a look now on PNBLACKLIST and while I see the value of a custom message I didn't come up with a way to do it using overrides as well. So, as the example in the commit log, it'd be harder to make a mx6 specific conflict. CONFLICT_DISTRO_FEATURES[wayland]_mx6 = Vivante GPU driver for Wayland is incompatible with X11 Would the above work with current BitBake code? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: update to 2013.07
On Sat, Aug 3, 2013 at 6:17 AM, Laszlo Papp lp...@kde.org wrote: Signed-off-by: Laszlo Papp lp...@kde.org Please reword the commit. You're not updating it but adding 2013.07 version. Personally I'd prefer to update for 2013.07 and drop previous releases. To support the update, I've been using this in meta-fsl-arm since rc1 ;-) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] distro_features_check.bbclass: Allow checking of required/conflicting features
On Sat, Aug 3, 2013 at 3:26 PM, Chris Larson clar...@kergoth.com wrote: On Sat, Aug 3, 2013 at 9:55 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Fri, Aug 2, 2013 at 6:16 PM, Chris Larson clar...@kergoth.com wrote: On Thu, Aug 1, 2013 at 3:13 PM, Otavio Salvador ota...@ossystems.com.br wrote: This add support to list required/confliting distro features for a recipe; this avoids user mistake when building recipes/images which would not work depending on DISTRO_FEATURES option set. Adding: ,[ Use example ] | inherit distro_features_check | | REQUIRED_DISTRO_FEATURES = x11 | CONFLICT_DISTRO_FEATURES_mx6 = wayland I wonder if it would be worth doing this like PNBLACKLIST to let the recipe provide its reasoning as a message, or if that would add too much overhead. I don't know enough about this use case, but something to consider if it hasn't been already. I did a look now on PNBLACKLIST and while I see the value of a custom message I didn't come up with a way to do it using overrides as well. So, as the example in the commit log, it'd be harder to make a mx6 specific conflict. CONFLICT_DISTRO_FEATURES[wayland]_mx6 = Vivante GPU driver for Wayland is incompatible with X11 Would the above work with current BitBake code? That's a good point, unfortunately I don't think flags propagate for overrides today :(. I think it would be something like CONFLICT_DISTRO_FEATURES_mx6[wayland], but I don't think that folds into the main variable when the overrides are applied (the semantics of that may be unclear0. Oh well, nevermind :) Yes; or done using code to set it only for specific cases. So I think it is better to let this as is and put a comment on the code where using the class /why/ it conflicts/requires it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: update to 2013.07
On Sat, Aug 3, 2013 at 5:00 PM, Saul Wold s...@linux.intel.com wrote: On 08/03/2013 11:12 AM, Laszlo Papp wrote: It is updating the latest version while also preserving the option of using an earlier one. As has been mentioned both on the IRC and here to various other patches that update without out removing the older version, we ask why is the older version still needed. In certain cases, such as changing licenses (GPLv2 - GPLv3), we keep the older version, in the case of the toolchain and eglibc, we keep n-1 around while we stability n. It appears that u-boot is one of those special cases, but I do not have enough information in the logs to determine why we are not removing the older recipes. Otavio, any reason we need to keep 3 older versions? Last time it was proposed, IIRC, it was late in the release cycle and people were worried about breaking other BSPs. I think every BSP which has specific patches on top of U-Boot mainline should handle it on the BSP so I see no reason to keep all those, I am all for updating to 2013.07. As I said, we're using it in meta-fsl-arm for some time. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] blacklist.bbclass: Avoid blacklist specific handle in base.bbclass
base.bbclass had code which handled the PNBLACKLIST in case of
multilib use. This is better to be done in the blacklist.bbclass so it
has all logic in a single place.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/base.bbclass | 10 --
meta/classes/blacklist.bbclass | 25 +
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index e2c9a7d..bc2b4f6 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -141,7 +141,6 @@ def pkgarch_mapping(d):
def preferred_ml_updates(d):
# If any PREFERRED_PROVIDER or PREFERRED_VERSION are set,
# we need to mirror these variables in the multilib case;
-# likewise the PNBLACKLIST flags.
multilibs = d.getVar('MULTILIBS', True) or
if not multilibs:
return
@@ -154,21 +153,12 @@ def preferred_ml_updates(d):
versions = []
providers = []
-blacklists = d.getVarFlags('PNBLACKLIST') or {}
for v in d.keys():
if v.startswith(PREFERRED_VERSION_):
versions.append(v)
if v.startswith(PREFERRED_PROVIDER_):
providers.append(v)
-for pkg, reason in blacklists.items():
-if pkg.endswith((-native, -crosssdk)) or
pkg.startswith((nativesdk-, virtual/nativesdk-)) or 'cross-canadian' in pkg:
-continue
-for p in prefixes:
-newpkg = p + - + pkg
-if not d.getVarFlag('PNBLACKLIST', newpkg, True):
-d.setVarFlag('PNBLACKLIST', newpkg, reason)
-
for v in versions:
val = d.getVar(v, False)
pkg = v.replace(PREFERRED_VERSION_, )
diff --git a/meta/classes/blacklist.bbclass b/meta/classes/blacklist.bbclass
index 75abd99..6153cf8 100644
--- a/meta/classes/blacklist.bbclass
+++ b/meta/classes/blacklist.bbclass
@@ -12,6 +12,31 @@
# PNBLACKLIST[pn] = message
#
+# Cope with PNBLACKLIST flags for multilib case
+addhandler blacklist_multilib_eventhandler
+blacklist_multilib_eventhandler[eventmask] = bb.event.ConfigParsed
+python blacklist_multilib_eventhandler() {
+multilibs = e.data.getVar('MULTILIBS', True) or
+if not multilibs:
+return
+
+# this block has been copied from base.bbclass so keep it in sync
+prefixes = []
+for ext in multilibs.split():
+eext = ext.split(':')
+if len(eext) 1 and eext[0] == 'multilib':
+prefixes.append(eext[1])
+
+blacklists = e.data.getVarFlags('PNBLACKLIST') or {}
+for pkg, reason in blacklists.items():
+if pkg.endswith((-native, -crosssdk)) or
pkg.startswith((nativesdk-, virtual/nativesdk-)) or 'cross-canadian' in pkg:
+continue
+for p in prefixes:
+newpkg = p + - + pkg
+if not e.data.getVarFlag('PNBLACKLIST', newpkg, True):
+e.data.setVarFlag('PNBLACKLIST', newpkg, reason)
+}
+
python () {
blacklist = d.getVarFlag('PNBLACKLIST', d.getVar('PN', True), True)
--
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] blacklist.bbclass: Avoid blacklist specific handle in base.bbclass
On Sat, Aug 3, 2013 at 7:44 PM, Mario Domenech Goulart
ma...@ossystems.com.br wrote:
...
+# Cope with PNBLACKLIST flags for multilib case
+addhandler blacklist_multilib_eventhandler
+blacklist_multilib_eventhandler[eventmask] = bb.event.ConfigParsed
+python blacklist_multilib_eventhandler() {
+multilibs = e.data.getVar('MULTILIBS', True) or
+if not multilibs:
+return
Is the `or ' part necessary, given that `if not multilibs' would
branch to return in case multilib is bound to a falsy value? It looks
redundant.
You're right. I just sent a v2 removing this code.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] blacklist.bbclass: Avoid blacklist specific handle in base.bbclass
base.bbclass had code which handled the PNBLACKLIST in case of
multilib use. This is better to be done in the blacklist.bbclass so it
has all logic in a single place.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- Drop redundant 'or ' code. Thanks to Mario for the hint.
meta/classes/base.bbclass | 10 --
meta/classes/blacklist.bbclass | 25 +
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index e2c9a7d..bc2b4f6 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -141,7 +141,6 @@ def pkgarch_mapping(d):
def preferred_ml_updates(d):
# If any PREFERRED_PROVIDER or PREFERRED_VERSION are set,
# we need to mirror these variables in the multilib case;
-# likewise the PNBLACKLIST flags.
multilibs = d.getVar('MULTILIBS', True) or
if not multilibs:
return
@@ -154,21 +153,12 @@ def preferred_ml_updates(d):
versions = []
providers = []
-blacklists = d.getVarFlags('PNBLACKLIST') or {}
for v in d.keys():
if v.startswith(PREFERRED_VERSION_):
versions.append(v)
if v.startswith(PREFERRED_PROVIDER_):
providers.append(v)
-for pkg, reason in blacklists.items():
-if pkg.endswith((-native, -crosssdk)) or
pkg.startswith((nativesdk-, virtual/nativesdk-)) or 'cross-canadian' in pkg:
-continue
-for p in prefixes:
-newpkg = p + - + pkg
-if not d.getVarFlag('PNBLACKLIST', newpkg, True):
-d.setVarFlag('PNBLACKLIST', newpkg, reason)
-
for v in versions:
val = d.getVar(v, False)
pkg = v.replace(PREFERRED_VERSION_, )
diff --git a/meta/classes/blacklist.bbclass b/meta/classes/blacklist.bbclass
index 75abd99..147e988 100644
--- a/meta/classes/blacklist.bbclass
+++ b/meta/classes/blacklist.bbclass
@@ -12,6 +12,31 @@
# PNBLACKLIST[pn] = message
#
+# Cope with PNBLACKLIST flags for multilib case
+addhandler blacklist_multilib_eventhandler
+blacklist_multilib_eventhandler[eventmask] = bb.event.ConfigParsed
+python blacklist_multilib_eventhandler() {
+multilibs = e.data.getVar('MULTILIBSA', True)
+if not multilibs:
+return
+
+# this block has been copied from base.bbclass so keep it in sync
+prefixes = []
+for ext in multilibs.split():
+eext = ext.split(':')
+if len(eext) 1 and eext[0] == 'multilib':
+prefixes.append(eext[1])
+
+blacklists = e.data.getVarFlags('PNBLACKLIST') or {}
+for pkg, reason in blacklists.items():
+if pkg.endswith((-native, -crosssdk)) or
pkg.startswith((nativesdk-, virtual/nativesdk-)) or 'cross-canadian' in pkg:
+continue
+for p in prefixes:
+newpkg = p + - + pkg
+if not e.data.getVarFlag('PNBLACKLIST', newpkg, True):
+e.data.setVarFlag('PNBLACKLIST', newpkg, reason)
+}
+
python () {
blacklist = d.getVarFlag('PNBLACKLIST', d.getVar('PN', True), True)
--
1.8.3.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH] uboot-config.bbclass: Allow choose of U-Boot config for machine
Some machines provide several possible configurations and until now
there was no easy way for user to override the default setting.
This class provides a system similar to PACKAGECONFIG but for
U-Boot. The format is:
UBOOT_CONFIG ??= default
UBOOT_CONFIG[foo] = config,images
There are two possible parameters:
- config: it is used to set UBOOT_MACHINE
- images: it is used to append onto IMAGE_FSTYPES
Below there's an usage example:
,[ i.MX6Q SABRE AUTO based example ]
| UBOOT_CONFIG ??= sd
| UBOOT_CONFIG[sd] = mx6qsabreauto_config,sdcard
| UBOOT_CONFIG[eimnor] = mx6qsabreauto_eimnor_config
| UBOOT_CONFIG[nand] = mx6qsabreauto_nand_config,ubifs
| UBOOT_CONFIG[spinor] = mx6qsabreauto_spinor_config
`
User can, from local.conf or environment, use UBOOT_CONFIG=nand and
override the default setting, as:
,[ Override example from command line ]
| MACHINE=imx6qsabreauto UBOOT_CONFIG=nand bitbake core-image-base
`
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/uboot-config.bbclass | 39 +++
1 file changed, 39 insertions(+)
create mode 100644 meta/classes/uboot-config.bbclass
diff --git a/meta/classes/uboot-config.bbclass
b/meta/classes/uboot-config.bbclass
new file mode 100644
index 000..fc37620
--- /dev/null
+++ b/meta/classes/uboot-config.bbclass
@@ -0,0 +1,39 @@
+# Allow easy override of U-Boot config for a machine
+#
+# The format to specify it, in the machine, is:
+#
+# UBOOT_CONFIG ??= default
+# UBOOT_CONFIG[foo] = config,images
+#
+# Copyright 2013 (C) O.S. Systems Software LTDA.
+
+addhandler uboot_config_eventhandler
+uboot_config_eventhandler[eventmask] = bb.event.ConfigParsed
+python uboot_config_eventhandler() {
+ubootconfigflags = e.data.getVarFlags('UBOOT_CONFIG')
+if not ubootconfigflags:
+return
+
+ubootconfig = (e.data.getVar('UBOOT_CONFIG', True) or ).split()
+if len(ubootconfig) 1:
+raise bb.parse.SkipPackage('You can only have a single default for
UBOOT_CONFIG.')
+elif len(ubootconfig) == 0:
+raise bb.parse.SkipPackage('You must set a default in UBOOT_CONFIG.')
+ubootconfig = ubootconfig[0]
+
+for f, v in ubootconfigflags.items():
+if f == 'defaultval':
+continue
+
+items = v.split(',')
+if items[0] and len(items) 2:
+raise bb.parse.SkipPackage('Only config,images can be specified!')
+
+if ubootconfig == f:
+bb.debug(1, Setting UBOOT_MACHINE to %s. % items[0])
+e.data.setVar('UBOOT_MACHINE', items[0])
+
+if items[1]:
+bb.debug(1, Appending '%s' to IMAGE_FSTYPES. % items[1])
+e.data.appendVar('IMAGE_FSTYPES', ' ' + items[1])
+}
--
1.8.3.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] uboot-config.bbclass: Allow choose of U-Boot config for machine
On Sun, Aug 4, 2013 at 7:25 PM, Otavio Salvador ota...@ossystems.com.br wrote: Some machines provide several possible configurations and until now there was no easy way for user to override the default setting. This class provides a system similar to PACKAGECONFIG but for U-Boot. The format is: UBOOT_CONFIG ??= default UBOOT_CONFIG[foo] = config,images There are two possible parameters: - config: it is used to set UBOOT_MACHINE - images: it is used to append onto IMAGE_FSTYPES Below there's an usage example: ,[ i.MX6Q SABRE AUTO based example ] | UBOOT_CONFIG ??= sd | UBOOT_CONFIG[sd] = mx6qsabreauto_config,sdcard | UBOOT_CONFIG[eimnor] = mx6qsabreauto_eimnor_config | UBOOT_CONFIG[nand] = mx6qsabreauto_nand_config,ubifs | UBOOT_CONFIG[spinor] = mx6qsabreauto_spinor_config ` User can, from local.conf or environment, use UBOOT_CONFIG=nand and override the default setting, as: ,[ Override example from command line ] | MACHINE=imx6qsabreauto UBOOT_CONFIG=nand bitbake core-image-base ` Signed-off-by: Otavio Salvador ota...@ossystems.com.br This patch is to bring the discussion about the problem I am trying to solve. Currently we'd need several duplicated machines to allow this kind of setup. Do people agree with this approach? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] base.bbclass: Fix PACKAGECONFIG usage comment
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index bc2b4f6..f30f4db 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -397,7 +397,7 @@ python () {
#
# These take the form:
#
-# PACKAGECONFIG ?? = default options
+# PACKAGECONFIG ??= default options
# PACKAGECONFIG[foo] =
--enable-foo,--disable-foo,foo_depends,foo_runtime_depends
pkgconfigflags = d.getVarFlags(PACKAGECONFIG) or {}
if pkgconfigflags:
--
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 V4 02/10] use a uniform way to determine whether rootfs is read-only
On Wed, Aug 7, 2013 at 5:08 AM, qi.c...@windriver.com wrote:
...
--- a/meta/recipes-core/initscripts/initscripts-1.0/functions
+++ b/meta/recipes-core/initscripts/initscripts-1.0/functions
@@ -58,3 +58,17 @@ status() {
fi
return 3
}
+
+# Determine whether rootfs is read-only or not according to /proc/mounts or
/etc/fstab.
+is_rootfs_readonly () {
+local DIRNAME=`dirname $0`
+local ROOT_DIR=`echo $DIRNAME | sed -ne 's:/etc/.*::p'`
+local criteria_file
+[ -n $ROOT_DIR ] criteria_file=$ROOT_DIR/etc/fstab ||
criteria_file=/proc/mounts
+local flag
+for flag in `awk '{ if ($2 == /) { split($4,FLAGS,,) } }; END { for
(f in FLAGS) print FLAGS[f] }' $criteria_file`; do
+ [ $flag = ro ] { echo yes; return 0; }
+done
+echo no
+return 0
+}
\ No newline at end of file
Please fix this.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] seperatebuilddir: mesa now builds out of tree
On Thu, Aug 8, 2013 at 1:29 PM, Ross Burton ross.bur...@intel.com wrote: Signed-off-by: Ross Burton ross.bur...@intel.com This should be squashed on 1/2 as one is dependant of another and in case of a revert both would need to be reverted. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] gst-meta-base: bring in the v4l2 related gst plugin
On Thu, Aug 8, 2013 at 6:34 PM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
If the v4l2 machine feature is enabled, then the v4l2 gstreamer plugin
is also pulled in the gst-meta-base packages.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb
b/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb
index 210da37..c1139f4 100644
--- a/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb
@@ -35,7 +35,9 @@ RDEPENDS_gst-meta-base = \
gst-plugins-base-videoscale \
gst-plugins-base-ffmpegcolorspace \
gst-plugins-good-autodetect \
-gst-plugins-good-souphttpsrc
+gst-plugins-good-souphttpsrc \
+gst-plugins-base-videotestsrc \
videotestsrc is not related to this change.
+${@base_contains('MACHINE_FEATURES', 'v4l2',
'gst-plugins-good-video4linux2', '', d)}
RRECOMMENDS_gst-meta-x11-base = \
gst-plugins-base-ximagesink \
--
1.8.1.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] linux-dtb.inc: Replace /boot/ with /${KERNEL_IMAGEDEST}/
On Fri, Aug 9, 2013 at 7:53 AM, Mike Looijmans mike.looijm...@topic.nl wrote:
Devicetree files were installed hard-coded in /boot. When KERNEL_IMAGEDEST
is anything else but boot, the postinstall script and the file locations
no longer match and the postinstall will fail.
Replace boot with ${KERNEL_IMAGEDEST} to fix this problem, and to allow
the devicetree files to be installed in another location.
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
Reviewed-by: Otavio Salvador ota...@ossystems.com.br
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] blacklist.bbclass: Avoid blacklist specific handle in base.bbclass
On Fri, Aug 9, 2013 at 12:47 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Saturday 03 August 2013 19:58:37 Otavio Salvador wrote:
+# Cope with PNBLACKLIST flags for multilib case
+addhandler blacklist_multilib_eventhandler
+blacklist_multilib_eventhandler[eventmask] = bb.event.ConfigParsed
+python blacklist_multilib_eventhandler() {
+multilibs = e.data.getVar('MULTILIBSA', True)
Typo - this should be MULTILIBS. Did you test this patch in a multilib
configuration?
I changed it to test and ended commiting it. Sorry. I can send a v2 of it.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/17] Review ACK
On Fri, Aug 9, 2013 at 12:03 PM, Saul Wold s...@linux.intel.com wrote: ... Otavio Salvador (1): blacklist.bbclass: Avoid blacklist specific handle in base.bbclass Please drop this one. Paul found my typo (did when I was testing it). I will send a v2. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] blacklist.bbclass: Avoid blacklist specific handle in base.bbclass
base.bbclass had code which handled the PNBLACKLIST in case of
multilib use. This is better to be done in the blacklist.bbclass so it
has all logic in a single place.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v3:
- Fix a typo kept when testing the code and commited by mistake
Changes in v2:
- Drop redundant 'or ' code. Thanks to Mario for the hint.
meta/classes/base.bbclass | 10 --
meta/classes/blacklist.bbclass | 25 +
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index a2403ac..f30f4db 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -141,7 +141,6 @@ def pkgarch_mapping(d):
def preferred_ml_updates(d):
# If any PREFERRED_PROVIDER or PREFERRED_VERSION are set,
# we need to mirror these variables in the multilib case;
-# likewise the PNBLACKLIST flags.
multilibs = d.getVar('MULTILIBS', True) or
if not multilibs:
return
@@ -154,21 +153,12 @@ def preferred_ml_updates(d):
versions = []
providers = []
-blacklists = d.getVarFlags('PNBLACKLIST') or {}
for v in d.keys():
if v.startswith(PREFERRED_VERSION_):
versions.append(v)
if v.startswith(PREFERRED_PROVIDER_):
providers.append(v)
-for pkg, reason in blacklists.items():
-if pkg.endswith((-native, -crosssdk)) or
pkg.startswith((nativesdk-, virtual/nativesdk-)) or 'cross-canadian' in pkg:
-continue
-for p in prefixes:
-newpkg = p + - + pkg
-if not d.getVarFlag('PNBLACKLIST', newpkg, True):
-d.setVarFlag('PNBLACKLIST', newpkg, reason)
-
for v in versions:
val = d.getVar(v, False)
pkg = v.replace(PREFERRED_VERSION_, )
diff --git a/meta/classes/blacklist.bbclass b/meta/classes/blacklist.bbclass
index 75abd99..a0141a8 100644
--- a/meta/classes/blacklist.bbclass
+++ b/meta/classes/blacklist.bbclass
@@ -12,6 +12,31 @@
# PNBLACKLIST[pn] = message
#
+# Cope with PNBLACKLIST flags for multilib case
+addhandler blacklist_multilib_eventhandler
+blacklist_multilib_eventhandler[eventmask] = bb.event.ConfigParsed
+python blacklist_multilib_eventhandler() {
+multilibs = e.data.getVar('MULTILIBS', True)
+if not multilibs:
+return
+
+# this block has been copied from base.bbclass so keep it in sync
+prefixes = []
+for ext in multilibs.split():
+eext = ext.split(':')
+if len(eext) 1 and eext[0] == 'multilib':
+prefixes.append(eext[1])
+
+blacklists = e.data.getVarFlags('PNBLACKLIST') or {}
+for pkg, reason in blacklists.items():
+if pkg.endswith((-native, -crosssdk)) or
pkg.startswith((nativesdk-, virtual/nativesdk-)) or 'cross-canadian' in pkg:
+continue
+for p in prefixes:
+newpkg = p + - + pkg
+if not e.data.getVarFlag('PNBLACKLIST', newpkg, True):
+e.data.setVarFlag('PNBLACKLIST', newpkg, reason)
+}
+
python () {
blacklist = d.getVarFlag('PNBLACKLIST', d.getVar('PN', True), True)
--
1.8.4.rc1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] linux-dtb: Use kernel build system to generate the dtb files
As the Linux kernel, unconditionally, builds the dtc application and
it is the compatible version with the DeviceTree files shipped within
the kernel it is better to use it and the kernel build system to
generate the dtb files.
Some DeviceTree files rely on CPP and kernel headers to be able to
generate the dtb binary contents and it is harder to replicate it
outside of Linux kernel build system so we /use/ it.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
NOTE: This depends on 'linux-dtb.inc: Replace /boot/ with
/${KERNEL_IMAGEDEST}/' patch
meta/recipes-kernel/linux/linux-dtb.inc | 59 +++--
1 file changed, 27 insertions(+), 32 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 41dd599..a65f8bd 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -1,44 +1,39 @@
# Support for device tree generation
FILES_kernel-devicetree = /${KERNEL_IMAGEDEST}/devicetree*
-KERNEL_DEVICETREE_FLAGS ?= -R 8 -p 0x3000
python __anonymous () {
-devicetree = d.getVar(KERNEL_DEVICETREE, True) or ''
-if devicetree:
-depends = d.getVar(DEPENDS, True)
-d.setVar(DEPENDS, %s dtc-native % depends)
-packages = d.getVar(PACKAGES, True)
-d.setVar(PACKAGES, %s kernel-devicetree % packages)
+d.appendVar(PACKAGES, kernel-devicetree)
}
do_install_append() {
+ bbwarn ARRG
if test -n ${KERNEL_DEVICETREE}; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE} ]; then
- echo Warning: ${DTS_FILE} is not available!
- continue
+ for DTB in ${KERNEL_DEVICETREE}; do
+ if echo ${DTB} | grep -q '/dts/'; then
+ bbwarn ${DTB} points to the full path dts file
while it should have the target for use.
+ DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
fi
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F .
'{print $1}'`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
- DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed s/${MACHINE}/${DTS_BASE_NAME}/g`
- dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o
${DTS_BASE_NAME} ${DTS_FILE}
- install -m 0644 ${DTS_BASE_NAME}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+ DTB_BASE_NAME=`basename ${DTB} .dtb`
+ DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTB_BASE_NAME}/g`
+ DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed s/${MACHINE}/${DTB_BASE_NAME}/g`
+ oe_runmake ${DTB}
+ install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
done
fi
}
do_deploy_append() {
if test -n ${KERNEL_DEVICETREE}; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE} ]; then
- echo Warning: ${DTS_FILE} is not available!
- continue
+ for DTB in ${KERNEL_DEVICETREE}; do
+ if echo ${DTB} | grep -q '/dts/'; then
+ bbwarn ${DTB} points to the full path dts file
while it should have the target for use.
+ DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
fi
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F .
'{print $1}'`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
- DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed s/${MACHINE}/${DTS_BASE_NAME}/g`
+ DTB_BASE_NAME=`basename ${DTB} .dtb`
+ DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTB_BASE_NAME}/g`
+ DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed s/${MACHINE}/${DTB_BASE_NAME}/g`
install -d ${DEPLOYDIR}
- install -m 0644 ${B}/${DTS_BASE_NAME}
${DEPLOYDIR}/${DTB_NAME}.dtb
+ install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${DEPLOYDIR}/${DTB_NAME}.dtb
cd ${DEPLOYDIR}
ln -sf ${DTB_NAME}.dtb ${DTB_SYMLINK_NAME}.dtb
cd -
@@ -48,20 +43,20 @@ do_deploy_append() {
pkg_postinst_kernel-devicetree () {
cd /${KERNEL_IMAGEDEST}
- for DTS_FILE in ${KERNEL_DEVICETREE}
+ for DTB_FILE in ${KERNEL_DEVICETREE}
do
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F . '{print
Re: [OE-core] [PATCH] linux-dtb: Use kernel build system to generate the dtb files
On Mon, Aug 12, 2013 at 12:37 PM, Otavio Salvador
ota...@ossystems.com.br wrote:
As the Linux kernel, unconditionally, builds the dtc application and
it is the compatible version with the DeviceTree files shipped within
the kernel it is better to use it and the kernel build system to
generate the dtb files.
Some DeviceTree files rely on CPP and kernel headers to be able to
generate the dtb binary contents and it is harder to replicate it
outside of Linux kernel build system so we /use/ it.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
NOTE: This depends on 'linux-dtb.inc: Replace /boot/ with
/${KERNEL_IMAGEDEST}/' patch
meta/recipes-kernel/linux/linux-dtb.inc | 59
+++--
1 file changed, 27 insertions(+), 32 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 41dd599..a65f8bd 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -1,44 +1,39 @@
# Support for device tree generation
FILES_kernel-devicetree = /${KERNEL_IMAGEDEST}/devicetree*
-KERNEL_DEVICETREE_FLAGS ?= -R 8 -p 0x3000
python __anonymous () {
-devicetree = d.getVar(KERNEL_DEVICETREE, True) or ''
-if devicetree:
-depends = d.getVar(DEPENDS, True)
-d.setVar(DEPENDS, %s dtc-native % depends)
-packages = d.getVar(PACKAGES, True)
-d.setVar(PACKAGES, %s kernel-devicetree % packages)
+d.appendVar(PACKAGES, kernel-devicetree)
}
do_install_append() {
+ bbwarn ARRG
Kept when testing.
I will await for more feedback before sending v2.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] nativesdk-qt4-tools: remove nativesdk-libx11 for qt-embedded
Hello Eric, On Mon, Aug 12, 2013 at 10:58 AM, Eric Nelson eric.nel...@boundarydevices.com wrote: I'm afraid we can't do this since you just broke any other kind of override which might get used anywhere by any recipe using this .inc file. I'd also be wary of adding something as simple as qt into overrides since it can match things more widely than you might want. I'm a bit of an OE n00b, and I'm not quite sure how to express this conditional. meta-toolchain-qte shouldn't depend on nativesdk-libx11, and I'm not sure how the dependency can be moved to the X11 recipe recipes_qt/meta/meta-toolchain-qt.bb. I think you're looking for to: http://privatepaste.com/cc22a68c56 The missing part for merging it is to /force/ it to be disabled in qt configure. This was last Richard complain about this patch when I sent it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-dtb: Use kernel build system to generate the dtb files
On Tue, Aug 13, 2013 at 12:40 AM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-08-12 11:37 AM, Otavio Salvador wrote:
As the Linux kernel, unconditionally, builds the dtc application and
it is the compatible version with the DeviceTree files shipped within
the kernel it is better to use it and the kernel build system to
generate the dtb files.
From my point of view, I agree with this. I've always pushed for using
all of the artifacts from the kernel built (uImage, dtb, etc) and this
is consistent with that approach.
Good.
Some DeviceTree files rely on CPP and kernel headers to be able to
generate the dtb binary contents and it is harder to replicate it
outside of Linux kernel build system so we /use/ it.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
NOTE: This depends on 'linux-dtb.inc: Replace /boot/ with
/${KERNEL_IMAGEDEST}/' patch
meta/recipes-kernel/linux/linux-dtb.inc | 59
+++--
1 file changed, 27 insertions(+), 32 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 41dd599..a65f8bd 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -1,44 +1,39 @@
# Support for device tree generation
FILES_kernel-devicetree = /${KERNEL_IMAGEDEST}/devicetree*
-KERNEL_DEVICETREE_FLAGS ?= -R 8 -p 0x3000
python __anonymous () {
-devicetree = d.getVar(KERNEL_DEVICETREE, True) or ''
-if devicetree:
-depends = d.getVar(DEPENDS, True)
-d.setVar(DEPENDS, %s dtc-native % depends)
-packages = d.getVar(PACKAGES, True)
-d.setVar(PACKAGES, %s kernel-devicetree % packages)
+d.appendVar(PACKAGES, kernel-devicetree)
What if someone, somewhere needs a custom dtc. Can we still trigger
a dependency on dtc-native is a different flag is set ?
The Kernel does not provide a way to 'override' it; it always use it
from scripts/dtc and it is the compatible version with the DeviceTree
files shipped within the kernel, so it is better to use it and the
kernel build system to generate the dtb files.
}
do_install_append() {
+ bbwarn ARRG
if test -n ${KERNEL_DEVICETREE}; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE} ]; then
- echo Warning: ${DTS_FILE} is not
available!
- continue
+ for DTB in ${KERNEL_DEVICETREE}; do
+ if echo ${DTB} | grep -q '/dts/'; then
+ bbwarn ${DTB} points to the full path dts
file while it should have the target for use.
This isn't reading right to me. What are you trying to say ? That
KERNEL_DEVICE_TREE should be the name of the dts and not the path
to that dts ? I'd say 'name' versus target.
You should name it 'imx6q-sabresd.dtb' for example.
What about testing for it's existence ? The old code used to do that.
It will fail if you ask it to build an invalid dtb file.
+ DTB=`basename ${DTB} | sed
's,\.dts$,.dtb,g'`
From the description of the patch .. this part is unexpected.
You are changing more than what is used to compile the dtb,
but the processing of the options.
It is not; I need to call it with the target. This is to support
converting from 'current' use to 'new' use and keep backward
compatibility.
fi
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F .
'{print $1}'`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
- DTB_SYMLINK_NAME=`echo
${KERNEL_IMAGE_SYMLINK_NAME} | sed s/${MACHINE}/${DTS_BASE_NAME}/g`
- dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o
${DTS_BASE_NAME} ${DTS_FILE}
- install -m 0644 ${DTS_BASE_NAME}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+ DTB_BASE_NAME=`basename ${DTB} .dtb`
+ DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTB_BASE_NAME}/g`
+ DTB_SYMLINK_NAME=`echo
${KERNEL_IMAGE_SYMLINK_NAME} | sed s/${MACHINE}/${DTB_BASE_NAME}/g`
+ oe_runmake ${DTB}
The change log should explain this as well. You are switching the
naming to DTB from the old DTS .. because ? The kernel build
requires it ? something else ? You tell me :)
This is to support converting from 'current' use to 'new' use and keep
backward compatibility.
+ install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
done
fi
}
do_deploy_append() {
if test -n ${KERNEL_DEVICETREE}; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE
Re: [OE-core] [PATCH] linux-dtb: Use kernel build system to generate the dtb files
On Tue, Aug 13, 2013 at 10:06 AM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-08-13 08:46 AM, Otavio Salvador wrote:
On Tue, Aug 13, 2013 at 12:40 AM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-08-12 11:37 AM, Otavio Salvador wrote:
As the Linux kernel, unconditionally, builds the dtc application and
it is the compatible version with the DeviceTree files shipped within
the kernel it is better to use it and the kernel build system to
generate the dtb files.
From my point of view, I agree with this. I've always pushed for using
all of the artifacts from the kernel built (uImage, dtb, etc) and this
is consistent with that approach.
Good.
Some DeviceTree files rely on CPP and kernel headers to be able to
generate the dtb binary contents and it is harder to replicate it
outside of Linux kernel build system so we /use/ it.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
NOTE: This depends on 'linux-dtb.inc: Replace /boot/ with
/${KERNEL_IMAGEDEST}/' patch
meta/recipes-kernel/linux/linux-dtb.inc | 59
+++--
1 file changed, 27 insertions(+), 32 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 41dd599..a65f8bd 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -1,44 +1,39 @@
# Support for device tree generation
FILES_kernel-devicetree = /${KERNEL_IMAGEDEST}/devicetree*
-KERNEL_DEVICETREE_FLAGS ?= -R 8 -p 0x3000
python __anonymous () {
-devicetree = d.getVar(KERNEL_DEVICETREE, True) or ''
-if devicetree:
-depends = d.getVar(DEPENDS, True)
-d.setVar(DEPENDS, %s dtc-native % depends)
-packages = d.getVar(PACKAGES, True)
-d.setVar(PACKAGES, %s kernel-devicetree % packages)
+d.appendVar(PACKAGES, kernel-devicetree)
What if someone, somewhere needs a custom dtc. Can we still trigger
a dependency on dtc-native is a different flag is set ?
The Kernel does not provide a way to 'override' it; it always use it
from scripts/dtc and it is the compatible version with the DeviceTree
files shipped within the kernel, so it is better to use it and the
kernel build system to generate the dtb files.
What I meant was not to override the kernel's dtc, but to simply fall
back to the old dtc-native reaching into the tree and compiling the
dts. That way we have flexibility as a fall back.
I think it will make the code much harder to follow and I am unsure we
will have it in a flexible enough way; for example if user uses kernel
headers for pins and like, it won't work, and it will be hard to come
up with something which could comply with all this. As this .inc file
is intended for 'in kernel build' it does not seems worth it.
}
do_install_append() {
+ bbwarn ARRG
if test -n ${KERNEL_DEVICETREE}; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE} ]; then
- echo Warning: ${DTS_FILE} is not
available!
- continue
+ for DTB in ${KERNEL_DEVICETREE}; do
+ if echo ${DTB} | grep -q '/dts/'; then
+ bbwarn ${DTB} points to the full path
dts
file while it should have the target for use.
This isn't reading right to me. What are you trying to say ? That
KERNEL_DEVICE_TREE should be the name of the dts and not the path
to that dts ? I'd say 'name' versus target.
You should name it 'imx6q-sabresd.dtb' for example.
right, that's what I always do myself. So I'm really just suggesting that
the bbwarn message be a bit more clear. i.e.
bbwarn ${DTB} contains the full path to the the dts file, but only the
dtb name should be used.
Great; changed for v2
What about testing for it's existence ? The old code used to do that.
It will fail if you ask it to build an invalid dtb file.
+ DTB=`basename ${DTB} | sed
's,\.dts$,.dtb,g'`
From the description of the patch .. this part is unexpected.
You are changing more than what is used to compile the dtb,
but the processing of the options.
It is not; I need to call it with the target. This is to support
converting from 'current' use to 'new' use and keep backward
compatibility.
Right, so you are switching to dtb, which the kernel expects, not
dts. The commit message should make this clear, right now it
doesn't. You need to understand what the kernel is looking for to
know why the change is being made.
Ok; Changed for v2.
fi
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F .
'{print $1}'`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
- DTB_SYMLINK_NAME=`echo
${KERNEL_IMAGE_SYMLINK_NAME} | sed s
[OE-core] [PATCH v2] linux-dtb: Use kernel build system to generate the dtb files
As the Linux kernel, unconditionally, builds the dtc application and
it is the compatible version with the DeviceTree files shipped within
the kernel it is better to use it and the kernel build system to
generate the dtb files.
Some DeviceTree files rely on CPP and kernel headers to be able to
generate the dtb binary contents and it is harder to replicate it
outside of Linux kernel build system so we /use/ it.
To comply with these assumptions we need to use the dtb file when
calling 'make' instead of pointing to the DeviceTree source file; the
code has been made backward compatible but it is advised to move to
the new definition to avoid warnings as:
,[ Original definition ]
| KERNEL_DEVICETREE = ${S}/arch/arm/boot/dts/imx6q-sabresd.dts
`
Becomes:
,[ New definition ]
| KERNEL_DEVICETREE = imx6q-sabresd.dtb
`
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- Drop debug warning left by mistake
- Improve bbwarn message (Bruce Ashfield)
- Improve commit log (Bruce Ascfield)
meta/recipes-kernel/linux/linux-dtb.inc | 58 +++--
1 file changed, 26 insertions(+), 32 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 41dd599..cebc76a 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -1,44 +1,38 @@
# Support for device tree generation
FILES_kernel-devicetree = /${KERNEL_IMAGEDEST}/devicetree*
-KERNEL_DEVICETREE_FLAGS ?= -R 8 -p 0x3000
python __anonymous () {
-devicetree = d.getVar(KERNEL_DEVICETREE, True) or ''
-if devicetree:
-depends = d.getVar(DEPENDS, True)
-d.setVar(DEPENDS, %s dtc-native % depends)
-packages = d.getVar(PACKAGES, True)
-d.setVar(PACKAGES, %s kernel-devicetree % packages)
+d.appendVar(PACKAGES, kernel-devicetree)
}
do_install_append() {
if test -n ${KERNEL_DEVICETREE}; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE} ]; then
- echo Warning: ${DTS_FILE} is not available!
- continue
+ for DTB in ${KERNEL_DEVICETREE}; do
+ if echo ${DTB} | grep -q '/dts/'; then
+ bbwarn ${DTB} contains the full path to the
the dts file, but only the dtb name should be used.
+ DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
fi
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F .
'{print $1}'`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
- DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed s/${MACHINE}/${DTS_BASE_NAME}/g`
- dtc -I dts -O dtb ${KERNEL_DEVICETREE_FLAGS} -o
${DTS_BASE_NAME} ${DTS_FILE}
- install -m 0644 ${DTS_BASE_NAME}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+ DTB_BASE_NAME=`basename ${DTB} .dtb`
+ DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTB_BASE_NAME}/g`
+ DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed s/${MACHINE}/${DTB_BASE_NAME}/g`
+ oe_runmake ${DTB}
+ install -m 0644 ${B}/arch/${ARCH}/boot/${DTB}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
done
fi
}
do_deploy_append() {
if test -n ${KERNEL_DEVICETREE}; then
- for DTS_FILE in ${KERNEL_DEVICETREE}; do
- if [ ! -f ${DTS_FILE} ]; then
- echo Warning: ${DTS_FILE} is not available!
- continue
+ for DTB in ${KERNEL_DEVICETREE}; do
+ if echo ${DTB} | grep -q '/dts/'; then
+ bbwarn ${DTB} contains the full path to the
the dts file, but only the dtb name should be used.
+ DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
fi
- DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F .
'{print $1}'`
- DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTS_BASE_NAME}/g`
- DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed s/${MACHINE}/${DTS_BASE_NAME}/g`
+ DTB_BASE_NAME=`basename ${DTB} .dtb`
+ DTB_NAME=`echo ${KERNEL_IMAGE_BASE_NAME} | sed
s/${MACHINE}/${DTB_BASE_NAME}/g`
+ DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed s/${MACHINE}/${DTB_BASE_NAME}/g`
install -d ${DEPLOYDIR}
- install -m 0644 ${B}/${DTS_BASE_NAME}
${DEPLOYDIR}/${DTB_NAME}.dtb
+ install -m 0644 ${B}/arch/${ARCH
Re: [OE-core] [PATCH 2/2 v2] meta-skeleton: Add busybox config fragment example
On Tue, Aug 13, 2013 at 2:11 PM, Saul Wold s...@linux.intel.com wrote:
This shows an example of the config fragment support that
both the linux-yocto and busybox recipes use. This example
is specific to busybox.
By adding busybox CONFIG options into a .cfg file and then
adding that .cfg file to SRC_URI the merge_config.sh script will
correctly handle these CONFIG options during the do_configure task.
v2: fixed FILESEXTRAPATHS
This should be bellow --- line or it ends in the commit log.
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta-skeleton/recipes-core/busybox/busybox/no_rfkill.cfg | 1 +
meta-skeleton/recipes-core/busybox/busybox_1.21.1.bbappend | 5 +
2 files changed, 6 insertions(+)
create mode 100644 meta-skeleton/recipes-core/busybox/busybox/no_rfkill.cfg
create mode 100644 meta-skeleton/recipes-core/busybox/busybox_1.21.1.bbappend
diff --git a/meta-skeleton/recipes-core/busybox/busybox/no_rfkill.cfg
b/meta-skeleton/recipes-core/busybox/busybox/no_rfkill.cfg
new file mode 100644
index 000..42c6730
--- /dev/null
+++ b/meta-skeleton/recipes-core/busybox/busybox/no_rfkill.cfg
@@ -0,0 +1 @@
+CONFIG_RFKILL=n
diff --git a/meta-skeleton/recipes-core/busybox/busybox_1.21.1.bbappend
b/meta-skeleton/recipes-core/busybox/busybox_1.21.1.bbappend
new file mode 100644
index 000..641f04a4
--- /dev/null
+++ b/meta-skeleton/recipes-core/busybox/busybox_1.21.1.bbappend
@@ -0,0 +1,5 @@
+FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+
+SRC_URI += \
+ file://no_rfkill.cfg \
+
--
1.8.1.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
