-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

please ignore
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE6vJLMkyGM64RGpERAt/dAKCJeoaUQPirpShdBvILfmM7tga57gCgk5k5
4+dEmGjNQjznXLp7n3W7FxQ=
=Cqjg
-----END PGP SIGNATURE-----

http://bugs.openembedded.org/show_bug.cgi?id=1351


koen@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED




------- Comment #2 from koen@... 2006-08-22 05:20 -------
Marcin committed this


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.openembedded.org/show_bug.cgi?id=1266


openembedded@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED




------- Comment #4 from openembedded@... 2006-08-22 05:21 -------
pushed into .dev


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Koen removed do_fetch[nostamp] from .dev earlier on (which I'm in total
agreement with) but its going to cause pain for a few people as
everything will need to be rebuilt.

http://www.rpsys.net/openzaurus/temp/make_fetch_stamps is a quick hack
to add the missing fetch stamps to you stamps directory and can save
rebuilding everything (run it with the stamps directory path as the
first argument).

Cheers,

Richard

On Fri, 2006-08-18 at 23:23 +0200, mreimer commit wrote:

swig-native: add a bb file for 1.3.29.

Author: mreimer@...

============================================================
--- packages/swig/swig-native_1.3.29.bb 89569bd5aec701a45a7c326cb76e3cc22761dd61
+++ packages/swig/swig-native_1.3.29.bb 89569bd5aec701a45a7c326cb76e3cc22761dd61
@@ -0,0 +1,7 @@
+require swig_${PV}.bb

Could you add swig_1.3.29.bb please? :)

Richard

@@ -142,7 +142,7 @@ RDEPENDS_angstrom-task-office := "\
gnumeric \
abiword \
imposter \
- evince \
+# evince \
gqview"

Does that really work that way? Isn't '\' just concatenating the lines
so we end up with

angstrom-task-office = "gnumeric abiword imposter evince # gqview" which
isn't what we want or is it?

--
Regards,

Michael 'Mickey' Lauer | FreeLancer | http://www.Vanille-Media.de

On Wed, 2006-08-23 at 00:14 +0200, Michael 'Mickey' Lauer wrote:

@@ -142,7 +142,7 @@ RDEPENDS_angstrom-task-office := "\
gnumeric \
abiword \
imposter \
- evince \
+# evince \
gqview"

Does that really work that way? Isn't '\' just concatenating the lines
so we end up with

angstrom-task-office = "gnumeric abiword imposter evince # gqview" which
isn't what we want or is it?

It does work. It is a bug in the parser though :)

Richard

http://bugs.openembedded.org/show_bug.cgi?id=1260


openembedded@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED




------- Comment #3 from openembedded@... 2006-08-23 03:58 -------
pushed into .dev:

wlan-ng: fixing to get it build and updated - close #1260
- added 0.2.4+svn20060823
- bumped SVN to 0.2.4
- SVN are DEFAULT_PREFERENCE = -1 now
- dropped pcmcia-driver.patch from wlan-ng-modules.inc
- for PCMCIA cards we use HostAP not wlan-ng


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.openembedded.org/show_bug.cgi?id=1341


hma@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |




------- Comment #3 from hma@... 2006-08-23 08:00 -------

That should be fixed already - rebuild kernel.

I don't understand.
I rebuild the kernel, linux-openzaurus-2.6.17-r17.

After the build procedure, I found pcnet_cs.ko in
oz354x/tmp/rootfs/lib/modules/2.6.17/kernel/drivers/net/pcmcia/ directory.

$ modinfo pcnet_cs.ko | grep depends
depends: 8390

but I can't find
oz354x/tmp/rootfs/lib/modules/2.6.17/kernel/drivers/net/8390.ko

Where is it?
Should I pick some patch from .dev branch?
Now I'm building for 3.5.4.2


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.openembedded.org/show_bug.cgi?id=1353

Summary: gpe-session-scripts shouldn't depend on gpe-bluetooth
Product: Openembedded
Version: OpenZaurus 3.5.4.x
Platform: ARM
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P4
Component: Build
AssignedTo: openembedded-devel@...
ReportedBy: hma@...
QAContact: tinderbox-oe@...


gpe-session-scripts is essential package to login to /logout from GPE.
Now the package depends on gpe-bluetooth.

SL-C700 doesn't have bluetooth facility.
I want more free space rather than unused package,
so tried to remove gpe-bluetooth package.
After that, I can't login to GPE, because gpe-session-scripts also removed.

I replaced the lines in gpe-session-scripts_0.66.bb.
Is this reasonable solution?

#RDEPENDS_${PN} = "matchbox gpe-session-starter gpe-bluetooth xstroke xtscal
gpe
-question gpe-clock matchbox-applet-inputmanager xrandr xmodmap xdpyinfo
xserver
-common"
RDEPENDS_${PN} = "matchbox gpe-session-starter xstroke xtscal gpe-question
gpe-c
lock matchbox-applet-inputmanager xrandr xmodmap xdpyinfo xserver-common"

and

-DEPENDS = "matchbox-wm matchbox-panel gpe-bluetooth xstroke xtscal
gpe-question
matchbox-applet-inputmanager gpe-clock xrandr xmodmap xdpyinfo xserver-common"
+DEPENDS = "matchbox-wm matchbox-panel xstroke xtscal gpe-question
matchbox-apple
t-inputmanager gpe-clock xrandr xmodmap xdpyinfo xserver-common"


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.openembedded.org/show_bug.cgi?id=1195





------- Comment #1 from papercrane@... 2006-08-23 12:45 -------
I also ran into this today. It's interesting to mention that it compiles fine
in .oz354x.


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

After some fixes to firefox (removing ~2MB of debug from the main package) I ran my
find-debug script again. You can find the output at

http://www.openembedded.org/~koen/OE/spurious-debug.txt

The needed fixes are pretty straight forward and excellent material for people that want
to pluck some low-hanging fruit :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE7MBSMkyGM64RGpERAoDpAKCYlQ/Mv8xePNalqh2KqiTB6NTi4wCfTl+P
EjOWt8LobErvbj3QmIq2WXo=
=yZs9
-----END PGP SIGNATURE-----

http://bugs.openembedded.org/show_bug.cgi?id=1354

Summary: glibc fails to build
Product: Openembedded
Version: OpenZaurus 3.5.4.x
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Build
AssignedTo: openembedded-devel@...
ReportedBy: bugs.openembedded.org@...
QAContact: tinderbox-oe@...


NOTE: package glibc-2.3.5+cvs20050627: started
NOTE: package glibc-2.3.5+cvs20050627-r12: task do_fetch: started
NOTE: package glibc-2.3.5+cvs20050627-r12: task do_fetch: completed
Updating
/export/interim/openembedded/tmp/stamps/arm-linux/glibc-2.3.5+cvs20050627-r12.do_fetch
NOTE: package glibc-2.3.5+cvs20050627-r12: task do_unpack: started
NOTE: Unpacking
/export/interim/openembedded/sources/stash_libc_sources.redhat.com__20050627.tar.gz
to /export/interim/openembedded/tmp/work/arm-linux/glibc-2.3.5+cvs20050627-r12/
NOTE: Unpacking
/export/interim/openembedded/sources/stash_ports_sources.redhat.com__20050627.tar.gz
to /export/interim/openembedded/tmp/work/arm-linux/glibc-2.3.5+cvs20050627-r12/
NOTE: Unpacking
/export/interim/openembedded/org.openembedded.dev/packages/glibc/files/etc/ld.so.conf
to /export/interim/openembedded/tmp/work/arm-linux/glibc-2.3.5+cvs20050627-r12/
NOTE: Unpacking
/export/interim/openembedded/org.openembedded.dev/packages/glibc/files/generate-supported.mk
to /export/interim/openembedded/tmp/work/arm-linux/glibc-2.3.5+cvs20050627-r12/
NOTE: package glibc-2.3.5+cvs20050627-r12: task do_unpack: completed
Updating
/export/interim/openembedded/tmp/stamps/arm-linux/glibc-2.3.5+cvs20050627-r12.do_unpack
NOTE: package glibc-2.3.5+cvs20050627-r12: task do_munge: started
ERROR: function do_munge failed
ERROR: log data follows
(/export/interim/openembedded/tmp/work/arm-linux/glibc-2.3.5+cvs20050627-r12/temp/log.do_munge.21570)
| mv: cannot overwrite directory
`/export/interim/openembedded/tmp/work/arm-linux/glibc-2.3.5+cvs20050627-r12/libc/ports'
NOTE: Task failed:
/export/interim/openembedded/tmp/work/arm-linux/glibc-2.3.5+cvs20050627-r12/temp/log.do_munge.21570
NOTE: package glibc-2.3.5+cvs20050627-r12: task do_munge: failed
ERROR: TaskFailed event exception, aborting
NOTE: package glibc-2.3.5+cvs20050627-r12: task do_clean: started
NOTE: removing
/export/interim/openembedded/tmp/work/arm-linux/glibc-2.3.5+cvs20050627-r12
NOTE: removing
/export/interim/openembedded/tmp/stamps/arm-linux/glibc-2.3.5+cvs20050627-r12.*
NOTE: package glibc-2.3.5+cvs20050627-r12: task do_clean: completed
NOTE: package glibc-2.3.5+cvs20050627: failed
ERROR: Build of altboot failed


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.openembedded.org/show_bug.cgi?id=1355

Summary: Add explicit command separators in populate-volatile.sh
Product: Openembedded
Version: Angstrom
Platform: ARM
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Distributions
AssignedTo: openembedded-devel@...
ReportedBy: pmiscml@...
QAContact: tinderbox-oe@...


Built an Angstrom bootstrap image for h4000 lately, during boot there were
quite few errors, yet need to investigate. What's interesting is that I got
funky files like "root.root" in / .

A look at populate-volatile.sh showed that it could use some semicolons to
separate commands which otherwise could get folded into one if argument is
empty. I really not sure why this happen - maybe due to populate-volatile.sh
caching, maybe due to busybox peculiarities, but the fact it does.


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.openembedded.org/show_bug.cgi?id=1356

Summary: new ja.po files are ready for some gpe-* packages
Product: Openembedded
Version: unspecified
Platform: All
URL: http://hp.vector.co.jp/authors/VA014481/team-ja/
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P3
Component: Distributions
AssignedTo: openembedded-devel@...
ReportedBy: hma@...
QAContact: tinderbox-oe@...


Hi, I prepared Japanese message catalog file for some gpe related packages.
They are placed at:
http://hp.vector.co.jp/authors/VA014481/team-ja/

The message catalogs include:

gpe-clock-0.6.ja.po
gpe-edit-0.13.ja.po
gpe-go-0.05.ja.po
gpe-login-0.60.ja.po
gpe-ownerinfo-0.22.ja.po
gpe-package-0.3.ja.po
gpe-su-0.09.ja.po
gpe-todo-0.54.ja.po
gpe-todo-0.55.ja.po

As you can see, most of them are some versions behind the newest.
It is because the newest POT files are not praced in Translation Project.
If you, package mainteners have to (re-)read the procedure to let POT file
keep track after new releases, please refer the following URL:
http://www.iro.umontreal.ca/translation/HTML/maintainers.html

I hope above ja.po files are included in each packages and help
Japanese people to use the packages.


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

On 8/22/06, Richard Purdie <rpurdie@...> wrote:

On Fri, 2006-08-18 at 23:23 +0200, mreimer commit wrote:

swig-native: add a bb file for 1.3.29.

Author: mreimer@...

============================================================
--- packages/swig/swig-native_1.3.29.bb 89569bd5aec701a45a7c326cb76e3cc22761dd61
+++ packages/swig/swig-native_1.3.29.bb 89569bd5aec701a45a7c326cb76e3cc22761dd61
@@ -0,0 +1,7 @@
+require swig_${PV}.bb

Could you add swig_1.3.29.bb please? :)

Richard

Looks like pH5 beat me to it. Thanks pH5!

Matt

On Fri, Aug 18, 2006 at 01:33:12AM +1000, Jamie Lenehan wrote:

On Thu, Aug 17, 2006 at 08:53:25PM +1000, Jamie Lenehan wrote:

Attached is a patch I'd like to propose to allow for multiple site
files to be used so that common stuff can be moved into common site

[...]

I've extended this a bit to allow site files to be per package,
rather than having to be global - including version specific site
files (such as db needs). Lots of packages just need a few site file
entries which are generally common across all builds or specific to
glibc or uclibc.

Probably the most useful part is allowing all of the x86 site files
to be merged together.

If no one has any comments on this then I guess I'll push it in.
First the info.bbclass, then clean up the few recipes that directly
mess with CONFIG_SITE, then clean up the x86 files and the the few
recipes that I've been maintaining.

=== oe-multi-site-file.patch ===

#
# old_revision [ac2124fc98391df1b17c8e6b7041eecdfa7543ed]
#
# add_file "classes/info.bbclass"
# content [e4021d0330d1006610d2d86ba7a6ebd6a1afbf23]
#
# patch "classes/autotools.bbclass"
# from [9467624c157cb8970b3658f48e7952ac0fa11fcc]
# to [e1849c9126d9460cb1c931e9a920ec02c3cb091c]
#
============================================================
--- classes/info.bbclass e4021d0330d1006610d2d86ba7a6ebd6a1afbf23
+++ classes/info.bbclass e4021d0330d1006610d2d86ba7a6ebd6a1afbf23
@@ -0,0 +1,81 @@
+# info.bbclass
+#
+# This class exists to provide information about the targets that
+# may be needed by other classes and/or recipes. If you add a new
+# target this will probably need to be updated.
+#
+
+#
+# Returns information about 'what' for the named target 'target'
+# where 'target' == "<arch>-<os>"
+#
+# 'what' can be one of
+# * target: Returns the target name ("<arch>-<os>")
+# * endianess: Return "be" for big endian targets, "le" for little endian
+# * bits: Returns the bit size of the target, either "32" or "64"
+# * libc: Returns the name of the c library used by the target
+#
+# It is an error for the target not to exist.
+# If 'what' doesn't exist then an empty value is returned
+#
+def get_info_for_named_target(target, what, d):
+ import bb
+ targetinfo = {\
+ "armeb-linux": dict(endianess="be", bits="32", libc="glibc" ),\
+ "armeb-linux-uclibc": dict(endianess="be", bits="32", libc="uclibc"),\
+ "arm-linux": dict(endianess="le", bits="32", libc="glibc" ),\
+ "arm-linux-gnueabi": dict(endianess="le", bits="32", libc="gnueabi", alias="arm-linux"),\
+ "arm-linux-uclibc": dict(endianess="le", bits="32", libc="uclibc" ),\
+ "i386-linux": dict(endianess="le", bits="32", libc="glibc", alias="ix86-linux"),\
+ "i486-linux": dict(endianess="le", bits="32", libc="glibc", alias="ix86-linux"),\
+ "i586-linux": dict(endianess="le", bits="32", libc="glibc", alias="ix86-linux"),\
+ "i686-linux": dict(endianess="le", bits="32", libc="glibc", alias="ix86-linux"),\
+ "i386-linux-uclibc": dict(endianess="le", bits="32", libc="uclibc", alias="ix86-linux-uclibc"),\
+ "i486-linux-uclibc": dict(endianess="le", bits="32", libc="uclibc", alias="ix86-linux-uclibc"),\
+ "i586-linux-uclibc": dict(endianess="le", bits="32", libc="uclibc", alias="ix86-linux-uclibc"),\
+ "i686-linux-uclibc": dict(endianess="le", bits="32", libc="uclibc", alias="ix86-linux-uclibc"),\
+ "mipsel-linux": dict(endianess="le", bits="32", libc="glibc" ),\
+ "mipsel-linux-uclibc": dict(endianess="le", bits="32", libc="uclibc"),\
+ "powerpc-darwin": dict(endianess="be", bits="32", libc="darwin"),\
+ "powerpc-linux": dict(endianess="be", bits="32", libc="glibc" ),\
+ "powerpc-linux-uclibc": dict(endianess="be", bits="32", libc="uclibc"),\
+ "sh3-linux": dict(endianess="le", bits="32", libc="glibc" ),\
+ "sh4-linux": dict(endianess="le", bits="32", libc="glibc" ),\
+ "sh4-linux-uclibc": dict(endianess="le", bits="32", libc="uclibc"),\
+ "sparc-linux": dict(endianess="be", bits="32", libc="glibc" ),\
+ "x86_64-linux": dict(endianess="le", bits="64", libc="glibc" ),\
+ "x86_64-linux-uclibc": dict(endianess="le", bits="64", libc="uclibc")}
+ if targetinfo.has_key(target):
+ info = targetinfo[target]
+ # allow them to ask for the target name
+ if what == "target":
+ return target;
+ # otherwise get the information from the table
+ return info.get(what, "")
+ else:
+ bb.error("Information not available for target '%s'" % target)
+
+#
+# Returns information about 'what' for the current target
+#
+def get_info_for_target(what, d):
+ import bb
+ target = bb.data.getVar('HOST_ARCH', d, 1) + "-" + bb.data.getVar('HOST_OS', d, 1)
+ return get_info_for_named_target(target, what, d)
+
+
+#
+# Return the value of 'le' if the target is little endian, or 'be' if
+# it's big endian. Let's a recipe define a specific value based on
+# the endianess of the target without the need to write lots of
+# tests.
+#
+def get_info_choice_endianess(le, be, d):
+ import bb
+ e = get_info_for_target('endianess', d);
+ if e == 'le':
+ return le
+ if e == 'be':
+ return be
+ else:
+ bb.error("Endianess unknown for target '%s'" % target)
============================================================
--- classes/autotools.bbclass 9467624c157cb8970b3658f48e7952ac0fa11fcc
+++ classes/autotools.bbclass e1849c9126d9460cb1c931e9a920ec02c3cb091c
@@ -1,5 +1,67 @@
-inherit base
+inherit base info

+#
+# Define which site files to use. We check for several site files and
+# use each one that is found in the following order:
+# 1) common - common settings
+# 2) common-<libc> - libc specified settings
+# 3) common-(32|64)bits - bit-size specific settings
+# 4) common-(le|be) - endianess specific settings
+# 5) <alias> - target alias, if it has one
+# 6) <arch>-<os> - target specific settings
+#
+# Search for the files in the following directories:
+# 1) ${BBPATH}/site (in reverse) - app specific, then site wide
+# 2) ${FILE_DIRNAME}/site-${PV} - app version specific
+#
+def get_config_site_files(d):
+ import bb, os
+ # How to map a specific type of info to the name of a site file
+ sitenamemap = { "common": "%s", \
+ "libc": "common-%s", \
+ "bits": "common-%sbits", \
+ "endianess": "common-%s", \
+ "alias": "%s", \
+ "target": "%s" }
+ sites = []
+ sitefiles = ""
+
+ # Determine which site files to look for
+ for i in ["common", "libc", "bits", "endianess", "alias", "target"]:
+ tmp = get_info_for_target(i, d)
+ if tmp:
+ sites.append(sitenamemap[i] % tmp)
+
+ # Check along bbpath for site files and append in reverse order so
+ # the application specific sites files are last and system site
+ # files first.
+ path_bb = bb.data.getVar('BBPATH', d, 1)
+ for p in (path_bb or "").split(':'):
+ tmp = ""
+ for i in sites:
+ fname = os.path.join(p, 'site', i)
+ if os.path.exists(fname):
+ tmp += fname + " "
+ sitefiles = tmp + sitefiles;
+
+ # Now check for the applications version specific site files
+ path_pkgv = os.path.join(bb.data.getVar('FILE_DIRNAME', d, 1), "site-" + bb.data.getVar('PV', d, 1))
+ for i in sites:
+ fname = os.path.join(path_pkgv, i)
+ if os.path.exists(fname):
+ sitefiles += fname + " "
+
+ bb.debug(1, "SITE files " + sitefiles);
+ return sitefiles
+
+#
+# Export CONFIG_SITE to the enviroment. The autotools will make use
+# of this to determine where to load in variables from. This is a
+# space seperate list of shell scripts processed in the order listed.
+#
+export CONFIG_SITE = "${@get_config_site_files(d)}"
+
+
def autotools_dep_prepend(d):
import bb;

=== oe-openssl-useinfo.patch ===

This is just an example of using the info class, and the methods I
added there, to clean up the openssl endianess selection code:

#
# old_revision [ac2124fc98391df1b17c8e6b7041eecdfa7543ed]
#
# patch "packages/openssl/openssl.inc"
# from [f31f2327d25b80adafc3098cc53e6327891e3bc3]
# to [7bf91f408b25843e121832d1c8baa068c66112c1]
#
============================================================
--- packages/openssl/openssl.inc f31f2327d25b80adafc3098cc53e6327891e3bc3
+++ packages/openssl/openssl.inc 7bf91f408b25843e121832d1c8baa068c66112c1
@@ -6,6 +6,8 @@ S = "${WORKDIR}/openssl-${PV}"
SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz"
S = "${WORKDIR}/openssl-${PV}"

+inherit info
+
AR_append = " r"
export CFLAG = "-fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIO -Wall ${FULL_OPTIMIZATION}"

@@ -26,15 +28,8 @@ do_compile () {
cd ..
ln -sf apps/openssl.pod crypto/crypto.pod ssl/ssl.pod doc/

- # endianness fun.. whee
- . ${CONFIG_SITE}
- if [ "x$ac_cv_c_bigendian" = "xyes" -o "x$ac_cv_c_littleendian" = "xno" ]; then
- CFLAG="${CFLAG} -DB_ENDIAN"
- elif [ "x$ac_cv_c_littleendian" = "xyes" -o "x$ac_cv_c_bigendian" = "xno" ]; then
- CFLAG="${CFLAG} -DL_ENDIAN"
- else
- oefatal do_configure cannot determine endianess
- fi
+ # Additional flag based on target endiness (see info.bbclass)
+ CFLAG="${CFLAG} ${@get_info_endianess_select('-DL_ENDIAN', '-DB_ENDIAN', d)}"

os=${HOST_OS}
if [ "x$os" = "xlinux-uclibc" ]; then

--
Jamie Lenehan <lenehan@...>

http://bugs.openembedded.org/show_bug.cgi?id=1357

Summary: misging dependency for libxine-x11 (libpng)
Product: Openembedded
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Build
AssignedTo: openembedded-devel@...
ReportedBy: stv@...
QAContact: tinderbox-oe@...


seems that libpng is missing off of the dependency list for libxine-x11 (and
possible other libxine providors, although I haven't checked).

simple fix: add libpng to DEPENDS :)


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

On Fri, 2006-08-25 at 15:33 +1000, Jamie Lenehan wrote:

On Fri, Aug 18, 2006 at 01:33:12AM +1000, Jamie Lenehan wrote:

On Thu, Aug 17, 2006 at 08:53:25PM +1000, Jamie Lenehan wrote:

Attached is a patch I'd like to propose to allow for multiple site
files to be used so that common stuff can be moved into common site

[...]

I've extended this a bit to allow site files to be per package,
rather than having to be global - including version specific site
files (such as db needs). Lots of packages just need a few site file
entries which are generally common across all builds or specific to
glibc or uclibc.

Probably the most useful part is allowing all of the x86 site files
to be merged together.

If no one has any comments on this then I guess I'll push it in.
First the info.bbclass, then clean up the few recipes that directly
mess with CONFIG_SITE, then clean up the x86 files and the the few
recipes that I've been maintaining.

For what its worth, I like the idea of this but haven't had time to
review the patches. The name info.bbclass is perhaps too generic though
- could you call it something like autotools-info.bbclass?

Regards,

Richard

On Fri, Aug 25, 2006 at 09:08:09AM +0100, Richard Purdie wrote:

On Fri, 2006-08-25 at 15:33 +1000, Jamie Lenehan wrote:

[...]

If no one has any comments on this then I guess I'll push it in.
First the info.bbclass, then clean up the few recipes that directly
mess with CONFIG_SITE,

I missed out the need to update autotools.bbclass once none of the
recipes directly mess with the CONFIG_SITE files.

then clean up the x86 files and the the few
recipes that I've been maintaining.

For what its worth, I like the idea of this but haven't had time to

I changed my mind about a dozen times on this, so seeing what someone
else thinks would be good.

review the patches. The name info.bbclass is perhaps too generic though
- could you call it something like autotools-info.bbclass?

The reason I called it info.bbclass is because it's not actually
related to autotools. What it does is provide information about a
target - endianess, 32/64 bit, which libc it's using, what alias
exists for it in a general sort of way.

The autotools.bbclass then makes use of this to decided which site
files to use.

I also made use of the info.bbclass to provide the endiness
information to recipes that were currently manaully looking in the
site file to determine this (since the way they currently work breaks
with the site file.)

--
Jamie Lenehan <lenehan@...>