Re: [oe] [PATCH] cairo: disable native atomic operations, conflicts with libatomics-ops
On Wed, 2011-03-16 at 21:25 -0400, Denys Dmytriyenko wrote: * Add --disable-atomic to configure, otherwise it finds previously staged libatomics-ops from pulseaudio, which doesn't have the necessary primitives: * From my previous builds I see that cairo used to build before libatomics-ops was staged, avoiding this issue. The observant reader would note that this is another example where per-recipe staging/sysroot would properly solve the problem. /Esben ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Python-native dependency in libxml2
Hello Martin/Frans and Khem,
Any recommendation after following analysis that how should I proceed.
Should I send the patches to community?
Regards,
Noor
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
Ahsan, Noor
Sent: Thursday, March 17, 2011 3:41 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Python-native dependency in libxml2
Hello,
Today I got the fresh stuff and tried to build gnome-doc-utils-native
(to build xml2po package). I am building on Ubuntu host 9.10. First it
gave me an error that it could not find intltoolize command. You can see
the attached build log build_intltool_error,log. So I added intltool
package in gnome-doc-utils-native DEPENDS so it built successfully. You
can see the build log build_intltool_fix.log. Then I removed all the
build stuff from build DIR and commented DEPENDS_virtclass-native =
python-native and XPY_virtclass-native =
--with-python=${PYTHON_DIR} in libxml2.inc file. Rebuild
gnome-doc-utils-native. It built successfully again. The build log is
also attached build_no_python.log. I think there is no need of python
dependency in libxml2 package. Kindly correct me if I am doing anything
wrong.
We need to fix gnome-doc-utils-native recipe, so that it does not show
intltoolize error.
Regards,
Noor
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
Ahsan, Noor
Sent: Wednesday, March 16, 2011 1:39 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Python-native dependency in libxml2
Hello,
I made 2 changes, first one was to remove python-native from DEPENDS and
second was commented out XPY_virtclass-native =
--with-python=${PYTHON_DIR}. Moreover I removed all the stuff from
build dir, so there were not python-native for me. After kicking this
build libxml2-native build fine.
I was looking for xml2po recipe, I couldn't find it. Can you tell me how
to build xml2po package so that I can reproduce the problem.
Regards,
Noor
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
Martin Jansa
Sent: Wednesday, March 16, 2011 1:05 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Python-native dependency in libxml2
On Wed, Mar 16, 2011 at 08:28:39AM +0100, Frans Meulenbroeks wrote:
2011/3/16 Khem Raj raj.k...@gmail.com:
On 3/15/2011 11:22 PM, Ahsan, Noor wrote:
Hello,
I was looking at the libxml2 package. While going through the
recipes I
came to know that its native package depends on python-native
package as
well. This dependency is defined in libxml2.inc file.
DEPENDS_virtclass-native = python-native
This package build fine after removing this dependency. I am not
clear
why this dependency is being added in libxml2 package. Can somebody
clear that to me. While looking at the git log I came to know that
this
change is coming from libxml2-native.inc file. But I am not clear
why
this dependency was added as this package build fine without it.
Please help me in understanding this dependency. Thanks.
Try to build this recipe from scratch and see if it still works then
we can
remove the dep
That's not enough, libxml2-native builds fine.. but then xml2po
will fail if there isn't libxml2-native built with python support.
see a25f07ca6159e1cd5b8a215ca5da8405fb1b9053
So yes.. for such tests you should build recipe from scratch _and_ check
if resulting package/sysroot is still the same.
Regards,
I'm not sure if that is the right way.
It might well be that typically python-native is already there in a
scratch build because some earlier package needed it (or even because
of the scheduling of build steps.
Probably a better way is to build with packaged staging (with staging
dir outside TMPDIR) then rm TMPDIR and bake the package.
Alternately peek into the package to see if it needs python. If it is
needed then the DEPENDS should stay.
Looking at the issue at hand maybe the best person to ask is Martin
Jansa as he last touched that line according to git blame:
3cd9ddbf recipes/libxml/libxml2.inc (Martin Jansa
2010-02-26 12:32:53 +0100 5) DEPENDS_virtclass-native =
python-native
The other thing is that further on in the .inc file I see:
XPY_virtclass-native = --with-python=${PYTHON_DIR}
This strongly suggests a hard dependency on python, so removing the
DEPENDS because it builds without it does not seem to be a good plan
to me.
My strong feeling is that recipes should be self-contained (so should
list all packages they need to build, minus the ones that are
inherited from classes (and maybe a few implicit ones like maybe make)
Frans
___
Openembedded-devel mailing list
Re: [oe] OE Bugzilla Future
2011/3/17 Richard Purdie richard.pur...@linuxfoundation.org: On Thu, 2011-03-17 at 19:10 +0100, Michael 'Mickey' Lauer wrote: I'm in favor of keeping it, cleaning it up, and improve the integration with patchwork / git. Throwing it away would be a very bad sign to all those countless people who've gone through the pains of actually working with the bugtracker. The simple question is who is actually going to sort out the mess its in? Who is going to look after it on a continuing basis? If there isn't ownership, nothing is going to change. Actually I feel the real problem is that: - people did not want to get bugs assigned to them (at least that was what someone told me in the past) - we're lacking a good notion of package or recipe ownership, so even if we had someone acting as a bug manager, (s)he would have a hard time to find out who to assign an issue to. and of course it takes discipline to look at regular intervals in the bug tracker to see if there are issues that affect the recipes you feel responsible for. A discipline that few people have and that is also easy to forget if there is only very rarely something for you. So it is more of a process issue. (btw this may be something that could be picked up by the TSC). Frans. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Triggering kgdb on linux-2.6.37 with ttyOx
In recent kernels the omap serial consoles have been renamed from ttySx to ttyOx. This seems to be an issue for kgdb. Setting kernel boot parameters has no effect: kgdb=ttyO2,115200n8 kgdboc=ttyO2,115200n8 kgdbwait and attempting to trigger kgdb from the console also fails: # echo ttyO2 /sys/module/kgdboc/parameters/kgdboc -bash: echo: write error: No such device Attempting to send 'g' to sysrequest also does nothing, not sure if there has been changes to the magic sysrq stuff as well? # echo g /proc/sysrq-trigger [ 120.267944] SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) t haw-filesystems(J) saK show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync s how-task-states(T) Unmount show-blocked-tasks(W) I've had a look at the kgdb code, but I can't figure out what to patch to make it understand that ttyO2 is a valid terminal. Any suggestions? Thanks, Tarjei ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Python-native dependency in libxml2
On Fri, Mar 18, 2011 at 08:41:40AM +0100, Ahsan, Noor wrote:
Hello Martin/Frans and Khem,
Any recommendation after following analysis that how should I proceed.
Should I send the patches to community?
Maybe koen will reply with more info about xml2po issue he found, imho
it wasn't in xml2po build but while using xml2to to generate docs in some
other recipe.
IIRC I had similar issue in some other recipe, but unfortunatelly don't
remember which one.
Regards,
Regards,
Noor
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
Ahsan, Noor
Sent: Thursday, March 17, 2011 3:41 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Python-native dependency in libxml2
Hello,
Today I got the fresh stuff and tried to build gnome-doc-utils-native
(to build xml2po package). I am building on Ubuntu host 9.10. First it
gave me an error that it could not find intltoolize command. You can see
the attached build log build_intltool_error,log. So I added intltool
package in gnome-doc-utils-native DEPENDS so it built successfully. You
can see the build log build_intltool_fix.log. Then I removed all the
build stuff from build DIR and commented DEPENDS_virtclass-native =
python-native and XPY_virtclass-native =
--with-python=${PYTHON_DIR} in libxml2.inc file. Rebuild
gnome-doc-utils-native. It built successfully again. The build log is
also attached build_no_python.log. I think there is no need of python
dependency in libxml2 package. Kindly correct me if I am doing anything
wrong.
We need to fix gnome-doc-utils-native recipe, so that it does not show
intltoolize error.
Regards,
Noor
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
Ahsan, Noor
Sent: Wednesday, March 16, 2011 1:39 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Python-native dependency in libxml2
Hello,
I made 2 changes, first one was to remove python-native from DEPENDS and
second was commented out XPY_virtclass-native =
--with-python=${PYTHON_DIR}. Moreover I removed all the stuff from
build dir, so there were not python-native for me. After kicking this
build libxml2-native build fine.
I was looking for xml2po recipe, I couldn't find it. Can you tell me how
to build xml2po package so that I can reproduce the problem.
Regards,
Noor
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
Martin Jansa
Sent: Wednesday, March 16, 2011 1:05 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Python-native dependency in libxml2
On Wed, Mar 16, 2011 at 08:28:39AM +0100, Frans Meulenbroeks wrote:
2011/3/16 Khem Raj raj.k...@gmail.com:
On 3/15/2011 11:22 PM, Ahsan, Noor wrote:
Hello,
I was looking at the libxml2 package. While going through the
recipes I
came to know that its native package depends on python-native
package as
well. This dependency is defined in libxml2.inc file.
DEPENDS_virtclass-native = python-native
This package build fine after removing this dependency. I am not
clear
why this dependency is being added in libxml2 package. Can somebody
clear that to me. While looking at the git log I came to know that
this
change is coming from libxml2-native.inc file. But I am not clear
why
this dependency was added as this package build fine without it.
Please help me in understanding this dependency. Thanks.
Try to build this recipe from scratch and see if it still works then
we can
remove the dep
That's not enough, libxml2-native builds fine.. but then xml2po
will fail if there isn't libxml2-native built with python support.
see a25f07ca6159e1cd5b8a215ca5da8405fb1b9053
So yes.. for such tests you should build recipe from scratch _and_ check
if resulting package/sysroot is still the same.
Regards,
I'm not sure if that is the right way.
It might well be that typically python-native is already there in a
scratch build because some earlier package needed it (or even because
of the scheduling of build steps.
Probably a better way is to build with packaged staging (with staging
dir outside TMPDIR) then rm TMPDIR and bake the package.
Alternately peek into the package to see if it needs python. If it is
needed then the DEPENDS should stay.
Looking at the issue at hand maybe the best person to ask is Martin
Jansa as he last touched that line according to git blame:
3cd9ddbf recipes/libxml/libxml2.inc (Martin Jansa
2010-02-26 12:32:53 +0100 5) DEPENDS_virtclass-native =
python-native
The other thing is that further on in the .inc file I see:
XPY_virtclass-native = --with-python=${PYTHON_DIR}
This strongly
Re: [oe] [PATCH 3/3] base-files-3.0.14 configuration files
Mark some files in ${sysconfdir} as configuration files so they are
not blindly overwritten when upgrading
I would suggest a pre-/post processing in the packages, like debian
does.
If a config file exists or is changed, the current File will be
rotated
or, if possible, left as it is and the new
file is installed beside the changed one.
The opkg does not touch a present config file, but installs the new
file with the name *-opkg
So if you do a find /etc -name \*-opkg you see the conflicts.
Any sensible conversion from old to new config file should be made by
the package itself.
As I experienced, opkg exits with an error code if a config file already
exists, so if you want to create an image, the process will break at
that error.
It wasn't possible to create an image automatically then.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Python-native dependency in libxml2
2011/3/18 Ahsan, Noor noor_ah...@mentor.com: Hello Martin/Frans and Khem, Any recommendation after following analysis that how should I proceed. Should I send the patches to community? Regards, Noor I think Martin is in a better position to judge this than I am. Did you also verify that the generated output (the packages and the contents of the packages) is identical in the python and no-python case? Best regards, Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] staging using kernel headers
CC:ing oe-core since we have kernel.bbclass patches there as well.
Op 18 mrt 2011, om 10:49 heeft Michael Jones het volgende geschreven:
Hello Koen co.,
I recently bumped into a problem with recipes ti-dmai and gstreamer-ti
when they included the kernel headers. These headers were staged by
kernel.bbclass sysroot_stage_all_append() with a lot of manual copying
and manipulating links and such, rather than using 'oe_runmake
headers_install'. Back in October Koen explained this
(http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is
because some recipes use private kernel API. The result of this with my
2.6.38 kernel
DMAI and gst-ti don't really work with anything newer than 2.6.32-psp, we're
trying to get that addressed internally.
is that I get a warning-turned-error from linux/types.h
that Attempt to use kernel headers from user space.
ti-dmai_svn.bb hacks this (self-admittedly) by defining
_EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to
modify the recipe to enable the define to actually get passed as a
compile option. For gstreamer-ti, there was no such hack in place, but
it was needed for the same reason.
I would think it is a common requirement for recipes to include kernel
headers, and this warning has been around since 2.6.32. I got around it
with gstreamer-ti by installing the headers with headers_install into a
subdir of the headers directory set up currently by kernel.bbclass, and
pointing the gstreamer-ti recipe at that, but I'm not sure if there's a
better way.
If there are some recipes that need internal kernel sources staged for
them, then it seems to me that we need both sets of kernel headers: one
exported to userspace (with headers_install) and one that is not.
Right? Can we agree on a standard place/manner for this?
Below is my patch to get gstreamer-ti working, for illustration.
I don't really have a better suggestion, apart from adding a var in e.g.
bitbake.conf to point to the userspace stuff.
We might even do the reverse, stage the full set into $kernel_dir/private and
the userspace ones in $kernel_dir, that would make it more clear which recipes
need internal API.
regards,
Koen
-Michael
From 71b3762ad5f6e7a8553a6b780296f7e994513f0b Mon Sep 17 00:00:00 2001
From: Michael Jones michael.jo...@matrix-vision.de
Date: Thu, 17 Mar 2011 17:23:53 +0100
Subject: [PATCH] install kernel headers exported for userspace
kernel.bbclass already copies and manipulates kernel headers into
sysroot, but it doesn't export them properly using make headers_install
which leads to a compiler error/warning in linux/types.h:
Attempt to use kernel headers from user space, see
http://kernelnewbies.org/KernelHeaders;
---
classes/kernel.bbclass |5 +
recipes/ti/gstreamer-ti.inc |2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/classes/kernel.bbclass b/classes/kernel.bbclass
index 422bcd7..6b46d51 100644
--- a/classes/kernel.bbclass
+++ b/classes/kernel.bbclass
@@ -210,6 +210,11 @@ sysroot_stage_all_append() {
[ -e Module.symvers ] install -m 0644 Module.symvers $kerneldir/
cp -fR scripts $kerneldir/
+
+ # install kernel headers in the proper manner to export them
+ # for userspace programs
+ userspace_hdrs=${kerneldir}/userspace
+ oe_runmake headers_install INSTALL_HDR_PATH=${userspace_hdrs}
ARCH=${ARCH}
}
kernel_do_configure() {
diff --git a/recipes/ti/gstreamer-ti.inc b/recipes/ti/gstreamer-ti.inc
index 905e192..04d990f 100644
--- a/recipes/ti/gstreamer-ti.inc
+++ b/recipes/ti/gstreamer-ti.inc
@@ -72,7 +72,7 @@ CPPFLAGS_append = -DPlatform_${PLATFORM}
export ENCODE_COMBO= ${installdir}/ti-codecs-server/encodeCombo.x64P
export DECODE_COMBO= ${installdir}/ti-codecs-server/decodeCombo.x64P
# Makefile also expects to be able to find the kernel headers from the
envirionment
-export LINUXKERNEL_INSTALL_DIR = ${STAGING_KERNEL_DIR}
+export LINUXKERNEL_INSTALL_DIR = ${STAGING_KERNEL_DIR}/userspace
do_configure_prepend() {
# PSP kernel is based on older DSS. we need to replace linux/omapfb.h
with mach/omapfb.h
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/2] ti-c6accel: fix building for uclibc
From: Henning Heinold hein...@inf.fu-berlin.de
Signed-off-by: Henning Heinold hein...@inf.fu-berlin.de
---
recipes/ti/ti-c6accel.inc |2 +-
recipes/ti/ti-c6accel/fix_time_symbol.patch | 46 +++
recipes/ti/ti-c6accel_1.01.00.03.bb |2 +
3 files changed, 49 insertions(+), 1 deletions(-)
create mode 100644 recipes/ti/ti-c6accel/fix_time_symbol.patch
diff --git a/recipes/ti/ti-c6accel.inc b/recipes/ti/ti-c6accel.inc
index 7d09783..216f4c2 100644
--- a/recipes/ti/ti-c6accel.inc
+++ b/recipes/ti/ti-c6accel.inc
@@ -18,7 +18,7 @@ PROVIDES += ti-c6accel-apps
# This recipe links statically against kernel dependant stuff, use kernel PR
as base and append a local version
PR = ${MACHINE_KERNEL_PR}
-PR_append = c
+PR_append = d
S = ${WORKDIR}/c6accel_${PV}
diff --git a/recipes/ti/ti-c6accel/fix_time_symbol.patch
b/recipes/ti/ti-c6accel/fix_time_symbol.patch
new file mode 100644
index 000..9963669
--- /dev/null
+++ b/recipes/ti/ti-c6accel/fix_time_symbol.patch
@@ -0,0 +1,46 @@
+Index: c6accel_1_01_00_03/soc/app/benchmark.h
+===
+--- c6accel_1_01_00_03.orig/soc/app/benchmark.h2011-03-12
17:45:49.640633120 +0100
c6accel_1_01_00_03/soc/app/benchmark.h 2011-03-12 17:46:10.360988120
+0100
+@@ -39,7 +39,7 @@
+
+
+ extern Time_Object sTime;
+- extern UInt32 time;
++ extern UInt32 timestamp;
+
+ #define OPEN_LOG_FILE(Name)\
+ if ((benchmarkFd = fopen(Name,wb)) == NULL) {\
+@@ -49,7 +49,7 @@
+ #define CLOSE_LOG_FILE() fclose(benchmarkFd);
+
+ #define START_BENCHMARK() \
+- Time_delta(sTime,time);
++ Time_delta(sTime,timestamp);
+
+ #define LOG_STRING(str)\
+fprintf(benchmarkFd,%s,str);
+@@ -70,8 +70,8 @@
+
+
+ #define END_AND_WRITE_BENCHMARK() \
+- Time_delta(sTime,time);\
+- fprintf(benchmarkFd,%d,(unsigned int)time);
++ Time_delta(sTime,timestamp);\
++ fprintf(benchmarkFd,%d,(unsigned int)timestamp);
+
+
+
+Index: c6accel_1_01_00_03/soc/app/appMain.c
+===
+--- c6accel_1_01_00_03.orig/soc/app/appMain.c 2011-03-12 17:46:42.030148120
+0100
c6accel_1_01_00_03/soc/app/appMain.c 2011-03-12 17:48:00.619423120
+0100
+@@ -66,7 +66,7 @@
+ /* This object is used in MACRO in benchmark.h */
+ #include timeObj.h
+ Time_Object sTime;
+-UInt32 time;
++UInt32 timestamp;
+
+ void Time_reset(Time_Object *sTime)
+ {
diff --git a/recipes/ti/ti-c6accel_1.01.00.03.bb
b/recipes/ti/ti-c6accel_1.01.00.03.bb
index bf5f1cf..42b0cc6 100644
--- a/recipes/ti/ti-c6accel_1.01.00.03.bb
+++ b/recipes/ti/ti-c6accel_1.01.00.03.bb
@@ -7,6 +7,8 @@ SRC_URI_append = file://fix-loadmodule.patch \
file://0001-soc-honour-buildsystem-CFLAGS-and-LDFLAGS-when-set.patch \
+SRC_URI_append_libc-uclibc = file://fix_time_symbol.patch
+
PV = 1_01_00_03
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/2] ti-codec-engine: make rebuild of ti-codec-engine itself possible
From: Henning Heinold hein...@inf.fu-berlin.de
Signed-off-by: Henning Heinold hein...@inf.fu-berlin.de
---
recipes/ti/ti-codec-engine.inc| 117 +
recipes/ti/ti-codec-engine/fix_core_package.patch | 13 +++
recipes/ti/ti-codec-engine/fix_ipc_dsplink.patch | 86 +++
recipes/ti/ti-codec-engine_2.26.01.09.bb |4 +
4 files changed, 220 insertions(+), 0 deletions(-)
create mode 100644 recipes/ti/ti-codec-engine/fix_core_package.patch
create mode 100644 recipes/ti/ti-codec-engine/fix_ipc_dsplink.patch
diff --git a/recipes/ti/ti-codec-engine.inc b/recipes/ti/ti-codec-engine.inc
index fdaebd5..9e8a8ad 100644
--- a/recipes/ti/ti-codec-engine.inc
+++ b/recipes/ti/ti-codec-engine.inc
@@ -64,6 +64,107 @@ do_configure() {
sed -i \
-e s:arm-none-linux-gnueabi-:${TARGET_PREFIX}:g \
${S}/examples/xdcpaths.mak
+
+# Generate a config.bld for codec engine lib
+
+cat ${S}/packages/ti/sdo/ce/config.bld EOF
+
+/* Generated by ti-codeco-engine.inc OE recipe */
+
+var Build = xdc.useModule('xdc.bld.BuildEnvironment');
+
+var GCArmv5T = xdc.useModule('gnu.targets.arm.GCArmv5T');
+GCArmv5T.LONGNAME = bin/${TARGET_PREFIX}gcc;
+GCArmv5T.rootDir = ${TOOLCHAIN_PATH};
+GCArmv5T.ccOpts.prefix += -Wall -fno-strict-aliasing
-I${FC_INSTALL_DIR}/packages -I${XDAIS_INSTALL_DIR}/packages ;
+GCArmv5T.platform = null;
+GCArmv5T.platforms = [
+${XDC_PLATFORM}
+];
+
+/* remove profiles we don't use */
+delete GCArmv5T.profiles[coverage];
+delete GCArmv5T.profiles[profile];
+
+Build.targets.\$add(GCArmv5T);
+
+var C64P = xdc.useModule('ti.targets.C64P');
+C64P.rootDir = ${CODEGEN_INSTALL_DIR};
+C64P.ccOpts.prefix += -I${FC_INSTALL_DIR}/packages
-I${XDAIS_INSTALL_DIR}/packages ;
+
+Build.targets.\$add(C64P);
+EOF
+
+cat ${S}/packages/ti/sdo/ce/osal/linux/config.bld EOF
+
+/* Generated by ti-codeco-engine.inc OE recipe */
+
+var Build = xdc.useModule('xdc.bld.BuildEnvironment');
+
+var GCArmv5T = xdc.useModule('gnu.targets.arm.GCArmv5T');
+GCArmv5T.LONGNAME = bin/${TARGET_PREFIX}gcc;
+GCArmv5T.rootDir = ${TOOLCHAIN_PATH};
+GCArmv5T.ccOpts.prefix += -Wall -fno-strict-aliasing
-I${FC_INSTALL_DIR}/packages -I${CMEM_INSTALL_DIR}/packages ;
+GCArmv5T.platform = null;
+GCArmv5T.platforms = [
+${XDC_PLATFORM}
+];
+
+/* remove profiles we don't use */
+delete GCArmv5T.profiles[coverage];
+delete GCArmv5T.profiles[profile];
+
+Build.targets.\$add(GCArmv5T);
+
+EOF
+
+cat ${S}/packages/ti/sdo/ce/ipc/dsplink/config.bld EOF
+
+/* Generated by ti-codeco-engine.inc OE recipe */
+
+var Build = xdc.useModule('xdc.bld.BuildEnvironment');
+
+var GCArmv5T = xdc.useModule('gnu.targets.arm.GCArmv5T');
+GCArmv5T.LONGNAME = bin/${TARGET_PREFIX}gcc;
+GCArmv5T.rootDir = ${TOOLCHAIN_PATH};
+GCArmv5T.ccOpts.prefix += -Wall -fno-strict-aliasing
-I${FC_INSTALL_DIR}/packages
+GCArmv5T.ccOpts.prefix += -I${CMEM_INSTALL_DIR}/packages
-I${LPM_INSTALL_DIR}/packages ;
+GCArmv5T.platform = null;
+GCArmv5T.platforms = [
+${XDC_PLATFORM}
+];
+
+/* remove profiles we don't use */
+delete GCArmv5T.profiles[coverage];
+delete GCArmv5T.profiles[profile];
+
+Build.targets.\$add(GCArmv5T);
+
+EOF
+
+cat ${S}/packages/ti/dsplink/utils/ladclient/config.bld EOF
+
+/* Generated by ti-codeco-engine.inc OE recipe */
+
+var Build = xdc.useModule('xdc.bld.BuildEnvironment');
+
+var GCArmv5T = xdc.useModule('gnu.targets.arm.GCArmv5T');
+GCArmv5T.LONGNAME = bin/${TARGET_PREFIX}gcc;
+GCArmv5T.rootDir = ${TOOLCHAIN_PATH};
+GCArmv5T.ccOpts.prefix += -Wall -fno-strict-aliasing
+GCArmv5T.platform = null;
+GCArmv5T.platforms = [
+${XDC_PLATFORM}
+];
+
+/* remove profiles we don't use */
+delete GCArmv5T.profiles[coverage];
+delete GCArmv5T.profiles[profile];
+
+Build.targets.\$add(GCArmv5T);
+
+EOF
+
}
do_prepsources() {
@@ -98,6 +199,22 @@ addtask prepsources after do_configure before do_compile
do_compile () {
+cd ${S}/packages/ti/sdo/ce
+ ${XDC_INSTALL_DIR}/xdc
+
+cd ${S}/packages/ti/sdo/ce/osal/linux
+ ${XDC_INSTALL_DIR}/xdc
+
+ cd ${S}/packages/ti/sdo/ce/ipc/dsplink
+ make XDC_INSTALL_DIR=${XDC_INSTALL_DIR} \
+CE_INSTALL_DIR=${S} \
+ DSPLINK_REPO=${LINK_INSTALL_DIR} \
+XDCARGS=DEVICE=${CEEXAMPLESDEVICES}
+
+
+cd ${S}/packages/ti/dsplink/utils/ladclient
+ ${XDC_INSTALL_DIR}/xdc
+
for i in codecs extensions servers apps ; do
cd ${S}/examples/ti/sdo/ce/examples/$i
make DEVICES=${CEEXAMPLESDEVICES} \
diff --git a/recipes/ti/ti-codec-engine/fix_core_package.patch
b/recipes/ti/ti-codec-engine/fix_core_package.patch
new file mode 100644
index 000..69ca438
--- /dev/null
+++ b/recipes/ti/ti-codec-engine/fix_core_package.patch
@@ -0,0 +1,13 @@
+Index: codec_engine_2_26_01_09/packages/ti/sdo/ce/package.bld
+===
+---
Re: [oe] Python-native dependency in libxml2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18-03-11 09:38, Martin Jansa wrote:
On Fri, Mar 18, 2011 at 08:41:40AM +0100, Ahsan, Noor wrote:
Hello Martin/Frans and Khem,
Any recommendation after following analysis that how should I proceed.
Should I send the patches to community?
Maybe koen will reply with more info about xml2po issue he found, imho
it wasn't in xml2po build but while using xml2to to generate docs in some
other recipe.
The issue I had that I needed xml2{t,p}o to work on the target as well
for native compilation. If that still works, Noors changes is fine by me.
regards,
Koen
IIRC I had similar issue in some other recipe, but unfortunatelly don't
remember which one.
Regards,
Regards,
Noor
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
Ahsan, Noor
Sent: Thursday, March 17, 2011 3:41 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Python-native dependency in libxml2
Hello,
Today I got the fresh stuff and tried to build gnome-doc-utils-native
(to build xml2po package). I am building on Ubuntu host 9.10. First it
gave me an error that it could not find intltoolize command. You can see
the attached build log build_intltool_error,log. So I added intltool
package in gnome-doc-utils-native DEPENDS so it built successfully. You
can see the build log build_intltool_fix.log. Then I removed all the
build stuff from build DIR and commented DEPENDS_virtclass-native =
python-native and XPY_virtclass-native =
--with-python=${PYTHON_DIR} in libxml2.inc file. Rebuild
gnome-doc-utils-native. It built successfully again. The build log is
also attached build_no_python.log. I think there is no need of python
dependency in libxml2 package. Kindly correct me if I am doing anything
wrong.
We need to fix gnome-doc-utils-native recipe, so that it does not show
intltoolize error.
Regards,
Noor
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
Ahsan, Noor
Sent: Wednesday, March 16, 2011 1:39 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Python-native dependency in libxml2
Hello,
I made 2 changes, first one was to remove python-native from DEPENDS and
second was commented out XPY_virtclass-native =
--with-python=${PYTHON_DIR}. Moreover I removed all the stuff from
build dir, so there were not python-native for me. After kicking this
build libxml2-native build fine.
I was looking for xml2po recipe, I couldn't find it. Can you tell me how
to build xml2po package so that I can reproduce the problem.
Regards,
Noor
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
[mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
Martin Jansa
Sent: Wednesday, March 16, 2011 1:05 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Python-native dependency in libxml2
On Wed, Mar 16, 2011 at 08:28:39AM +0100, Frans Meulenbroeks wrote:
2011/3/16 Khem Raj raj.k...@gmail.com:
On 3/15/2011 11:22 PM, Ahsan, Noor wrote:
Hello,
I was looking at the libxml2 package. While going through the
recipes I
came to know that its native package depends on python-native
package as
well. This dependency is defined in libxml2.inc file.
DEPENDS_virtclass-native = python-native
This package build fine after removing this dependency. I am not
clear
why this dependency is being added in libxml2 package. Can somebody
clear that to me. While looking at the git log I came to know that
this
change is coming from libxml2-native.inc file. But I am not clear
why
this dependency was added as this package build fine without it.
Please help me in understanding this dependency. Thanks.
Try to build this recipe from scratch and see if it still works then
we can
remove the dep
That's not enough, libxml2-native builds fine.. but then xml2po
will fail if there isn't libxml2-native built with python support.
see a25f07ca6159e1cd5b8a215ca5da8405fb1b9053
So yes.. for such tests you should build recipe from scratch _and_ check
if resulting package/sysroot is still the same.
Regards,
I'm not sure if that is the right way.
It might well be that typically python-native is already there in a
scratch build because some earlier package needed it (or even because
of the scheduling of build steps.
Probably a better way is to build with packaged staging (with staging
dir outside TMPDIR) then rm TMPDIR and bake the package.
Alternately peek into the package to see if it needs python. If it is
needed then the DEPENDS should stay.
Looking at the issue at hand maybe the best person to ask is Martin
Jansa as he last touched that line according to git blame:
3cd9ddbf recipes/libxml/libxml2.inc (Martin Jansa
2010-02-26 12:32:53 +0100 5)
[oe] uClibc fixes for TI recipes
Hi, the first patch fixes uclibc by refactoring variables name and the second patch let us rebuild the codec-engine itself not only the examples. Bye Henning ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OE Bugzilla Future
On Fri, 2011-03-18 at 08:57 +0100, Frans Meulenbroeks wrote: 2011/3/17 Richard Purdie richard.pur...@linuxfoundation.org: On Thu, 2011-03-17 at 19:10 +0100, Michael 'Mickey' Lauer wrote: I'm in favor of keeping it, cleaning it up, and improve the integration with patchwork / git. Throwing it away would be a very bad sign to all those countless people who've gone through the pains of actually working with the bugtracker. The simple question is who is actually going to sort out the mess its in? Who is going to look after it on a continuing basis? If there isn't ownership, nothing is going to change. Actually I feel the real problem is that: - people did not want to get bugs assigned to them (at least that was what someone told me in the past) - we're lacking a good notion of package or recipe ownership, so even if we had someone acting as a bug manager, (s)he would have a hard time to find out who to assign an issue to. Yes, agreed. A few people have tried in the past to take responsibility for bugzilla itself (in infrastructure terms) and I would be happy enough to do that for the future. But it clearly is not reasonable to expect the Bugzilla maintainer(s) to be personally responsible for fixing every bug that gets reported. Unless other developers are cooperative, this leads inevitably to the current situation of issues languishing in bugzilla forever. As you say, the real issue here seems to be that someone (presumably the TSC) needs to determine the workflow that OE is going to use and then convince the developers to stick to it. Bugzilla works most effectively if everything goes through it, which means you can use the bug list as a kind of dashboard showing the issues which need attention each day, and if everybody uses it (and hence is diligent about closing bugs once they are actually fixed). To that extent its role overlaps somewhat with patchwork and, personally, I would be quite happy to see bugzilla replace patchwork for email submissions. But clearly others have a different view on that and, again, it is probably going to be down to the TSC to decide what tools are right for OE. p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Eliminating dependency race-conditions (was Re: [PATCH] net-snmp: disable libnl use)
On Fri, 2011-03-18 at 06:29 +0100, Esben Haabendal wrote: Yes, I get your point. You could of-course still specify build dependencies using recipe names/provides, and then just unpack all target packages build by that recipe. This would give you the major part of the KISS win I see, except for in the dependency handling code of BitBake (and in the learning curve of OE developers). Keep in mind that by using packages for build-time dependencies, the mechanism is exactly identical for run-time and build-time dependencies. Exactly the same code in BitBake handles both, and the same mechanism needs to be understood. This is also part of the KISS win of doing it this way. Right. So, it seems to me that the appropriate way to attack the problem in OE is to start by doing exactly that: leave the syntax of DEPENDS alone for now, treat each entry in DEPENDS as meaning all packages built by the named recipe, and then implement the per-recipe sysroot construction that I think we are agreed is highly desirable. Then, as a later refinement, we could introduce a mechanism for specifying dependencies more precisely, at the package level rather than the recipe level. We could do that either by extending the syntax of DEPENDS, something like: DEPENDS = boost:boost-iostreams (to say that you wanted just the boost-iostreams package from the boost recipe) or, alternately, by introducing a new variable which would either supplement or replace DEPENDS. Either of those would allow us to migrate to fine-grained dependencies without breaking existing recipes. (How) do you deal with library package renaming in OE-lite? What exactly do you mean? (We are doing several things with library package naming...) I was thinking of situations like the Debian package autonamer, ie the thing that causes glibc-dev to come out named libc6-dev.ipk or similar depending on the soname of the library that was built. It seems like this would be a bit awkward to deal with if your dependencies were specified purely in terms of output packages. p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/2] ti-codec-engine: make rebuild of ti-codec-engine itself possible
From: Henning Heinold hein...@inf.fu-berlin.de
Signed-off-by: Henning Heinold hein...@inf.fu-berlin.de
---
recipes/ti/ti-codec-engine.inc| 117 +
recipes/ti/ti-codec-engine/fix_core_package.patch | 13 +++
recipes/ti/ti-codec-engine/fix_ipc_dsplink.patch | 86 +++
recipes/ti/ti-codec-engine_2.26.01.09.bb |4 +
4 files changed, 220 insertions(+), 0 deletions(-)
create mode 100644 recipes/ti/ti-codec-engine/fix_core_package.patch
create mode 100644 recipes/ti/ti-codec-engine/fix_ipc_dsplink.patch
diff --git a/recipes/ti/ti-codec-engine.inc b/recipes/ti/ti-codec-engine.inc
index fdaebd5..9e8a8ad 100644
--- a/recipes/ti/ti-codec-engine.inc
+++ b/recipes/ti/ti-codec-engine.inc
@@ -64,6 +64,107 @@ do_configure() {
sed -i \
-e s:arm-none-linux-gnueabi-:${TARGET_PREFIX}:g \
${S}/examples/xdcpaths.mak
+
+# Generate a config.bld for codec engine lib
+
+cat ${S}/packages/ti/sdo/ce/config.bld EOF
+
+/* Generated by ti-codeco-engine.inc OE recipe */
+
+var Build = xdc.useModule('xdc.bld.BuildEnvironment');
+
+var GCArmv5T = xdc.useModule('gnu.targets.arm.GCArmv5T');
+GCArmv5T.LONGNAME = bin/${TARGET_PREFIX}gcc;
+GCArmv5T.rootDir = ${TOOLCHAIN_PATH};
+GCArmv5T.ccOpts.prefix += -Wall -fno-strict-aliasing
-I${FC_INSTALL_DIR}/packages -I${XDAIS_INSTALL_DIR}/packages ;
+GCArmv5T.platform = null;
+GCArmv5T.platforms = [
+${XDC_PLATFORM}
+];
+
+/* remove profiles we don't use */
+delete GCArmv5T.profiles[coverage];
+delete GCArmv5T.profiles[profile];
+
+Build.targets.\$add(GCArmv5T);
+
+var C64P = xdc.useModule('ti.targets.C64P');
+C64P.rootDir = ${CODEGEN_INSTALL_DIR};
+C64P.ccOpts.prefix += -I${FC_INSTALL_DIR}/packages
-I${XDAIS_INSTALL_DIR}/packages ;
+
+Build.targets.\$add(C64P);
+EOF
+
+cat ${S}/packages/ti/sdo/ce/osal/linux/config.bld EOF
+
+/* Generated by ti-codeco-engine.inc OE recipe */
+
+var Build = xdc.useModule('xdc.bld.BuildEnvironment');
+
+var GCArmv5T = xdc.useModule('gnu.targets.arm.GCArmv5T');
+GCArmv5T.LONGNAME = bin/${TARGET_PREFIX}gcc;
+GCArmv5T.rootDir = ${TOOLCHAIN_PATH};
+GCArmv5T.ccOpts.prefix += -Wall -fno-strict-aliasing
-I${FC_INSTALL_DIR}/packages -I${CMEM_INSTALL_DIR}/packages ;
+GCArmv5T.platform = null;
+GCArmv5T.platforms = [
+${XDC_PLATFORM}
+];
+
+/* remove profiles we don't use */
+delete GCArmv5T.profiles[coverage];
+delete GCArmv5T.profiles[profile];
+
+Build.targets.\$add(GCArmv5T);
+
+EOF
+
+cat ${S}/packages/ti/sdo/ce/ipc/dsplink/config.bld EOF
+
+/* Generated by ti-codeco-engine.inc OE recipe */
+
+var Build = xdc.useModule('xdc.bld.BuildEnvironment');
+
+var GCArmv5T = xdc.useModule('gnu.targets.arm.GCArmv5T');
+GCArmv5T.LONGNAME = bin/${TARGET_PREFIX}gcc;
+GCArmv5T.rootDir = ${TOOLCHAIN_PATH};
+GCArmv5T.ccOpts.prefix += -Wall -fno-strict-aliasing
-I${FC_INSTALL_DIR}/packages
+GCArmv5T.ccOpts.prefix += -I${CMEM_INSTALL_DIR}/packages
-I${LPM_INSTALL_DIR}/packages ;
+GCArmv5T.platform = null;
+GCArmv5T.platforms = [
+${XDC_PLATFORM}
+];
+
+/* remove profiles we don't use */
+delete GCArmv5T.profiles[coverage];
+delete GCArmv5T.profiles[profile];
+
+Build.targets.\$add(GCArmv5T);
+
+EOF
+
+cat ${S}/packages/ti/dsplink/utils/ladclient/config.bld EOF
+
+/* Generated by ti-codeco-engine.inc OE recipe */
+
+var Build = xdc.useModule('xdc.bld.BuildEnvironment');
+
+var GCArmv5T = xdc.useModule('gnu.targets.arm.GCArmv5T');
+GCArmv5T.LONGNAME = bin/${TARGET_PREFIX}gcc;
+GCArmv5T.rootDir = ${TOOLCHAIN_PATH};
+GCArmv5T.ccOpts.prefix += -Wall -fno-strict-aliasing
+GCArmv5T.platform = null;
+GCArmv5T.platforms = [
+${XDC_PLATFORM}
+];
+
+/* remove profiles we don't use */
+delete GCArmv5T.profiles[coverage];
+delete GCArmv5T.profiles[profile];
+
+Build.targets.\$add(GCArmv5T);
+
+EOF
+
}
do_prepsources() {
@@ -98,6 +199,22 @@ addtask prepsources after do_configure before do_compile
do_compile () {
+cd ${S}/packages/ti/sdo/ce
+ ${XDC_INSTALL_DIR}/xdc
+
+cd ${S}/packages/ti/sdo/ce/osal/linux
+ ${XDC_INSTALL_DIR}/xdc
+
+ cd ${S}/packages/ti/sdo/ce/ipc/dsplink
+ make XDC_INSTALL_DIR=${XDC_INSTALL_DIR} \
+CE_INSTALL_DIR=${S} \
+ DSPLINK_REPO=${LINK_INSTALL_DIR} \
+XDCARGS=DEVICE=${CEEXAMPLESDEVICES}
+
+
+cd ${S}/packages/ti/dsplink/utils/ladclient
+ ${XDC_INSTALL_DIR}/xdc
+
for i in codecs extensions servers apps ; do
cd ${S}/examples/ti/sdo/ce/examples/$i
make DEVICES=${CEEXAMPLESDEVICES} \
diff --git a/recipes/ti/ti-codec-engine/fix_core_package.patch
b/recipes/ti/ti-codec-engine/fix_core_package.patch
new file mode 100644
index 000..69ca438
--- /dev/null
+++ b/recipes/ti/ti-codec-engine/fix_core_package.patch
@@ -0,0 +1,13 @@
+Index: codec_engine_2_26_01_09/packages/ti/sdo/ce/package.bld
+===
+---
[oe] [PATCH 1/2] ti-c6accel: fix building for uclibc
From: Henning Heinold hein...@inf.fu-berlin.de
Signed-off-by: Henning Heinold hein...@inf.fu-berlin.de
---
recipes/ti/ti-c6accel.inc |2 +-
recipes/ti/ti-c6accel/fix_time_symbol.patch | 46 +++
recipes/ti/ti-c6accel_1.01.00.03.bb |2 +
3 files changed, 49 insertions(+), 1 deletions(-)
create mode 100644 recipes/ti/ti-c6accel/fix_time_symbol.patch
diff --git a/recipes/ti/ti-c6accel.inc b/recipes/ti/ti-c6accel.inc
index 7d09783..216f4c2 100644
--- a/recipes/ti/ti-c6accel.inc
+++ b/recipes/ti/ti-c6accel.inc
@@ -18,7 +18,7 @@ PROVIDES += ti-c6accel-apps
# This recipe links statically against kernel dependant stuff, use kernel PR
as base and append a local version
PR = ${MACHINE_KERNEL_PR}
-PR_append = c
+PR_append = d
S = ${WORKDIR}/c6accel_${PV}
diff --git a/recipes/ti/ti-c6accel/fix_time_symbol.patch
b/recipes/ti/ti-c6accel/fix_time_symbol.patch
new file mode 100644
index 000..9963669
--- /dev/null
+++ b/recipes/ti/ti-c6accel/fix_time_symbol.patch
@@ -0,0 +1,46 @@
+Index: c6accel_1_01_00_03/soc/app/benchmark.h
+===
+--- c6accel_1_01_00_03.orig/soc/app/benchmark.h2011-03-12
17:45:49.640633120 +0100
c6accel_1_01_00_03/soc/app/benchmark.h 2011-03-12 17:46:10.360988120
+0100
+@@ -39,7 +39,7 @@
+
+
+ extern Time_Object sTime;
+- extern UInt32 time;
++ extern UInt32 timestamp;
+
+ #define OPEN_LOG_FILE(Name)\
+ if ((benchmarkFd = fopen(Name,wb)) == NULL) {\
+@@ -49,7 +49,7 @@
+ #define CLOSE_LOG_FILE() fclose(benchmarkFd);
+
+ #define START_BENCHMARK() \
+- Time_delta(sTime,time);
++ Time_delta(sTime,timestamp);
+
+ #define LOG_STRING(str)\
+fprintf(benchmarkFd,%s,str);
+@@ -70,8 +70,8 @@
+
+
+ #define END_AND_WRITE_BENCHMARK() \
+- Time_delta(sTime,time);\
+- fprintf(benchmarkFd,%d,(unsigned int)time);
++ Time_delta(sTime,timestamp);\
++ fprintf(benchmarkFd,%d,(unsigned int)timestamp);
+
+
+
+Index: c6accel_1_01_00_03/soc/app/appMain.c
+===
+--- c6accel_1_01_00_03.orig/soc/app/appMain.c 2011-03-12 17:46:42.030148120
+0100
c6accel_1_01_00_03/soc/app/appMain.c 2011-03-12 17:48:00.619423120
+0100
+@@ -66,7 +66,7 @@
+ /* This object is used in MACRO in benchmark.h */
+ #include timeObj.h
+ Time_Object sTime;
+-UInt32 time;
++UInt32 timestamp;
+
+ void Time_reset(Time_Object *sTime)
+ {
diff --git a/recipes/ti/ti-c6accel_1.01.00.03.bb
b/recipes/ti/ti-c6accel_1.01.00.03.bb
index bf5f1cf..42b0cc6 100644
--- a/recipes/ti/ti-c6accel_1.01.00.03.bb
+++ b/recipes/ti/ti-c6accel_1.01.00.03.bb
@@ -7,6 +7,8 @@ SRC_URI_append = file://fix-loadmodule.patch \
file://0001-soc-honour-buildsystem-CFLAGS-and-LDFLAGS-when-set.patch \
+SRC_URI_append_libc-uclibc = file://fix_time_symbol.patch
+
PV = 1_01_00_03
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] uClibc fixes for TI recipes
Hi, the first patch fixes uclibc by refactoring variables name and the second patch let us rebuild the codec-engine itself not only the examples. Bye Henning ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 3/3] base-files-3.0.14 configuration files
On Fri, 2011-03-18 at 09:59 +0100, Hauser, Wolfgang (external) wrote: As I experienced, opkg exits with an error code if a config file already exists, so if you want to create an image, the process will break at that error. It wasn't possible to create an image automatically then. I don't think that situation should ever arise during image construction. If there are two packages which ship the same conffile and don't Conflict: with each other then that seems like it must be a packaging bug. What were the circumstances that caused this to happen for you? p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] xfce_session_4.6.{1, 2}: explicitly pass the path of `iceauth`
Date: Fri, 18 Mar 2011 12:03:43 +0100
Xfce Session build depends on the executable `iceauth`, which fails when cross
compiling for a different architecture.
checking if the linker (arm-oe-linux-gnueabi-ld
--sysroot=/oe/build-minimal-eglibc/minimal-dev/sysroots/armv5te-oe-linux-gnueabi)
is GNU ld... (cached) yes
checking whether to build with profiling support... no
checking whether to compile with coverage profiling instrumentation...
no
checking whether to disable assertions... no
checking whether to build final version... yes
checking whether arm-oe-linux-gnueabi-ld
--sysroot=/oe/build-minimal-eglibc/minimal-dev/sysroots/armv5te-oe-linux-gnueabi
accepts -O1... yes
checking for iceauth... no
configure: error: iceauth missing, please check your X11 installation
As suggested by Khem Raj [1] pass the value – `/usr/bin/iceauth` is taken – to
the configure script so that the test is avoided.
Therefore `iceauth` is removed from `DEPENDS` and the `PR` variable is
incremented.
This issue has been reported upstream as ticket #7420 [2].
[1]
http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-March/031115.html
[2] http://bugzilla.xfce.org/show_bug.cgi?id=7420
Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net
---
recipes/xfce-base/xfce4-session_4.6.1.bb |6 --
recipes/xfce-base/xfce4-session_4.6.2.bb |6 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/recipes/xfce-base/xfce4-session_4.6.1.bb
b/recipes/xfce-base/xfce4-session_4.6.1.bb
index ba66ac1..5029b21 100644
--- a/recipes/xfce-base/xfce4-session_4.6.1.bb
+++ b/recipes/xfce-base/xfce4-session_4.6.1.bb
@@ -1,13 +1,15 @@
DESCRIPTION = xfce4-session is a session manager for Xfce 4 Desktop
Environment
-DEPENDS = lbwnck libxfcegui4 libxfce4util dbus iceauth xfce-utils
+DEPENDS = lbwnck libxfcegui4 libxfce4util dbus xfce-utils
SECTION = x11
-PR = r4
+PR = r5
inherit xfce46
RDEPENDS_${PN} = iceauth xfce-utils xinit dbus-x11
+EXTRA_OECONF += ac_cv_path_ICEAUTH=/usr/bin/iceauth
+
FILES_${PN} += ${libdir}/xfce4/splash/engines/*.so
FILES_${PN} += ${datadir}/xfce4/tips/*
FILES_${PN} += ${datadir}/themes/Default/balou/*
diff --git a/recipes/xfce-base/xfce4-session_4.6.2.bb
b/recipes/xfce-base/xfce4-session_4.6.2.bb
index d7f768a..c937775 100644
--- a/recipes/xfce-base/xfce4-session_4.6.2.bb
+++ b/recipes/xfce-base/xfce4-session_4.6.2.bb
@@ -1,13 +1,15 @@
DESCRIPTION = xfce4-session is a session manager for Xfce 4 Desktop
Environment
-DEPENDS = libwnck libxfcegui4 libxfce4util dbus iceauth xfce-utils
+DEPENDS = libwnck libxfcegui4 libxfce4util dbus xfce-utils
SECTION = x11
-PR = r0
+PR = r1
inherit xfce46
RDEPENDS_${PN} = iceauth xfce-utils xinit dbus-x11
+EXTRA_OECONF += ac_cv_path_ICEAUTH=/usr/bin/iceauth
+
FILES_${PN} += ${libdir}/xfce4/splash/engines/*.so
FILES_${PN} += ${datadir}/xfce4/tips/*
FILES_${PN} += ${datadir}/themes/Default/balou/*
--
1.7.4.1
signature.asc
Description: This is a digitally signed message part
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Eliminating dependency race-conditions
Phil Blundell ph...@gnu.org writes: On Fri, 2011-03-18 at 06:29 +0100, Esben Haabendal wrote: Yes, I get your point. You could of-course still specify build dependencies using recipe names/provides, and then just unpack all target packages build by that recipe. This would give you the major part of the KISS win I see, except for in the dependency handling code of BitBake (and in the learning curve of OE developers). Keep in mind that by using packages for build-time dependencies, the mechanism is exactly identical for run-time and build-time dependencies. Exactly the same code in BitBake handles both, and the same mechanism needs to be understood. This is also part of the KISS win of doing it this way. Right. So, it seems to me that the appropriate way to attack the problem in OE is to start by doing exactly that: leave the syntax of DEPENDS alone for now, treat each entry in DEPENDS as meaning all packages built by the named recipe, and then implement the per-recipe sysroot construction that I think we are agreed is highly desirable. By doing it this way, I don't think we are getting much closer to the second step (package-based build-time dependencies). The OE-lite implementation of per-recipe staging builds on top of package-based build-time dependencies, so to do it the other way around, would imply taking the sstate concept and extend it to do per-recipe sysroots. After that, I believe you have exactly the same amount of development left to get where OE-lite is in respect to package-based build-time depencies and per-recipe staging. As I see it, package-based build-time dependencies practically obsoletes sstate. So if we for a moment imagine that we have moved OE to have sstate based per-recipe staging, we still have the same amount of work to do in the following areas: * Modifying BitBake and OE metadata to handle package-based build-time dependencies * Modifying existing recipes to include package-based build-time dependency information You can see the per-recipe staging as a postive side-effect of the package-based build-time dependency implementation. So why take the detour instead of just doing it? Then, as a later refinement, we could introduce a mechanism for specifying dependencies more precisely, at the package level rather than the recipe level. We could do that either by extending the syntax of DEPENDS, something like: DEPENDS = boost:boost-iostreams (to say that you wanted just the boost-iostreams package from the boost recipe) That is IMO just adding more cruft to OE. Not really what we need. or, alternately, by introducing a new variable which would either supplement or replace DEPENDS. Either of those would allow us to migrate to fine-grained dependencies without breaking existing recipes. Sounds better. Also, just as for run-time dependencies, the build-time package dependencies is not necesarely the actual package names, but some provides names, so having a recipe:package syntax really does not make much sense. (How) do you deal with library package renaming in OE-lite? What exactly do you mean? (We are doing several things with library package naming...) I was thinking of situations like the Debian package autonamer, ie the thing that causes glibc-dev to come out named libc6-dev.ipk or similar depending on the soname of the library that was built. It seems like this would be a bit awkward to deal with if your dependencies were specified purely in terms of output packages. As OE-lite is not OE, we are currently not supporting such type of package renaming. Let's leave that to Debian guys to fight with ;-) But as we build-time dependencies are typically in the form of some package provides, it doesn't really matter if the package is renamed. /Esben ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] qemu: `ERROR: QA Issue with qemu: Architecture did not match (3 to 20) on /work/i686-oe-linux/qemu-0.14.0-r3/packages-split/qemu/usr/share/qemu/openbios-ppc`
Dear OE folks, $ MACHINE=qemux86 bitbake -k qemu […] Build Configuration: BB_VERSION= 1.12.0 METADATA_BRANCH = unknown METADATA_REVISION = e043f30 TARGET_ARCH = i686 TARGET_OS = linux MACHINE = qemux86 DISTRO= minimal DISTRO_VERSION= dev-snapshot-20110318 […] NOTE: package qemu-0.14.0-r3: task do_qa_staging: Succeeded ERROR: QA Issue with qemu: Architecture did not match (3 to 20) on /work/i686-oe-linux/qemu-0.14.0-r3/packages-split/qemu/usr/share/qemu/openbios-ppc ERROR: QA Issue with qemu: Architecture did not match (3 to 2) on /work/i686-oe-linux/qemu-0.14.0-r3/packages-split/qemu/usr/share/qemu/openbios-sparc32 ERROR: QA run found fatal errors. Please consider fixing them. NOTE: package qemu-0.14.0-r3: task do_package_qa: Failed ERROR: Function 'do_package_qa' failed ERROR: Task 15 (/oe/openembedded/recipes/qemu/qemu_0.14.0.bb, do_package) failed with exit code '1' ERROR: '/oe/openembedded/recipes/qemu/qemu_0.14.0.bb' failed Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] xbmc: add `libass` to `DEPENDS`
Date: Fri, 18 Mar 2011 09:51:52 +0100 Task compile of `xbmc_svn.bb` fails with the following error message when using `angstrom-2010.x`. `angstrom-2008.1` does/did not have this problem probably because of using Libtool 2.2. arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb --sysroot=/oe/build-angstrom-next/angstrom-dev/s ysroots/armv7a-angstrom-linux-gnueabi -MD -c -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb2 -fpermissive -fvisibility-inlines-hidden -fPIC -DPIC -D_RE ENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -D_DEBUG -Wall -O2 -mfloat-abi=softfp -mno-apcs-stack-check -Wa,-march=armv7a -mcpu=cortex-a8 -mfpu=neon -mvectorize-with-ne on-quad -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb2 -fpermissive -fvisibility-inlines-hidden -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE _OFFSET_BITS=64 -g -D_DEBUG -Wall -O2 -mfloat-abi=softfp -mno-apcs-stack-check -Wa,-march=armv7a -mcpu=cortex-a8 -mfpu=neon -mvectorize-with-neon-quad -fexpensive-optimizations -fo mit-frame-pointer -frename-registers -O2 -ggdb2 -fpermissive -fvisibility-inlines-hidden -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -D_DEBUG -Wall -O2 -mfloat-abi=softfp -mno-apcs-stack-check -Wa,-march=armv7a -mcpu=cortex-a8 -mfpu=neon -mvectorize-with-neon-quad -D_LINUX -D_FILE_DEFINED -D__STDC_CONSTANT_MACROS -DBIN_INSTALL_PA TH=\/usr/lib/xbmc\ -DINSTALL_PATH=\/usr/share/xbmc\ -DHAS_SDL_JOYSTICK -D'SVN_REV=Unknown' -D_ARMEL -DHAVE_CONFIG_H -I. -I.. -I../../ -I../linux -I../cores -I../../guili b -I../posix -I../../lib/jsoncpp/jsoncpp/include -D_GNU_SOURCE=1 -D_REENTRANT -I/oe/build-angstrom-next/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/ - I/oe/build-angstrom-next/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/SDL -I/oe/build-angstrom-next/angstrom-dev/sysroots/armv7a-angstrom-lin ux-gnueabi/usr/include/alsa -I/oe/build-angstrom-next/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/dbus-1.0 -I/oe/build-angstrom-next/angstro m-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/freetype2 -I/oe/build-angstrom-next/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/fribidi -I/ho me/paul/oe/build-angstrom-next/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/glib-2.0 -I/oe/build-angstrom-next/angstrom-dev/sysroots/armv7a-angstrom-li nux-gnueabi/usr/include/libpng12 -I/oe/build-angstrom-next/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/dbus-1.0/include -I/oe/build-angstrom-nex t/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/glib-2.0/include -I/oe/build-angstrom-next/angstrom-dev/sysroots/i686-linux/usr/armv7a/include -I/ oe/build-angstrom-next/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/xbmc-10.05-r11+gitr0+e2ab481ebe964321c358ab9d6402088c714adcbe/git Socket.cpp -o Socket.o LINK libass.la In file included from log.h:25:0, from Socket.cpp:26: ../../guilib/StdString.h:1597:14: note: the mangling of 'va_list' has changed in GCC 4.4 arm-angstrom-linux-gnueabi-libtool: link: warning: library `/oe/build-angstrom-next/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/libfreetype.la' was moved. /bin/grep: /usr/lib/libz.la: No such file or directory /bin/sed: can't read /usr/lib/libz.la: No such file or directory arm-angstrom-linux-gnueabi-libtool: link: `/usr/lib/libz.la' is not a valid libtool archive make[4]: *** [libass.la] Error 1 make[4]: Leaving directory `/oe/build-angstrom-next/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/xbmc-10.05-r11+gitr0+e2ab481ebe964321c358ab9d6402088c714adcbe/git/lib/ libass/libass' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/oe/build-angstrom-next/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/xbmc-10.05-r11+gitr0+e2ab481ebe964321c358ab9d6402088c714adcbe/git/lib/ libass' make[2]: *** [all] Error 2 make[2]: Leaving directory `/oe/build-angstrom-next/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/xbmc-10.05-r11+gitr0+e2ab481ebe964321c358ab9d6402088c714adcbe/git/lib/ libass' make[1]: *** [../libass/.libs/libass.so] Error 2 make[1]: Leaving directory `/oe/build-angstrom-next/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/xbmc-10.05-r11+gitr0+e2ab481ebe964321c358ab9d6402088c714adcbe/git/lib/ libass/xbmc' make: *** [dvdpcodecs] Error 2 make: *** Waiting for unfinished jobs Using the external package fixes this problem. Build Configuration: BB_VERSION= 1.12.0 METADATA_BRANCH = unknown
Re: [oe] [PATCH 3/3] base-files-3.0.14 configuration files
Am Freitag, 18. März 2011, 09:59:17 schrieb Hauser, Wolfgang (external):
Mark some files in ${sysconfdir} as configuration files so they are
not blindly overwritten when upgrading
I would suggest a pre-/post processing in the packages, like debian
does.
If a config file exists or is changed, the current File will be
rotated
or, if possible, left as it is and the new
file is installed beside the changed one.
The opkg does not touch a present config file, but installs the new
file with the name *-opkg
So if you do a find /etc -name \*-opkg you see the conflicts.
Any sensible conversion from old to new config file should be made by
the package itself.
As I experienced, opkg exits with an error code if a config file already
exists, so if you want to create an image, the process will break at
that error.
It wasn't possible to create an image automatically then.
If you create a fresh new image, the config files should not exist.
opkg should not complain.
Problem arises if you do a 'opkg upgrade' from the running target;
With patch, opkg knows about Conffiles of base-files:
root@us-3:~# opkg info base-files
Package: base-files
Version: 3.0.14-r101.9
Provides:
Status: install user installed
Section: base
Architecture: pcontrol_g20
Maintainer: Angstrom Developers angstrom-distro-de...@linuxtogo.org
MD5Sum: d5553232d20233866c7f626b7f1d6d4f
Size: 4336
Filename: base-files_3.0.14-r101.9_pcontrol_g20.ipk
Conffiles:
/etc/fstab 8a0d747a1565dfb39ae3b27b33ab5031
/etc/hostname 0e97f4187e8f27c48206165806f9310a
/etc/motd d41d8cd98f00b204e9800998ecf8427e
/etc/profile 573d43f3c53d5bdabca7ec2317f5eb28
/etc/nsswitch.conf 109e33e2c91d1853b5bc56078a96aa18
/etc/host.conf a61b9f6548d337c1cc1e5a4de39f7b7f
Source: file://nsswitch.conf file://motd file://inputrc file://host.conf
file://profile file://profile.d file://fstab file://filesystems
file://issue.net file://issue file://usbd file://share/dot.bashrc
file://share/dot.profile file://licenses/BSD file://licenses/GPL-2
file://licenses/GPL-3 file://licenses/LGPL-2 file://licenses/LGPL-2.1
file://licenses/LGPL-3 file://licenses/GFDL-1.2 file://licenses/Artistic
Description: Miscellaneous files for the base system.
Installed-Time: 1300270958
As you can see, opkg maintains some md5-hash value for the unchanged Conffile
so a sensible conflict resolution is possible.
If it is not done so, its a opkg bug
Tested: it is possible to create an image with this patch.
Tested: 'opkg upgrade' handles the Conffiles as expected.
Peter
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 01/12] libnl: rename libnl2 to libnl as used in openembedded-core
* libnl1/libnl2 still conflicts even when using separate includedir so it will be easier for distro maintainers to use only libnl1 or libnl2 by PREFERRED_VERSION Signed-off-by: Martin Jansa martin.ja...@gmail.com --- .../libnl/files/dont-link-libnl-from-sysroot.patch | 26 --- recipes/libnl/files/fix-includes.patch | 13 - recipes/libnl/files/fix-pc-file.patch | 11 recipes/libnl/files/local-includes.patch | 12 - recipes/libnl/files/netlink-local-fix.patch| 12 - recipes/libnl/files/respect-ldflags.patch | 12 - .../libnl-1.1/dont-link-libnl-from-sysroot.patch | 26 +++ recipes/libnl/libnl-1.1/fix-includes.patch | 13 + recipes/libnl/libnl-1.1/local-includes.patch | 12 + recipes/libnl/libnl-1.1/netlink-local-fix.patch| 12 + recipes/libnl/libnl-1.1/respect-ldflags.patch | 12 + recipes/libnl/libnl/fix-pc-file.patch | 11 recipes/libnl/libnl/fix-pktloc-dep-race.patch | 20 ++ recipes/libnl/libnl2/fix-pc-file.patch | 11 recipes/libnl/libnl2/fix-pktloc-dep-race.patch | 20 -- recipes/libnl/libnl2_2.0.bb| 27 recipes/libnl/libnl2_git.bb| 27 recipes/libnl/libnl_2.0.bb | 27 recipes/libnl/libnl_git.bb | 27 19 files changed, 160 insertions(+), 171 deletions(-) delete mode 100644 recipes/libnl/files/dont-link-libnl-from-sysroot.patch delete mode 100644 recipes/libnl/files/fix-includes.patch delete mode 100644 recipes/libnl/files/fix-pc-file.patch delete mode 100644 recipes/libnl/files/local-includes.patch delete mode 100644 recipes/libnl/files/netlink-local-fix.patch delete mode 100644 recipes/libnl/files/respect-ldflags.patch create mode 100644 recipes/libnl/libnl-1.1/dont-link-libnl-from-sysroot.patch create mode 100644 recipes/libnl/libnl-1.1/fix-includes.patch create mode 100644 recipes/libnl/libnl-1.1/local-includes.patch create mode 100644 recipes/libnl/libnl-1.1/netlink-local-fix.patch create mode 100644 recipes/libnl/libnl-1.1/respect-ldflags.patch create mode 100644 recipes/libnl/libnl/fix-pc-file.patch create mode 100644 recipes/libnl/libnl/fix-pktloc-dep-race.patch delete mode 100644 recipes/libnl/libnl2/fix-pc-file.patch delete mode 100644 recipes/libnl/libnl2/fix-pktloc-dep-race.patch delete mode 100644 recipes/libnl/libnl2_2.0.bb delete mode 100644 recipes/libnl/libnl2_git.bb create mode 100644 recipes/libnl/libnl_2.0.bb create mode 100644 recipes/libnl/libnl_git.bb diff --git a/recipes/libnl/files/dont-link-libnl-from-sysroot.patch b/recipes/libnl/files/dont-link-libnl-from-sysroot.patch deleted file mode 100644 index beb6361..000 --- a/recipes/libnl/files/dont-link-libnl-from-sysroot.patch +++ /dev/null @@ -1,26 +0,0 @@ -Index: libnl-1.1/src/Makefile -=== libnl-1.1.orig/src/Makefile2008-01-14 07:48:45.0 -0800 -+++ libnl-1.1/src/Makefile 2010-09-22 14:58:46.820826001 -0700 -@@ -13,7 +13,7 @@ ifeq ($(shell [ ! -r ../Makefile.opts ] - include ../Makefile.opts - endif - --LDFLAGS += -L../lib -lnl utils.o -+LDFLAGS += ../lib/libnl.so utils.o - CIN := $(wildcard nl-*.c) $(wildcard genl-*.c) $(wildcard nf-*.c) - TOOLS := $(CIN:%.c=%) - -Index: libnl-1.1/tests/Makefile -=== libnl-1.1.orig/tests/Makefile 2008-01-14 07:48:45.0 -0800 -+++ libnl-1.1/tests/Makefile 2010-09-22 14:58:46.820826001 -0700 -@@ -13,7 +13,7 @@ ifeq ($(shell [ ! -r ../Makefile.opts ] - include ../Makefile.opts - endif - --LDFLAGS += -L../lib -lnl ../src/utils.o -+LDFLAGS += ../lib/libnl.so ../src/utils.o - CIN := $(wildcard test-*.c) - TOOLS := $(CIN:%.c=%) - diff --git a/recipes/libnl/files/fix-includes.patch b/recipes/libnl/files/fix-includes.patch deleted file mode 100644 index b172fd2..000 --- a/recipes/libnl/files/fix-includes.patch +++ /dev/null @@ -1,13 +0,0 @@ -diff -ruN libnl-1.1/lib/route/link/vlan.c libnl-1.1-new/lib/route/link/vlan.c libnl-1.1/lib/route/link/vlan.c2008-01-14 18:48:45.0 +0300 -+++ libnl-1.1-new/lib/route/link/vlan.c2009-01-30 10:55:09.0 +0300 -@@ -26,7 +26,9 @@ - #include netlink/route/link/info-api.h - #include netlink/route/link/vlan.h - -+#ifndef VLAN_FLAG_REORDER_HDR - #include linux/if_vlan.h -+#endif - - /** @cond SKIP */ - #define VLAN_HAS_ID (10) diff --git a/recipes/libnl/files/fix-pc-file.patch b/recipes/libnl/files/fix-pc-file.patch deleted file mode 100644 index 77f3e88..000 --- a/recipes/libnl/files/fix-pc-file.patch +++
[oe] [PATCH 02/12] libnl: don't use /usr/include/libnl2 anymore
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/libnl/libnl_2.0.bb |4 +---
recipes/libnl/libnl_git.bb |2 --
2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/recipes/libnl/libnl_2.0.bb b/recipes/libnl/libnl_2.0.bb
index 7e9336e..8b77d07 100644
--- a/recipes/libnl/libnl_2.0.bb
+++ b/recipes/libnl/libnl_2.0.bb
@@ -9,14 +9,12 @@ DEPENDS = flex-native bison-native
inherit autotools pkgconfig
-includedir = ${prefix}/include/libnl2
-
-S = ${WORKDIR}/libnl-${PV}
SRC_URI = \
http://www.infradead.org/~tgr/libnl/files/libnl-${PV}.tar.gz \
file://fix-pc-file.patch \
file://fix-pktloc-dep-race.patch \
+
SRC_URI[md5sum] = 6aaf1e9802a17a7d702bb0638044ffa7
SRC_URI[sha256sum] =
5a40dc903d3ca1074da7424b908bec8ff16936484798c7e46e53e9db8bc87a9c
diff --git a/recipes/libnl/libnl_git.bb b/recipes/libnl/libnl_git.bb
index b667815..b3bb749 100644
--- a/recipes/libnl/libnl_git.bb
+++ b/recipes/libnl/libnl_git.bb
@@ -11,8 +11,6 @@ DEPENDS = flex-native bison-native
inherit autotools
-includedir = ${prefix}/include/libnl2
-
SRC_URI = \
git://git.kernel.org/pub/scm/libs/netlink/libnl.git;protocol=git \
file://fix-pc-file.patch \
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 03/12] libnl: add RREPLACES libnl2 for upgradable path
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/libnl/libnl_2.0.bb |7 +++
recipes/libnl/libnl_git.bb |7 +++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/recipes/libnl/libnl_2.0.bb b/recipes/libnl/libnl_2.0.bb
index 8b77d07..6614478 100644
--- a/recipes/libnl/libnl_2.0.bb
+++ b/recipes/libnl/libnl_2.0.bb
@@ -23,3 +23,10 @@ FILES_${PN}-route = ${libdir}/libnl-route.so.*
FILES_${PN}-nf= ${libdir}/libnl-nf.so.*
FILES_${PN}-genl = ${libdir}/libnl-genl.so.*
FILES_${PN}-cli = ${libdir}/libnl-cli.so.*
+
+# for upgradable path from libnl2_2.0 to libnl_2.0
+RREPLACES_${PN} = ${PN}2
+RREPLACES_${PN}-route = ${PN}2-route
+RREPLACES_${PN}-nf = ${PN}2-nf
+RREPLACES_${PN}-genl = ${PN}2-genl
+RREPLACES_${PN}-cli = ${PN}2-cli
diff --git a/recipes/libnl/libnl_git.bb b/recipes/libnl/libnl_git.bb
index b3bb749..b844bdd 100644
--- a/recipes/libnl/libnl_git.bb
+++ b/recipes/libnl/libnl_git.bb
@@ -23,3 +23,10 @@ FILES_${PN}-route = ${libdir}/libnl-route.so.*
FILES_${PN}-nf= ${libdir}/libnl-nf.so.*
FILES_${PN}-genl = ${libdir}/libnl-genl.so.*
FILES_${PN}-cli = ${libdir}/libnl-cli.so.*
+
+# for upgradable path from libnl2_2.0 to libnl_2.0
+RREPLACES_${PN} = ${PN}2
+RREPLACES_${PN}-route = ${PN}2-route
+RREPLACES_${PN}-nf = ${PN}2-nf
+RREPLACES_${PN}-genl = ${PN}2-genl
+RREPLACES_${PN}-cli = ${PN}2-cli
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 04/12] libnl_git: remove fix-pktloc-dep-race.patch from this version
* it does not apply because there isn't pktloc in this SRCREV yet,
commented out in upstream src/lib/Makefile.am
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/libnl/libnl_git.bb |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/recipes/libnl/libnl_git.bb b/recipes/libnl/libnl_git.bb
index b844bdd..e645892 100644
--- a/recipes/libnl/libnl_git.bb
+++ b/recipes/libnl/libnl_git.bb
@@ -14,7 +14,6 @@ inherit autotools
SRC_URI = \
git://git.kernel.org/pub/scm/libs/netlink/libnl.git;protocol=git \
file://fix-pc-file.patch \
- file://fix-pktloc-dep-race.patch \
S = ${WORKDIR}/git
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 05/12] libnl: add libnl.inc and use INC_PR
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/libnl/libnl.inc|9 +
recipes/libnl/libnl_1.1.bb | 10 ++
recipes/libnl/libnl_2.0.bb |9 ++---
recipes/libnl/libnl_git.bb | 16 ++--
4 files changed, 19 insertions(+), 25 deletions(-)
create mode 100644 recipes/libnl/libnl.inc
diff --git a/recipes/libnl/libnl.inc b/recipes/libnl/libnl.inc
new file mode 100644
index 000..6f502b1
--- /dev/null
+++ b/recipes/libnl/libnl.inc
@@ -0,0 +1,9 @@
+DESCRIPTION = libnl is a library for applications dealing with netlink
sockets
+SECTION = libs/network
+LICENSE = LGPL
+HOMEPAGE = http://www.infradead.org/~tgr/libnl/;
+
+INC_PR = r5
+
+inherit autotools pkgconfig
+
diff --git a/recipes/libnl/libnl_1.1.bb b/recipes/libnl/libnl_1.1.bb
index f1b2a9d..d9f250e 100644
--- a/recipes/libnl/libnl_1.1.bb
+++ b/recipes/libnl/libnl_1.1.bb
@@ -1,11 +1,6 @@
-DESCRIPTION = libnl is a library for applications dealing with netlink
sockets
-SECTION = libs/network
-LICENSE = LGPL
-HOMEPAGE = http://www.infradead.org/~tgr/libnl/;
+require libnl.inc
-PR = r4
-
-inherit autotools pkgconfig
+PR = ${INC_PR}.0
CFLAGS += '-DVLAN_FLAG_REORDER_HDR=1'
@@ -18,6 +13,5 @@ SRC_URI = \
file://dont-link-libnl-from-sysroot.patch \
-
SRC_URI[md5sum] = ae970ccd9144e132b68664f98e7ceeb1
SRC_URI[sha256sum] =
35cea4cfb6cd8af0cafa0f34fff81def5a1f193b8b8384299b4b21883e22edc3
diff --git a/recipes/libnl/libnl_2.0.bb b/recipes/libnl/libnl_2.0.bb
index 6614478..3038487 100644
--- a/recipes/libnl/libnl_2.0.bb
+++ b/recipes/libnl/libnl_2.0.bb
@@ -1,14 +1,9 @@
-DESCRIPTION = libnl2 is a library for applications dealing with netlink
sockets
-SECTION = libs/network
-LICENSE = LGPL
-HOMEPAGE = http://www.infradead.org/~tgr/libnl/;
+require libnl.inc
PE = 1
-PR = r2
+PR = ${INC_PR}.0
DEPENDS = flex-native bison-native
-inherit autotools pkgconfig
-
SRC_URI = \
http://www.infradead.org/~tgr/libnl/files/libnl-${PV}.tar.gz \
file://fix-pc-file.patch \
diff --git a/recipes/libnl/libnl_git.bb b/recipes/libnl/libnl_git.bb
index e645892..8ce4a6e 100644
--- a/recipes/libnl/libnl_git.bb
+++ b/recipes/libnl/libnl_git.bb
@@ -1,21 +1,17 @@
-DESCRIPTION = libnl2 is a library for applications dealing with netlink
sockets
-SECTION = libs/network
-LICENSE = LGPL
-HOMEPAGE = http://www.infradead.org/~tgr/libnl/;
-SRCREV = d378220c96c3c8b6f27dca33e7d8ba03318f9c2d
-PV = 1.9+gitr${SRCPV}
+require libnl.inc
+
PE = 1
-PR = r3
+PV = 1.9+gitr${SRCPV}
+PR = ${INC_PR}.0
DEPENDS = flex-native bison-native
-inherit autotools
-
+S = ${WORKDIR}/git
+SRCREV = d378220c96c3c8b6f27dca33e7d8ba03318f9c2d
SRC_URI = \
git://git.kernel.org/pub/scm/libs/netlink/libnl.git;protocol=git \
file://fix-pc-file.patch \
-S = ${WORKDIR}/git
PACKAGES =+ ${PN}-route ${PN}-nf ${PN}-genl ${PN}-cli
FILES_${PN}-route = ${libdir}/libnl-route.so.*
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 07/12] libfsobasics: depend only on libnl(-2.0) not libnl2(-2.0)
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/freesmartphone/libfsobasics_git.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes/freesmartphone/libfsobasics_git.bb
b/recipes/freesmartphone/libfsobasics_git.bb
index c99bd8e..1d751ca 100644
--- a/recipes/freesmartphone/libfsobasics_git.bb
+++ b/recipes/freesmartphone/libfsobasics_git.bb
@@ -1,8 +1,8 @@
require cornucopia.inc
DESCRIPTION = freesmartphone.org support library
-DEPENDS += libnl2
+DEPENDS += libnl
SRCREV = ${FSO_CORNUCOPIA_SRCREV}
PV = 0.9.10+gitr${SRCPV}
PE = 1
-PR = ${INC_PR}.1
+PR = ${INC_PR}.2
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 09/12] iw: depend only on libnl(-2.0) not libnl2(-2.0)
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/iw/iw_0.9.20.bb |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/recipes/iw/iw_0.9.20.bb b/recipes/iw/iw_0.9.20.bb
index 0b6a768..7048091 100644
--- a/recipes/iw/iw_0.9.20.bb
+++ b/recipes/iw/iw_0.9.20.bb
@@ -3,18 +3,15 @@ HOMEPAGE =
http://linuxwireless.org/en/users/Documentation/iw;
SECTION = base
PRIORITY = optional
LICENSE = BSD
-PR = r2
+PR = r3
-DEPENDS = libnl2 pkgconfig
+DEPENDS = libnl pkgconfig
SRC_URI = \
http://wireless.kernel.org/download/iw/${P}.tar.bz2 \
file://kill-git-version-check.patch \
-# We stage libnl2 header files not directly as they clash with libnl files.
Once
-# we only use libnl2 and stage the headers at the normal place we can remove
-# this.
-CFLAGS += -I${STAGING_INCDIR}/libnl2/ -DCONFIG_LIBNL20
+CFLAGS += -DCONFIG_LIBNL20
do_compile() {
oe_runmake
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 06/12] SHR: drop blacklist entries for libnl, now when libnl2 is used by default
Signed-off-by: Martin Jansa martin.ja...@gmail.com --- conf/distro/shr.conf |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/conf/distro/shr.conf b/conf/distro/shr.conf index e8fd844..be5904e 100644 --- a/conf/distro/shr.conf +++ b/conf/distro/shr.conf @@ -59,7 +59,6 @@ ANGSTROM_BLACKLIST_pn-xserver-kdrive-1300 = xorg-server is preferred ANGSTROM_BLACKLIST_pn-bluez-libs = bluez-libs 3.x has been replaced by bluez4 ANGSTROM_BLACKLIST_pn-bluez-utils = bluez-utils 3.x has been replaced by bluez4 ANGSTROM_BLACKLIST_pn-atd = atd has been replaced by atd-over-fso -ANGSTROM_BLACKLIST_pn-libnl = libnld has been replaced by libnl2 ANGSTROM_BLACKLIST_pn-update-alternatives-cworth-native = update-alternatives-cworth-native has been replaced by opkg implementation of u-a script ANGSTROM_BLACKLIST_pn-update-alternatives-cworth = update-alternatives-cworth has been replaced by opkg implementation of u-a script ANGSTROM_BLACKLIST_pn-qt4-x11-free-gles = qt4-x11-free is fine even without gles @@ -85,7 +84,6 @@ ANGSTROM_BLACKLIST_pn-linux-jlime-current = strange kernel, spank maintainer ANGSTROM_BLACKLIST_pn-linux-ml403-mvista-2.6.x = strange kernel, spank maintainer ANGSTROM_BLACKLIST_pn-linux-davinci = strange kernel, spank maintainer - CVS_TARBALL_STASH += http://build.shr-project.org/sources/; #The shr-mirrors.bbclass repleaces this -- 1.7.4.1 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 10/12] ti-wifi-utils: depend only on libnl(-2.0) not libnl2(-2.0)
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/ti/ti-wifi-utils_git.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes/ti/ti-wifi-utils_git.bb b/recipes/ti/ti-wifi-utils_git.bb
index e6795a8..92edb7f 100644
--- a/recipes/ti/ti-wifi-utils_git.bb
+++ b/recipes/ti/ti-wifi-utils_git.bb
@@ -1,7 +1,7 @@
DESCRIPTION = The calibrator and other useful utilities for TI wireless
solution based on wl12xx driver
LICENSE = TI-BSD
-DEPENDS = libnl2
+DEPENDS = libnl
PV =0.0
PR_append = +gitr${SRCPV}
@@ -12,7 +12,7 @@ SRC_URI = git://github.com/gxk/ti-utils.git;protocol=git
S = ${WORKDIR}/git
export CROSS_COMPILE = ${TARGET_PREFIX}
-CFLAGS += -I${STAGING_INCDIR}/libnl2/ -DCONFIG_LIBNL20
+CFLAGS += -DCONFIG_LIBNL20
do_install() {
install -d ${D}${bindir}
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 11/12] wpa-supplicant-0.7: depend only on libnl(-2.0) not libnl2(-2.0)
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/wpa-supplicant/wpa-supplicant-0.7.inc |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/recipes/wpa-supplicant/wpa-supplicant-0.7.inc
b/recipes/wpa-supplicant/wpa-supplicant-0.7.inc
index 7649038..0cf3b70 100644
--- a/recipes/wpa-supplicant/wpa-supplicant-0.7.inc
+++ b/recipes/wpa-supplicant/wpa-supplicant-0.7.inc
@@ -6,9 +6,9 @@ LICENSE = GPLv2 | BSD
LIC_FILES_CHKSUM = file://../COPYING;md5=c54ce9345727175ff66d17b67ff51f58 \
file://../README;md5=54cfc88015d3ce83f7156e63c6bb1738 \
file://wpa_supplicant.c;beginline=1;endline=17;md5=acdc5a4b0d6345f21f136eace747260e
-DEPENDS = gnutls dbus libnl2 openssl ${@base_contains(COMBINED_FEATURES,
madwifi, madwifi-ng, ,d)}
+DEPENDS = gnutls dbus libnl openssl ${@base_contains(COMBINED_FEATURES,
madwifi, madwifi-ng, ,d)}
RRECOMMENDS_${PN} = wpa-supplicant-passphrase wpa-supplicant-cli
-INC_PR = r6
+INC_PR = r7
SRC_URI = http://hostap.epitest.fi/releases/wpa_supplicant-${PV}.tar.gz \
file://defconfig \
@@ -20,11 +20,6 @@ SRC_URI =
http://hostap.epitest.fi/releases/wpa_supplicant-${PV}.tar.gz \
S = ${WORKDIR}/wpa_supplicant-${PV}/wpa_supplicant
-# We stage libnl2 header files not directly as they clash with libnl files.
Once
-# we only use libnl2 and stage the headers at the normal place we can remove
-# this.
-CFLAGS += -I${STAGING_INCDIR}/libnl2/
-
PACKAGES_prepend = wpa-supplicant-passphrase wpa-supplicant-cli
FILES_wpa-supplicant-passphrase = /usr/sbin/wpa_passphrase
FILES_wpa-supplicant-cli = /usr/sbin/wpa_cli
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 12/12] connman: depend only on libnl(-2.0) not libnl2(-2.0)
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/connman/connman.inc |2 +-
recipes/connman/connman_0.46.bb |2 +-
recipes/connman/connman_0.51.bb |2 +-
recipes/connman/connman_0.65.bb |2 +-
recipes/connman/connman_0.68.bb |2 +-
recipes/connman/connman_git.bb |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/recipes/connman/connman.inc b/recipes/connman/connman.inc
index e25d64a..7306b1b 100644
--- a/recipes/connman/connman.inc
+++ b/recipes/connman/connman.inc
@@ -3,7 +3,7 @@ HOMEPAGE = http://www.moblin.org/projects/projects_connman.php;
SECTION = libs/network
LICENSE = GPL
# we need to define the depends here, the dynamic stuff is too late
-DEPENDS = libnl2 wpa-supplicant dbus glib-2.0 ppp busybox dhclient
resolvconf bluez4
+DEPENDS = libnl wpa-supplicant dbus glib-2.0 ppp busybox dhclient resolvconf
bluez4
EXTRA_OECONF += \
ac_cv_path_WPASUPPLICANT=/usr/sbin/wpa_supplicant \
diff --git a/recipes/connman/connman_0.46.bb b/recipes/connman/connman_0.46.bb
index a7bf286..1f1df9c 100644
--- a/recipes/connman/connman_0.46.bb
+++ b/recipes/connman/connman_0.46.bb
@@ -1,5 +1,5 @@
require connman.inc
-PR = r5
+PR = r6
EXTRA_OECONF += \
--disable-gtk-doc \
diff --git a/recipes/connman/connman_0.51.bb b/recipes/connman/connman_0.51.bb
index f1c5003..036a710 100644
--- a/recipes/connman/connman_0.51.bb
+++ b/recipes/connman/connman_0.51.bb
@@ -1,5 +1,5 @@
require connman.inc
-PR = r1
+PR = r2
EXTRA_OECONF += \
--disable-gtk-doc \
diff --git a/recipes/connman/connman_0.65.bb b/recipes/connman/connman_0.65.bb
index 78e4287..880d775 100644
--- a/recipes/connman/connman_0.65.bb
+++ b/recipes/connman/connman_0.65.bb
@@ -1,7 +1,7 @@
require connman.inc
# connman requires libXtables now
DEPENDS += iptables
-PR = r0
+PR = r1
EXTRA_OECONF += \
--disable-gtk-doc \
diff --git a/recipes/connman/connman_0.68.bb b/recipes/connman/connman_0.68.bb
index ead215d..093a5a5 100644
--- a/recipes/connman/connman_0.68.bb
+++ b/recipes/connman/connman_0.68.bb
@@ -1,7 +1,7 @@
require connman.inc
# connman requires libXtables now
DEPENDS += iptables
-PR = r1
+PR = r2
EXTRA_OECONF += \
--disable-gtk-doc \
diff --git a/recipes/connman/connman_git.bb b/recipes/connman/connman_git.bb
index 39ffac6..283eb6b 100644
--- a/recipes/connman/connman_git.bb
+++ b/recipes/connman/connman_git.bb
@@ -27,7 +27,7 @@ require connman.inc
SRCREV = 1a94db417ecaba20a609ff4b4431a3f67c5dcbc6
PV = 0.42+git
-PR = r2
+PR = r3
PR_append = .gitr${SRCREV}
DEFAULT_PREFERENCE = -1
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 08/12] hostap-daemon: depend only on libnl(-2.0) not libnl2(-2.0)
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/hostap/hostap-daemon_0.7.3.bb |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/recipes/hostap/hostap-daemon_0.7.3.bb
b/recipes/hostap/hostap-daemon_0.7.3.bb
index 2dfec35..10b1389 100644
--- a/recipes/hostap/hostap-daemon_0.7.3.bb
+++ b/recipes/hostap/hostap-daemon_0.7.3.bb
@@ -3,8 +3,8 @@ HOMEPAGE = http://hostap.epitest.fi;
SECTION = kernel/userland
PRIORITY = optional
LICENSE = GPL
-DEPENDS = libnl2 openssl
-PR = r1
+DEPENDS = libnl openssl
+PR = r2
DEFAULT_PREFERENCE = -1
@@ -21,7 +21,6 @@ INITSCRIPT_NAME=hostapd
do_configure() {
install -m 0644 ${WORKDIR}/defconfig ${S}/.config
- echo 'CFLAGS += -I${STAGING_INCDIR}/libnl2' ${S}/.config
}
do_compile() {
--
1.7.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 03/12] libnl: add RREPLACES libnl2 for upgradable path
On Fri, Mar 18, 2011 at 03:00:20PM +0100, Martin Jansa wrote:
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/libnl/libnl_2.0.bb |7 +++
recipes/libnl/libnl_git.bb |7 +++
2 files changed, 14 insertions(+), 0 deletions(-)
This one is probably not needed (don't have libnl1 installed here to test)
I've PATCHv2 with this:
+# for upgradable path from libnl_1.0 to libnl_2.0
+# old libnl2_2.0 already had same names so RREPLACES isn't needed
+# libnl2_2.0/libnl_2.0 with debian naming produces ie libnl-route2
+RREPLACES_${PN} = libnl1
+RREPLACES_${PN}-route = libnl1
+RREPLACES_${PN}-nf = libnl1
+RREPLACES_${PN}-genl = libnl1
+RREPLACES_${PN}-cli = libnl1
but still it looks like only libnl2-dev and libnl-dev have conflicting
files, so maybe RCONFLICTS will be better to let user to remove old
libnl1 before upgrade to libnl2?
diff --git a/recipes/libnl/libnl_2.0.bb b/recipes/libnl/libnl_2.0.bb
index 8b77d07..6614478 100644
--- a/recipes/libnl/libnl_2.0.bb
+++ b/recipes/libnl/libnl_2.0.bb
@@ -23,3 +23,10 @@ FILES_${PN}-route = ${libdir}/libnl-route.so.*
FILES_${PN}-nf= ${libdir}/libnl-nf.so.*
FILES_${PN}-genl = ${libdir}/libnl-genl.so.*
FILES_${PN}-cli = ${libdir}/libnl-cli.so.*
+
+# for upgradable path from libnl2_2.0 to libnl_2.0
+RREPLACES_${PN} = ${PN}2
+RREPLACES_${PN}-route = ${PN}2-route
+RREPLACES_${PN}-nf = ${PN}2-nf
+RREPLACES_${PN}-genl = ${PN}2-genl
+RREPLACES_${PN}-cli = ${PN}2-cli
diff --git a/recipes/libnl/libnl_git.bb b/recipes/libnl/libnl_git.bb
index b3bb749..b844bdd 100644
--- a/recipes/libnl/libnl_git.bb
+++ b/recipes/libnl/libnl_git.bb
@@ -23,3 +23,10 @@ FILES_${PN}-route = ${libdir}/libnl-route.so.*
FILES_${PN}-nf= ${libdir}/libnl-nf.so.*
FILES_${PN}-genl = ${libdir}/libnl-genl.so.*
FILES_${PN}-cli = ${libdir}/libnl-cli.so.*
+
+# for upgradable path from libnl2_2.0 to libnl_2.0
+RREPLACES_${PN} = ${PN}2
+RREPLACES_${PN}-route = ${PN}2-route
+RREPLACES_${PN}-nf = ${PN}2-nf
+RREPLACES_${PN}-genl = ${PN}2-genl
+RREPLACES_${PN}-cli = ${PN}2-cli
--
1.7.4.1
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
pgpQwvmMkvskQ.pgp
Description: PGP signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] xbmc: add `libass` to `DEPENDS`
Hi Paul,
the problem is this
do_configure() {
if [ -e bootstrap.angstrom ] ; then
sh bootstrap.angstrom
else
sh bootstrap
fi
oe_runconf
}
which prevents the autoreconf run and so the regenerating of libtool stuff,
which results
in that the configure option --with-sysrootdir is not available. I cannt see how
your patch is fixing that.
Bye Henning
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 3/3] base-files-3.0.14 configuration files
On Fri, Mar 18, 2011 at 02:08:15PM +0100, Peter Gsellmann wrote:
Am Freitag, 18. März 2011, 09:59:17 schrieb Hauser, Wolfgang (external):
Mark some files in ${sysconfdir} as configuration files so they are
not blindly overwritten when upgrading
I would suggest a pre-/post processing in the packages, like debian
does.
If a config file exists or is changed, the current File will be
rotated
or, if possible, left as it is and the new
file is installed beside the changed one.
The opkg does not touch a present config file, but installs the new
file with the name *-opkg
So if you do a find /etc -name \*-opkg you see the conflicts.
Any sensible conversion from old to new config file should be made by
the package itself.
As I experienced, opkg exits with an error code if a config file already
exists, so if you want to create an image, the process will break at
that error.
It wasn't possible to create an image automatically then.
If you create a fresh new image, the config files should not exist.
opkg should not complain.
Looks like you two are talking about 2 different things.
W) If 2 different packages are installing same config file, opkg won't
overwrite it and image creation would also fail
P) If same package is trying to install newer version of config file it
overwrites it silently when md5 sums are the same or file is not in
CONFFILES or creates config.file-opkg otherwise.
So the patch idea looks sane to me, only please check why there is
unused conffiles variable and maybe use it as default CONFFILES or
remove it completely.
Regards,
Problem arises if you do a 'opkg upgrade' from the running target;
With patch, opkg knows about Conffiles of base-files:
root@us-3:~# opkg info base-files
Package: base-files
Version: 3.0.14-r101.9
Provides:
Status: install user installed
Section: base
Architecture: pcontrol_g20
Maintainer: Angstrom Developers angstrom-distro-de...@linuxtogo.org
MD5Sum: d5553232d20233866c7f626b7f1d6d4f
Size: 4336
Filename: base-files_3.0.14-r101.9_pcontrol_g20.ipk
Conffiles:
/etc/fstab 8a0d747a1565dfb39ae3b27b33ab5031
/etc/hostname 0e97f4187e8f27c48206165806f9310a
/etc/motd d41d8cd98f00b204e9800998ecf8427e
/etc/profile 573d43f3c53d5bdabca7ec2317f5eb28
/etc/nsswitch.conf 109e33e2c91d1853b5bc56078a96aa18
/etc/host.conf a61b9f6548d337c1cc1e5a4de39f7b7f
Source: file://nsswitch.conf file://motd file://inputrc file://host.conf
file://profile file://profile.d file://fstab file://filesystems
file://issue.net file://issue file://usbd file://share/dot.bashrc
file://share/dot.profile file://licenses/BSD file://licenses/GPL-2
file://licenses/GPL-3 file://licenses/LGPL-2 file://licenses/LGPL-2.1
file://licenses/LGPL-3 file://licenses/GFDL-1.2 file://licenses/Artistic
Description: Miscellaneous files for the base system.
Installed-Time: 1300270958
As you can see, opkg maintains some md5-hash value for the unchanged Conffile
so a sensible conflict resolution is possible.
If it is not done so, its a opkg bug
Tested: it is possible to create an image with this patch.
Tested: 'opkg upgrade' handles the Conffiles as expected.
Peter
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
pgpq1YRSdkdxJ.pgp
Description: PGP signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 03/12] libnl: add RREPLACES libnl2 for upgradable path
On Fri, 2011-03-18 at 15:00 +0100, Martin Jansa wrote:
+# for upgradable path from libnl2_2.0 to libnl_2.0
+RREPLACES_${PN} = ${PN}2
+RREPLACES_${PN}-route = ${PN}2-route
Don't you also want RPROVIDES, RCONFLICTS?
p.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 3/3] base-files-3.0.14 configuration files
Hi Martin!
Am Freitag, 18. März 2011, 16:30:48 schrieb Martin Jansa:
On Fri, Mar 18, 2011 at 02:08:15PM +0100, Peter Gsellmann wrote:
Am Freitag, 18. März 2011, 09:59:17 schrieb Hauser, Wolfgang (external):
Mark some files in ${sysconfdir} as configuration files so they are
not blindly overwritten when upgrading
I would suggest a pre-/post processing in the packages, like debian
does.
If a config file exists or is changed, the current File will be
rotated
or, if possible, left as it is and the new
file is installed beside the changed one.
The opkg does not touch a present config file, but installs the new
file with the name *-opkg
So if you do a find /etc -name \*-opkg you see the conflicts.
Any sensible conversion from old to new config file should be made by
the package itself.
As I experienced, opkg exits with an error code if a config file already
exists, so if you want to create an image, the process will break at
that error.
It wasn't possible to create an image automatically then.
If you create a fresh new image, the config files should not exist.
opkg should not complain.
Looks like you two are talking about 2 different things.
W) If 2 different packages are installing same config file, opkg won't
overwrite it and image creation would also fail
This should considered as bug in opkg;
why 2 packages may not use the same Conffile?
For example one would split 'ntp' into 'ntpd' and 'ntpdate':
both should use the servers in /etc/ntp.conf .
In present configuration you have to syncronize 2 files /etc/ntp.conf
and /etc/ntp/step-tickers .
P) If same package is trying to install newer version of config file it
overwrites it silently when md5 sums are the same or file is not in
CONFFILES or creates config.file-opkg otherwise.
This should considered as user error to 'install' a package instead of
'upgrade'.
So the patch idea looks sane to me, only please check why there is
unused conffiles variable and maybe use it as default CONFFILES or
remove it completely.
I think you talk about CONFFILES_${PN}_micro, CONFFILES_${PN}_nylon,
CONFFILES_${PN}_slugos ?
For 'nylon' and 'slugos' it generates an additional empty file /etc/resolv.conf
.
Otherwise this file is not owned by any package even so it exists!
(anybody knows who creates it?)
Could this be written as:
CONFFILES_${PN}_nylon = ${CONFFILES_${PN}} + ${sysconfdir}/resolv.conf
or is there a smarter syntax?
OTOH, declaring 'base-files' as owner of /etc/resolv.conf for _all_ images
would be the better solution (in my opinion). Votings?
For 'micro' the list is empty! What is the advantage of an empty list for this
image?
I dont know and for this i am a bit reluctant to remove it.
Peter
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] blacklist.bbclass
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: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] blacklist.bbclass
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 Frans ___ 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] blacklist.bbclass
On Fri, 2011-03-18 at 21:33 +0100, Frans Meulenbroeks 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 The class that Mickey is talking about is just the mechanism to allow blacklisting. It doesn't actually contain a list of blacklisted packages; I think that typically goes in DISTRO.conf for distros that use it. However, if we do want to rename it to something more global (which I agree seems like a good idea) then the contents would need a bit of tweaking since both the variables that it looks at, and the messages that it outputs, make reference to Angstrom specifically. p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] blacklist.bbclass
On 03/18/2011 02:35 PM, Phil Blundell wrote: On Fri, 2011-03-18 at 21:33 +0100, Frans Meulenbroeks wrote: 2011/3/18 Dr. Michael Lauermic...@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 The class that Mickey is talking about is just the mechanism to allow blacklisting. It doesn't actually contain a list of blacklisted packages; I think that typically goes in DISTRO.conf for distros that use it. However, if we do want to rename it to something more global (which I agree seems like a good idea) then the contents would need a bit of tweaking since both the variables that it looks at, and the messages that it outputs, make reference to Angstrom specifically. I've had that locally for a long while now (BLACKLIST and just %s is unsupported because %s). So I vote in favor of a generic list distros blacklist items class. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] xbmc: add `libass` to `DEPENDS`
Dear Henning,
Am Freitag, den 18.03.2011, 16:14 +0100 schrieb Henning Heinold:
Hi Paul,
the problem is this
do_configure() {
if [ -e bootstrap.angstrom ] ; then
sh bootstrap.angstrom
else
sh bootstrap
fi
oe_runconf
}
which prevents the autoreconf run and so the regenerating of libtool stuff,
which results
in that the configure option --with-sysrootdir is not available. I cannt see
how
your patch is fixing that.
I think the following goes on. XBMC’s configure script detects that the
external libass is available and just uses that. XBMC ships all used
libraries with it, so it is buildable without downloading additional
stuff (which is of course bad for maintainability reasons). So
beforehand the configure script set up compilation of the internal
libass which failed for the reason you pointed out above.
I build tested this, so it should be fine?
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] blacklist.bbclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-03-11 20:24, Dr. Michael Lauer wrote: 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. So include it in your $DISTRO. Would there be a strong objection of renaming this to blacklist.bbclass? Why is a rename needed? SHR is already using it as is. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFNg9x+MkyGM64RGpERApRIAKCaBrrX6A/yyoIMuRrELdeJCTqs1gCggw93 q+51Hc05SmGVgocnoEJeR10= =+KOd -END PGP SIGNATURE- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] blacklist.bbclass
2011/3/18 Phil Blundell ph...@gnu.org: On Fri, 2011-03-18 at 21:33 +0100, Frans Meulenbroeks 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 The class that Mickey is talking about is just the mechanism to allow blacklisting. It doesn't actually contain a list of blacklisted packages; I think that typically goes in DISTRO.conf for distros that use it. However, if we do want to rename it to something more global (which I agree seems like a good idea) then the contents would need a bit of tweaking since both the variables that it looks at, and the messages that it outputs, make reference to Angstrom specifically. Ah ok, thanks for the explanation! Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] blacklist.bbclass
On 03/18/2011 06:28 PM, Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-03-11 20:24, Dr. Michael Lauer wrote: 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. So include it in your $DISTRO. Would there be a strong objection of renaming this to blacklist.bbclass? Why is a rename needed? SHR is already using it as is. What is oe-core doing? I would think they would want to make this more generic. The solution may be to adopt what happens there. Philip ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] blacklist.bbclass
On 18/03/2011 19:24, Dr. Michael Lauer wrote: 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. As the author I object to renaming it. We have played this rename game before and Im still not happy with the results of the last time. I also object on the grounds of the amount of abuse I got from some other distro maintainers for implementing this, which is the reason it is called angstrom.bbclass. Graeme ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Eliminating dependency race-conditions (was Re: [PATCH] net-snmp: disable libnl use)
On Thu, 2011-03-17 at 20:58 +0100, Esben Haabendal wrote: On Thu, 2011-03-17 at 18:05 +, Phil Blundell wrote: On Thu, 2011-03-17 at 18:52 +0100, Esben Haabendal wrote: Well, it might be possible to minimize the disruption for a transitional period by carefully specifying some catch-all build-time package dependencies pulling in all packages for recipes not ported yet. Yes, that's the sort of thing I was thinking of. It isn't even totally obvious to me that specifying individual packages is any better than all packages from recipe X, since with the former you then have a potential maintenance headache if files get moved from one package to another. There is a number of ways that I believe package based build dependencies are better than recipe based. a) It is possible to depend on parts of a recipe, which fx. is useful when a recipe provides more than 1 library, where you might not want all of them. b) To build a recipe, you depend on some stuff which you don't need to, or perhaps even really don't want to pass on to recipes depending on this recipe. c) KISS. Using the actual target packages for satisfying build-time dependencies are a very simple approach, which I strongly believe will make OE a better tool in the long run, by reducing complexity, and thus lowering the bar for contributing to OE archictural work. I'd like to step in here and point out that your approach is not as simple as you claim. It certainly is a really nice solution for one very specific use case. There are however many other problems which appear when you step away from your isolated usecase. Take the case of different package managers, how is that handled? Can you only have one enabled at a given time? What happens if you switch package manager half way through a build. Currently package managers and package format are abstracted, I suspect we lose that with your implementation. What if the package managers have slightly different behaviours? Secondly, how about task output that isn't packages? The output of do_deploy for example(kernel/firmware/bootloader)? The pkgdata generated by do_package? A generic extra task added by the user which outputs some data? What you're proposing is to totally actually totally collapse our current generic task structure into something entirely governed by target packages and their specific requirements. Of course you could say the existing mechanisms are still available but then where is the simplification? sstate is very simple in concept and very simple in operation compared to anything we've previously had. It is generic being task based and can apply to any task as required. It doesn't require radical changes to the existing model, there is a clear migration path and it also embraces things like the checksum/signature generation which I believe are going to play a significant role in the future. This isn't to say what you're doing is wrong or that we shouldn't be looking at it for ideas but I believe it needs to be something incremental on top of what we already have and functionality we have now cannot simply be lost as people use it. Cheers, Richard ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Eliminating dependency race-conditions
On Fri, 2011-03-18 at 13:14 +0100, Esben Haabendal wrote: By doing it this way, I don't think we are getting much closer to the second step (package-based build-time dependencies). The OE-lite implementation of per-recipe staging builds on top of package-based build-time dependencies, so to do it the other way around, would imply taking the sstate concept and extend it to do per-recipe sysroots. After that, I believe you have exactly the same amount of development left to get where OE-lite is in respect to package-based build-time depencies and per-recipe staging. As I see it, package-based build-time dependencies practically obsoletes sstate. This is where I think you misunderstand why sstate has been written and what its role is. Its a generic abstraction of taking the output from a task, saving it away somewhere and then being able to reuse a prebuilt version of it. There is no dependency on a package manager, package format or special dependency formats. sstate simply looks for a prebuilt version (matching a checksum), uses it if present, otherwise builds from scratch. I was thinking of situations like the Debian package autonamer, ie the thing that causes glibc-dev to come out named libc6-dev.ipk or similar depending on the soname of the library that was built. It seems like this would be a bit awkward to deal with if your dependencies were specified purely in terms of output packages. As OE-lite is not OE, we are currently not supporting such type of package renaming. Let's leave that to Debian guys to fight with ;-) What other features are you not supporting? Are you prepared to think about them or is that someone else's problem? Cheers, Richard ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OE Bugzilla Future
On Fri, 2011-03-18 at 10:15 +, Phil Blundell wrote: On Fri, 2011-03-18 at 08:57 +0100, Frans Meulenbroeks wrote: 2011/3/17 Richard Purdie richard.pur...@linuxfoundation.org: On Thu, 2011-03-17 at 19:10 +0100, Michael 'Mickey' Lauer wrote: I'm in favor of keeping it, cleaning it up, and improve the integration with patchwork / git. Throwing it away would be a very bad sign to all those countless people who've gone through the pains of actually working with the bugtracker. The simple question is who is actually going to sort out the mess its in? Who is going to look after it on a continuing basis? If there isn't ownership, nothing is going to change. Actually I feel the real problem is that: - people did not want to get bugs assigned to them (at least that was what someone told me in the past) - we're lacking a good notion of package or recipe ownership, so even if we had someone acting as a bug manager, (s)he would have a hard time to find out who to assign an issue to. Yes, agreed. A few people have tried in the past to take responsibility for bugzilla itself (in infrastructure terms) and I would be happy enough to do that for the future. But it clearly is not reasonable to expect the Bugzilla maintainer(s) to be personally responsible for fixing every bug that gets reported. This is the key question. Who is responsible for fixing bugs? The recipe's original author? The maintainer? The reporter? The bugzilla maintainer? The TSC? The answer in general is whoever has time and an interest in it and none of the above. As you say, the real issue here seems to be that someone (presumably the TSC) needs to determine the workflow that OE is going to use and then convince the developers to stick to it. Here lies the problem. All OE's developers are effectively volunteers. We have no means to convince developers to stick to anything. Volunteer developers have a tendency to rebel as soon as it even remotely looks like someone might force them to do something :). I put the smile in as I don't mean this in a bad way but I do think we need to understand that few people have the time to dive into other people's problems. This is the underlying issue and I don't think anything has changed for OE. I don't think there is anything magic the TSC can do either. Yocto has different dynamics and I think those could be useful for some of this and can help improve things for the better but its never a free for all. Yocto has, can and will look at certain bugs but the scope needs to be constrained, certainly to OE-Core. Cheers, Richard ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
