Re: [OE-core] The swap partition's size is too big for BSP?
On Mon, 2011-07-04 at 13:35 +0800, Cui, Dexuan wrote: In meta/recipes-core/initrdscripts/files/init-install.sh, we have # 5% for the swap swap_ratio=5 # dexuan: this variable is not used at all! ... swap_size=$((disk_size*5/100)) This algorithm seems too wasty -- e.g., for a CrownBay box with a 160GB disk, we would create a 8GB swap partition while the box has only 1GB memory. What's the proper swap size? This link http://www.cyberciti.biz/tips/linux-swap-space.html discussed this and I think the below algorithm seems suitable for us: Systems with 2GB of ram or less require the same size of swap space Systems with 2GB to 4GB of ram require a minimum of 2GB of swap space Systems with 4GB to 16GB of ram require a minimum of 4GB of swap space Systems with 16GB to 64GB of ram require a minimum of 8GB of swap space Systems with 64GB to 256GB of ram require a minimum of 16GB of swap space Any comment? Looks like a much better idea to me, I'll take patches :) For reference if you want to do suspend to disk (swap) you need a lot of swap space btw. Still no where near that much though! Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2]coreutils: Upgrade from 8.9 to 8.12
On Mon, 2011-07-04 at 14:04 +0800, Mei Lei wrote: Upgrade coreutils and update the distro_tracking_fields.inc The following changes since commit ad2363278f0ea86fcf3464f8f6073d3a3d06be63: Khem Raj (1): uclibc: Fix compilation in thumb mode are available in the git repository at: git://git.pokylinux.org/poky-contrib lmei3/coreutils http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lmei3/coreutils Mei Lei (2): coreutils: Upgrade from 8.9 to 8.12 distro_tracking_fields.inc: update recipes upgrade information Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1]curl: Upgrade from 7.21.6 to 7.21.7
On Mon, 2011-07-04 at 14:01 +0800, Mei Lei wrote:
The following changes since commit ad2363278f0ea86fcf3464f8f6073d3a3d06be63:
Khem Raj (1):
uclibc: Fix compilation in thumb mode
are available in the git repository at:
git://git.pokylinux.org/poky-contrib lmei3/curl
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lmei3/curl
Mei Lei (1):
curl: Upgrade from 7.21.6 to 7.21.7
.../curl/{curl_7.21.6.bb = curl_7.21.7.bb}|4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/curl/{curl_7.21.6.bb = curl_7.21.7.bb} (92%)
Merged to master, thanks.
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] resolvconf: update to version 1.58.
On Mon, 2011-07-04 at 11:18 +0200, Anders Darander wrote:
The old version has become unavailable from the download site.
Signed-off-by: Anders Darander and...@chargestorm.se
---
.../{resolvconf_1.48.bb = resolvconf_1.58.bb} |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
rename meta/recipes-connectivity/resolvconf/{resolvconf_1.48.bb =
resolvconf_1.58.bb} (87%)
Merged to master, thanks.
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] upgrade recipes
On Sun, 2011-07-03 at 21:03 +0800, Yu Ke wrote: upgrade the recipe libidn, libdrm, xauth, sqlite, also update the manual check field in distro_tracking_field The following changes since commit ad2363278f0ea86fcf3464f8f6073d3a3d06be63: Khem Raj (1): uclibc: Fix compilation in thumb mode are available in the git repository at: git://git.pokylinux.org/poky-contrib kyu3/upgrade-0701 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kyu3/upgrade-0701 Yu Ke (5): libidn: upgrade from 1.20 to 1.22 libdrm: upgrade to 2.4.26 xauth: upgrade from 1.05 to 1.06 sqlite: upgrade from 3.7.6.2 to 3.7.7.1 distro_tracking_field: update the manually check field Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PROPOSAL] Package feature switches, redux.
Since responses to my previous mail were generally positive, I've
reworked the package feature switches so that the interface is as RP
suggested.
In the recipe for foo you would have a set of features defined like
this:
PACKAGE_CONFIG[bar] = --enable-bar, --disable-bar, libbar
PACKAGE_CONFIG[baz] = --enable-baz, --disable-baz, libbaz
The default set of features for the package would be defined with:
PACKAGE_FEATURES ?= bar baz
Perhaps this set of features could go into a metadata field in the .ipk
- would this be helpful for feed users?
The package features can then be tailored in a config/layer with
something like:
PACKAGE_FEATURES_pn-foo = baz pop
If a layer requests a feature not supported by the recipe, you get a
warning (should help distro maintainers detect bitrot in their layer):
WARNING: foo: Unknown feature 'pop' requested
The patch below uses gstreamer as an example of something which would
benefit from this:
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 8f4ef1e..ee8e914 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -396,6 +396,30 @@ python () {
break
bb.data.setVar('MULTIMACH_ARCH', multiarch, d)
+
+features = bb.data.getVar('PACKAGE_FEATURES', d, True)
+if features:
+config = list(bb.data.getVarFlags('PACKAGE_CONFIG', d) or {})
+oeconf = [ (bb.data.getVar('EXTRA_OECONF', d, True) or '') ]
+depends = [ (bb.data.getVar('DEPENDS', d, True) or '') ]
+for feature in features.split():
+if feature in config:
+settings = bb.data.getVarFlag('PACKAGE_CONFIG', feature,
d).split(',')
+oeconf.append(settings[0])
+depends.append(settings[2])
+config.remove(feature)
+else:
+bb.warn(%s: Unknown feature '%s' requested % (pn, feature))
+
+for feature in config:
+settings = bb.data.getVarFlag('PACKAGE_CONFIG', feature,
d).split(',')
+oeconf.append(settings[1])
+
+if len(oeconf) 1:
+bb.data.setVar('EXTRA_OECONF', ' '.join(oeconf), d)
+
+if len(depends) 1:
+bb.data.setVar('DEPENDS', ' '.join(depends), d)
}
def check_gcc3(data):
diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
index f81011f..70f0171 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
@@ -6,10 +6,16 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605 \
file://gst/ffmpegcolorspace/utils.c;beginline=1;endline=20;md5=9c83a200b8e597b26ca29df20fc6ecd0
-DEPENDS += virtual/libx11 alsa-lib freetype gnome-vfs liboil libogg libvorbis
libxv libtheora avahi util-linux tremor
+DEPENDS += virtual/libx11 alsa-lib freetype gnome-vfs liboil libxv avahi
util-linux tremor
RDEPENDS_${PN} += gnome-vfs-plugin-file gnome-vfs-plugin-http
gnome-vfs-plugin-ftp \
gnome-vfs-plugin-sftp
+PACKAGE_CONFIG[ogg] = --enable-ogg, --disable-ogg, libogg
+PACKAGE_CONFIG[vorbis] = --enable-vorbis, --disable-vorbis, libvorbis
+PACKAGE_CONFIG[theora] = --enable-theora, --disable-theora, libtheora
+
+PACKAGE_FEATURES ?= ogg vorbis theora
+
SRC_URI += file://gst-plugins-base-tremor.patch
SRC_URI[md5sum] = 2920af2b3162f3d9fbaa7fabc8ed4d38
---
Cheers,
Chris.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] The swap partition's size is too big for BSP?
Richard Purdie wrote: On Mon, 2011-07-04 at 13:35 +0800, Cui, Dexuan wrote: In meta/recipes-core/initrdscripts/files/init-install.sh, we have # 5% for the swap swap_ratio=5 # dexuan: this variable is not used at all! ... swap_size=$((disk_size*5/100)) This algorithm seems too wasty -- e.g., for a CrownBay box with a 160GB disk, we would create a 8GB swap partition while the box has only 1GB memory. What's the proper swap size? This link http://www.cyberciti.biz/tips/linux-swap-space.html discussed this and I think the below algorithm seems suitable for us: Systems with 2GB of ram or less require the same size of swap space Systems with 2GB to 4GB of ram require a minimum of 2GB of swap space Systems with 4GB to 16GB of ram require a minimum of 4GB of swap space Systems with 16GB to 64GB of ram require a minimum of 8GB of swap space Systems with 64GB to 256GB of ram require a minimum of 16GB of swap space Any comment? Looks like a much better idea to me, I'll take patches :) Ok, I'll try to make a patch for this algorithm. For reference if you want to do suspend to disk (swap) you need a lot of swap space btw. Still no where near that much though! Does (or should )Yocto Linux support suspend-to-disk? I'm not sure about this. BTW: Linux can alse use a regular file as swap area. So in case the swap size is not enough (e.g., for suspend-to-disk), I think a user could create a big enough file to meet the need (I didn't test this with Linux yet). Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ppp: sync packaging with OE .dev
those don't get created on my system :( Op 4 jul. 2011 om 12:02 heeft Steffen Sledz sl...@dresearch-fe.de het volgende geschreven: Can you please resync again. Commit e05db51b7aea7a0359babd918d7efbb9cc213d83 introduces an own package for PPPoL2TP plugin. Adding that package fixes the following error message. NOTE: package ppp-2.4.5-r1: task do_qa_staging: Started WARNING: the following files were installed but not shipped in any package: WARNING: /usr/lib/pppd/2.4.5/pppol2tp.so WARNING: /usr/lib/pppd/2.4.5/openl2tp.so Regards, Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add support for remote layering.
On Saturday 02 July 2011 01:33:58 Jeremy Puhlman wrote: On 7/1/2011 2:37 PM, Richard Purdie wrote: If we go forward with the patch and don't reverse that decision it means that layers can sometimes be a thing that are above bitbake, sometimes not depending on the circumstances. This kind of goes back to work flow issue. Unless you plan to make it so you cannot use the layers with out the specific layering tools that are in development, bitbake will always need to support different work flows. We aren't going to tie bitbake layer support of local layers to the layer tooling, no. We're expressly trying to avoid that. You suggest that I'm trying to dictate workflow however I'd argue that I'm doing the opposite (see below regarding updating). I'm trying hard to avoid that kind of interwoven complexity as it makes code changes very hard to make in the future and leads to frequent breakage where multiple usage methods exist. Well in this case, there is little that is interwoven. The remote layers bit in the main thread of the execution is a single line in the cooker. Paul was saying that he wanted to more or less still implement the tool with in the bitbake code. Ironically, that will likely be more interwoven then this patch. I don't think that they will. Firstly, no hooks are needed to fetch a layer remotely - it's just a fetch; you call cooker to run through a parse and then run the fetch operations you need. No changes to the bitbake core should be necessary, as far as I can see. (I don't object to reworking fetcher initialisation so that they are set up correctly out of the box, though, that may be helpful to both approaches.) Secondly, the changes I have previously implemented within bitbake for use by bitbake-layers are generic and have negligible impact on bitbake operation. If you have any technical concerns with these, in all seriousness please reply to the patches on bitbake-devel; there's always room for improvement. When ever you evaluate any of the layers, they are downloaded and unpacked prior to examination of any of the meta data(stay bblayers.conf). More or less any place where you would evalute bblayers.conf you would evaluate the collection uri's. How you update(i.e. if they are git for example) should be setable via the already in place fetch mechanism. Updating is something I would like to allow to be a conscious action. That way, if you want to fetch down the metadata, then disconnect and carry on building, you can do so easily. Also, if you want to stay with the current version you have on disk, you know bitbake is not going to update the metadata in the course of doing the build, because you didn't explicitly ask it to. You're also free to make any additional changes on top of the fetched metadata before running the build. If bitbake is doing all the fetching/updating of metadata then immediately jumping into the build, there's no room for that - unless you use Ctrl+C to break out, which isn't really ideal. I think the piece I am missing at the moment is why having it as an external tool that largely replicates the same outward functionality as having it within bitbake presents a problem for the use case that you have. Is there some technical capability that we couldn't have using this approach - other than the fact that you're just calling bitbake and it does everything? If that's the only objection, would it not achieve the same thing if you had a small shell script that ran the fetch/update then bitbake? More or less you would just need to run the BBLAYERS var through the remote layers class then the end result is the BBLAYERS is just a list of directories like it is now, which is why there is only one line of change in the current thread of execution. Can something external to the bitbake code do that? Unless your planning on creating tooling that doesn't use any of the bitbake internals, not unless you want to duplicate a whole bunch of code. I don't plan to duplicate any significant amount of code. I'm not seeing that you couldn't do what was described using an external tool. When we extend the later tooling are we expected to extend this code to match functionality? Well if the end results of the layer tooling is a BBLAYERS with a list of directories as it is now, there is nothing to extend. The code handles that now. More or less if unless you are going in a drastically different direction with the BBLAYERS list, I am not sure what would need to be updated. Well, with my solution I would prefer to see BBLAYERS unchanged, so it just points to the local checkout of the remote layer. The abstraction in the remote layers code isn't strong enough to cope with that kind of interaction in its own right and I'm not sure its possible to do that simply with a line in a bblayers.conf file and still be readable. My problem with this is currently using the same uri mechanism used in
Re: [OE-core] [RFH] Wrong behaviour regarding SDK native and target paths
On Sun, 2011-07-03 at 19:29 -0300, Otavio Salvador wrote:
Hello,
I am looking for help to get our nativesdk working fine and I am quite
confused how does it can work after all.
I have looked at meta/recipes-qt/meta/meta-toolchain-qte.bb and it has:
QT_TOOLS_PREFIX = ${SDKPATHNATIVE}${bindir_nativesdk}
Running it is expanded to:
QT_TOOLS_PREFIX=/usr/local/oecore-i686-i586/sysroots/i686-oesdk-linux/usr/bin
It seems right but in fact it is wrong since Qt binaries are installed into:
(devel)~/hacking/el% tar tjf
tmp-eglibc-eglibc/deploy/sdk/oecore-i686-i586-toolchain-devel.tar.bz2|
grep 'bin/moc4'
./usr/local/oecore-i686-i686/sysroots/i686-oesdk-linux/usr/bin/moc4
so, the generated information for the script won't work.
I am quite confused by all this is suppose to work. Someone help me?
It looks like in OE-Core we have:
conf/bitbake.conf:SDKPATHNATIVE = ${SDKPATH}/sysroots/${SDK_SYS}
conf/bitbake.conf:SDKPATH = /usr/local/${SDK_NAME}
conf/bitbake.conf:SDK_NAME = oecore-${SDK_ARCH}-${TARGET_ARCH}
and in meta-yocto:
conf/distro/poky.conf:SDKPATH = /opt/${DISTRO}/${SDK_VERSION}
I suspect having TARGET_ARCH in the PATH might be a bad idea and we need
to rethink the defaults in OE-Core. Using something more like the
meta-yocto default above might help your problem.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] The swap partition's size is too big for BSP?
On Mon, 2011-07-04 at 20:02 +0800, Cui, Dexuan wrote: Richard Purdie wrote: For reference if you want to do suspend to disk (swap) you need a lot of swap space btw. Still no where near that much though! Does (or should )Yocto Linux support suspend-to-disk? I'm not sure about this. BTW: Linux can alse use a regular file as swap area. So in case the swap size is not enough (e.g., for suspend-to-disk), I think a user could create a big enough file to meet the need (I didn't test this with Linux yet). I don't think we've supported it in the past, its just a datapoint to keep in mind. For reference, you can't use a file easily since the VM data needs to be available as the kernel boots to be able to resume from it. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] The swap partition's size is too big for BSP?
Richard Purdie wrote: On Mon, 2011-07-04 at 20:02 +0800, Cui, Dexuan wrote: Richard Purdie wrote: For reference if you want to do suspend to disk (swap) you need a lot of swap space btw. Still no where near that much though! Does (or should )Yocto Linux support suspend-to-disk? I'm not sure about this. BTW: Linux can alse use a regular file as swap area. So in case the swap size is not enough (e.g., for suspend-to-disk), I think a user could create a big enough file to meet the need (I didn't test this with Linux yet). I don't think we've supported it in the past, its just a datapoint to keep in mind. Ok, so I can put a comment when I make the patch, saying this new algorithm doesn't work with suspend-to-disk in future. For reference, you can't use a file easily since the VM data needs to be available as the kernel boots to be able to resume from it. I admit I didn't try this on Linux. Windows does use a regular file when doing suspend-to-disk, so I thought Linux could do it, too... :-) Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PROPOSAL] Package feature switches, redux.
On Mon, 2011-07-04 at 12:54 +0100, Chris Elston wrote:
Since responses to my previous mail were generally positive, I've
reworked the package feature switches so that the interface is as RP
suggested.
In the recipe for foo you would have a set of features defined like
this:
PACKAGE_CONFIG[bar] = --enable-bar, --disable-bar, libbar
PACKAGE_CONFIG[baz] = --enable-baz, --disable-baz, libbaz
The default set of features for the package would be defined with:
PACKAGE_FEATURES ?= bar baz
Perhaps this set of features could go into a metadata field in the .ipk
- would this be helpful for feed users?
The package features can then be tailored in a config/layer with
something like:
PACKAGE_FEATURES_pn-foo = baz pop
If a layer requests a feature not supported by the recipe, you get a
warning (should help distro maintainers detect bitrot in their layer):
WARNING: foo: Unknown feature 'pop' requested
The patch below uses gstreamer as an example of something which would
benefit from this:
Looks good, thanks.
My main concern is still the PACKAGE_FEATURES variable. I've been
meaning to reply to your original email about this.
I understand your issue that you want to be able to do this on a per
package basis. I suspect you also see my concern about maintain this
centrally as a distro decision primarily rather than letting things
descend into more of a free for all.
FWIW, even if done centrally using DISTRO_FEATURES, you can customise on
a per recipe basis if you ever needed to, e.g.:
DISTRO_FEATURES = a b c ${MYDISTROTWEAKS}
MYDISTROTWEAKS = d e f
MYDISTROTWEAKS_pn-gstreamer = e
Now I'd agree this is a bit ugly but I think it would encourage less
misuse of the variable.
Any thoughts on that?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] insane bbclass: turn fatal errors back into fatal errors
On Friday 01 July 2011 18:12:47 Richard Purdie wrote: Any volunteers for qt4-x11-free-4.7.3? I'll take a look at it. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PROPOSAL] Package feature switches, redux.
On 07/04/2011 12:54 PM, Chris Elston wrote: Since responses to my previous mail were generally positive, I've reworked the package feature switches so that the interface is as RP suggested. In the recipe for foo you would have a set of features defined like this: PACKAGE_CONFIG[bar] = --enable-bar, --disable-bar, libbar PACKAGE_CONFIG[baz] = --enable-baz, --disable-baz, libbaz The default set of features for the package would be defined with: PACKAGE_FEATURES ?= bar baz Perhaps this set of features could go into a metadata field in the .ipk - would this be helpful for feed users? The package features can then be tailored in a config/layer with something like: PACKAGE_FEATURES_pn-foo = baz pop If a layer requests a feature not supported by the recipe, you get a warning (should help distro maintainers detect bitrot in their layer): Hi, with my Angstrom cap on I like this syntax and I think it will be really useful. A second level concern I have is about conflicting features, its not something we will come across probably in DISTRO land as we are sensible enough not to select them. But users could select them in local.conf. Graeme ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PROPOSAL] Package feature switches, redux.
Hi, with my Angstrom cap on I like this syntax and I think it will be really useful. A second level concern I have is about conflicting features, its not something we will come across probably in DISTRO land as we are sensible enough not to select them. But users could select them in local.conf. Graeme As a new developer, I've discovered that there are plenty of things that you can set in local.conf which break things :D Could you please give an example of conflicting features that could cause problems, I'm not experienced enough with OE to have encountered that problem yet. Cheers, Chris. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PROPOSAL] Package feature switches, redux.
On 07/04/2011 05:12 PM, Chris Elston wrote: Hi, with my Angstrom cap on I like this syntax and I think it will be really useful. A second level concern I have is about conflicting features, its not something we will come across probably in DISTRO land as we are sensible enough not to select them. But users could select them in local.conf. Graeme As a new developer, I've discovered that there are plenty of things that you can set in local.conf which break things :D Could you please give an example of conflicting features that could cause problems, I'm not experienced enough with OE to have encountered that problem yet. Cant think of a solid one off the top of my head, but I mean the cases where --enable-feature means that --disable-another-feature is done. This is why I listed it as a secondary issue. Graeme ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/8] Various QA fixes
The following changes since commit 2b3bf5350861f62435e2fdf1c56c8a02f4b1b4ac fix a number of QA warnings/errors. There are a couple of RFC style commits in this mix: A key change is that functionality is added to insane.bbclass to allow skipping of individual QA tests by name. It needs two existing users (elfutils and u-boot) to specify which QA tests they want to skip (I'm working on a patch). Any external layer using that variable would need to update and I can't decide if that is a drawback or a feature. Also a gettext change I'm testing to see which approach performs best is included. A final decision on that will depend on the performance test results (thanks go to paul for hightlighting the impact of that git-native depenedency). Also included is a gcc libiberty fix (yocto #1199). They are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rpurdie/master http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rpurdie/master Richard Purdie (5): gcc: Fix removal of libiberty.a gettext: Disable both git and cvs for autopoint's archive format. gcc: Remove unneeded module .la file and .so link insane.bbclass: Allow INSANE_SKIP to work on a per test basis lttng-viewer: Fixup various QA warnings and a false positive Richard Purdie (3): oprofile: Fix QA warnings libgsmd: Fix QA warnings gcc-package-cross: Switch to using pattern matching to detect when to stash libgcc into the sysroot meta/classes/insane.bbclass| 37 +++- meta/recipes-connectivity/gsm/gsmd.inc | 26 ++ meta/recipes-core/gettext/gettext_0.18.1.1.bb |7 ++-- meta/recipes-devtools/gcc/gcc-4.6.inc |2 +- .../gcc/gcc-cross-intermediate.inc |4 +- meta/recipes-devtools/gcc/gcc-package-cross.inc| 30 --- meta/recipes-devtools/gcc/gcc-package-target.inc |6 ++- meta/recipes-devtools/gcc/gcc_4.5.1.bb |2 +- meta/recipes-kernel/lttng/lttng-viewer_0.12.38.bb |6 ++- meta/recipes-kernel/oprofile/oprofile_0.9.6.bb |4 ++ 10 files changed, 75 insertions(+), 49 deletions(-) -- 1.7.4.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/8] oprofile: Fix QA warnings
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-kernel/oprofile/oprofile_0.9.6.bb |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-kernel/oprofile/oprofile_0.9.6.bb
b/meta/recipes-kernel/oprofile/oprofile_0.9.6.bb
index eb707e0..603500d 100644
--- a/meta/recipes-kernel/oprofile/oprofile_0.9.6.bb
+++ b/meta/recipes-kernel/oprofile/oprofile_0.9.6.bb
@@ -15,6 +15,10 @@ DEPENDS = popt binutils
RDEPENDS_${PN} = binutils-symlinks
RRECOMMENDS_${PN} = kernel-vmlinux
+FILES_${PN} = ${bindir} ${libdir}/${BPN}/lib*.so.* ${datadir}/${BPN}
+FILES_${PN}-dev += ${libdir}/${BPN}/lib*.so ${libdir}/${BPN}/lib*.la
+FILES_${PN}-staticdev += ${libdir}/${BPN}/lib*.a
+
PR = r1
SRC_URI = ${SOURCEFORGE_MIRROR}/oprofile/oprofile-${PV}.tar.gz \
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/8] libgsmd: Fix QA warnings
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-connectivity/gsm/gsmd.inc | 26 +++---
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-connectivity/gsm/gsmd.inc
b/meta/recipes-connectivity/gsm/gsmd.inc
index b2aebb1..682456b 100644
--- a/meta/recipes-connectivity/gsm/gsmd.inc
+++ b/meta/recipes-connectivity/gsm/gsmd.inc
@@ -35,11 +35,13 @@ PACKAGES =+ \
${PN}-tools \
${BASEPN}-plugins \
${BASEPN}-plugin-machine-generic \
+ ${BASEPN}-plugin-machine-telit \
${BASEPN}-plugin-machine-tihtc \
${BASEPN}-plugin-machine-gta01 \
${BASEPN}-plugin-vendor-bcm \
${BASEPN}-plugin-vendor-qc \
${BASEPN}-plugin-vendor-ti \
+ ${BASEPN}-plugin-vendor-telit \
${BASEPN}-plugin-vendor-tihtc \
@@ -47,11 +49,13 @@ ALLOW_EMPTY_${BASEPN}-plugin-machine-gta01 = 1
RDEPENDS_${BASEPN}-plugins = \
${BASEPN}-plugin-machine-generic \
+ ${BASEPN}-plugin-machine-telit \
${BASEPN}-plugin-machine-tihtc \
${BASEPN}-plugin-machine-gta01 \
${BASEPN}-plugin-vendor-bcm \
${BASEPN}-plugin-vendor-qc \
${BASEPN}-plugin-vendor-ti \
+ ${BASEPN}-plugin-vendor-telit \
${BASEPN}-plugin-vendor-tihtc \
@@ -59,15 +63,19 @@ RDEPENDS_${PN} += update-rc.d initscripts
RRECOMMENDS_${PN} += ${BASEPN}-plugins
FILES_${PN}-dbg += ${libdir}/gsmd/.debug/*
+FILES_${PN}-dev += ${libdir}/gsmd/*.so ${libdir}/gsmd/*.la
+FILES_${PN}-staticdev += ${libdir}/gsmd/*.a
FILES_${PN}-tools = ${bindir}/*
FILES_${BASEPN}-plugins =
-FILES_${BASEPN}-plugin-machine-generic =
${libdir}/gsmd/libgsmd-machine_generic.so*
-FILES_${BASEPN}-plugin-machine-tihtc =
${libdir}/gsmd/libgsmd-machine_tihtc.so*
-FILES_${BASEPN}-plugin-machine-gta01 =
${libdir}/gsmd/libgsmd-machine_gta01.so*
-FILES_${BASEPN}-plugin-vendor-qc = ${libdir}/gsmd/libgsmd-vendor_qc.so*
-FILES_${BASEPN}-plugin-vendor-bcm = ${libdir}/gsmd/libgsmd-vendor_bcm.so*
-FILES_${BASEPN}-plugin-vendor-ti = ${libdir}/gsmd/libgsmd-vendor_ti.so*
-FILES_${BASEPN}-plugin-vendor-tihtc = ${libdir}/gsmd/libgsmd-vendor_tihtc.so*
+FILES_${BASEPN}-plugin-machine-generic =
${libdir}/gsmd/libgsmd-machine_generic.so.*
+FILES_${BASEPN}-plugin-machine-tihtc =
${libdir}/gsmd/libgsmd-machine_tihtc.so.*
+FILES_${BASEPN}-plugin-machine-telit =
${libdir}/gsmd/libgsmd-machine_telit.so.*
+FILES_${BASEPN}-plugin-machine-gta01 =
${libdir}/gsmd/libgsmd-machine_gta01.so.*
+FILES_${BASEPN}-plugin-vendor-qc = ${libdir}/gsmd/libgsmd-vendor_qc.so.*
+FILES_${BASEPN}-plugin-vendor-bcm = ${libdir}/gsmd/libgsmd-vendor_bcm.so.*
+FILES_${BASEPN}-plugin-vendor-ti = ${libdir}/gsmd/libgsmd-vendor_ti.so.*
+FILES_${BASEPN}-plugin-vendor-telit =
${libdir}/gsmd/libgsmd-vendor_telit.so.*
+FILES_${BASEPN}-plugin-vendor-tihtc =
${libdir}/gsmd/libgsmd-vendor_tihtc.so.*
PACKAGES_DYNAMIC = lib${BASEPN}* ${BASEPN}
@@ -77,20 +85,24 @@ RCONFLICTS_lib${BASEPN} = lib${CONFLICTNAME}
RCONFLICTS_${BASEPN} = ${CONFLICTNAME}
RCONFLICTS_${BASEPN}-plugins = ${CONFLICTNAME}-plugins
RCONFLICTS_${BASEPN}-plugin-machine-generic =
${CONFLICTNAME}-plugin-machine-generic
+RCONFLICTS_${BASEPN}-plugin-machine-telit =
${CONFLICTNAME}-plugin-machine-telit
RCONFLICTS_${BASEPN}-plugin-machine-tihtc =
${CONFLICTNAME}-plugin-machine-tihtc
RCONFLICTS_${BASEPN}-plugin-machine-gta01 =
${CONFLICTNAME}-plugin-machine-gta01
RCONFLICTS_${BASEPN}-plugin-vendor-qc = ${CONFLICTNAME}-plugin-vendor-qc
RCONFLICTS_${BASEPN}-plugin-vendor-bcm = ${CONFLICTNAME}-plugin-vendor-bcm
RCONFLICTS_${BASEPN}-plugin-vendor-ti = ${CONFLICTNAME}-plugin-vendor-ti
+RCONFLICTS_${BASEPN}-plugin-vendor-telit =
${CONFLICTNAME}-plugin-vendor-telit
RCONFLICTS_${BASEPN}-plugin-vendor-tihtc =
${CONFLICTNAME}-plugin-vendor-tihtc
RPROVIDES_lib${BASEPN} += lib${CONFLICTNAME}
RPROVIDES_${BASEPN} = ${CONFLICTNAME}
RPROVIDES_${BASEPN}-plugins = ${CONFLICTNAME}-plugins
RPROVIDES_${BASEPN}-plugin-machine-generic =
${CONFLICTNAME}-plugin-machine-generic
+RPROVIDES_${BASEPN}-plugin-machine-telit =
${CONFLICTNAME}-plugin-machine-telit
RPROVIDES_${BASEPN}-plugin-machine-tihtc =
${CONFLICTNAME}-plugin-machine-tihtc
RPROVIDES_${BASEPN}-plugin-machine-gta01 =
${CONFLICTNAME}-plugin-machine-gta01
RPROVIDES_${BASEPN}-plugin-vendor-qc = ${CONFLICTNAME}-plugin-vendor-qc
RPROVIDES_${BASEPN}-plugin-vendor-bcm = ${CONFLICTNAME}-plugin-vendor-bcm
RPROVIDES_${BASEPN}-plugin-vendor-ti = ${CONFLICTNAME}-plugin-vendor-ti
+RPROVIDES_${BASEPN}-plugin-vendor-telit = ${CONFLICTNAME}-plugin-vendor-telit
RPROVIDES_${BASEPN}-plugin-vendor-tihtc = ${CONFLICTNAME}-plugin-vendor-tihtc
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/8] lttng-viewer: Fixup various QA warnings and a false positive
From: Richard Purdie richard.pur...@linuxfoundation.org
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-kernel/lttng/lttng-viewer_0.12.38.bb |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/lttng/lttng-viewer_0.12.38.bb
b/meta/recipes-kernel/lttng/lttng-viewer_0.12.38.bb
index 5e7bd4c..233d836 100644
--- a/meta/recipes-kernel/lttng/lttng-viewer_0.12.38.bb
+++ b/meta/recipes-kernel/lttng/lttng-viewer_0.12.38.bb
@@ -9,7 +9,7 @@ LICENSE = GPLv2 LGPLv2.1
LIC_FILES_CHKSUM = file://COPYING;md5=f650d5f5af1e9648fe0b40e290d3adbb \
file://ltt/ltt.h;beginline=2;endline=18;md5=8b7da9190028c50396d97fc85bad0da9 \
file://lttv/lttv/traceset.c;beginline=2;endline=17;md5=bcab42863b64b41d153bf81bbe2490a6
-PR = r1
+PR = r2
DEPENDS = gtk+ pango popt
@@ -34,4 +34,6 @@ FILES_${PN} += \
${datadir}/lttv/facilities/* \
${datadir}/lttv/pixmaps/*
FILES_${PN}-dbg += ${libdir}/lttv/plugins/.debug/
-
+FILES_${PN}-dev += ${libdir}/lttv/plugins/*.la
+FILES_${PN}-staticdev += ${libdir}/lttv/plugins/*.a
+INSANE_SKIP_${PN} = dev-so
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/8] gcc: Fix removal of libiberty.a
From: Richard Purdie richard.pur...@linuxfoundation.org
The changes in commit 553a92c442bc3a35d1520a22e640a3a0e377b8f7 were not
applying correctly
due to the error: find: paths must precede expression
This patch corrects the find syntax.
[YOCTO #1199]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-devtools/gcc/gcc-4.6.inc |2 +-
.../gcc/gcc-cross-intermediate.inc |4 ++--
meta/recipes-devtools/gcc/gcc-package-cross.inc|4 ++--
meta/recipes-devtools/gcc/gcc-package-target.inc |4 ++--
meta/recipes-devtools/gcc/gcc_4.5.1.bb |2 +-
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc
b/meta/recipes-devtools/gcc/gcc-4.6.inc
index a012049..6844995 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@
require gcc-common.inc
-PR = r4
+PR = r5
# Third digit in PV should be incremented after a minor release
# happens from this branch on gcc e.g. currently its 4.6.0
diff --git a/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
b/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
index 05b5dbc..df5958a 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
@@ -40,8 +40,8 @@ do_install () {
rm -rf ${D}${datadir}/
# We use libiberty from binutils
- find -name libiberty.a ${D}${exec_prefix}/lib | xargs rm -f
- find -name libiberty.h ${D}${exec_prefix}/lib | xargs rm -f
+ find ${D}${exec_prefix}/lib -name libiberty.a | xargs rm -f
+ find ${D}${exec_prefix}/lib -name libiberty.h | xargs rm -f
# Insert symlinks into libexec so when tools without a prefix are
searched for, the correct ones are
# found. These need to be relative paths so they work in different
locations.
diff --git a/meta/recipes-devtools/gcc/gcc-package-cross.inc
b/meta/recipes-devtools/gcc/gcc-package-cross.inc
index b51336b..3d27788 100644
--- a/meta/recipes-devtools/gcc/gcc-package-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-package-cross.inc
@@ -29,8 +29,8 @@ do_install () {
done
# We use libiberty from binutils
- find -name libiberty.a ${D}${exec_prefix}/lib | xargs rm -f
- find -name libiberty.h ${D}${exec_prefix}/lib | xargs rm -f
+ find ${D}${exec_prefix}/lib -name libiberty.a | xargs rm -f
+ find ${D}${exec_prefix}/lib -name libiberty.h | xargs rm -f
# gcc-runtime installs libgcc into a special location in staging since
it breaks doing a standalone build
if [ ${PN} == gcc-cross -o ${PN} == gcc-crosssdk ]; then
diff --git a/meta/recipes-devtools/gcc/gcc-package-target.inc
b/meta/recipes-devtools/gcc/gcc-package-target.inc
index 43e2bd5..6cc308c 100644
--- a/meta/recipes-devtools/gcc/gcc-package-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-package-target.inc
@@ -88,8 +88,8 @@ do_install () {
rm -f *gcc-?.?*
# We use libiberty from binutils
- find -name libiberty.a ${D}${exec_prefix}/lib | xargs rm -f
- find -name libiberty.h ${D}${exec_prefix}/lib | xargs rm -f
+ find ${D}${exec_prefix}/lib -name libiberty.a | xargs rm -f
+ find ${D}${exec_prefix}/lib -name libiberty.h | xargs rm -f
# Symlinks so we can use these trivially on the target
ln -sf ${TARGET_PREFIX}g77 g77 || true
diff --git a/meta/recipes-devtools/gcc/gcc_4.5.1.bb
b/meta/recipes-devtools/gcc/gcc_4.5.1.bb
index e04f443..785d719 100644
--- a/meta/recipes-devtools/gcc/gcc_4.5.1.bb
+++ b/meta/recipes-devtools/gcc/gcc_4.5.1.bb
@@ -1,4 +1,4 @@
-PR = r5
+PR = r6
require gcc-${PV}.inc
require gcc-configure-target.inc
require gcc-package-target.inc
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/8] gcc: Remove unneeded module .la file and .so link
From: Richard Purdie richard.pur...@linuxfoundation.org
This avoids a QA error.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-devtools/gcc/gcc-4.6.inc|2 +-
meta/recipes-devtools/gcc/gcc-package-target.inc |2 ++
meta/recipes-devtools/gcc/gcc_4.5.1.bb |2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc
b/meta/recipes-devtools/gcc/gcc-4.6.inc
index 6844995..a880111 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@
require gcc-common.inc
-PR = r5
+PR = r6
# Third digit in PV should be incremented after a minor release
# happens from this branch on gcc e.g. currently its 4.6.0
diff --git a/meta/recipes-devtools/gcc/gcc-package-target.inc
b/meta/recipes-devtools/gcc/gcc-package-target.inc
index 6cc308c..8c66c72 100644
--- a/meta/recipes-devtools/gcc/gcc-package-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-package-target.inc
@@ -72,6 +72,8 @@ do_install () {
# Cleanup some of the ${libdir}{,exec}/gcc stuff ...
rm -r ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/install-tools
rm -r ${D}${libexecdir}/gcc/${TARGET_SYS}/${BINV}/install-tools
+ rm -r ${D}${libexecdir}/gcc/${TARGET_SYS}/${BINV}/*.so
+ rm -r ${D}${libexecdir}/gcc/${TARGET_SYS}/${BINV}/*.la
# Hack around specs file assumptions
test -f ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/specs sed -i -e
'/^*cross_compile:$/ { n; s/1/0/; }'
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/specs
diff --git a/meta/recipes-devtools/gcc/gcc_4.5.1.bb
b/meta/recipes-devtools/gcc/gcc_4.5.1.bb
index 785d719..12e42c4 100644
--- a/meta/recipes-devtools/gcc/gcc_4.5.1.bb
+++ b/meta/recipes-devtools/gcc/gcc_4.5.1.bb
@@ -1,4 +1,4 @@
-PR = r6
+PR = r7
require gcc-${PV}.inc
require gcc-configure-target.inc
require gcc-package-target.inc
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/8] insane.bbclass: Allow INSANE_SKIP to work on a per test basis
From: Richard Purdie richard.pur...@linuxfoundation.org
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/classes/insane.bbclass | 37 -
1 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index a6f9c1e..3572ce7 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -383,7 +383,7 @@ def package_qa_check_staged(path,d):
return sane
# Walk over all files in a directory and call func
-def package_qa_walk(path, warnfuncs, errorfuncs, package, d):
+def package_qa_walk(path, warnfuncs, errorfuncs, skip, package, d):
import oe.qa
#if this will throw an exception, then fix the dict above
@@ -414,7 +414,7 @@ def package_qa_walk(path, warnfuncs, errorfuncs, package,
d):
return len(errors) == 0
-def package_qa_check_rdepends(pkg, pkgdest, d):
+def package_qa_check_rdepends(pkg, pkgdest, skip, d):
sane = True
if not -dbg in pkg and not task- in pkg and not -image in pkg:
# Copied from package_ipk.bbclass
@@ -439,7 +439,7 @@ def package_qa_check_rdepends(pkg, pkgdest, d):
# Now do the sanity check!!!
for rdepend in rdepends:
-if -dbg in rdepend:
+if -dbg in rdepend and debug-deps not in skip:
error_msg = %s rdepends on %s % (pkgname,rdepend)
sane = package_qa_handle_error(debug-deps, error_msg, d)
@@ -480,27 +480,30 @@ python do_package_qa () {
testmatrix = d.getVarFlags(QAPATHTEST)
g = globals()
-warnchecks = []
-for w in (d.getVar(WARN_QA, True) or ).split():
-if w in testmatrix and testmatrix[w] in g:
-warnchecks.append(g[testmatrix[w]])
-errorchecks = []
-for e in (d.getVar(ERROR_QA, True) or ).split():
-if e in testmatrix and testmatrix[e] in g:
-errorchecks.append(g[testmatrix[e]])
-
walk_sane = True
rdepends_sane = True
for package in packages.split():
-if bb.data.getVar('INSANE_SKIP_' + package, d, True):
-bb.note(Package: %s (skipped) % package)
-continue
+skip = (bb.data.getVar('INSANE_SKIP_' + package, d, True) or
).split()
+if skip:
+bb.note(Package %s skipping QA tests: %s % (package, str(skip)))
+warnchecks = []
+for w in (d.getVar(WARN_QA, True) or ).split():
+if w in skip:
+ continue
+if w in testmatrix and testmatrix[w] in g:
+warnchecks.append(g[testmatrix[w]])
+errorchecks = []
+for e in (d.getVar(ERROR_QA, True) or ).split():
+if e in skip:
+ continue
+if e in testmatrix and testmatrix[e] in g:
+errorchecks.append(g[testmatrix[e]])
bb.note(Checking Package: %s % package)
path = %s/%s % (pkgdest, package)
-if not package_qa_walk(path, warnchecks, errorchecks, package, d):
+if not package_qa_walk(path, warnchecks, errorchecks, skip, package,
d):
walk_sane = False
-if not package_qa_check_rdepends(package, pkgdest, d):
+if not package_qa_check_rdepends(package, pkgdest, skip, d):
rdepends_sane = False
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PROPOSAL] Package feature switches, redux.
On Mon, 2011-07-04 at 17:44 +0100, Graeme Gregory wrote: On 07/04/2011 05:12 PM, Chris Elston wrote: Hi, with my Angstrom cap on I like this syntax and I think it will be really useful. A second level concern I have is about conflicting features, its not something we will come across probably in DISTRO land as we are sensible enough not to select them. But users could select them in local.conf. Graeme As a new developer, I've discovered that there are plenty of things that you can set in local.conf which break things :D Could you please give an example of conflicting features that could cause problems, I'm not experienced enough with OE to have encountered that problem yet. Cant think of a solid one off the top of my head, but I mean the cases where --enable-feature means that --disable-another-feature is done. This is why I listed it as a secondary issue. Graeme I understand. We could capture that information with an optional extra field in the config info something like: PACKAGE_CONFIG[foo] = --enable-foo, --disable-foo, libfoo, options which conflict with foo And then detect the conflict. It's a trade off of time to handle that conflicts field, versus how many potential conflicts there are I guess. I think we could add it later if it turned out to be a common problem. Cheers, Chris. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
