Re: [oe] How can I use / enable strace of the image of oe-core?
On Mon, Apr 21, 2014 at 4:56 AM, Journeyer J. Joh oosaprogram...@gmail.comwrote: oe-core for MSM is just a clone of oe-core. And mine is open via codeaurora : git://codeaurora.org/quic/le/openembedded/openembedded-core https://www.codeaurora.org/xwiki/bin/QLBEP/WebHome I want to use strace to debug my application on the image of oe-core (for MSM). I mean I want to use it on target embedded system. And I found strace from my oe-core source tree: oe-core/meta/recipes-devtools/strace And there are: strace-4.6/ strace_4.6.bb This gives me impression that I can use strace from my target system. But there is no source code for strace... in it! There's almost never source for anything in oe-core, ever. Sources are downloaded from upstream locations on the internet, patched if appropriate, and built by bitbake. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] differences between target and native configure options
On Wed, Oct 23, 2013 at 2:04 PM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: i have a recipe that is both used for target and for native. I need to have different configure options when it's built for target as opposed to native. earlier today on IRC, ericben showed me EXTRA_OEMAKE_virtclass-native = what you want However i now realize i need the exact opposite, i need to specify an option only when building the 'target', not native. iirc, virtclass is for native, or multilib... so is there another mechanism to do what i need? EXTRA_OEMAKE_class-target = “ -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [WIP][PATCH 00/66] Deterministic dependencies II
On Thu, Aug 29, 2013 at 8:50 AM, Martin Jansa martin.ja...@gmail.comwrote: WIP because verification build is still running and I must admit that I'm mostly testing that all dependencies are correctly disabled and in the end deterministic. I'm not testing if every possible combination of PACKAGECONFIG options provide sufficient dependency tree. The following changes since commit 72e23c12296fbc77193898c38426add58d0c2d71: mysql5: replace with mariadb 5.1.67 and tweak (2013-08-27 16:39:31 +0100) are available in the git repository at: git://git.openembedded.org/meta-openembedded-contrib jansa/deps http://cgit.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=jansa/deps Haven't reviewed all the patches, but just wanted to say, this is an impressive amount of work on this task, nicely done. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] test-dependencies.sh results from big world build
On Wed, Jul 24, 2013 at 9:50 AM, Martin Jansa martin.ja...@gmail.comwrote: My biggest build with 20+ layers included finally finished today (after many days because there was hw issue on server where it was running, so it was slower then it should be). The results are a bit messy because: 1) It had only some fixes from my last autodetected dependencies patchsets for oe-core and meta-oe 2) It was started when oe-core/master had broken boost, so many packages failed because of boost 3) It was started when oe-core/master had issues with qt-mobility (not sure if all were fixed already) 4) It wasn't using latest version of test-dependencies script 5) It was using complete buildhistory repo which had many stalled packages like task-* and couple of architectures. But at least it will allow me to restrict recipes to rebuild from 1900 to only 256 which were failing in this build. It was tested only for qemuarm. Complete logs are here: http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/test-dependencies-2013-07-24/ Interesting parts 11 recipes failed in world build: http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/test-dependencies-2013-07-24/failed.world 101 recipes failed in minimal build (8 caused by boost): http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/test-dependencies-2013-07-24/failed.min 216 packages (160 recipes) doesn't have deterministic dependencies http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/test-dependencies-2013-07-24/failed.dependencies Next results should be more interesting, because many issues are already fixed by change I've sent today to oe-core and oe-devel ML, but not all, because they were detected in build without x11 in DISTRO_FEATURES and without some layers (like meta-browser meta-efl meta-gnome meta-gpe meta-initramfs meta-webserver meta-xfce). I just wanted to say, this is some impressive work, nicely done. I'm amazed at how many recipes still don't have deterministic dependencies, even after all these years :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFC] Layers, PRINC and bbappends
On Wed, May 22, 2013 at 3:14 AM, Phil Blundell p...@pbcl.net wrote: On Wed, 2013-05-22 at 09:47 +0100, Paul Barker wrote: I've just sent a patch to the yocto@ list to fix this but it's brought up two things: 1) In openembedded-core/meta/classes/image.bbclass SPLASH is set with '?='. I'm overriding this with '=' in meta-raspberrypi/conf/machine/raspberrypi.conf which means it can't be overridden further in local.conf. Is this worth changing to '??=' in image.bbclass, '?=' in the machine conf so that it can be overridden with '=' in local.conf? Is my understanding of the overrides correct here? You can always override it from local.conf using a _forcevariable override (which used to be named _local, in fact, but that terminology turned out to be a bit confusing), or a _MACHINE override of course. So I don't think there is any major problem here. But, that said, it probably is true that the semantics of ??= are less surprising for users (since it isn't position-dependent in the way that ?= is) which might make it a better choice for image.bbclass. ??= is great in config files, but not ideal in classes that aren't globally inherited. If bitbake.conf sets a ??=, and a distro .conf updates the default by using ??= again, and then the class uses ??=, it'll replace the latest default set by the config. So, I think for default values, classes should use ?=, config files should use ??=. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Please submit your unindexed layers
On Tue, May 7, 2013 at 3:49 AM, Carlos Rafael Giani d...@pseudoterminal.orgwrote: * it uses _prepend in various places; I was able to replace all but one of them with prefuncs. The remaining one is populate_packages_prepend , and I just do not see how this could be turned into a prefunc. (And it is necessary to use it, because do_packages_split apparently cannot be used anywhere else.) I think prefuncs are cleaner, because they do not modify an existing function. Also, if the indentation style changes again someday, prefuncs cause less problems than _prepend does. Warning: as things stand today, as far as I know, prefuncs/postfuncs don't affect the checksums of the variable they interact with, so changing the contents of a prefunc/postfunc won't cause the function to be re-run automatically. You can work around this by adding it to vardeps as well: do_foo[vardeps] += bar do_foo[prefuncs] += bar -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][for-danny] guile: remove from meta-oe, there is newer version in oe-core
On Thu, Mar 21, 2013 at 6:07 AM, Eric Bénard e...@eukrea.com wrote: Le Thu, 21 Mar 2013 09:48:59 +, Ross Burton ross.bur...@intel.com a écrit : Signed-off-by: Martin Jansa martin.ja...@gmail.com --- meta-oe/recipes-support/guile/guile-1.8.7/18.diff | 1743 .../guile/guile-1.8.7/configure-fix.patch | 10 - .../guile/guile-native-1.8.7/cpp-linemarkers.patch |8 - .../guile/guile-native-1.8.7/reloc.patch | 22 - meta-oe/recipes-support/guile/guile-native.inc | 13 - .../recipes-support/guile/guile-native_1.8.7.bb| 13 - meta-oe/recipes-support/guile/guile.inc| 47 - meta-oe/recipes-support/guile/guile_1.8.7.bb | 14 - 8 files changed, 1870 deletions(-) delete mode 100644 meta-oe/recipes-support/guile/guile-1.8.7/18.diff delete mode 100644 meta-oe/recipes-support/guile/guile -1.8.7/configure-fix.patch delete mode 100644 meta-oe/recipes-support/guile/guile -native-1.8.7/cpp-linemarkers.patch delete mode 100644 meta-oe/recipes-support/guile/guile -native-1.8.7/reloc.patch delete mode 100644 meta-oe/recipes-support/guile/guile-native.inc delete mode 100644 meta-oe/recipes-support/guile/guile-native_1.8.7.bb delete mode 100644 meta-oe/recipes-support/guile/guile.inc delete mode 100644 meta-oe/recipes-support/guile/guile_1.8.7.bb pushed to danny-next I'm a bit confused about why this went in. danny is a stable branch, and this is clearly not a bugfix. Did the existence of this recipe actually cause a problem? This just caused a temporary build break for us due to bbappending to a removed recipe. What exactly is the policy for meta-oe's danny branch, if it's not bugfixes only? -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][for-danny] guile: remove from meta-oe, there is newer version in oe-core
On Fri, Apr 5, 2013 at 10:13 AM, Burton, Ross ross.bur...@intel.com wrote: On 5 April 2013 18:02, Chris Larson clar...@kergoth.com wrote: bit confused about why this went in. danny is a stable branch, and this is clearly not a bugfix. Did the existence of this recipe actually cause a problem? This just caused a temporary build break for us due to bbappending to a removed recipe. What exactly is the policy for meta-oe's danny branch, if it's not bugfixes only? Yes, it was causing problems, as the guile-native 1.7 was preferred over guile 2.0.6's ability to build natively, which meant oe-core+meta-oe was unable to build grub. Fair enough, but in the future please mention this sort of reasoning in the commit messages, or at the very least the patch series emails. Knowing *what* a commit does without *why* is much less useful. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][for-danny] guile: remove from meta-oe, there is newer version in oe-core
On Fri, Apr 5, 2013 at 1:13 PM, Eric Bénard e...@eukrea.com wrote: Le Fri, 5 Apr 2013 10:02:22 -0700, Chris Larson clar...@kergoth.com a écrit : I'm a bit confused about why this went in. danny is a stable branch, and this is clearly not a bugfix. Did the existence of this recipe actually cause a problem? This just caused a temporary build break for us due to bbappending to a removed recipe. What exactly is the policy for meta-oe's danny branch, if it's not bugfixes only? I usually apply patches to danny-next and wait at least one week to get feedback before pushing to danny (and usually I try to do that on a friday). So if you want to prevent this kind of problem for the future, you may be able to configure one of your autobuilders to build your projects using danny-next's branch so that you get the error before the patches are pushed to danny. Good point, I'll keep that in mind. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][danny][PATCH] layer.conf: Use .= for adding to BBPATH and += to BBFILES
On Thu, Mar 21, 2013 at 3:11 PM, Mark Hatle mark.ha...@windriver.comwrote:
On 3/21/13 4:46 PM, Christopher Larson wrote:
From: Andrei Gherzan andrei.gher...@windriver.com
Fixes parsing errors which is appearing after this commit to
meta-openembedded
http://cgit.openembedded.org/**meta-openembedded/commit/?id=**
3c21a46020bd0816579648f684c41d**bd6333583ehttp://cgit.openembedded.org/meta-openembedded/commit/?id=3c21a46020bd0816579648f684c41dbd6333583e
This triggers
exception NameError: name 'base_contains' is not defined
without this change
Signed-off-by: Andrei Gherzan andrei.gher...@windriver.com
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
meta-networking/conf/layer.**conf | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta-networking/conf/layer.**conf
b/meta-networking/conf/layer.**conf
index f26a172..1ea2bc2 100644
--- a/meta-networking/conf/layer.**conf
+++ b/meta-networking/conf/layer.**conf
@@ -1,9 +1,9 @@
# We have a conf and classes directory, add to BBPATH
-BBPATH := ${BBPATH}:${LAYERDIR}
+BBPATH .= :${LAYERDIR}
# We have a packages directory, add to BBFILES
-BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
- ${LAYERDIR}/recipes-*/*/*.**bbappend
+BBFILES += ${LAYERDIR}/recipes-*/*/*.bb \
+${LAYERDIR}/recipes-*/*/*.**bbappend
BBFILE_COLLECTIONS += networking
BBFILE_PATTERN_networking := ^${LAYERDIR}/
Don't those two have to be := so that 'LAYERDIR' is immediately
evaluated? LAYERDIR changes depending on which layer is currently being
processed
Nope, bitbake has handled LAYERDIR specially since Wed Apr 14 14:30:09
2010. See commits 849dbd63244cbc4eaca0f1beedbb67baca024629 and
40778a6e9e82c7ea4673a74fc19574430fa63e8d in bitbake.
--
Christopher Larson
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] RFC: meta-oe appends and overlayed recipes
On Tue, Feb 12, 2013 at 12:19 PM, Martin Jansa martin.ja...@gmail.comwrote: * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this as a distro policy decision; these should move to the layers for whichever distros want this. FWIW, this is particularly egregious if you've already built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt. MySQL and PostgreSQL are not in oe-core so it cannot be replaced with simple PACKAGECONFIG option in oe-core recipe, but I also prefer to share such .bbappend somewhere instead of every distribution reinventing the wheel when trying to enable something as simple as db in qt. I don't see any reason the oe-core recipe couldn't provide the packageconfig options, even missing the dependencies. They are valid package configuration options, so they should exist in PACKAGECONFIG. If a distro wants to enable one of them, however, they'd better include the layers that provide the deps :) -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] devshell - setting up additional environment variable
On Thu, Nov 8, 2012 at 9:48 AM, John Stirling ap.john.stirl...@gmail.comwrote: On 8 November 2012 14:09, Chris Larson clar...@kergoth.com wrote: On Thu, Nov 8, 2012 at 3:03 AM, John Stirling ap.john.stirl...@gmail.com wrote: Can someone advise best way to set up additional environment variables automatically when invoking devshell - We used to define a do_devshell_prepend() function but that doesn't seem to work any more. See OE_TERMINAL_EXPORTS - https://github.com/openembedded/oe-core/blob/master/meta/classes/terminal.bbclass#L7 -- Am I correct in thinking that would set the extra variables up for every devshell rather than for a specific package ? Or am I missing something ? I'd ideally like to set them on a per package basis rather than globally for all devshells. We used to be able to do this in the .bb file via do_devshell_prepend(). No, you're missing something. The class gets inherited globally, but the task is still run in recipe context. You should be just fine in appending to OE_TERMINAL_EXPORTS in a recipe, if you really need to (though it seems a little odd :). -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [meta-browser] Question regarding status of chromium recipes
Greetings, I'm wondering if the chromium recipes in this layer have ever been build tested. As far as I can tell, both 19 and 20 are missing dependencies on udev (libudev), gtk+, and gconf, and 20 also wants the openssl headers. 19 also fails due to an attempt to build/link a native tool requiring libxi, so it seems it can't be built without x11 headers on the build machine (along with the odd ld.gold requirement). Given these issues, I figured I'd throw out a contact email and try to determine if perhaps the OSSystems folks have local changes that never made it into the public layer, or if the recipes just didn't get a great deal of testing. Thanks, I'd appreciate any input on their status :) -- Christopher Larson clarson at kergoth dot com Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-ti] OE Changelog since 2012-08-05 until 2012-08-12
On Thu, Aug 16, 2012 at 8:18 AM, Cliff Brake cliff.br...@gmail.com wrote: The OE Changelog is back. Some time ago, I got several reports that the changelog was missing entries. I have since revamped the way dates are handled and may have made things better (or worse). The tool simply runs git shortlog --since date --until date with the dates referenced. This should capture changes from Mon through Sun of that week. The git shortlog --since/until uses the commit dates, not the author date, so that may explain some of the missing entries. git log --format=fuller can be used to view commit dates. If you still see missing entries, please send me the changeset hash and repo, and I'll debug it. If there are additional repos to include, please let me know. Woo! Welcome back, OE Changelog. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [PATCH] sstate: Add a two character subdirectory to the sstate directory layout
On Thu, Aug 2, 2012 at 8:53 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2012-08-02 at 16:14 +0200, Martin Jansa wrote: On Thu, Aug 02, 2012 at 03:53:35PM +0200, Martin Jansa wrote: On Wed, Jul 25, 2012 at 10:09:22PM +0100, Richard Purdie wrote: Currently all sstate files are placed into one directory. This does not scale and causes a variety of filesystem issues. This patch adds a two character subdirectory to the layout (based on the first two characters of the hash) so that files can be split into several directories. This should help performance of sstate in most cases by avoding creating directories with huge numbers of files. The SSTATE_MIRRORS syntax needs updating to account for the extra path element by the addition of a PATH item, for example: SSTATE_MIRRORS = file://.* file:///some/path/to/sstate-cache/PATH SSTATE_MIRRORS = file://.* http://192.168.1.23/sstate-cache/PATH; This change also sets the scene for using things like lsb-release in the Is it possible to create 2nd level cache with this? I have some server with slow upload but fully populated sstate-cache. So on server with faster upload which could be used as offical SSTATE_MIRROR for SHR distro I would like to add SSTATE_MIRRORS ?= file://.* http://slow-server/sstate-cache/PATH; And then sync my sstate-cache directory to public accessible web root (with rsync). Problem is that now sstate-cache has all files in slightly different layout then original sstate-cache on slow server. From what I see I guess it finds URL with correct prefix sstate-cache/Gentoo-2.1/0d and downloads it directly to sstate-cache dir (and adds .done) OE @ ~/oe-core $ ll sstate-cache/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-*populate-lic* -rw-r--r-- 1 bitbake bitbake 9257 Jul 30 12:31 sstate-cache/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-0d2ed24b90d50bf83e5fe94536596e50_populate-lic.tgz -rw-r--r-- 1 bitbake bitbake0 Aug 2 15:40 sstate-cache/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-0d2ed24b90d50bf83e5fe94536596e50_populate-lic.tgz.done And then creates symlink in right prefix back to absolute path of sstate-cache/file: OE @ ~/oe-core $ ll sstate-cache/Gentoo-2.1/0d/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-*populate-lic* lrwxrwxrwx 1 bitbake bitbake 123 Aug 2 15:40 sstate-cache/Gentoo-2.1/0d/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-0d2ed24b90d50bf83e5fe94536596e50_populate-lic.tgz - /OE/oe-core/sstate-cache/sstate-apr-native-x86_64-linux-1.4.6-r1-x86_64-2-0d2ed24b90d50bf83e5fe94536596e50_populate-lic.tgz But after sstate-cache directory is rsynced somewhere else and oe-core/sstate-cache is removed, all those symlinks point nowhere and public sstate-cache is unusable. Can we have relative paths used in symlinks or even instruct fetcher to download that file directly to right prefix? 2 more ideas: 1) would be great to also download file.sigdata if it exists, to be able to compare them when they change even on machine which downloaded older sstate file from remote url 2) if the reason for this patch was number of files in shared sstate-cache directory, then fetcher creating .done files makes number double too (would be fine if fetcher stores all 3 files (.tgz, .tgz.sigdata, .tgz.done) in right prefix, or moves them to right prefix instead of symlinks. I'm aware of the problem. The main issue is that we probably need to start enforcing complete paths for all downloads in DL_DIR, including http:// urls. This would resolve conflicts like: SRC_URI = http://server1.org/somefile.patch \ http://server2.org/somefile.patch; where the two files are different. The trouble is it will pretty much break all the source mirrors :(. I think we need to stop the tendency to use DL_DIR as is as a mirror, and instead create a task or something to populate a mirror directory from the DL_DIR. This would avoid potential issues with licensing if it uses license filtering to control what gets populated, as well. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH V2 6/7] blacklist.bbclass: Move to meta-angstrom
On Tue, Jul 31, 2012 at 12:07 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 31-07-12 20:56, Khem Raj schreef: This class is angstrom specific so lets move it to more appropriate layer Ehm, it was put in meta-oe on request so other distros could use it. A version of this with a different control interface is already in oe-core. See oe-core/meta/classes/blacklist.bbclass. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe] [PATCH 2/2] nano: rreplaces/rconflicts nano-tiny
On Thu, Jun 28, 2012 at 5:10 PM, Khem Raj raj.k...@gmail.com wrote:
On Thu, Jun 28, 2012 at 11:18 AM, Christopher Larson kerg...@gmail.com
wrote:
Signed-off-by: Christopher Larson kerg...@gmail.com
---
meta-oe/recipes-support/nano/nano.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-support/nano/nano.inc
b/meta-oe/recipes-support/nano/nano.inc
index 2d52cab..9e9cc62 100644
--- a/meta-oe/recipes-support/nano/nano.inc
+++ b/meta-oe/recipes-support/nano/nano.inc
@@ -7,8 +7,10 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949
SECTION = console/utils
DEPENDS = ncurses
RDEPENDS_${PN} = ncurses-terminfo
+RREPLACES_${PN} += nano-tiny
+RCONFLICTS_${PN} += nano-tiny
-INC_PR = r2
+INC_PR = r3
I was wondering if tinyness of nano can be turned into a PACKAGECONFIG ?
Good point, could do it that way too. Hmm.
--
Christopher Larson
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Python exception running step do_package_update_index_ipk in OE classic
On Thu, May 17, 2012 at 12:58 AM, Martin Jansa martin.ja...@gmail.com wrote: On Thu, May 17, 2012 at 07:34:24AM +, Craig McQueen wrote: I'm trying to build OE classic for i.MX28, following instructions at: http://www.imxdev.org/wiki/index.php?title=All_Boards_OpenEmbedded I'm trying to run: bitbake bootstrap-image It is failing on a step do_package_update_index_ipk when calling Python program opkg-make-index. See error below. The problem is when it calls subprocess.check_output(), but check_output() is only in Python 2.7, but not Python 2.6. On my machine, Python 2.7 is installed, however it seems that OE must be running Python 2.6. I see that OE builds Python 2.6 in tmp/work/i686-linux/python-native-2.6.6-ml12.0. What would be a good way to fix this? send patch against http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/ to yocto ML to make it compatible with both python 2.6 and 2.7 In oe-core, we pulled check_output() and CalledProcessException() out of 2.7 into the lib/oe tree for local use. You could do that in opkg-utils too if licensing isn't an issue. It's a relatively small amount of code. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Provide a master/setup layer - best practice?
On Wed, May 9, 2012 at 9:58 PM, Khem Raj raj.k...@gmail.com wrote: On Wed, May 9, 2012 at 1:13 PM, Radoslav Kolev rados...@kolev.info wrote: It seems like there's some reinventing the wheel going on. What would be your advice for the best approach and starting point in this situation? If there was one 'best' option for any given situation, we wouldn't have this much so-called wheel reinvention. People have different needs. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] COMPATIBLE_MACHINE
On Fri, Apr 20, 2012 at 6:20 AM, Gary Thomas g...@mlbassoc.com wrote: I'm writing a .bbappend for a recipe which contains a COMPATIBLE_MACHINE pattern like this: COMPATIBLE_MACHINE = (machine1|machine2|machine3) Is there a way my .bbappend file can add to this pattern? I don't want to disturb what's there, just add my machine as well. It's just a standard regular expression. COMPATIBLE_MACHINE = (machine1|machine2|machine3) COMPATIBLE_MACHINE .= |machine4 Will result in a value of (machine1|machine2|machine3)|machine4, which is still a perfectly valid pattern, as far as I can tell. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] COMPATIBLE_MACHINE
On Fri, Apr 20, 2012 at 7:15 AM, Gary Thomas g...@mlbassoc.com wrote: On 2012-04-20 08:04, Chris Larson wrote: On Fri, Apr 20, 2012 at 6:20 AM, Gary Thomasg...@mlbassoc.com wrote: I'm writing a .bbappend for a recipe which contains a COMPATIBLE_MACHINE pattern like this: COMPATIBLE_MACHINE = (machine1|machine2|machine3) Is there a way my .bbappend file can add to this pattern? I don't want to disturb what's there, just add my machine as well. It's just a standard regular expression. COMPATIBLE_MACHINE = (machine1|machine2|machine3) COMPATIBLE_MACHINE .= |machine4 Will result in a value of (machine1|machine2|machine3)|machine4, which is still a perfectly valid pattern, as far as I can tell. Yes, this does seem to work. Any clues why most uses of COMPATIBLE_MACHINE use the regex (x|y|z) instead of just x|y|z? Aren't they the same? They are. No idea why people use the grouping. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] build meta-oe without systemd
On Fri, Apr 6, 2012 at 12:12 AM, Eric Bénard e...@eukrea.com wrote:
Le Thu, 05 Apr 2012 16:50:32 -0700,
Koen Kooi k...@dominion.thruhere.net a écrit :
I would appreciate people sending decent bugreports to the list, because it
is *NOT* supposed to break this way. The breakage needs to get fixed before
we merge it into oe-core.
to reproduce the problem I met, simply add to a conf file :
PREFERRED_VERSION_udev = 164
and using oe-core + meta-oe try to build anything which has inherit
systemd (even if in the end you don't install the corresponding
${PN}-systemd in the target's rootfs) : systemd's configure will fail
because it requires a more recent udev.
In addition, for me, at least in the past, I hit an issue where
systemd sucks in x11 bits, which means any DISTRO lacking the 'x11'
distro feature fails miserably at even building busybox.
--
Christopher Larson
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] build meta-oe without systemd
On Wed, Apr 4, 2012 at 10:55 AM, Koen Kooi k...@dominion.thruhere.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 04-04-12 00:17, Eric Bénard schreef: Hi, would that make sense to support systemd as a DISTRO_FEATURES ? That would make builds using older udev ( 174) possible with meta-oe as this actually fails because of systemd. We talked about this during the yocto bsp summit this week and I'm working on a patchset to send as RFC later this month (post 1.2 release): commit b98d45b1bc2d9cf9ba41629240e6c21f19ddceff Author: Koen Kooi k...@dominion.thruhere.net Date: Tue Apr 3 14:13:59 2012 -0700 meta-systemd: move over systemd from meta-oe Signed-off-by: Koen Kooi k...@dominion.thruhere.net commit 59c57bd73d1f157dfada233df889852fdb4a692f Author: Koen Kooi k...@dominion.thruhere.net Date: Tue Apr 3 14:12:42 2012 -0700 meta-systemd: create layer Signed-off-by: Koen Kooi k...@dominion.thruhere.net Woot! We can stop using BBMASK to exclude bbappends from meta-oe when this happens :) -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] build meta-oe without systemd
On Wed, Apr 4, 2012 at 12:09 PM, Denys Dmytriyenko de...@denix.org wrote: On Wed, Apr 04, 2012 at 11:59:38AM -0700, Chris Larson wrote: On Wed, Apr 4, 2012 at 10:55 AM, Koen Kooi k...@dominion.thruhere.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 04-04-12 00:17, Eric B??nard schreef: Hi, would that make sense to support systemd as a DISTRO_FEATURES ? That would make builds using older udev ( 174) possible with meta-oe as this actually fails because of systemd. We talked about this during the yocto bsp summit this week and I'm working on a patchset to send as RFC later this month (post 1.2 release): commit b98d45b1bc2d9cf9ba41629240e6c21f19ddceff Author: Koen Kooi k...@dominion.thruhere.net Date: Tue Apr 3 14:13:59 2012 -0700 meta-systemd: move over systemd from meta-oe Signed-off-by: Koen Kooi k...@dominion.thruhere.net commit 59c57bd73d1f157dfada233df889852fdb4a692f Author: Koen Kooi k...@dominion.thruhere.net Date: Tue Apr 3 14:12:42 2012 -0700 meta-systemd: create layer Signed-off-by: Koen Kooi k...@dominion.thruhere.net Woot! We can stop using BBMASK to exclude bbappends from meta-oe when this happens :) You should have been at the BSP Summit, especially as it was hosted at Mentor. :) That was one of the important decisions made, but this topic in particular was being discussed for a while... So, I second your Woot! :) Yeah, I wanted to make it, but unfortunately wasn't able to. Will probably be there next time around. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] CONFIG_SITE usage
On Tue, Feb 21, 2012 at 3:48 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: I'm in trouble trying to set CONFIG_SITE to allow my build process to load cache from a given file. I've understood CONFIG_SITE can be set from .bb file, but I'm wondering if it could be set on local.conf or distro/machine conf file to be inherited by all packages. CONFIG_SITE is automatically set for all autotools recipes. Read siteinfo.bbclass and autotools.bbclass. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] CONFIG_SITE usage
On Tue, Feb 21, 2012 at 2:15 PM, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: Il giorno martedì 21 febbraio 2012, Chris Larson ha scritto: On Tue, Feb 21, 2012 at 3:48 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com javascript:; wrote: I'm in trouble trying to set CONFIG_SITE to allow my build process to load cache from a given file. I've understood CONFIG_SITE can be set from .bb file, but I'm wondering if it could be set on local.conf or distro/machine conf file to be inherited by all packages. CONFIG_SITE is automatically set for all autotools recipes. Read siteinfo.bbclass and autotools.bbclass. Yes I know this but I'm wondering how I can overwrite the CONFIG_SITE default setting (made by autotools) for all packages in one single shot. I mean, I think that exporting CONFIG_SITE = my *.site files on one of the .conf files I can say to the system to read those instead of the ones set as default by autotools. CONFIG_SITE is set by a class, which means it overrides the config metadata (e.g. local.conf). You could either set it in the recipes, or set it in the config metadata using an appropriate override (see OVERRIDES). -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] checkroot.sh and fsck the root partition
On 2/15/12, Holger Freyther holger...@freyther.de wrote: I know most of use ubifs/jffs2 but I have one device with a ext3/ext4 partition and would like to run fsck as part of the boot (with auto fix up). Besides installing the e2fs fsck, fixing the fstab fsck will not be executed. E.g. if I take a look at this script: http://git.openembedded.org/openembedded-core/tree/meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh it is not clear how 'rootcheck' could ever be 'yes'. My guess, and it is a guess (though potentially comparing against the original debian initscripts we started with, or looking through git history, may be informative) is that the original default value of rootcheck was yes, and hence the conditional in the loop setting rootcheck=no made sense, but it was changed at some point in the history due to the use of non-checkable filesystems. If we change the default back, we'll break everyone using the stock fstab or one based on it, as the default sets pass=1 for the 'rootfs' mount. One option would be to source /etc/default/rcS after the definition of the defaults prior to the loop, thereby allowing a per machine rcS which changes the default value. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] #oe topic
On Mon, Jan 16, 2012 at 1:34 AM, Marcin Juszkiewicz mar...@juszkiewicz.com.pl wrote: W dniu 14.01.2012 16:35, Frans Meulenbroeks pisze: Ping. Almost a week ago. No one with rights to change the topic ??? Current #oe access list: 1 kergoth +votsriRfAF [modified ? ago] 2 apt +votiA [modified ? ago] 3 mickey|zzZZzz +votriA [modified 3 years, 30 weeks, 1 day, 16:10:28 ago] 4 *!*@www.xora.org.uk +votriA [modified 1 year, 42 weeks, 4 days, 15:25:50 ago] Fixed, sorry about the delay. Let me know if anyone wants/needs access to the channel, I can adjust the chanserv permissions, or if the current topic isn't ideal. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] oe-core license description practices
On Sun, Jan 15, 2012 at 8:15 AM, Peter Bigot big...@acm.org wrote: http://www.openembedded.org/wiki/OpenEmbedded-Core states that the LICENSE field should be as correct as possible (e.g. 'GPLv2', not just 'GPL'). If the upstream package self-describes as GPL, is it necessary that this be refined to a more specific version? Generally they may say they're GPL, but are actually GPLv2+ or similar. Read the actual license text included in the source tree, and the headers of the files. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] BlueZ old releases have new checksums
On Wed, Jan 4, 2012 at 11:14 AM, Denys Dmytriyenko de...@denix.org wrote: The main archive of BlueZ/obexd/hcidump releases on kernel.org[1] finally re-appeared after missing for long time since kernel.org compromise. Unfortunately, all previous tarballs have new checksums, breaking builds for anyone w/o previous copy cached. Old copies were also extensively mirrored, so you never know which one you fetch next time... Heh, checksums changing after a security compromise, that's worrisome :) should diff their contents to see what's going on, or whether its just a gzip timestamp change or something. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [OE] Python2.7.2 compatibility
On Wed, Dec 28, 2011 at 9:57 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: ERROR: There is a comment on line 24 of file /home/condorg/work/openembedded/recipes/ekiga/ekiga_git.bb (# --enable-static-libs \) which is in the middle of a multiline expression. Bitbake used to ignore these but no longer does so, please fix your metadata as errors are likely as a result of this change. Did you not actually read the error message? It's bitbake erroring out, and right here it's explaining why, and that it's an issue with this metadata with the new bitbake. Fix the metadata, or use an older bitbake. -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] packages versioning
On Thu, Dec 8, 2011 at 7:57 PM, Mr Dash Four mr.dash.f...@googlemail.com wrote: Is there a way I could force/select a particular version of a specific package in a given target? I am building my fso-console-image and I would like it to use udev-165 instead of udev-162, but I can't find a way to alter this. I could build udev-165 separately - no problem, but don't know how to integrate this into the main task of building the image itself. PREFERRED_VERSION_udev = 165 Also, is there a way I can include additional packages as part of that fso-console-image build? I'd like to have openvpn, a different version of wpa_supplicant, openssl etc. IMAGE_INSTALL_append = openvpn -- Christopher Larson ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [[RFC] 0/4] license.bbclass: License Manifest Stage 1
On Sat, Dec 3, 2011 at 8:42 PM, Beth Flanagan
elizabeth.flana...@intel.com wrote:
Please see commit messages for full description:
This RFC includes:
- License manifest implementation in preparation for SPDX manifests.
- fixes to how licenses are collected. We now can support accurate licenses
during a parallel bitbake.
- optional addition of license manifest to the generated image.
- optional addition of full common-license directory to the generated image.
- additional licenses, more SPDX mappings.
- ability to add custom license directories instead of adding license files
to common-licenses.
- some recipe fixes to fix LICENSE fields.
- removal of license functionality of base-files as it's now redundant.
These patches require the included commits by Paul Eggleton in order to
function. Specifically, it requires list_installed_packages in rootfs_*.
Please note. License manifest does not work with .deb packaging yet. When
list_installed_packages is working in rootfs_deb, I'll patch include deb.
The following changes since commit 9be6d59b78510443d0944513503d515df13caa45:
dpkg-native: Fix perl path (2011-12-02 15:31:08 +)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib eflanagan/license_m1
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=eflanagan/license_m1
Nice work on all of this :) Small nits:
- 74efa4d: you revert the bb.data.getVar - d.getVar change to busybox.inc.
- e1a3bfe: license_create_manifest uses a combination of space and tab
indentation. please pick one :)
- e1a3bfe: license_create_manifest uses a more complex pipeline with
more execs of sed than is necessary. This will do it:
pkged_pn=$(sed -n 's/^PN: //p' ${filename})
pkged_lic=$(sed -n '/^LICENSE: /{ s/^LICENSE: //; s/[+|()*]/ /g;
s/ */ /g; p }' ${filename})
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OE-core based java layer?
On Thu, Dec 1, 2011 at 2:25 AM, Koen Kooi k...@dominion.thruhere.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 01-12-11 09:08, Stefan Schmidt schreef: Hello. On Wed, 2011-11-30 at 20:22, Koen Kooi wrote: Beagleboard.org has moved to the OE-core metaverse to build the factory images and we need java support to stay feature compatible with OE classic. Are there already people working on such a thing or should I just go ahead and add a meta-java to the meta-oe repo and start importing recipes one-by-one? Henning already did it. https://github.com/woglinde/meta-java/ I was able to build openjdk-6 from it. I've found a common theme for this week: It works if you follow the README, but noone actually reads a README :) That's one of the nice things about github -- if they go to the web page, it's right there in their face :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [RFC] Documentation problems and future plans
On Sun, Nov 27, 2011 at 2:58 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Am Samstag, den 26.11.2011, 19:40 -0700 schrieb Tom Rini: As things stand today, the wiki is out of date and a number of folks refuse to work on it. Using things like It's all text! for firefox only go so far and don't solve problems like people just avoiding documentation anyhow. the Special Pages page [1] has interesting information. For example you can get an overview of the recent changes in the Wiki [2]. Paul Menzel has mentioned that ikiwiki has been mentioned before and that lets us have the website in a repository. Do folks have other ideas? Before the implementation is discussed, could we decide what documentation we need and what is possible to maintain in the long run? Avoiding maintenance and duplicate efforts should be the objective. This is a very good idea. 1. User manual 2. FAQ 3. README 4. Guidelines (Commit, patch, style) 5. Getting started document (could be included in 1.) 6. Git usage (a lot of existing documentation for that one elsewhere) or can be put in a file `HACKING`. This is a good idea. I think we should extend this beyond just git command info and references to existing git documentation, by adding actual snippets of shell showing what to do to accomplish several common development tasks -- example workflows. 7. … 7. Troubleshooting Guide 8. Tips Tricks - these could be more advanced and unusual things which aren't suitable for an FAQ, but which nonetheless can be quite helpful if you're in particular situations. Formatted in a markup language like Markdown those could be converted to HTML easily. Agreed, Markdown or RST would lovely. The second question is, is OE-core documented in the OE wiki or for example at the Yocto project? To get users started we could also recommend to use the Ȧngström scripts or to take a look at the Yocto project, i. e. just point to distributions being well documented. They have a Wiki already [3] and we could decide to use that instead. Or we could say to use use the Wiki at eLinux.org [4]. -- Christopher Larson clarson at kergoth dot com Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Documentation problems
On Sun, Nov 27, 2011 at 7:29 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Saturday 26 November 2011 19:40:48 Tom Rini wrote: As things stand today, the wiki is out of date and a number of folks refuse to work on it. The question is why do they refuse to work on it? And would throwing out our current wiki and setting up something completely new and different actually solve the issue? I suspect the problem is more that people feel they can't make time for writing documentation or simply aren't interested. Personally, I'm quite interested in helping to improve the documentation, but the wiki has degraded to the point where I wouldn't even know where to begin. -- Christopher Larson clarson at kergoth dot com Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Understanding recipes vs packages
On Mon, Nov 7, 2011 at 3:34 PM, Charles Manning cdhmann...@gmail.com wrote:
On Mon, Nov 7, 2011 at 6:15 PM, Xu, Dongxiao dongxiao...@intel.com wrote:
Hi Charles,
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
Charles Manning
Sent: Monday, November 07, 2011 11:32 AM
To: openembedded-devel@lists.openembedded.org
Subject: [oe] Understanding recipes vs packages
Hello
Something very weird is going on with some changes I have made recently to a
custom image I am building.
For some reason I was getting libpng12 built and now that no longer happens.
In debugging this I've been doing things that now stump me.
From my understanding, a recipe can build multiple different packages.
For example libpng.inc has the following in it:
Yes, it is correct.
PACKAGES =+ ${PN}12-dbg ${PN}12 ${PN}12-dev
FILES_${PN}12-dbg += ${libdir}/libpng12*.dbg
FILES_${PN}12 = ${libdir}/libpng12.so.*
FILES_${PN}12-dev = ${libdir}/libpng12.* ${includedir}/libpng12
${libdir}/pkgconfig/libpng12.pc
FILES_${PN} = ${libdir}/lib*.so.*
FILES_${PN}-dev = ${includedir} ${libdir}/lib*.so ${libdir}/*.la \
${libdir}/*.a ${libdir}/pkgconfig \
${datadir}/aclocal ${bindir} ${sbindir}
Does that mean I should be able to build libgpng12 as follows:
bitbake libpng12
No, package name could not be passed to bitbake as a parameter.
Bitbake can accept a recipe name as its parameter, and it will process tasks
like do_fetch, do_unpack, ..., do_package, etc. for that recipe. In
the above case, libpng12 will be generated in do_package task, and then it
will be archived into rpm/ipk/deb package formats.
Try to run bitbake libpng and see if libpng12 is generated.
Yes it is.
OK thanks for the clarification
So if I want to put the libpng12 in an image then do I need to do
something like:
# Add libpng to DEPENDS to get the recipe to build
# Add libpng12 to IMAGE_INSTALL because that's what I want in the package
DEPENDS += libpng
IMAGE_INSTALL += libpng12
No. Bitbake knows about both build time and runtime dependencies.
IMAGE_INSTALL's contents are automatically added to the runtime
dependencies of the image recipe, and bitbake will build the recipes
which provide those packages, so all you need is the IMAGE_INSTALL.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] running bb located path info
On Thu, Nov 3, 2011 at 2:06 PM, mgundes mg...@hotmail.com wrote: I need to know is there a variable assigned with running current bb file path? One of freenode #oe friend told me to try THISDIR but It did not work for me. By the way, I use openembedded classic. The 'FILE' variable holds the current file's full path. FILE_DIRNAME is the directory it's in. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] git server move
On Wed, Oct 12, 2011 at 8:22 AM, Khem Raj raj.k...@gmail.com wrote: On Wed, Oct 12, 2011 at 8:18 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven: On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi k...@dominion.thruhere.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 11-10-11 21:11, Cliff Brake schreef: Hi, we are moving git.openembedded.org to a new server. SSH access on the old server has been disabled. git:// still works there. As soon as DNS propagates, SSH access will work with the new server. Let me know if you see any problems. When will cgit be back up? It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org Let me rephrase: when will it be working again? I still get No repositories found when clicking on a repo. Weird I see all the repos fine. Works here too. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Creating Rootfs images without packages
On Wed, Oct 12, 2011 at 5:34 AM, Gary Thomas g...@mlbassoc.com wrote: On 2011-10-12 06:22, mgundes wrote: Hi, I think one of the big issue with OE is build time. It does everything for you, so that it takes too much times. I want to minimize build time and realized that OE creates ipkgs for almost every package. If there is a way Not true. Only the packages needed to complete your image will be built. This isn't the case, of course. Only the *recipes* needed to complete your image will be built, but all of the packages for those recipes are constructed, whether they'll eventually be used or not. Of course, not saying that's a problem, just clarifying for mgundes. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] psyco-dist not supported on 64 bit Linux - What to do?
On Mon, Oct 10, 2011 at 2:29 PM, Ulf Samuelsson ulf_samuels...@telia.com wrote: psyco-dist will not run on a 64 bit linux. The guys behind psyco-dist recommends the use of PyPy What is the recommendation for 64 bit linux? Just run without JIT? Don't run on a 64 bit linux? Anything else? Python works fine as is. You're welcome to attempt use of pypy, but last time I tried there were a couple hiccups and the performance benefit wasn't particularly substantial. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] How do we get programs into sysroots?
On Sun, Aug 28, 2011 at 1:07 PM, Joel A Fernandes agnel.j...@gmail.com wrote:
DESCRIPTION = A tool to format SD Cards correctly
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=393a5ca445f6965873eca0259a17f833
SECTION = base
SRC_URI = file://mkcard.txt \
file://COPYING.patch
PR = r3
do_configure() {
install -m 0644 ${WORKDIR}/mkcard.txt ${S}/
}
do_install() {
install -d ${D}${base_sbindir}
install -m 0755 ${S}/mkcard.txt ${D}${base_sbindir}/mkcard
}
BBCLASSEXTEND = native
---
Everything works fine, but I don't see 'mkcard' in /sbin in sysroots
directory. I'd like to install it there. I tried looking at other
scripts to see the right way to do it but I'm not sure of a clean way
to do so. I looked at the staging.bbclass and it seems to only pickup
libs and headers.
When using a custom do_install, with BBCLASSEXTEND, afaik you need to
set NATIVE_INSTALL_WORKS = 1 to get its files into the sysroot for
the native version.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe] need to add some verfication package recipes
On Mon, Aug 22, 2011 at 12:57 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 22-08-11 11:03, Paul Menzel schreef: It would be nice if the oe-core folks can comment too in case these recipes should go into oe-core some day. OE-core needs to get smaller, not bigger. Regarding where recipes go, am I the only one that finds the recipes-*/ directories just annoying for day to day use? The breakdown might make sense from a categorical viewpoint, but as someone looking to modify a recipe, it's a crapshoot trying to find anything. I resort to shell globbing or find commands, every time. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Issue of OE with Ubuntu 11.04
On Tue, Aug 16, 2011 at 5:41 AM, Rizwan Shaik rizwanco...@gmail.com wrote: I was trying to build the OE desktop image for the PXA300 board in Ubuntu 11.04 and was facing the error of not able to compile the package guile-native-1.8.5.bb Except the above error all the other packages were build. I have mailed the same error to OE developer list and was not able to get any solution. So, I tried the same build or one can say continued the build in Ubuntu 10.10 and was able to sucessfully build the package guile-native-1.8.5.bb. I think you'll need to provide more information than this, like the exact log message from your guile-native failure, as I and others do builds on 11.04 every day. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] understanding overlays
On Wed, Jul 27, 2011 at 7:24 AM, Steffen Sledz sl...@dresearch-fe.de wrote: I'm not really familiar with the oe/bitbake overlay details. So please forgive me if this is a faq. ;-) Is the overlay package or file based? Or in other words is the following scenario possible? base layer: recipes/ foo/ foo.inc foo_x.y.z.bb overlay: recipes/ foo/ foo.inc And than build foo-x.y.z with the foo.inc from the overlay. That depends. If the .bb does 'require foo.inc', then no, it will use the local one. If it does 'require recipes/foo/foo.inc', then yes, it will use the overlay one, assuming the overlay is before the main layer in your BBLAYERS. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] preferred version not available
On Tue, Jul 19, 2011 at 12:20 AM, Detlef Vollmann d...@vollmann.ch wrote: On 07/18/11 23:05, Chris Larson wrote: On Mon, Jul 18, 2011 at 2:02 PM, Detlef Vollmannd...@vollmann.ch wrote: Ok, I found the problem: PREFERRED_VERSION refers to PV inside the recipe, not to the part of the filename after '_'. As I tinker with PV inside the recipe, bitbake is actually correct that a PV 'githead' is not available for linux-taurus. All variables which are typically set by the filename can be overridden. Those are simply defaults. See the definitions of PN, PV, and PR in bitbake.conf. Yes, I knew that (I actually wrote the line changing the PV myself). What surprised me (though it makes sense) that PREFERRED_VERSION refers to PV, and not directly to a part of the filename. I'm not sure why that would be surprising. PN, PV, and PR are what are used. The fact that they default to being based on the filename is just an artifact of how oe does things. You could quite easily change that, and make it required to set them all in the recipe. Bitbake does *not* care about the filename, other than in determining what bbappend to apply to the recipe when an append exists. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] preferred version not available
On Mon, Jul 18, 2011 at 2:02 PM, Detlef Vollmann d...@vollmann.ch wrote: On 07/18/11 21:16, Detlef Vollmann wrote: NOTE: preferred version githead of linux-taurus not available (for item linux-taurus) What really drives me nuts is the last line: it clearly parsed linux-taurus_githead.bb before, doesn't give me any error on it, but then tells me 'preferred version githead of linux-taurus not available'. It's clearly there, so why is it not available? Ok, I found the problem: PREFERRED_VERSION refers to PV inside the recipe, not to the part of the filename after '_'. As I tinker with PV inside the recipe, bitbake is actually correct that a PV 'githead' is not available for linux-taurus. All variables which are typically set by the filename can be overridden. Those are simply defaults. See the definitions of PN, PV, and PR in bitbake.conf. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Remove SHELL from preserved_envvars_exported?
On Mon, Jun 27, 2011 at 6:58 AM, Phil Blundell ph...@gnu.org wrote: One of my colleagues pointed out to me just now that $SHELL is, somewhat surprisingly, passed through to bitbake subprocesses from the calling environment. Under most circumstances this would be fairly benign since few things actually care about that variable, but it turns out that: a) flock(1) has the misfeature of using $SHELL rather than /bin/sh if the former is set in the environment (in contrast to system(3), which always uses /bin/sh); and b) zsh has the misfeature of always reading ~/.zshenv even if it was invoked as zsh -c So the net result of all this is that, if you are using zsh as your interactive shell, the contents of your .zshenv end up in the environment for everything that's run under flock and bad results can potentially ensue. In our particular case my colleague was setting $PATH from his .zshenv with predictably unfortunate consequences. It isn't very obvious to me that having SHELL whitelisted is sensible for anything except interactive tasks. Does anybody know of a reason why it needs to be included everywhere? I don't know why it is the way it is right now, but I want to jump in here and say that as another zsh user, this has bitten me multiple times before as well. I actually have SHELL overridden in my ~/.oe/conf/site.conf to work around it for now. I agree that it should probably not be exported other than for interactive tasks, for what it's worth. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] initscripts: don't background volatile creation
From: Chris Larson chris_lar...@mentor.com
This fix is courtesy Chris Hallinan. There is/can be assumptions made in
the volatiles file that they're processed in order (e.g. directory
created, then files within that directory), yet the script processes
them in parallel, backgrounding the operations. This is racy, and means
it's possible to end up with dependent files/dirs not created before the
bits that need them.
It's likely that this will have a performance impact, but I haven't
benchmarked it. Better that we behave correctly than quickly. We can
look back into improving the speed of this, without breaking
dependencies, in the future.
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
.../initscripts-1.0/populate-volatile.sh | 12 ++--
recipes/initscripts/initscripts_1.0.bb |2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/recipes/initscripts/initscripts-1.0/populate-volatile.sh
b/recipes/initscripts/initscripts-1.0/populate-volatile.sh
index f0a45ea..d9ec1b7 100755
--- a/recipes/initscripts/initscripts-1.0/populate-volatile.sh
+++ b/recipes/initscripts/initscripts-1.0/populate-volatile.sh
@@ -19,7 +19,7 @@ create_file() {
[ -e $1 ] {
[ ${VERBOSE} != no ] echo Target already exists. Skipping.
} || {
- eval $EXEC
+ eval $EXEC
}
}
@@ -34,7 +34,7 @@ mk_dir() {
[ -e $1 ] {
[ ${VERBOSE} != no ] echo Target already exists. Skipping.
} || {
- eval $EXEC
+ eval $EXEC
}
}
@@ -46,7 +46,7 @@ link_file() {
[ -e $2 ] {
echo Cannot create link over existing -${TNAME}-. 2
} || {
- eval $EXEC
+ eval $EXEC
}
}
@@ -123,7 +123,7 @@ apply_cfgfile() {
TSOURCE=$TLTARGET
[ -L ${TNAME} ] || {
[ ${VERBOSE} != no ] echo Creating link -${TNAME}- pointing to
-${TSOURCE}-.
-link_file ${TSOURCE} ${TNAME}
+link_file ${TSOURCE} ${TNAME}
}
continue
}
@@ -142,10 +142,10 @@ apply_cfgfile() {
case ${TTYPE} in
f) [ ${VERBOSE} != no ] echo Creating file -${TNAME}-.
-create_file ${TNAME}
+create_file ${TNAME}
;;
d) [ ${VERBOSE} != no ] echo Creating directory -${TNAME}-.
-mk_dir ${TNAME}
+mk_dir ${TNAME}
# Add check to see if there's an entry in fstab to mount.
;;
*)[ ${VERBOSE} != no ] echo Invalid type -${TTYPE}-.
diff --git a/recipes/initscripts/initscripts_1.0.bb
b/recipes/initscripts/initscripts_1.0.bb
index 87a0e99..adf8594 100644
--- a/recipes/initscripts/initscripts_1.0.bb
+++ b/recipes/initscripts/initscripts_1.0.bb
@@ -4,7 +4,7 @@ PRIORITY = required
DEPENDS = makedevs
RDEPENDS_${PN} = makedevs
LICENSE = GPL
-PR = r128
+PR = r129
SRC_URI = file://functions \
file://halt \
--
1.7.5.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Packaging from devshell
On Fri, Jun 24, 2011 at 2:40 PM, Joel A Fernandes agnel.j...@gmail.com wrote:
I use devshell for compiling by running a bitbake generated do_compile shell
script in work/ for my package, this helps me develop faster as I can skip
over parsing and other repetitive stages.
However I'm not able to do the same with do_package_write, as the shell
script for the same appears to have an empty function:
do_package_write() {
:
}
Could anyone suggest which script should I execute to package from
devshell?
Nearly all of the packaging process is done from python code, not shell.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] base.bbclass: Why is `oe_runmake install` not the default for `do_install()`?
On Wed, Jun 1, 2011 at 5:29 PM, Tom Rini tom_r...@mentor.com wrote:
There's not a common enough way to make sure it tries to write to ${D}
when we don't know what the build system is, other than someones Makefile.
Yeah, like Tom says -- with autoconf, we know we can use DESTDIR, but
there's no standard mechanism for custom make-based buildsystems, and
some don't have such a variable at all (until we patch them in).
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] oe-core and mercurial
On Tue, May 31, 2011 at 6:33 AM, Chris Elston cels...@katalix.com wrote: So the question is, does the OEandYourDistro page need updating for oe-core? In which case, where do I request a wiki account to do so? Or alternatively, should oe-core include the mercurial-native recipe to cover this case? Discuss :-) I would think oe-core should contain the recipe and use it as appropriate when hg:// is in SRC_URI, personally. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] oe-core and mercurial
On Tue, May 31, 2011 at 10:04 AM, Khem Raj raj.k...@gmail.com wrote: Or alternatively, should oe-core include the mercurial-native recipe to cover this case? Discuss :-) Well it can but usually OE does not need a captive version of mercurial so it can use the one installed on the build machine. Which is what ASSUME_PROVIDED is for.. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] RFC: Remove -e from default EXTRA_OEMAKE
On Mon, May 23, 2011 at 2:26 PM, Stanislav Brabec u...@penguin.cz wrote: EXTRA_OEMAKE contains -e by default for years (in bitbake.conf). In my opinion it causes more bad than good. It makes live simpler in (rare) cases when Makefile proposes its own default CFLAGS without chance to easily change them from outside, but it causes subtle (and often overseen) breakages in many other cases. For example -e in EXTRA_OEMAKE caused breakage of crda (tested with GNU make 3.82): ifeq ($(USE_OPENSSL),1) CFLAGS += -DUSE_OPENSSL endif As you can check, there are several hundreds of recipes that need to override this default. Also autotools.bbclass, distutils-common-base.bbclass, qmake_base.bbclass and kernel.bbclass remove -e from default make flags. It means that at least 6000 recipes remove -e from EXTRA_OEMAKE. That is why I think that -e should not be a default. If needed, it would be easy to add it for particular recipes. I have to agree, here. The biggest problem, I think, in addition to the above breakage, is that it's too much magic. It's too implicit. It might simplify recipe creation in some cases, but that isn't necessarily a good thing. If you're creating a recipe for a non-autotools thing, you need to sit down and read its makefiles. Hoping and crossing your fingers that the default behavior will work is just asking for trouble. It would be better for things to not just work for regular make and make the user read the makefiles and pass the vars explicitly in EXTRA_OEMAKE, which thereby increases their knowledge of the system, and encodes more of that knowledge in the recipe for future maintenance. It took me a heck of a lot of trial and error to come up with the -e MAKEFLAGS='' hack to make sure the -e only took effect at the toplevel make -- more trouble than its worth. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] OE Changelog for 2011-4-8 to 2011-4-15
On Thu, May 19, 2011 at 11:43 AM, Cliff Brake cliff.br...@gmail.com wrote: Are there any other repos or maillists that I should include in this report? I'm trying to increase visibility in what all the projects are doing, so we can reduce duplication of work in various layers. There's a meta-slugos now, and pb is hosting a meta-micro. Those are all that come to mind off the top of my head. Not sure how much you want to include :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCHv3 1/3] conf/layer.conf: Use .= for BBPATH and += for BBFILES
On Mon, May 9, 2011 at 8:05 AM, Phil Blundell ph...@gnu.org wrote: On Mon, 2011-05-09 at 07:48 -0700, raj.k...@gmail.com wrote: From: Khem Raj raj.k...@gmail.com Provide additional commentary that should help a bit more I'm still struggling slightly to understand why this patch is an improvement. As far as I can tell: - the change from prepending to appending BBPATH will alter all the priorities of the layers. It isn't entirely obvious to me if (or why) this is a good thing; and - the change to the way that BBFILES is assigned doesn't make any functional difference. Is that just a cosmetic change? Also: +# It really depends on order of the layers appearing in BBLAYERS +# variable in toplevel bblayers.conf file, where bitbake will search +# for .inc files and others where bitbake uses BBPATH since it will +# search the directories from first to last as specified in BBPATH +# Therefore if you want a given layer to be considered high priority +# for the .inc and .conf etc. then consider it adding at the beginning +# of BBPATH. For bblayers bitbake will use BBFILES_PRIORITY to resolve +# the recipe contention so the order of directories in BBFILES does +# not matter. Maybe it's just my lack of familiarity with the code, but I find this comment rather difficult to parse. Even after reading it a few times I'm not totally sure that I've grasped what the first sentence is saying. The layer.conf files are parsed in the order of the layers in BBLAYERS, and the resulting BBPATH will be based upon that and whether the layer.conf files appended or prepended to it. Recipe priority, however, is governed by the BBFILE_ variables in the layer. So responsibility over the priority of a given layer is split, in two different places, the layer itself, and the user/project configuration. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] error in push of origin/org.openmbedded.dev
On Tue, May 3, 2011 at 8:03 AM, Florian Boor florian.b...@kernelconcepts.de wrote: Am 03.05.2011 16:54, schrieb Paul Menzel: you pushed to org.open*mb*edded.dev and therefore a new branch was created. Args - sorry my bad, I have a typo in the local branch name. Interesting what can happen working on a fresh tree :-) All the more reason to use master, which is less prone to such typos. org.openembedded.dev is just a compatibility pointer at master, master is the real branch. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] opencv_2.2.bb recipe doesn't install libopencv_core.so
On Wed, Apr 20, 2011 at 6:54 PM, James Sarrett jsarr...@appliedminds.com wrote: I'm trying to bitbake OpenCV for a BeagleBoard-xM, and having limited success. OpenCV builds and installs fine into /usr/lib, but it doesn't create (sym?-)links for the base shared objects. In other words, after install there is a /usr/lib/libopencv_opencvpart.so.2.2 but no corresponding /usr/lib/libopencv_opencvpart.so or .a. this causes the OpenCV samples to fail to build on the target (they install as source) because the cflags and libs returned by pkg-config are inconsistent. pkg-config assumes no version numbers (-llibopencv_core etc.). Install the libopencv-dev package on the target if you want to build against it... -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] blacklist.bbclass
On Fri, Mar 18, 2011 at 1:33 PM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2011/3/18 Dr. Michael Lauer mic...@vanille-media.de: Salut, the blacklisting of packages as found in angstrom.bbclass is pretty helpful and would be beneficial to all kinds of distribution configurations in OE. Would there be a strong objection of renaming this to blacklist.bbclass? Copying, of course, is also a possibility, but in my opinion it would only be the second best choice. Cheers, :M: If blacklisting a certain package for all distro's is there then still a need to keep those blacklisted packages Just because the class is named blacklist and *can* be used by any distro doesn't mean we'd be globally blacklisting something for all distros. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Discussion: Version retention policy in oe-core
On Mon, Mar 14, 2011 at 3:22 PM, Philip Balister phi...@balister.org wrote: The TSC has discussed this item at the request of the community and has come up with the following recommendation which we are looking for feedback (positive/negative/neutral) before putting this up on the wiki. Looks reasonable. One thing I did not see is asking people not to add a new recipe and delete the old one in separate commits. This makes it easier to figure out problems when they arise. I'd think this is a smaller piece of the general commit policies, and in particular, bisectability, rather than version retention in particular -- having a commit in the history where the recipe doesn't exist would certainly violate bisectability, as it's hard to build something that doesn't exist ;) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Backporting bitbake python fixes to 1.12 branch?
On Fri, Mar 11, 2011 at 6:25 AM, Koen Kooi k.k...@student.utwente.nl wrote: Various people trying out the maintenance branch get stuck on parsing recipes: 0% when using python 2.6.0 - 2.6.5-ish. I know master has bugfixes for that, could someone please backport/cherrypick/rediff them for the 1.12 branch? Pushed to the 1.12 branch. Thanks for the reminder :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Backporting bitbake python fixes to 1.12 branch?
On Fri, Mar 11, 2011 at 7:38 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 11 mrt 2011, om 15:27 heeft Chris Larson het volgende geschreven: On Fri, Mar 11, 2011 at 6:25 AM, Koen Kooi k.k...@student.utwente.nl wrote: Various people trying out the maintenance branch get stuck on parsing recipes: 0% when using python 2.6.0 - 2.6.5-ish. I know master has bugfixes for that, could someone please backport/cherrypick/rediff them for the 1.12 branch? Pushed to the 1.12 branch. Thanks for the reminder :) Thanks for the quick response! By the way, can I take this as confirmation that this fix actually worked? I never got confirmation from anyone but myself that it fixed the problem :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] What does PACKAGES_DYNAMIC do?
On Mon, Mar 7, 2011 at 7:47 PM, Charles Manning cdhmann...@gmail.com wrote: What is the rationale behind PACKAGES_DYNAMIC. I tried to RTFM, but that's in one of the Todo sections :-(. It informs bitbake about the emission of binary packages when we don't know what packages will be emitted until runtime (e.g. the locale packages, kernel modules, etc. Note kernel.bbclass sets PACKAGES_DYNAMIC += kernel-module-*). -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Bitbake 1.12.0 released!
On Sun, Feb 27, 2011 at 3:15 PM, Chris Larson clar...@kergoth.com wrote: https://github.com/kergoth/bitbake/compare/master...f12-hang https://github.com/kergoth/bitbake/commit/12d9095 This fixes the parsing hang on Fedora 12 for me. Note that I'm not sure about the version check. We could just use this version of _bootstrap all the time, but I'd rather avoid this for future versions, as we could miss fixes. We should determine if this fix was in python 2.6.3. Verified that the fix is in 2.6.3. If someone other than me could confirm that the above commit resolves their issues, I'd appreciate it :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Bitbake 1.12.0 released!
On Sun, Feb 27, 2011 at 8:30 AM, Mike Westerhof m...@mwester.net wrote: On 02/18/11 17:18, Richard Purdie wrote: Bitbake 1.12.0 has been released. http://prdownload.berlios.de/bitbake/bitbake-1.12.0.tar.gz This release has many cleanups and improvements to the bitbake core. The biggest and most user visible change is the parallel parsing work which is the driving reason for the release. A git log of the differences between 1.10 and 1.12 follows. It's a dumb question, but what are the intended restrictions on python version for running bitbake? 1.10 seems to work fine with python2.7 whereas I can only get 1.12 to work with python2.6. Just to add another datapoint to the python version restrictions: it seems that bitbake 1.12 requires python 2.6.4 and fails with python 2.6.2 (which means that bitbake 1.12 doesn't work on Fedora 12 or earlier). FYI, from some quick testing in a f12 chroot and creation of a test case outside of bitbake, it appears we're hitting http://bugs.python.org/issue5331, whose root cause is http://bugs.python.org/issue5155, which refers to http://bugs.python.org/issue5313. Looking into this now, it's possible we could replace the appropriate method of Process in our subclass with the one with the fix. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Bitbake 1.12.0 released!
On Sun, Feb 27, 2011 at 1:14 PM, Chris Larson clar...@kergoth.com wrote: On Sun, Feb 27, 2011 at 8:30 AM, Mike Westerhof m...@mwester.net wrote: On 02/18/11 17:18, Richard Purdie wrote: Bitbake 1.12.0 has been released. http://prdownload.berlios.de/bitbake/bitbake-1.12.0.tar.gz This release has many cleanups and improvements to the bitbake core. The biggest and most user visible change is the parallel parsing work which is the driving reason for the release. A git log of the differences between 1.10 and 1.12 follows. It's a dumb question, but what are the intended restrictions on python version for running bitbake? 1.10 seems to work fine with python2.7 whereas I can only get 1.12 to work with python2.6. Just to add another datapoint to the python version restrictions: it seems that bitbake 1.12 requires python 2.6.4 and fails with python 2.6.2 (which means that bitbake 1.12 doesn't work on Fedora 12 or earlier). FYI, from some quick testing in a f12 chroot and creation of a test case outside of bitbake, it appears we're hitting http://bugs.python.org/issue5331, whose root cause is http://bugs.python.org/issue5155, which refers to http://bugs.python.org/issue5313. Looking into this now, it's possible we could replace the appropriate method of Process in our subclass with the one with the fix. https://github.com/kergoth/bitbake/compare/master...f12-hang https://github.com/kergoth/bitbake/commit/12d9095 This fixes the parsing hang on Fedora 12 for me. Note that I'm not sure about the version check. We could just use this version of _bootstrap all the time, but I'd rather avoid this for future versions, as we could miss fixes. We should determine if this fix was in python 2.6.3. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Any good bitbake front-ends out there?
On Sat, Feb 26, 2011 at 3:38 PM, Hans Henry von Tresckow hvont...@gmail.com wrote: I was curious if anybody on the list has any recomendations for a bitbake front-end. bitbake -u goggle foo # assuming bitbake 1.12.0 or newer -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OT: pull requests, merges and bisection (was: OE TSC Meeting 2011/02/21 Minutes)
On Thu, Feb 24, 2011 at 3:55 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: it is great that the minutes of the meetings get published. Thank you. Am Donnerstag, den 24.02.2011, 09:20 -0700 schrieb Tom Rini: […] Not clear in the summary but from the logs is that we want to, as part of making this be transparent, publish guidelines for how this will work, based on what poky is doing now. The high level plan is to follow the contrib tree model that poky has which means sending pull requests (which in turn also post the patches to the ML for review). For changes that don't have a tree to pull from, someone with write access would need to pick them up. XBMC is using also an approach with pull requests. The Linux kernel is doing that also. Is there documentation on how pull requests, merges and bisecting works together? My problem is that pull requests are based on a certain commit in origin/master. After the request is sent most of the time several commits are pushed to origin/master in the mean time, so a merge is necessary “polluting” the commit history. I don't really see a problem with it, personally. It's not pollution if it's useful information, and recording the point where the branch was brought it can indeed be useful information. With my current knowledge I find it very difficult to track down bad commits especially if commits break the builds in between. Does `git bisect` take care of that itself? How do the Linux developers deal with that problem, especially merge conflicts? Well, you can mark commits that are broken for unrelated reasons with bisect, but ideally people would use something like git test-sequence combined with rebase to ensure that there are no points in their commits which will break bisect, and *that* gets merged to master. I think it's pretty important to retain bisectability (not a word, I know :) on our branches. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/4] autotools: break up into multiple files
From: Chris Larson chris_lar...@mentor.com
Split up most of autotools.bbclass into:
- classes/autotools/configure.inc
- classes/autotools/bootstrap.inc
- classes/autotools/staging.inc
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
classes/autotools.bbclass | 243 ---
classes/autotools/bootstrap.inc | 70 +++
classes/autotools/configure.inc | 91 +++
classes/autotools/staging.inc | 36 ++
4 files changed, 222 insertions(+), 218 deletions(-)
create mode 100644 classes/autotools/bootstrap.inc
create mode 100644 classes/autotools/configure.inc
create mode 100644 classes/autotools/staging.inc
diff --git a/classes/autotools.bbclass b/classes/autotools.bbclass
index a88a4d1..60925e9 100644
--- a/classes/autotools.bbclass
+++ b/classes/autotools.bbclass
@@ -1,237 +1,44 @@
-# use autotools_stage_all for native packages
-AUTOTOOLS_NATIVE_STAGE_INSTALL = 1
+require classes/autotools/staging.inc
+require classes/autotools/bootstrap.inc
+require classes/autotools/configure.inc
def autotools_deps(d):
- if bb.data.getVar('INHIBIT_AUTOTOOLS_DEPS', d, 1):
- return ''
+if bb.data.getVar('INHIBIT_AUTOTOOLS_DEPS', d, 1):
+return ''
- pn = bb.data.getVar('PN', d, 1)
- deps = ''
+pn = bb.data.getVar('PN', d, 1)
+deps = ''
- if pn in ['autoconf-native', 'automake-native', 'help2man-native']:
- return deps
- deps += 'autoconf-native automake-native help2man-native '
+if pn in ['autoconf-native', 'automake-native', 'help2man-native']:
+return deps
- if pn not in ['libtool', 'libtool-native', 'libtool-cross']:
- deps += 'libtool-native '
- if (not oe.utils.inherits(d, 'native', 'nativesdk', 'cross',
- 'sdk') and
- not d.getVar('INHIBIT_DEFAULT_DEPS', True)):
- deps += 'libtool-cross '
+deps += 'autoconf-native automake-native help2man-native '
- return deps + 'gnu-config-native '
+if pn not in ['libtool', 'libtool-native', 'libtool-cross']:
+deps += 'libtool-native '
+if (not oe.utils.inherits(d, 'native', 'nativesdk', 'cross',
+ 'sdk') and
+not d.getVar('INHIBIT_DEFAULT_DEPS', True)):
+deps += 'libtool-cross '
-EXTRA_OEMAKE =
+return deps + 'gnu-config-native '
DEPENDS_prepend = ${@autotools_deps(d)}
DEPENDS_virtclass-native_prepend = ${@autotools_deps(d)}
DEPENDS_virtclass-nativesdk_prepend = ${@autotools_deps(d)}
-inherit siteinfo
+autotools_do_configure () {
+autotools_do_bootstrap
-def _autotools_get_sitefiles(d):
-if oe.utils.inherits(d, 'native', 'nativesdk'):
-return
-
-sitedata = siteinfo_data(d)
-for path in d.getVar(BBPATH, True).split(:):
-for element in sitedata:
-filename = os.path.join(path, site, element)
-if os.path.exists(filename):
-yield filename
-
-# Space separated list of shell scripts with variables defined to supply test
-# results for autoconf tests we cannot run at build time.
-export CONFIG_SITE = ${@' '.join(_autotools_get_sitefiles(d))}
-
-acpaths = default
-EXTRA_AUTORECONF = --exclude=autopoint
-
-def autotools_set_crosscompiling(d):
- if not bb.data.inherits_class('native', d):
- return cross_compiling=yes
- return
-
-def append_libtool_sysroot(d):
- if bb.data.getVar('LIBTOOL_HAS_SYSROOT', d, 1) == yes:
- if bb.data.getVar('BUILD_SYS', d, 1) ==
bb.data.getVar('HOST_SYS', d, 1):
- return '--with-libtool-sysroot'
- else:
- return '--with-libtool-sysroot=${STAGING_DIR_HOST}'
- return ''
-
-def distro_imposed_configure_flags(d):
- distro_features = bb.data.getVar('DISTRO_FEATURES', d, True) or
- distro_features = distro_features.split()
- flags = set()
- features = (('largefile', 'largefile'),
- ('ipv6' , 'ipv6'),
- ('nls' , 'nls'))
-
- for knob, cfgargs in features:
- if isinstance(cfgargs, basestring):
- cfgargs = [cfgargs]
- en_or_dis = knob in distro_features and enable or disable
- for flg in cfgargs:
- flags.add(--%s-%s % (en_or_dis, flg))
- return .join(flags)
-
-# EXTRA_OECONF_append = ${@autotools_set_crosscompiling(d)}
-
-CONFIGUREOPTS = --build=${BUILD_SYS} \
- --host=${HOST_SYS} \
- --target=${TARGET_SYS} \
- --prefix=${prefix} \
- --exec_prefix=${exec_prefix} \
- --bindir=${bindir} \
- --sbindir=${sbindir} \
- --libexecdir=${libexecdir} \
- --datadir=${datadir} \
- --sysconfdir=${sysconfdir
[oe] [PATCH 3/4] autotools: add INHIBIT_AUTOTOOLS_BOOTSTRAP
From: Chris Larson chris_lar...@mentor.com
Setting this variable to a true value (obeying the semantics of the 'boolean'
type in oe.types) will result in not running autoreconf, and not depending on
the things which the autoreconf requires. Note that the
config.guess/config.sub files are still updated when using
INHIBIT_AUTOTOOLS_BOOTSTRAP, and these are updated directly via a find+ln
rather than through gnu-configize usage in order to avoid the dependency upon
autoconf/automake (gnu-configize is included with gnu-config, but requires the
perl modules from the other recipes).
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
classes/autotools.bbclass | 29 ++---
1 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/classes/autotools.bbclass b/classes/autotools.bbclass
index 3c124ae..dd52e03 100644
--- a/classes/autotools.bbclass
+++ b/classes/autotools.bbclass
@@ -2,26 +2,31 @@ require classes/autotools/staging.inc
require classes/autotools/bootstrap.inc
require classes/autotools/configure.inc
+INHIBIT_AUTOTOOLS_BOOTSTRAP ?= false
+INHIBIT_AUTOTOOLS_BOOTSTRAP[type] = boolean
+
def autotools_deps(d):
if bb.data.getVar('INHIBIT_AUTOTOOLS_DEPS', d, 1):
return ''
-pn = bb.data.getVar('PN', d, 1)
-deps = ''
+deps = 'gnu-config-native'
+if oe.data.typed_value('INHIBIT_AUTOTOOLS_BOOTSTRAP', d):
+return deps
+pn = bb.data.getVar('PN', d, 1)
if pn in ['autoconf-native', 'automake-native', 'help2man-native']:
return deps
-deps += 'autoconf-native automake-native help2man-native '
+deps += ' autoconf-native automake-native help2man-native'
if pn not in ['libtool', 'libtool-native', 'libtool-cross']:
-deps += 'libtool-native '
+deps += ' libtool-native'
if (not oe.utils.inherits(d, 'native', 'nativesdk', 'cross',
'sdk') and
not d.getVar('INHIBIT_DEFAULT_DEPS', True)):
-deps += 'libtool-cross '
+deps += ' libtool-cross'
-return deps + ' gnu-config-native'
+return deps
AUTOTOOLS_DEPENDS = ${@autotools_deps(d)}
@@ -29,8 +34,18 @@ DEPENDS_prepend = ${AUTOTOOLS_DEPENDS}
DEPENDS_virtclass-native_prepend = ${AUTOTOOLS_DEPENDS}
DEPENDS_virtclass-nativesdk_prepend = ${AUTOTOOLS_DEPENDS}
+_INHIBITED =
${@base_ifelse(oe.data.typed_value('INHIBIT_AUTOTOOLS_BOOTSTRAP', \
+ d), \
+ 'y', 'n')}
autotools_do_configure () {
-autotools_do_bootstrap
+if [ ${_INHIBITED} = n ]; then
+autotools_do_bootstrap
+else
+find ${S} -name config.guess -exec \
+ln -sf ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess {} \;
+find ${S} -name config.sub -exec \
+ln -sf ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub {} \;
+fi
if [ -e ${S}/configure ]; then
oe_runconf $@
--
1.7.2.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/4] autotools: shift deps into AUTOTOOLS_DEPENDS
From: Chris Larson chris_lar...@mentor.com
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
classes/autotools.bbclass | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/classes/autotools.bbclass b/classes/autotools.bbclass
index 60925e9..3c124ae 100644
--- a/classes/autotools.bbclass
+++ b/classes/autotools.bbclass
@@ -21,11 +21,13 @@ def autotools_deps(d):
not d.getVar('INHIBIT_DEFAULT_DEPS', True)):
deps += 'libtool-cross '
-return deps + 'gnu-config-native '
+return deps + ' gnu-config-native'
-DEPENDS_prepend = ${@autotools_deps(d)}
-DEPENDS_virtclass-native_prepend = ${@autotools_deps(d)}
-DEPENDS_virtclass-nativesdk_prepend = ${@autotools_deps(d)}
+AUTOTOOLS_DEPENDS = ${@autotools_deps(d)}
+
+DEPENDS_prepend = ${AUTOTOOLS_DEPENDS}
+DEPENDS_virtclass-native_prepend = ${AUTOTOOLS_DEPENDS}
+DEPENDS_virtclass-nativesdk_prepend = ${AUTOTOOLS_DEPENDS}
autotools_do_configure () {
autotools_do_bootstrap
--
1.7.2.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 4/4] autotools: avoid special casing autoconf/automake/help2man
From: Chris Larson chris_lar...@mentor.com
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
classes/autotools.bbclass |6 +-
recipes/autoconf/autoconf.inc |3 ++-
recipes/automake/automake.inc |4 +---
recipes/help2man/help2man_1.36.4.bb |6 +-
recipes/help2man/help2man_1.38.2.bb |6 +-
5 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/classes/autotools.bbclass b/classes/autotools.bbclass
index dd52e03..eaeca7f 100644
--- a/classes/autotools.bbclass
+++ b/classes/autotools.bbclass
@@ -13,13 +13,9 @@ def autotools_deps(d):
if oe.data.typed_value('INHIBIT_AUTOTOOLS_BOOTSTRAP', d):
return deps
-pn = bb.data.getVar('PN', d, 1)
-if pn in ['autoconf-native', 'automake-native', 'help2man-native']:
-return deps
-
deps += ' autoconf-native automake-native help2man-native'
-if pn not in ['libtool', 'libtool-native', 'libtool-cross']:
+if d.getVar('BPN', True) != 'libtool':
deps += ' libtool-native'
if (not oe.utils.inherits(d, 'native', 'nativesdk', 'cross',
'sdk') and
diff --git a/recipes/autoconf/autoconf.inc b/recipes/autoconf/autoconf.inc
index 7f22c2b..d13b61e 100644
--- a/recipes/autoconf/autoconf.inc
+++ b/recipes/autoconf/autoconf.inc
@@ -5,8 +5,9 @@ HOMEPAGE = http://www.gnu.org/software/autoconf/;
SECTION = devel
DEPENDS += m4-native perl-native
RDEPENDS_${PN} = m4 perl gnu-config
-DEPENDS_virtclass-native = m4-native gnu-config-native perl-native
+DEPENDS_virtclass-native = m4-native perl-native
RDEPENDS_${PN}_virtclass-native = m4-native gnu-config-native perl-native
+INHIBIT_AUTOTOOLS_BOOTSTRAP_virtclass-native = true
INC_PR = r13
diff --git a/recipes/automake/automake.inc b/recipes/automake/automake.inc
index de4df34..6ed21cd 100644
--- a/recipes/automake/automake.inc
+++ b/recipes/automake/automake.inc
@@ -28,6 +28,7 @@ RDEPENDS_automake += \
perl-module-strict \
perl-module-text-parsewords \
perl-module-vars
+INHIBIT_AUTOTOOLS_BOOTSTRAP_virtclass-native = true
SRC_URI = ${GNU_MIRROR}/automake/automake-${PV}.tar.bz2;name=automake
INC_PR = r4
AUTOMAKE_API = ${@..join(bb.data.getVar(PV,d,1).split(.)[0:2])}
@@ -36,9 +37,6 @@ inherit autotools
FILES_${PN} += ${datadir}/automake* ${datadir}/aclocal*
-do_configure_append() {
-}
-
do_install_append () {
autotools_do_install
# replace paths to STAGING_BINDIR_NATIVE/perl with ${bindir}/perl
diff --git a/recipes/help2man/help2man_1.36.4.bb
b/recipes/help2man/help2man_1.36.4.bb
index 8cb5530..8cd4475 100644
--- a/recipes/help2man/help2man_1.36.4.bb
+++ b/recipes/help2man/help2man_1.36.4.bb
@@ -5,6 +5,7 @@ LICENSE = GPLv2
DEPENDS = gettext-native perl-native liblocale-gettext-perl-native
DEPENDS_virtclass-native = perl-native autoconf-native automake-native
RDEPENDS_${PN}= gettext perl liblocale-gettext-perl
+INHIBIT_AUTOTOOLS_BOOTSTRAP = true
TARGET_CC_ARCH += ${LDFLAGS}
@@ -16,11 +17,6 @@ BBCLASSEXTEND = native
PR = r3
-# We don't want to reconfigure things
-do_configure() {
- oe_runconf
-}
-
do_install_append () {
# Make sure we use /usr/bin/env perl
sed -i -e 1s:#!.*:#! /usr/bin/env perl: ${D}${bindir}/help2man
diff --git a/recipes/help2man/help2man_1.38.2.bb
b/recipes/help2man/help2man_1.38.2.bb
index ab06186..795bad6 100644
--- a/recipes/help2man/help2man_1.38.2.bb
+++ b/recipes/help2man/help2man_1.38.2.bb
@@ -5,6 +5,7 @@ DEPENDS = gettext-native perl-native
liblocale-gettext-perl-native
DEPENDS_virtclass-native = perl-native autoconf-native automake-native
RDEPENDS_${PN} = gettext perl liblocale-gettext-perl
RDEPENDS_${PN}_virtclass-native =
+INHIBIT_AUTOTOOLS_BOOTSTRAP = true
PR = r2
SRC_URI = ${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz
@@ -18,11 +19,6 @@ EXTRA_OECONF = --disable-nls
BBCLASSEXTEND = native
-# We don't want to reconfigure things
-do_configure() {
- oe_runconf
-}
-
do_install_append () {
# Make sure we use /usr/bin/env perl
sed -i -e 1s:#!.*:#! /usr/bin/env perl: ${D}${bindir}/help2man
--
1.7.2.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 2/4] package.bbclass: remove superfluous whitespace characters from RDEPENDS
On Fri, Feb 11, 2011 at 5:51 AM, Andreas Oberritter o...@opendreambox.org wrote: Signed-off-by: Andreas Oberritter o...@opendreambox.org Acked-by: Chris Larson chris_lar...@mentor.com -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/4] utils.bbclass: restore previous implementation of explode_deps()
On Fri, Feb 11, 2011 at 5:51 AM, Andreas Oberritter
o...@opendreambox.org wrote:
* explode_deps() changed its behavior to omit version information
when the function was removed from OE in favor of BitBake's
implementation in March 2010. Since then, packages didn't contain
versioned runtime dependencies.
See commit 89b7e433719f43f1c36c76cb8856d559014e99bc
* This patch restores the previous implementation of explode_deps(),
thus fixing the generation of versioned runtime dependencies.
* Reimplementing explode_deps() using bb.utils.explode_dep_versions()
didn't work, because it choked upon parsing inline python code, e.g.
on update-modules_1.0.bb
's RDEPENDS_${PN} field.
Signed-off-by: Andreas Oberritter o...@opendreambox.org
CC: Chris Larson chris_lar...@mentor.com
Acked-by: Chris Larson chris_lar...@mentor.com
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] different access rights for oe branches?
On Thu, Feb 10, 2011 at 6:34 AM, Steffen Sledz sl...@dresearch.de wrote: We like to create a branch specific for our hipox machine. Is it possible to define access rights different to the dev-branch here? We would like to give write access to some of our developers which do not have/need write access do dev. In opposite it would be nice to limit the write access to these maintainers. We use gitolite now, which can indeed exert control over branch access for the users, afaik. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/4] autotools: cleanup
From: Chris Larson chris_lar...@mentor.com
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
classes/autotools.bbclass | 60 +---
1 files changed, 23 insertions(+), 37 deletions(-)
diff --git a/classes/autotools.bbclass b/classes/autotools.bbclass
index c8cb0e9..4d7a66b 100644
--- a/classes/autotools.bbclass
+++ b/classes/autotools.bbclass
@@ -17,7 +17,7 @@ def autotools_deps(d):
if (not oe.utils.inherits(d, 'native', 'nativesdk', 'cross',
'sdk') and
not d.getVar('INHIBIT_DEFAULT_DEPS', True)):
-deps += 'libtool-cross '
+ deps += 'libtool-cross '
return deps + 'gnu-config-native '
@@ -110,22 +110,13 @@ oe_runconf () {
autotools_do_configure() {
case ${PN} in
- autoconf*)
- ;;
- automake*)
+ autoconf*|automake*)
;;
*)
- # WARNING: gross hack follows:
- # An autotools built package generally needs these scripts,
however only
- # automake or libtoolize actually install the current versions
of them.
- # This is a problem in builds that do not use libtool or
automake, in the case
- # where we -need- the latest version of these scripts. e.g.
running a build
- # for a package whose autotools are old, on an x86_64 machine,
which the old
- # config.sub does not support. Work around this by installing
them manually
- # regardless.
- ( for ac in `find ${S} -name configure.in -o -name
configure.ac`; do
- rm -f `dirname $ac`/configure
- done )
+ find ${S} -name configure.in -o -name configure.ac | \
+ while read fn; do
+ rm -f `dirname $fn`/configure
+ done
if [ -e ${S}/configure.in -o -e ${S}/configure.ac ]; then
olddir=`pwd`
cd ${S}
@@ -138,9 +129,7 @@ autotools_do_configure() {
else
acpaths=${acpaths}
fi
- AUTOV=`automake --version |head -n 1 |sed s/.*
//;s/\.[0-9]\+$//`
- automake --version
- echo AUTOV is $AUTOV
+ AUTOV=`automake --version | head -n 1 | sed s/.*
//;s/\.[0-9]\+$//`
install -d ${STAGING_DATADIR}/aclocal
install -d ${STAGING_DATADIR}/aclocal-$AUTOV
acpaths=$acpaths -I${STAGING_DATADIR}/aclocal-$AUTOV
-I ${STAGING_DATADIR}/aclocal
@@ -151,34 +140,31 @@ autotools_do_configure() {
rm -f aclocal.m4
fi
if [ -e configure.in ]; then
- CONFIGURE_AC=configure.in
+ CONFIGURE_AC=configure.in
else
- CONFIGURE_AC=configure.ac
+ CONFIGURE_AC=configure.ac
fi
- if grep -q ^[[:space:]]*AM_GLIB_GNU_GETTEXT
$CONFIGURE_AC; then
- if grep -q sed.*POTFILES $CONFIGURE_AC; then
- : do nothing -- we still have an old unmodified
configure.ac
- else
- oenote Executing glib-gettextize --force --copy
- echo no | glib-gettextize --force --copy
- fi
- else if grep -q ^[[:space:]]*AM_GNU_GETTEXT
$CONFIGURE_AC; then
- if [ -e ${STAGING_DATADIR}/gettext/config.rpath ];
then
- cp ${STAGING_DATADIR}/gettext/config.rpath ${S}/
- else
- oenote ${STAGING_DATADIR}/gettext/config.rpath not
found. gettext is not installed.
- fi
+ if grep ^[[:space:]]*AM_GLIB_GNU_GETTEXT
$CONFIGURE_AC /dev/null; then
+ if grep sed.*POTFILES $CONFIGURE_AC
/dev/null; then
+ : do nothing -- we still have an old
unmodified configure.ac
+ else
+ echo no | glib-gettextize --force
--copy
+ fi
+ else if grep ^[[:space:]]*AM_GNU_GETTEXT
$CONFIGURE_AC /dev/null; then
+ if [ -e ${STAGING_DATADIR}/gettext/config.rpath
]; then
+ cp
${STAGING_DATADIR}/gettext/config.rpath ${S}/
+ else
+ oenote
${STAGING_DATADIR}/gettext/config.rpath not found. gettext is not installed
[oe] [PATCH 2/4] autotools: split out a oe_autoreconf function
From: Chris Larson chris_lar...@mentor.com
This functionality logically belongs in its own function, and it makes it
easier to explicitly run against subdirs in certain cases.
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
classes/autotools.bbclass | 96 +++-
1 files changed, 50 insertions(+), 46 deletions(-)
diff --git a/classes/autotools.bbclass b/classes/autotools.bbclass
index 4d7a66b..9744589 100644
--- a/classes/autotools.bbclass
+++ b/classes/autotools.bbclass
@@ -108,6 +108,55 @@ oe_runconf () {
fi
}
+oe_autoreconf () {
+ if [ x${acpaths} = xdefault ]; then
+ acpaths=
+ for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v
'aclocal.m4'| \
+ grep -v 'acinclude.m4' | sed -e 's,\(.*/\).*$,\1,'|sort
-u`; do
+ acpaths=$acpaths -I $i
+ done
+ else
+ acpaths=${acpaths}
+ fi
+ AUTOV=`automake --version | head -n 1 | sed s/.* //;s/\.[0-9]\+$//`
+ install -d ${STAGING_DATADIR}/aclocal
+ install -d ${STAGING_DATADIR}/aclocal-$AUTOV
+ acpaths=$acpaths -I${STAGING_DATADIR}/aclocal-$AUTOV -I
${STAGING_DATADIR}/aclocal
+ # autoreconf is too shy to overwrite aclocal.m4 if it doesn't look
+ # like it was auto-generated. Work around this by blowing it away
+ # by hand, unless the package specifically asked not to run aclocal.
+ if ! echo ${EXTRA_AUTORECONF} | grep -q aclocal; then
+ rm -f aclocal.m4
+ fi
+ if [ -e configure.in ]; then
+ CONFIGURE_AC=configure.in
+ else
+ CONFIGURE_AC=configure.ac
+ fi
+ if grep ^[[:space:]]*AM_GLIB_GNU_GETTEXT $CONFIGURE_AC /dev/null;
then
+ if grep sed.*POTFILES $CONFIGURE_AC /dev/null; then
+ : do nothing -- we still have an old unmodified
configure.ac
+ else
+ echo no | glib-gettextize --force --copy
+ fi
+ else if grep ^[[:space:]]*AM_GNU_GETTEXT $CONFIGURE_AC /dev/null;
then
+ if [ -e ${STAGING_DATADIR}/gettext/config.rpath ]; then
+ cp ${STAGING_DATADIR}/gettext/config.rpath ${S}/
+ else
+ oenote ${STAGING_DATADIR}/gettext/config.rpath not
found. gettext is not installed.
+ fi
+ fi
+
+ fi
+ for aux in m4 `sed -n -e
'/^[[:space:]]*AC_CONFIG_MACRO_DIR/s|[^(]*([[]*\([^])]*\)[]]*)|\1|p'
$CONFIGURE_AC`; do
+ mkdir -p ${aux}
+ done
+ autoreconf -Wcross --verbose --install --force ${EXTRA_AUTORECONF}
$acpaths || oefatal autoreconf execution failed.
+ if grep ^[[:space:]]*[AI][CT]_PROG_INTLTOOL $CONFIGURE_AC /dev/null;
then
+ intltoolize --copy --force --automake
+ fi
+}
+
autotools_do_configure() {
case ${PN} in
autoconf*|automake*)
@@ -120,52 +169,7 @@ autotools_do_configure() {
if [ -e ${S}/configure.in -o -e ${S}/configure.ac ]; then
olddir=`pwd`
cd ${S}
- if [ x${acpaths} = xdefault ]; then
- acpaths=
- for i in `find ${S} -maxdepth 2 -name
\*.m4|grep -v 'aclocal.m4'| \
- grep -v 'acinclude.m4' | sed -e
's,\(.*/\).*$,\1,'|sort -u`; do
- acpaths=$acpaths -I $i
- done
- else
- acpaths=${acpaths}
- fi
- AUTOV=`automake --version | head -n 1 | sed s/.*
//;s/\.[0-9]\+$//`
- install -d ${STAGING_DATADIR}/aclocal
- install -d ${STAGING_DATADIR}/aclocal-$AUTOV
- acpaths=$acpaths -I${STAGING_DATADIR}/aclocal-$AUTOV
-I ${STAGING_DATADIR}/aclocal
- # autoreconf is too shy to overwrite aclocal.m4 if it
doesn't look
- # like it was auto-generated. Work around this by
blowing it away
- # by hand, unless the package specifically asked not to
run aclocal.
- if ! echo ${EXTRA_AUTORECONF} | grep -q aclocal; then
- rm -f aclocal.m4
- fi
- if [ -e configure.in ]; then
- CONFIGURE_AC=configure.in
- else
- CONFIGURE_AC=configure.ac
- fi
- if grep ^[[:space:]]*AM_GLIB_GNU_GETTEXT
$CONFIGURE_AC /dev/null; then
- if grep sed.*POTFILES $CONFIGURE_AC
/dev/null; then
- : do nothing -- we still have an old
unmodified configure.ac
- else
[oe] [PATCH 3/4] autotools: symlink where we can
From: Chris Larson chris_lar...@mentor.com
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
classes/autotools.bbclass |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/classes/autotools.bbclass b/classes/autotools.bbclass
index 9744589..a88a4d1 100644
--- a/classes/autotools.bbclass
+++ b/classes/autotools.bbclass
@@ -137,11 +137,11 @@ oe_autoreconf () {
if grep sed.*POTFILES $CONFIGURE_AC /dev/null; then
: do nothing -- we still have an old unmodified
configure.ac
else
- echo no | glib-gettextize --force --copy
+ echo no | glib-gettextize --force
fi
else if grep ^[[:space:]]*AM_GNU_GETTEXT $CONFIGURE_AC /dev/null;
then
if [ -e ${STAGING_DATADIR}/gettext/config.rpath ]; then
- cp ${STAGING_DATADIR}/gettext/config.rpath ${S}/
+ ln -sf ${STAGING_DATADIR}/gettext/config.rpath ${S}/
else
oenote ${STAGING_DATADIR}/gettext/config.rpath not
found. gettext is not installed.
fi
@@ -151,9 +151,9 @@ oe_autoreconf () {
for aux in m4 `sed -n -e
'/^[[:space:]]*AC_CONFIG_MACRO_DIR/s|[^(]*([[]*\([^])]*\)[]]*)|\1|p'
$CONFIGURE_AC`; do
mkdir -p ${aux}
done
- autoreconf -Wcross --verbose --install --force ${EXTRA_AUTORECONF}
$acpaths || oefatal autoreconf execution failed.
+ autoreconf -Wcross --verbose --install --symlink --force
${EXTRA_AUTORECONF} $acpaths || oefatal autoreconf execution failed.
if grep ^[[:space:]]*[AI][CT]_PROG_INTLTOOL $CONFIGURE_AC /dev/null;
then
- intltoolize --copy --force --automake
+ intltoolize --force --automake
fi
}
--
1.7.2.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 4/4] autotools: split up into multiple files
From: Chris Larson chris_lar...@mentor.com
Split up autotools.bbclass into:
classes/autotools/configure.bbclass
To be inherited if one wants ./configure and config.{sub,guess}
updating, but not autoreconf execution
classes/autotools/bootstrap.bbclass
Autoreconf execution
classes/autotools/staging.inc
Holds the old autotools staging utility functions
autotools.bbclass still exists, and simply inherits
classes/autotools/bootstrap.bbclass.
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
classes/autotools.bbclass | 238 +--
classes/autotools/bootstrap.bbclass | 101 +++
classes/autotools/configure.bbclass | 118 +
classes/autotools/staging.inc | 36 ++
4 files changed, 256 insertions(+), 237 deletions(-)
create mode 100644 classes/autotools/bootstrap.bbclass
create mode 100644 classes/autotools/configure.bbclass
create mode 100644 classes/autotools/staging.inc
diff --git a/classes/autotools.bbclass b/classes/autotools.bbclass
index a88a4d1..6f30a9e 100644
--- a/classes/autotools.bbclass
+++ b/classes/autotools.bbclass
@@ -1,237 +1 @@
-# use autotools_stage_all for native packages
-AUTOTOOLS_NATIVE_STAGE_INSTALL = 1
-
-def autotools_deps(d):
- if bb.data.getVar('INHIBIT_AUTOTOOLS_DEPS', d, 1):
- return ''
-
- pn = bb.data.getVar('PN', d, 1)
- deps = ''
-
- if pn in ['autoconf-native', 'automake-native', 'help2man-native']:
- return deps
- deps += 'autoconf-native automake-native help2man-native '
-
- if pn not in ['libtool', 'libtool-native', 'libtool-cross']:
- deps += 'libtool-native '
- if (not oe.utils.inherits(d, 'native', 'nativesdk', 'cross',
- 'sdk') and
- not d.getVar('INHIBIT_DEFAULT_DEPS', True)):
- deps += 'libtool-cross '
-
- return deps + 'gnu-config-native '
-
-EXTRA_OEMAKE =
-
-DEPENDS_prepend = ${@autotools_deps(d)}
-DEPENDS_virtclass-native_prepend = ${@autotools_deps(d)}
-DEPENDS_virtclass-nativesdk_prepend = ${@autotools_deps(d)}
-
-inherit siteinfo
-
-def _autotools_get_sitefiles(d):
-if oe.utils.inherits(d, 'native', 'nativesdk'):
-return
-
-sitedata = siteinfo_data(d)
-for path in d.getVar(BBPATH, True).split(:):
-for element in sitedata:
-filename = os.path.join(path, site, element)
-if os.path.exists(filename):
-yield filename
-
-# Space separated list of shell scripts with variables defined to supply test
-# results for autoconf tests we cannot run at build time.
-export CONFIG_SITE = ${@' '.join(_autotools_get_sitefiles(d))}
-
-acpaths = default
-EXTRA_AUTORECONF = --exclude=autopoint
-
-def autotools_set_crosscompiling(d):
- if not bb.data.inherits_class('native', d):
- return cross_compiling=yes
- return
-
-def append_libtool_sysroot(d):
- if bb.data.getVar('LIBTOOL_HAS_SYSROOT', d, 1) == yes:
- if bb.data.getVar('BUILD_SYS', d, 1) ==
bb.data.getVar('HOST_SYS', d, 1):
- return '--with-libtool-sysroot'
- else:
- return '--with-libtool-sysroot=${STAGING_DIR_HOST}'
- return ''
-
-def distro_imposed_configure_flags(d):
- distro_features = bb.data.getVar('DISTRO_FEATURES', d, True) or
- distro_features = distro_features.split()
- flags = set()
- features = (('largefile', 'largefile'),
- ('ipv6' , 'ipv6'),
- ('nls' , 'nls'))
-
- for knob, cfgargs in features:
- if isinstance(cfgargs, basestring):
- cfgargs = [cfgargs]
- en_or_dis = knob in distro_features and enable or disable
- for flg in cfgargs:
- flags.add(--%s-%s % (en_or_dis, flg))
- return .join(flags)
-
-# EXTRA_OECONF_append = ${@autotools_set_crosscompiling(d)}
-
-CONFIGUREOPTS = --build=${BUILD_SYS} \
- --host=${HOST_SYS} \
- --target=${TARGET_SYS} \
- --prefix=${prefix} \
- --exec_prefix=${exec_prefix} \
- --bindir=${bindir} \
- --sbindir=${sbindir} \
- --libexecdir=${libexecdir} \
- --datadir=${datadir} \
- --sysconfdir=${sysconfdir} \
- --sharedstatedir=${sharedstatedir} \
- --localstatedir=${localstatedir} \
- --libdir=${libdir} \
- --includedir=${includedir} \
- --oldincludedir=${oldincludedir} \
- --infodir=${infodir} \
- --mandir=${mandir} \
- ${@append_libtool_sysroot(d)} \
- ${@distro_imposed_configure_flags(d)} \
-
-
-oe_runconf () {
- if [ -x ${S
Re: [oe] Patching from a file containing a compressed directory (directory.tar.bz2)
On Thu, Jan 27, 2011 at 4:17 PM, Ulf Samuelsson ulf.samuels...@atmel.com wrote: To me, maintaining this is much less work than maintaining a SRC_URI statement. Obviously, it would be better if the build system had a defined order when applying patches from a file containing multiple patches. You seem to be under the mistaken impression that it's the build system that's handling that. It just calls quilt/patch to apply it.. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] openembedded-core git repository
On Tue, Jan 25, 2011 at 10:53 AM, Tom Rini tom_r...@mentor.com wrote: * start an integration branch o remove bitbake Not sure what you mean with that. Which BB do you propose to use? Chris Larson has been doing a lot of work (and Richard has been confirming, testing, etc, etc) to try and keep poky's bitbake changes in sync with master when at all possible (the delta has gotten very very small, iirc). I would personally like to see yocto use upstream bitbake with git submodules or similar, rather than maintaining its own bitbake directory. I'd also like to see the bitbake sync completed, but it seems like it's a low priority for Richard at this time. As you say, though, the delta is fairly small, considering. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] openembedded-core git repository
On Thu, Jan 20, 2011 at 3:21 AM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2011/1/19 Graham Gower graham.go...@gmail.com: On 20 January 2011 05:22, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2011/1/19 Graeme Gregory d...@xora.org.uk: Core should probably have a build bot which crunches a standard set of tests on each commit so unlike OE currently people don't wake up to bad day of debugging OE. I'm not sure if that is needed (at least not on for every commit). Doing this for every commit may be good from the point of view of keeping git-bisect useful. Good point. Didn't think of that! Take a look at git test-sequence. It's *awesome* for ensuring bisectability on changes before pushing. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] busybox: move syslog config to /etc/default
On Wed, Jan 19, 2011 at 1:10 PM, Martin Jansa martin.ja...@gmail.com wrote: Here it's right but to OE you've pushed version of patch where it is also renamed to default/busybox-syslog, but that patern in sed call 's,/etc/default/busybox-syslog,' should still read 's,/etc/default/syslog,', otherwise nothing is replaced and syslog.busybox is still trying to read /etc/default/syslog which does not exist or rename it to busybox-syslog in files/syslog file too http://git.openembedded.org/cgit.cgi/openembedded/commit/recipes/busybox/files/syslog?id=a25c0750c7892990c59e8d6048b8c4d99410bcee Bah, damnit, thanks. Well spotted. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/4] bitbake.conf: include bin dirs from BBPATH in PATH
From: Chris Larson chris_lar...@mentor.com
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
bin/{ = darwin}/cp|0
bin/{ = darwin}/sed |0
conf/bitbake.conf |5 +++--
conf/build/Power Macintosh-darwin.conf |2 +-
conf/build/i386-darwin.conf|2 +-
5 files changed, 5 insertions(+), 4 deletions(-)
rename bin/{ = darwin}/cp (100%)
rename bin/{ = darwin}/sed (100%)
diff --git a/bin/cp b/bin/darwin/cp
similarity index 100%
rename from bin/cp
rename to bin/darwin/cp
diff --git a/bin/sed b/bin/darwin/sed
similarity index 100%
rename from bin/sed
rename to bin/darwin/sed
diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index f1dc0ff..d03d7e3 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -421,8 +421,9 @@ EXTRA_IMAGEDEPENDS =
LIBTOOL_HAS_SYSROOT ?= no
-PATH_prepend =
${STAGING_BINDIR_CROSS}:${STAGING_DIR_NATIVE}${sbindir_native}:${STAGING_BINDIR_NATIVE}:${STAGING_DIR_NATIVE}${base_sbindir_native}:${STAGING_DIR_NATIVE}/${base_bindir_native}:
-export PATH
+BBPATH_BIN = ${@':'.join('%s/bin' % path for path in '${BBPATH}'.split(':'))}
+PATH =.
${BBPATH_BIN}:${STAGING_BINDIR_CROSS}:${STAGING_DIR_NATIVE}${sbindir_native}:${STAGING_BINDIR_NATIVE}:${STAGING_DIR_NATIVE}${base_sbindir_native}:${STAGING_DIR_NATIVE}/${base_bindir_native}:
+PATH[export] = 1
##
# Build utility info.
diff --git a/conf/build/Power Macintosh-darwin.conf b/conf/build/Power
Macintosh-darwin.conf
index effddbf..b42051b 100644
--- a/conf/build/Power Macintosh-darwin.conf
+++ b/conf/build/Power Macintosh-darwin.conf
@@ -1,4 +1,4 @@
-PATH =. ${@bb.which('${BBPATH}', 'bin')}:
+PATH =. ${@bb.which('${BBPATH}', 'bin')}/darwin:
BUILD_ARCH = powerpc
require conf/build/darwin/utilities.inc
diff --git a/conf/build/i386-darwin.conf b/conf/build/i386-darwin.conf
index c9e81b9..bdcb075 100644
--- a/conf/build/i386-darwin.conf
+++ b/conf/build/i386-darwin.conf
@@ -1,4 +1,4 @@
-PATH =. ${@bb.which('${BBPATH}', 'bin')}:
+PATH =. ${@bb.which('${BBPATH}', 'bin')}/darwin:
BUILD_CC_ARCH += -m32
require conf/build/darwin/utilities.inc
--
1.7.2.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/4] Move stage-manager-* into bin/ rather than a recipe
From: Chris Larson chris_lar...@mentor.com
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
{recipes/stage-manager/files = bin}/stage-manager |3 --
.../stage-manager/files = bin}/stage-manager-ipkg | 26 ++--
.../files = bin}/stage-manager-ipkg-build |6 ++--
classes/base.bbclass |5 +--
classes/packaged-staging.bbclass |5
recipes/stage-manager/stagemanager-native_0.0.1.bb | 26
6 files changed, 18 insertions(+), 53 deletions(-)
rename {recipes/stage-manager/files = bin}/stage-manager (99%)
rename {recipes/stage-manager/files = bin}/stage-manager-ipkg (98%)
rename {recipes/stage-manager/files = bin}/stage-manager-ipkg-build (99%)
delete mode 100644 recipes/stage-manager/stagemanager-native_0.0.1.bb
diff --git a/recipes/stage-manager/files/stage-manager b/bin/stage-manager
similarity index 99%
rename from recipes/stage-manager/files/stage-manager
rename to bin/stage-manager
index 0c01a18..5b47791 100755
--- a/recipes/stage-manager/files/stage-manager
+++ b/bin/stage-manager
@@ -151,6 +151,3 @@ if __name__ == __main__:
if found_difference:
sys.exit(5)
sys.exit(0)
-
-
-
diff --git a/recipes/stage-manager/files/stage-manager-ipkg
b/bin/stage-manager-ipkg
similarity index 98%
rename from recipes/stage-manager/files/stage-manager-ipkg
rename to bin/stage-manager-ipkg
index 105ea54..456bc78 100755
--- a/recipes/stage-manager/files/stage-manager-ipkg
+++ b/bin/stage-manager-ipkg
@@ -131,15 +131,15 @@ Valid destinations are directories or one of the dest
names from $IPKG_CONF:
IPKG_HTTP_PROXY=`ipkg_option http_proxy`
IPKG_FTP_PROXY=`ipkg_option ftp_proxy`
IPKG_NO_PROXY=`ipkg_option no_proxy`
- if [ -n $IPKG_HTTP_PROXY ]; then
+ if [ -n $IPKG_HTTP_PROXY ]; then
export http_proxy=$IPKG_HTTP_PROXY
fi
- if [ -n $IPKG_FTP_PROXY ]; then
+ if [ -n $IPKG_FTP_PROXY ]; then
export ftp_proxy=$IPKG_FTP_PROXY
fi
- if [ -n $IPKG_NO_PROXY ]; then
+ if [ -n $IPKG_NO_PROXY ]; then
export no_proxy=$IPKG_NO_PROXY
fi
@@ -175,7 +175,7 @@ Options:
configuration file, (but can also be a directory
name in a pinch).
-o offline_root Use offline_root as the root for offline
installation.
--offline offline_root
+-offline offline_root
Force Options (use when ipkg is too smart for its own good):
-force-depends Make dependency checks warnings instead of
errors
@@ -221,7 +221,7 @@ ipkg_download() {
local proxyuser=
local proxypassword=
local proxyoption=
-
+
if [ -n $IPKG_PROXY_USERNAME ]; then
proxyuser=--proxy-user=\$IPKG_PROXY_USERNAME\
proxypassword=--proxy-passwd=\$IPKG_PROXY_PASSWORD\
@@ -276,7 +276,7 @@ ipkg_update() {
ipkg_list() {
for src in `ipkg_src_names`; do
- if ipkg_require_list $src; then
+ if ipkg_require_list $src; then
# black magic...
sed -ne
/^Package:/{
@@ -342,7 +342,7 @@ ipkg_info() {
case $# in
0)
cat $IPKG_LISTS_DIR/$src
- ;;
+ ;;
1)
ipkg_extract_paragraph $1 $IPKG_LISTS_DIR/$src
;;
@@ -545,7 +545,7 @@ ipkg_safe_pkg_name() {
}
ipkg_set_depends() {
- local pkg=$1; shift
+ local pkg=$1; shift
local new_deps=$*
pkg=`ipkg_safe_pkg_name $pkg`
## setvar ${pkg}_depends $new_deps
@@ -672,7 +672,7 @@ Status: install ok not-installed | ipkg_status_update_sd
$sd $pkg
new_pkgs=$new_pkgs $pkg
### echo Dependences not satisfied for $pkg:
$remaining_deps
if [ $curcheck -ne `echo $pkgs|wc -w` ]; then
- continue
+ continue
fi
fi
@@ -886,7 +886,7 @@ diff -u $dest/$conffile $IPKG_TMP/$pkg/data/$conffile
fi
local owd=`pwd`
- (cd $IPKG_TMP/$pkg/data/; tar cf - . | (cd $owd; cd $dest; tar xf -))
+ (cd $IPKG_TMP/$pkg/data/; tar cf - . | (cd $owd; cd $dest; tar xf -))
rm -rf $IPKG_TMP/$pkg/data
rmdir $IPKG_TMP/$pkg
rm -f $IPKG_TMP/data.tar.gz $IPKG_TMP/data.tar
@@ -924,7 +924,7 @@ ipkg_install() {
while [ $# -gt 0 ]; do
local pkg=$1
shift
-
+
case $pkg in
http://* | ftp://*)
local tmp_pkg_file=$IPKG_TMP/`ipkg_file_part
[oe] [PATCH 4/4] bin/install: implement -D internally
From: Chris Larson chris_lar...@mentor.com Signed-off-by: Chris Larson chris_lar...@mentor.com --- bin/install | 13 - 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/bin/install b/bin/install index 4ad8172..1c938755 100755 --- a/bin/install +++ b/bin/install @@ -1,9 +1,13 @@ #!/bin/sh +# +# Portability notes: +# - We allow what SuSv3 defines +# - We implement -D internally source $(dirname $0)/wrapper.sh saved= -while getopts dbCcMpSsvB:f:g:m:o: opt; do +while getopts dbCcMpSsvB:f:g:m:o:D opt; do case $opt in s) # Ignore strip argument @@ -12,6 +16,9 @@ while getopts dbCcMpSsvB:f:g:m:o: opt; do save -$opt save $OPTARG ;; +D) +createleading=1 +;; \?) exit 1 ;; @@ -25,4 +32,8 @@ for arg; do save $arg done +if [ $# == 2 -a -n $createleading ]; then +install -d $(dirname $2) +fi + exec_real -- 1.7.2.3 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] busybox: move syslog config to /etc/default
On Wed, Jan 12, 2011 at 12:43 AM, Steffen Sledz sl...@dresearch.de wrote: Am 12.01.2011 02:43, schrieb Chris Larson: From: Chris Larson chris_lar...@mentor.com The busybox syslog syslog.conf is parsed by the /etc/init.d script, not by the syslog process itself, so it belongs in /etc/default. In addition, the file format is *completely* different from the standard sysklogd configuration, so while we should resolve the file conflict between busybox-syslog and sysklogd, we should not use update-alternatives for it, so this is a cleaner solution. Moving the file into /etc/default seems to be OK for me. But i would suggest to rename the config file itself to busybox-syslog, because it does not contain (default) configuration for any syslog incarnation but only for busybox-syslog. Good point, will do. Thanks. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] busybox: move syslog config to /etc/default
On Wed, Jan 12, 2011 at 12:33 AM, Khem Raj raj.k...@gmail.com wrote: On 1/11/2011 5:43 PM, Chris Larson wrote: From: Chris Larsonchris_lar...@mentor.com The busybox syslog syslog.conf is parsed by the /etc/init.d script, not by the syslog process itself, so it belongs in /etc/default. In addition, the file format is *completely* different from the standard sysklogd configuration, so while we should resolve the file conflict between busybox-syslog and sysklogd, we should not use update-alternatives for it, so this is a cleaner solution. Signed-off-by: Chris Larsonchris_lar...@mentor.com looks ok will upgrade paths work ok after this change Acked-by: Khem Raj raj.k...@gmail.com Hmm, I suspect that if the user modified the busybox /etc/syslog.conf, opkg would leave their version behind with a different filename, rather than blindly removing a user edited conffile, but of course the new one in /etc/default wouldn't include any of the old user customizations. I'll look into this a bit more closely. Thanks. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] busybox: move syslog config to /etc/default
From: Chris Larson chris_lar...@mentor.com
The busybox syslog syslog.conf is parsed by the /etc/init.d script, not by the
syslog process itself, so it belongs in /etc/default. In addition, the file
format is *completely* different from the standard sysklogd configuration, so
while we should resolve the file conflict between busybox-syslog and sysklogd,
we should not use update-alternatives for it, so this is a cleaner solution.
Signed-off-by: Chris Larson chris_lar...@mentor.com
---
recipes/busybox/busybox.inc | 13 +
recipes/busybox/files/syslog |4 ++--
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/recipes/busybox/busybox.inc b/recipes/busybox/busybox.inc
index a9d1e6e..1106910 100644
--- a/recipes/busybox/busybox.inc
+++ b/recipes/busybox/busybox.inc
@@ -11,7 +11,7 @@ LICENSE = GPLv2
SECTION = base
PRIORITY = required
-INC_PR = r38
+INC_PR = r39
SRC_URI = \
file://busybox-cron \
@@ -47,7 +47,8 @@ RDEPENDS_${PN} += ${PN}-mountall
RRECOMMENDS_${PN} += libgcc ${PN}-syslog
FILES_${PN}-httpd = ${sysconfdir}/init.d/busybox-httpd /srv/www
-FILES_${PN}-syslog = ${sysconfdir}/init.d/syslog.${PN}
${sysconfdir}/syslog.conf
+FILES_${PN}-syslog = ${sysconfdir}/init.d/syslog.${PN} \
+ ${sysconfdir}/default/syslog
FILES_${PN}-udhcpd = ${sysconfdir}/init.d/busybox-udhcpd
FILES_${PN} += ${datadir}/udhcpc
@@ -58,7 +59,7 @@ INITSCRIPT_PACKAGES = ${PN}-httpd ${PN}-udhcpd
INITSCRIPT_NAME_${PN}-httpd = busybox-httpd
INITSCRIPT_NAME_${PN}-syslog = syslog
INITSCRIPT_NAME_${PN}-udhcpd = busybox-udhcpd
-CONFFILES_${PN}-syslog = ${sysconfdir}/syslog.conf
+CONFFILES_${PN}-syslog = ${sysconfdir}/default/syslog
# This disables the syslog startup links in slugos (see slugos-init)
INITSCRIPT_PARAMS_${PN}-syslog_slugos = start 20 .
@@ -168,7 +169,11 @@ do_install () {
if grep -q CONFIG_SYSLOGD=y ${WORKDIR}/defconfig; then
install -m 0755 ${WORKDIR}/syslog
${D}${sysconfdir}/init.d/syslog.${PN}
- install -m 644 ${WORKDIR}/syslog.conf ${D}${sysconfdir}/
+ sed -i -e 's,/etc/default/syslog,${sysconfdir}/default/syslog,'
\
+ ${D}${sysconfdir}/init.d/syslog.${PN}
+
+ install -d ${D}${sysconfdir}/default
+ install -m 644 ${WORKDIR}/syslog.conf
${D}${sysconfdir}/default/syslog
fi
if grep CONFIG_CROND=y ${WORKDIR}/defconfig; then
install -m 0755 ${WORKDIR}/busybox-cron
${D}${sysconfdir}/init.d/
diff --git a/recipes/busybox/files/syslog b/recipes/busybox/files/syslog
index 61d273b..6e86346 100644
--- a/recipes/busybox/files/syslog
+++ b/recipes/busybox/files/syslog
@@ -5,8 +5,8 @@
# Configuration file added by bruno.rand...@4g-systems.biz
set -e
-if [ -f /etc/syslog.conf ]; then
- . /etc/syslog.conf
+if [ -f /etc/default/syslog ]; then
+ . /etc/default/syslog
LOG_LOCAL=0
LOG_REMOTE=0
for D in $DESTINATION; do
--
1.7.2.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [Bitbake-dev] Bitbake task logging
On Tue, Jan 4, 2011 at 5:45 PM, Richard Purdie rpur...@rpsys.net wrote: On Wed, 2011-01-05 at 00:40 +0300, Yury Bushmelev wrote: 2011/1/1 Richard Purdie richard.pur...@linuxfoundation.org: I've been looking at the changes in bitbake master and those in Poky. Both are trying to improve the logging situation but I think we need to discuss/agree what we're trying to achieve. [skip] Thoughts/Comments/Suggestions? I'm interested in build perfomance monitoring/analyze. It would be great to have some tool (may be like bootchart) to be able to look at CPU time/RAM/Disk bandwidth/network traffic per task. You should already be able to do this with the addhandler functionality in a bbclass file to tap into bitbake's event stream. If you find you can't, we should enhance things so you can :). http://kergoth.pastey.net/142813 shows an example of using this to show per-task and per-build CPU usage and execution times. I intended to implement I/O and network, but it got pushed to the back burner. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Bitbake Architecture, Roadmap, Maintainers and the future
On Sat, Jan 1, 2011 at 12:49 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: The split between the code in general in bitbake is in general ever improving in my opinion. Chris has some some really great work on bitbake recently, particularly making it more pythonic. Some of the changes just before the holidays, particularly the UI changes on the cooker to UI relationship make me uncomfortable, particularly if they mean the xmlrpc client/server code no longer works. My concern is that they cross the boundary into what I'd class as regressing an API boundary, particularly one that is only in the early stages of being properly established and that we very much need. I don't know if this is an API you use or not but its the kind of thing we need to be careful about. FWIW, its independent of the parallel parsing code and other changes which is partly why I'm so concerned it was merged as is :(. Unless you think parallel parsing is the only work I've done on bitbake, I fail to see what it being independent of parallel parsing has to do with anything. Of course it's independent. It's entirely different work for an entirely different purpose, done on different branches, and trying to compare them is pointless and means nothing. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Bitbake task logging
On Sat, Jan 1, 2011 at 11:14 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I've been looking at the changes in bitbake master and those in Poky. Both are trying to improve the logging situation but I think we need to discuss/agree what we're trying to achieve. I'm trying to think about this from the user point of view. What does a user need and expect from bitbake to be as easy to use as possible and figure out whats going on. New users often ask what is it doing? what functions does it run? and its hard to work out for someone new to it. Some of the list below works today, some is close, some doesn't but I'm looking to work out what the experience should be, then we can figure out how to get there technically. The things I think we need are: a) A logfile per task. Agreed, and I'm pretty sure I merged this commit from poky already, to make it task bound rather than function bound. b) All output from the task should end up in the logfile, copied or otherwise, be it bitbake LogRecords, output to stdout, stderr or anything else. This is reasonable, though it could encourage python code to use non-bitbake mechanisms like print rather than the correct bitbake APIs for messaging. The only piece of this which is not happening today is stdout/stderr of python functions. If we do what you describe here, we can use the file descriptor redirection context manager in https://github.com/kergoth/bitbake/commit/3acd45c to do it in a clean way, rather than the old code which was crammed into exec_func. c) The logfile should be able to include different output from that shown in the UI console. For example, I think note output in the logfiles might be useful all the time, I'm wondering if it ever is useful on the UI console. Turning off note for the console but keeping it and maybe using it more in tasks could be useful. For example, exec_func() could note which functions are being executed and I can imagine a user finding that very useful in the log file for debugging (which is when a user would look there). Debug output is probably too verbose even for the log files in general but I'm open to persuasion one way or another on that. I think this point is up to the UIs. They have the log records, and can decide what to do with them. I'd suggest that we add more context to the log records (which we really need to do anyway, to ensure that UIs like goggle can *always* associate messages with a specific task), and let the UI decide which messages from where to display. I agree wholeheartedly on debug output being too verbose. We need to ensure that all debug messages are helpful to the user, and developers helping them -- I suspect that some of the ones we have today are remnants of us debugging bitbake internal behavior as opposed to that which is helpful in assisting the user, but that's just a guess. d) Handling of the default stdout is a tricky one. I think it makes most sense to redirect this to the logfile always, for both python and shell tasks. For bitbake itself, nothing in bitbake should be putting output there though IMO. This makes sense since we can control stdout from within bitbake itself but from within generic tasks we cannot make guarantees. Python tasks may make os.system calls, or run binaries and it would make sense for stdout to just work for these rather than need special handling or wrapper functions especially for log handling (they could be a good idea for other reasons). You've already stated that you want this in b) -- output to stdout, stderr or anything else.. I'm not sure how covering this twice in the same email helps, other than elaborating the aforementioned point. Even if we switch back to the file descriptor redirections to send everything to the log file for all tasks, we still need to do something to capture what's going to the log file and get it to the UI for the debug case, and blindly using tee the way it was before is not the solution, as that was going to the server stdout, not the UI. If we do it the way you describe, the same for all tasks, we'd likely have to spawn off a separate thread or process to read the log file and send that to the UI. This is an uglier solution, in my opinion, and risks more potential performance impact, though should only be necessary for the debug case, so its arguable. I'd question whether this is worthwhile, given the additional ugliness it adds to the code in multiple ways, simply to support python functions doing something they shouldn't be doing anyway -- print/os.system. e) I'm not 100% on this yet but I'm wondering if we should scrap stdout/stderr output to the UI console in debug mode, just make it clear where the output went on the console? If you ever have two tasks running the output is unreadable anyway. First, the stdout/stderr output doesn't go to the UI console, they're messages sent to the UI, and the UI decides what to do with it. The messages aren't
Re: [oe] [Bitbake-dev] Bitbake Architecture, Roadmap, Maintainers and the future
On Tue, Jan 4, 2011 at 4:17 PM, Richard Purdie rpur...@rpsys.net wrote: I'm also going to look at getting back the XMLRPC interfaces and abstraction that the removal of triggered this discussion. There does appear to be some differences in opinion on the future of bitbake from the server/UI perspective and I will do what I can to ensure we all have common goals. To clarify, the abstraction is not gone, only the server is. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] bitbake 1.10.2 tarball, where is it?
On Fri, Dec 31, 2010 at 5:45 AM, Koen Kooi k.k...@student.utwente.nl wrote: I would like to bump the requirement for bitbake in OE to 1.10.2, but the tarball for that still hasn't materialized. So what's the way forward for requiring 1.10.x in OE? It should be on berlios now. It's been available on the git server / via cgit, but I hadn't gotten it uploaded to berlios. Thanks for the reminder. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] avoid addtask?
On Fri, Dec 24, 2010 at 8:21 AM, Khem Raj raj.k...@gmail.com wrote:
On Fri, Dec 24, 2010 at 12:33 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
I was wondering whether it is better to avoid addtask where easily possible.
If the tasks are logically inline in existing tasks then it would be
ok. Although I dont know the big O notation of
runqueue algorithm to ascertain the gain.
Personally, I'd rather recipes stuck 100% to setting variables and
including files and inheriting classes, as simple and declarative as
possible, rather than changing behavior. It shouldn't be their
responsibility. I'd rather see the classes define tasks for common
things and let the recipes create the definitions for those tasks than
actually add their own, personally.
E.g. from one recipe:
do_postpatch() {
rm -rf patches rm -rf .pc mv -f debian/patches patches
quilt push -av
}
addtask postpatch after do_patch before do_configure
Wouldn't it be simpler and probably even a little bit faster just to say:
do_configure_prepend() {
rm -rf patches rm -rf .pc mv -f debian/patches patches
quilt push -av
}
Well this seems more like a patching task then configure to me.
I agree, this should likely just replace the patch task with its own
implementation.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] sanity: release 2010.12 is out, so bump minimum bitbake to 1.10.0 per TSC decision
On Wed, Dec 22, 2010 at 11:07 AM, Khem Raj raj.k...@gmail.com wrote: On Wed, Dec 22, 2010 at 8:43 AM, Chris Larson clar...@kergoth.com wrote: On Wed, Dec 22, 2010 at 9:35 AM, Tom Rini tom_r...@mentor.com wrote: I agree and would like it done soon too (well, I'd almost rather see 1.11 be required, yaaay parallel parsing) but since we can't tell 1.10.0 from .1 and I don't think this week (since that's just a few more days) is too bad. Chris, when can you do a 1.10.2? I might be able to get to it today. We really need to make the process more automated. We should also stop using berlios for bitbake release tarballs and just rely on the oe site / freshmeat / cgit, imo. our cgit now has the possibility to download tarballs so proabably just pointing to cgit ? e.g. http://git.openembedded.org/cgit.cgi/bitbake/snapshot/bitbake-1.10.1.tar.bz2 is there and so are others This won't work, unless we want to cause problems for other distros the way upstreams do for us. gzip includes timestamp information, if you wget bitbake-1.10.1.tar.gz twice with over a second between, you get tarballs with two different md5sums. We need pristine, specific, always locked down archives for releases. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [ANNOUNCE] BitBake 1.10.2
Greetings all, There is a new 1.10 bugfix release available: 1.10.2. As usual, there is a tag in the git repository, as well as pristine-tar metadata. The tarball isn't on berlios yet, but will be. Changes in Bitbake 1.10.2: - Fix GraphViz .dot output for rdepends and rrecs - cooker: fix UnboundLocalError - lib/bb/fetch/hg: fix fetching from a mercurial repository Thanks, -- Christopher Larson clarson at kergoth dot com Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [ANNOUNCE] BitBake 1.8.19
Greetings all, There is a new 1.8 bugfix release available: 1.8.19. As usual, there is a tag in the git repository, as well as pristine-tar metadata. The tarball isn't on berlios yet, but will be. Changes in BitBake 1.8.19: lib/bb/fetch/hg: fix fetching from a mercurial repository Fix bb.plain and bb.warn function Thanks, -- Christopher Larson clarson at kergoth dot com Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] base.bbclass changes broke BitBake 1.8.19
On Wed, Dec 22, 2010 at 1:28 AM, Koen Kooi k.k...@student.utwente.nl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21-12-10 23:00, Denys Dmytriyenko wrote: Chris, The c67b95955d023c1f198531b4f06100a40b05efa7 has introduced the following problem with BitBake 1.8.19 and even af81d52e48cb6d4f91fff0c70e09dfd421e0057d didn't fix it. Any thoughts? Thanks. Since the release is out, can be bump to 1.10.0 as minimum bitbake now? I'm all for this, personally. The only reason the TSC didn't decide to bump it already was the release, so I don't see any reason why not. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] sanity: release 2010.12 is out, so bump minimum bitbake to 1.10.0 per TSC decision
On Wed, Dec 22, 2010 at 9:35 AM, Tom Rini tom_r...@mentor.com wrote: I agree and would like it done soon too (well, I'd almost rather see 1.11 be required, yaaay parallel parsing) but since we can't tell 1.10.0 from .1 and I don't think this week (since that's just a few more days) is too bad. Chris, when can you do a 1.10.2? I might be able to get to it today. We really need to make the process more automated. We should also stop using berlios for bitbake release tarballs and just rely on the oe site / freshmeat / cgit, imo. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
