* binutils from meta-oe does build build
From: Philip Balister @ 2011-10-08 16:08 UTC (permalink / raw)
To: openembedded-core
http://pastebin.com/M0Gw0Db2
Basically, warnings are being treated as errors and the compile fails.
Philip
^ permalink raw reply
* Re: tiff compile fails
From: Andreas Müller @ 2011-10-08 15:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1spn7bCDxwtV_r4pi34V_q0gcum6P+4sbfHQPs76CuXegg@mail.gmail.com>
On Saturday, October 08, 2011 05:00:33 PM Khem Raj wrote:
> On Saturday, October 8, 2011, Andreas Müller <schnitzeltony@gmx.de> wrote:
> > On Saturday, October 08, 2011 03:43:11 PM Andreas Müller wrote:
> >> With latest git pull for oe-core/meta-oe... & clean build dir I get
> >>
> >> | arm-angstrom-linux-gnueabi-libtool: compile: ccache
> arm-angstrom-linux-gnueabi-g++ -march=armv7-a -fno-tree-vectorize
> -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8
> -mthumb-interwork -mno-thumb
> --sysroot=/home/Superandy/tmp/oe-core-eglibc/sysroots/overo -DHAVE_CONFIG_H
> -I. -O2 -pipe -g -feliminate-unused-debug-types -fpermissive
> -fvisibility-inlines-hidden -fvisibility-inlines-hidden -MT tif_stream.lo
> -MD -MP -MF .deps/tif_stream.Tpo -c tif_stream.cxx -fPIC -DPIC -o
> .libs/tif_stream.o
> >> | tif_stream.cxx:31:20: fatal error: iostream: No such file or directory
> >> | compilation terminated.
> >> | make[2]: *** [tif_stream.lo] Error 1
> >>
> >> I think it is not tiff to blame - but which one is it?
> >>
> > In tiff's config.log I find
> >
> > Configured with: ... --with-gxx-include-dir=/usr/include/c++ ...
> >
>
> Seems that libstdc++ headers are not installed or compiler is not finding
> then
> Try a small hello.cc example and include iostream see if that compiles fine
> with
> Your g++
>
Thanks for the hints: there was a file iostream in sysroots/overo/usr/include/c++ and on host libstdc++ headers are installed.
Before your response I was already running a rebuild on fresh tmp dir. This time it worked...?! The only difference to the previous run is that I now did not try to build my full image but I ran 'bitbake tiff'..
Strange - but it seems I can continue
Andreas
^ permalink raw reply
* Re: Bitbake dependency failure with git fetcher
From: Eric Bénard @ 2011-10-08 15:06 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <5F487E45-9539-4DE6-AF5F-5664351F86C9@dominion.thruhere.net>
Hi,
Le 08/10/2011 12:27, Koen Kooi a écrit :
>
> Op 8 okt. 2011, om 10:08 heeft Richard Purdie het volgende geschreven:
>
>> On Sat, 2011-10-08 at 01:29 +0200, Koen Kooi wrote:
>>> Everytime openssl and a git recipe get changed at the same time, I end
>>> up with:
>>>
>>> | /angstrom/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/git.real: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
>>>
>>> Why is bitbake not resolving the git-native -> openssl-native dep
>>> before invoking the git fetcher?
>>
>> I suspect you're using rm_work?
>
> Yes I do
same thing here, and same issue when updating git.
Eric
^ permalink raw reply
* Re: tiff compile fails
From: Khem Raj @ 2011-10-08 15:00 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <201110081556.38345.schnitzeltony@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
On Saturday, October 8, 2011, Andreas Müller <schnitzeltony@gmx.de> wrote:
> On Saturday, October 08, 2011 03:43:11 PM Andreas Müller wrote:
>> With latest git pull for oe-core/meta-oe... & clean build dir I get
>>
>> | arm-angstrom-linux-gnueabi-libtool: compile: ccache
arm-angstrom-linux-gnueabi-g++ -march=armv7-a -fno-tree-vectorize
-mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8
-mthumb-interwork -mno-thumb
--sysroot=/home/Superandy/tmp/oe-core-eglibc/sysroots/overo -DHAVE_CONFIG_H
-I. -O2 -pipe -g -feliminate-unused-debug-types -fpermissive
-fvisibility-inlines-hidden -fvisibility-inlines-hidden -MT tif_stream.lo
-MD -MP -MF .deps/tif_stream.Tpo -c tif_stream.cxx -fPIC -DPIC -o
.libs/tif_stream.o
>> | tif_stream.cxx:31:20: fatal error: iostream: No such file or directory
>> | compilation terminated.
>> | make[2]: *** [tif_stream.lo] Error 1
>>
>> I think it is not tiff to blame - but which one is it?
>>
> In tiff's config.log I find
>
> Configured with: ... --with-gxx-include-dir=/usr/include/c++ ...
>
Seems that libstdc++ headers are not installed or compiler is not finding
then
Try a small hello.cc example and include iostream see if that compiles fine
with
Your g++
> Hmm
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 1814 bytes --]
^ permalink raw reply
* Re: tiff compile fails
From: Andreas Müller @ 2011-10-08 13:56 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <201110081543.11799.schnitzeltony@gmx.de>
On Saturday, October 08, 2011 03:43:11 PM Andreas Müller wrote:
> With latest git pull for oe-core/meta-oe... & clean build dir I get
>
> | arm-angstrom-linux-gnueabi-libtool: compile: ccache arm-angstrom-linux-gnueabi-g++ -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mthumb-interwork -mno-thumb --sysroot=/home/Superandy/tmp/oe-core-eglibc/sysroots/overo -DHAVE_CONFIG_H -I. -O2 -pipe -g -feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden -fvisibility-inlines-hidden -MT tif_stream.lo -MD -MP -MF .deps/tif_stream.Tpo -c tif_stream.cxx -fPIC -DPIC -o .libs/tif_stream.o
> | tif_stream.cxx:31:20: fatal error: iostream: No such file or directory
> | compilation terminated.
> | make[2]: *** [tif_stream.lo] Error 1
>
> I think it is not tiff to blame - but which one is it?
>
In tiff's config.log I find
Configured with: ... --with-gxx-include-dir=/usr/include/c++ ...
Hmm
^ permalink raw reply
* tiff compile fails
From: Andreas Müller @ 2011-10-08 13:43 UTC (permalink / raw)
To: openembedded-core
With latest git pull for oe-core/meta-oe... & clean build dir I get
| arm-angstrom-linux-gnueabi-libtool: compile: ccache arm-angstrom-linux-gnueabi-g++ -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mthumb-interwork -mno-thumb --sysroot=/home/Superandy/tmp/oe-core-eglibc/sysroots/overo -DHAVE_CONFIG_H -I. -O2 -pipe -g -feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden -fvisibility-inlines-hidden -MT tif_stream.lo -MD -MP -MF .deps/tif_stream.Tpo -c tif_stream.cxx -fPIC -DPIC -o .libs/tif_stream.o
| tif_stream.cxx:31:20: fatal error: iostream: No such file or directory
| compilation terminated.
| make[2]: *** [tif_stream.lo] Error 1
I think it is not tiff to blame - but which one is it?
Andreas
^ permalink raw reply
* Re: [PATCH 0/1] gnutls: fix configure failure
From: Koen Kooi @ 2011-10-08 10:28 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1318062305.git.edwin.zhai@intel.com>
http://cgit.openembedded.org/cgit.cgi/openembedded-core/commit/?id=808b3123e359f1aebabb8af44694275e4075e031
Op 8 okt. 2011, om 10:30 heeft edwin.zhai@intel.com het volgende geschreven:
> From: Zhai Edwin <edwin.zhai@intel.com>
>
> All,
> This patch fix configure failure of guntls after last upgrade.
> Pls. help to review.
>
> Thanks,
> Edwin
>
> The following changes since commit 0d8c8cf462e5df446669355b554b3d5fdc532a11:
>
> mutter: update to 2.29.1 and fix SRC_URI (2011-10-07 11:35:50 +0100)
>
> are available in the git repository at:
> git://git.pokylinux.org/poky-contrib gzhai/master2
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master2
>
> Zhai Edwin (1):
> gnutls: Fix configure failure
>
> meta/recipes-support/gnutls/gnutls.inc | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: Bitbake dependency failure with git fetcher
From: Koen Kooi @ 2011-10-08 10:27 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318061333.8533.58.camel@ted>
Op 8 okt. 2011, om 10:08 heeft Richard Purdie het volgende geschreven:
> On Sat, 2011-10-08 at 01:29 +0200, Koen Kooi wrote:
>> Everytime openssl and a git recipe get changed at the same time, I end
>> up with:
>>
>> | /angstrom/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/git.real: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
>>
>> Why is bitbake not resolving the git-native -> openssl-native dep
>> before invoking the git fetcher?
>
> I suspect you're using rm_work?
Yes I do
^ permalink raw reply
* [PATCH 1/1] gnutls: Fix configure failure
From: edwin.zhai @ 2011-10-08 8:30 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1318062305.git.edwin.zhai@intel.com>
From: Zhai Edwin <edwin.zhai@intel.com>
gnutls fails in configure as depends on p11-kit after last upgrade. Removing
this dependency via configure option can fix following error:
| checking for fork... (cached) yes
| checking for P11_KIT... configure: error: Package requirements (p11-kit-1 >= 0.2) were not met:
|
| No package 'p11-kit-1' found
|
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
|
| Alternatively, you may set the environment variables P11_KIT_CFLAGS
| and P11_KIT_LIBS to avoid the need to call pkg-config.
| See the pkg-config man page for more details.
|
| ERROR: oe_runconf failed
Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
---
meta/recipes-support/gnutls/gnutls.inc | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/gnutls/gnutls.inc b/meta/recipes-support/gnutls/gnutls.inc
index 9257880..8818c32 100644
--- a/meta/recipes-support/gnutls/gnutls.inc
+++ b/meta/recipes-support/gnutls/gnutls.inc
@@ -3,7 +3,7 @@ HOMEPAGE = "http://www.gnu.org/software/gnutls/"
BUGTRACKER = "https://savannah.gnu.org/support/?group=gnutls"
DEPENDS = "zlib lzo libtasn1 libgcrypt (>= 1.4.2) libcap"
-INC_PR = "r2"
+INC_PR = "r3"
LICENSE = "GPLv3+ & LGPLv2.1+"
LICENSE_${PN} = "LGPLv2.1+"
@@ -24,7 +24,7 @@ EXTRA_OECONF="--with-included-opencdk --with-included-libcfg --disable-rpath \
--with-libgcrypt --with-libgcrypt-prefix=${STAGING_DIR_HOST}${prefix} \
--with-libdl-prefix=${STAGING_DIR_HOST}${prefix} \
--with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \
- --with-lzo --disable-guile \
+ --with-lzo --disable-guile --without-p11-kit \
"
do_configure_prepend() {
for dir in . lib libextra; do
--
1.7.1
^ permalink raw reply related
* [PATCH 0/1] gnutls: fix configure failure
From: edwin.zhai @ 2011-10-08 8:30 UTC (permalink / raw)
To: openembedded-core
From: Zhai Edwin <edwin.zhai@intel.com>
All,
This patch fix configure failure of guntls after last upgrade.
Pls. help to review.
Thanks,
Edwin
The following changes since commit 0d8c8cf462e5df446669355b554b3d5fdc532a11:
mutter: update to 2.29.1 and fix SRC_URI (2011-10-07 11:35:50 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib gzhai/master2
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master2
Zhai Edwin (1):
gnutls: Fix configure failure
meta/recipes-support/gnutls/gnutls.inc | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: Bitbake dependency failure with git fetcher
From: Richard Purdie @ 2011-10-08 8:08 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <D3F85958-4E8C-4D2C-B8BD-C7AF341FAF47@dominion.thruhere.net>
On Sat, 2011-10-08 at 01:29 +0200, Koen Kooi wrote:
> Everytime openssl and a git recipe get changed at the same time, I end
> up with:
>
> | /angstrom/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/git.real: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
>
> Why is bitbake not resolving the git-native -> openssl-native dep
> before invoking the git fetcher?
I suspect you're using rm_work?
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH v3 0/2] Fix useradd class to accept useradd long options
From: Scott Garman @ 2011-10-08 0:57 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1317946258.git.julian.pidancet@gmail.com>
On 10/06/2011 05:13 PM, Julian Pidancet wrote:
> This first patch fixes the --root option for programs in shadow-native and
> allow one to specify useradd long options when using the useradd class
> in a recipe.
>
> The second patch demonstrates usage of the useradd class and ability to
> specify long options in the USERADD_PARAM variable by converting the OpenSSH
> recipe to useradd.
>
> v2: Fixed a typo in add_root_cmd_options.patch, --root is equivalent to -Q
> instead of -R.
>
> v3: Comment modifications and add Signed-off-by line in the modified patch
> directly.
Thank you Julian for these fixes.
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
^ permalink raw reply
* [PATCH] git: update to 1.7.7
From: Koen Kooi @ 2011-10-08 0:55 UTC (permalink / raw)
To: openembedded-core; +Cc: Koen Kooi
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
meta/recipes-devtools/git/git_1.7.5.1.bb | 10 ----------
meta/recipes-devtools/git/git_1.7.7.bb | 10 ++++++++++
2 files changed, 10 insertions(+), 10 deletions(-)
delete mode 100644 meta/recipes-devtools/git/git_1.7.5.1.bb
create mode 100644 meta/recipes-devtools/git/git_1.7.7.bb
diff --git a/meta/recipes-devtools/git/git_1.7.5.1.bb b/meta/recipes-devtools/git/git_1.7.5.1.bb
deleted file mode 100644
index b5eb015..0000000
--- a/meta/recipes-devtools/git/git_1.7.5.1.bb
+++ /dev/null
@@ -1,10 +0,0 @@
-require git.inc
-
-PR = "r3"
-
-EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no ac_cv_c_c99_format=yes \
- ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
- "
-
-SRC_URI[md5sum] = "a49291116e3b0564e069ae989e4db6fb"
-SRC_URI[sha256sum] = "a1d4a1c59300e68fbc493a2cbe9257048d4d6f4363924bf34f38c413a825f80c"
diff --git a/meta/recipes-devtools/git/git_1.7.7.bb b/meta/recipes-devtools/git/git_1.7.7.bb
new file mode 100644
index 0000000..486e2e5
--- /dev/null
+++ b/meta/recipes-devtools/git/git_1.7.7.bb
@@ -0,0 +1,10 @@
+require git.inc
+
+SRC_URI = "http://git-core.googlecode.com/files/git-${PV}.tar.gz"
+SRC_URI[md5sum] = "5d645884e688921e773186783b65ce33"
+SRC_URI[sha256sum] = "5a977bc01e4989b9928345e99aab15ce896cf5897c6e32eb449538574df377f6"
+
+EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no ac_cv_c_c99_format=yes \
+ ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
+ "
+
--
1.6.6.1
^ permalink raw reply related
* Bitbake dependency failure with git fetcher
From: Koen Kooi @ 2011-10-07 23:29 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Hi,
Everytime openssl and a git recipe get changed at the same time, I end up with:
| /angstrom/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/git.real: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
Why is bitbake not resolving the git-native -> openssl-native dep before invoking the git fetcher?
regards,
Koen
^ permalink raw reply
* Re: [PATCH 1/3] autotools: fix multi-word arguments for EXTRA_OECONF
From: Koen Kooi @ 2011-10-07 22:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <bc7e830e85f9f5242e0178dee517d24cbdfc9fa3.1318021323.git.kergoth@gmail.com>
Op 7 okt 2011, om 23:02 heeft Christopher Larson het volgende
geschreven:
> This is needed to better support things like the following (with a
> multi-word BUILD_CC):
>
> EXTRA_OECONF += '"ac_cv_prog_CC_FOR_BUILD=${BUILD_CC}"'
>
> Signed-off-by: Christopher Larson <kergoth@gmail.com>
> ---
> meta/classes/autotools.bbclass | 14 ++++++--------
> 1 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/meta/classes/autotools.bbclass b/meta/classes/
> autotools.bbclass
> index a4ce851..135be33 100644
> --- a/meta/classes/autotools.bbclass
> +++ b/meta/classes/autotools.bbclass
> @@ -70,14 +70,12 @@ CONFIGUREOPT_DEPTRACK = "--disable-dependency-
> tracking"
>
>
> oe_runconf () {
> - if [ -x ${S}/configure ] ; then
> - cfgcmd="${S}/configure \
> - ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
> - bbnote "Running $cfgcmd..."
> - $cfgcmd || bbfatal "oe_runconf failed"
> - else
> - bbfatal "no configure script found"
> - fi
> + if [ -x ${S}/configure ] ; then
> + bbnote "Running ${S}/configure ${CONFIGUREOPTS} $
> {EXTRA_OECONF} $@"
> + ${S}/configure ${CONFIGUREOPTS} ${EXTRA_OECONF} "$@" ||
> bbfatal "oe_runconf failed"
> + else
> + bbfatal "no configure script found"
> + f
Was the tab->spaces conversion intentional?
^ permalink raw reply
* Re: Use for filedeps/rpmdeps data?
From: Richard Purdie @ 2011-10-07 22:30 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <E7A9054A5ACABE48B0E540E46E862B0F0177E5@NAEMMAIL01.na.leapfrog.com>
On Fri, 2011-10-07 at 21:21 +0000, Daniel Lazzari wrote:
> Hey everyone,
>
> I noticed today that one of our recipes takes a very long time to get
> through the do_package task. The recipe has a couple of binaries and a
> whole lot of assets (thousands of audio files). It takes over 20
> minutes for the do_package task to complete on my local desktop. I
> finally tracked it down to the package_do_filedeps function which
> appears to be running an rpmdeps process for each file in each
> package. As far as I can tell, it just then dumps that data to text
> files in pkgdata and only seems concerned with the binaries. Can
> anyone shed some light on what this info is used for? Should it only
> be concerned with executables and libraries (there is currently no
> filter on it)? Do I even need that data if we are using ipkg instead
> of rpm?
This is why there is a line in package.bbclass which says:
if pkg.endswith('-dbg') or pkg.endswith('-doc') or pkg.find('-locale-') != -1 or pkg.find('-localedata-') != -1 or pkg.find('-gconv-') != -1 or pkg.find('-charmap-') != -1 or pkg.startswith('kernel-module-'):
continue
since those are packages we know we're not going to get useful
information from. It finds perl and python module dependencies so its
not just executable binaries/libraries unfortunately :/.
It would probably be useful to have a way of flagging other packages as
uninteresting though. The idea is the information is used by all the
package backends. At present it is used more by some than by others and
the ipk backend is limited in its use iirc. That will be changing over
time though.
Cheers,
Richard
^ permalink raw reply
* Use for filedeps/rpmdeps data?
From: Daniel Lazzari @ 2011-10-07 21:21 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
Hey everyone,
I noticed today that one of our recipes takes a very long time to get through the do_package task. The recipe has a couple of binaries and a whole lot of assets (thousands of audio files). It takes over 20 minutes for the do_package task to complete on my local desktop. I finally tracked it down to the package_do_filedeps function which appears to be running an rpmdeps process for each file in each package. As far as I can tell, it just then dumps that data to text files in pkgdata and only seems concerned with the binaries. Can anyone shed some light on what this info is used for? Should it only be concerned with executables and libraries (there is currently no filter on it)? Do I even need that data if we are using ipkg instead of rpm?
Thanks,
Dan Lazzari Jr.
Firmware Engineer
dlazzari@leapfrog.com
^ permalink raw reply
* [PATCH 3/3] oe.patch: drop bb.msg.domain reference
From: Christopher Larson @ 2011-10-07 21:03 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1318021323.git.kergoth@gmail.com>
Signed-off-by: Christopher Larson <kergoth@gmail.com>
---
meta/lib/oe/patch.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index 1406e19..9b0ff37 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -376,8 +376,8 @@ class UserResolver(Resolver):
os.environ['SHELLCMDS'] = "bash --rcfile " + rcfile
rc = os.system(bb.data.getVar('TERMCMDRUN', self.patchset.d, 1))
if os.WIFEXITED(rc) and os.WEXITSTATUS(rc) != 0:
- bb.msg.fatal(bb.msg.domain.Build, ("Cannot proceed with manual patch resolution - '%s' not found. " \
- + "Check TERMCMDRUN variable.") % bb.data.getVar('TERMCMDRUN', self.patchset.d, 1))
+ bb.fatal(("Cannot proceed with manual patch resolution - '%s' not found. "
+ + "Check TERMCMDRUN variable.") % bb.data.getVar('TERMCMDRUN', self.patchset.d, 1))
# Construct a new PatchSet after the user's changes, compare the
# sets, checking patches for modifications, and doing a remote
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/3] A few miscellaneous fixes
From: Christopher Larson @ 2011-10-07 21:02 UTC (permalink / raw)
To: openembedded-core
The following changes since commit cc626b9e1671670a931ea3e528ea4b0f7b2e923b:
webkit-gtk: Enable dependency tracking since the webkit makefiles have bugs (2011-10-05 14:36:18 +0100)
are available in the git repository at:
http://github.com/kergoth/oe-core misc-fixes
Christopher Larson (3):
autotools: fix multi-word arguments for EXTRA_OECONF
autoconf: no need to hardcode the full path to m4
oe.patch: drop bb.msg.domain reference
meta/classes/autotools.bbclass | 14 ++++++--------
meta/lib/oe/patch.py | 4 ++--
meta/recipes-devtools/autoconf/autoconf_2.68.bb | 4 +++-
3 files changed, 11 insertions(+), 11 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH 2/3] autoconf: no need to hardcode the full path to m4
From: Christopher Larson @ 2011-10-07 21:03 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1318021323.git.kergoth@gmail.com>
This way autom4te uses m4 as it finds it in the PATH, rather than
hardcoding any particular path.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
---
meta/recipes-devtools/autoconf/autoconf_2.68.bb | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/autoconf/autoconf_2.68.bb b/meta/recipes-devtools/autoconf/autoconf_2.68.bb
index c6209a3..21b5fb3 100644
--- a/meta/recipes-devtools/autoconf/autoconf_2.68.bb
+++ b/meta/recipes-devtools/autoconf/autoconf_2.68.bb
@@ -1,6 +1,6 @@
require autoconf.inc
-PR = "r2"
+PR = "r3"
PARALLEL_MAKE = ""
@@ -27,4 +27,6 @@ RDEPENDS_${PN}_virtclass-native = "m4-native gnu-config-native"
SRC_URI_append_virtclass-native = " file://fix_path_xtra.patch"
+EXTRA_OECONF += "ac_cv_path_M4=m4"
+
BBCLASSEXTEND = "native"
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/3] autotools: fix multi-word arguments for EXTRA_OECONF
From: Christopher Larson @ 2011-10-07 21:02 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1318021323.git.kergoth@gmail.com>
This is needed to better support things like the following (with a
multi-word BUILD_CC):
EXTRA_OECONF += '"ac_cv_prog_CC_FOR_BUILD=${BUILD_CC}"'
Signed-off-by: Christopher Larson <kergoth@gmail.com>
---
meta/classes/autotools.bbclass | 14 ++++++--------
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index a4ce851..135be33 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -70,14 +70,12 @@ CONFIGUREOPT_DEPTRACK = "--disable-dependency-tracking"
oe_runconf () {
- if [ -x ${S}/configure ] ; then
- cfgcmd="${S}/configure \
- ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
- bbnote "Running $cfgcmd..."
- $cfgcmd || bbfatal "oe_runconf failed"
- else
- bbfatal "no configure script found"
- fi
+ if [ -x ${S}/configure ] ; then
+ bbnote "Running ${S}/configure ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
+ ${S}/configure ${CONFIGUREOPTS} ${EXTRA_OECONF} "$@" || bbfatal "oe_runconf failed"
+ else
+ bbfatal "no configure script found"
+ fi
}
autotools_do_configure() {
--
1.7.4.1
^ permalink raw reply related
* MINUTES: OE-TSC meeting 6-Oct-2011
From: Jeff Osier-Mixon @ 2011-10-07 17:59 UTC (permalink / raw)
To: openembedded-core, openembedded-devel, tsc
[-- Attachment #1: Type: text/plain, Size: 16381 bytes --]
MINUTES: OE-TSC meeting 6-Oct-2011
Attending: Mark, Richard, Khem, Koen, Tom
Notes: Jefro
--------------------------------------------------------
Agenda & Results
1. pick a moderator
RP
2. new items:
maintainer files
bitbake doesn't have one
acknowledged need for READMEs in bitbake, main directory, oe-core layers
possibly add knowledge to pull request scripts
PACKAGECONFIG
concept generally positive, continue discussing on list
ELCE
RP: reminder about GA proxy voting
GA plans - Jefro finding a room, Philip B. gathering RSVPs
need a new place for bitbake tarball downloads
Khem can ask Tom K. to revive downloads.oe.org
3. status on old items:
oe-core release
need BSP tarballs (TI), "official" is preferred (having a maintainer is a
good start)
oe-core needs promotion, needs plans in place for release
OE infrastructure moving around, admin issues need a lead
release bitbake as well
elections
Denys sent mail, khem standing down & up
infrastructure
new server "opal", 64 bit VM
transitioning all services from melo to opal
wiki runs on it, moving git over
some difficulty using nginx, Tartarus knows someone good with it
yocto also uses nginx, RP and Tom will both pass on questions
note: berlios closing at end of year,
yocto
1.2 feature list shaping up
rc4 release build successful, waiting now on QA
TI had strategic meeting for 1.2/1.3 wish list, going through yocto channels
WR focusing on workflow improvements
--------------------------------------------------------
Raw Transcript:
(1:02:44 PM) fray: ok.. I;m here now
(1:03:31 PM) RP__: quorum :)
(1:03:51 PM) khem: ok it was not pear but peaches took a bit longer :)
(1:03:53 PM) RP__: Anything for the agenda?
(1:04:05 PM) khem: Infra update
(1:04:14 PM) fray: maintainer files or something similar for "newbies" to
know where to send patches
(1:04:19 PM) khem: move of git to new server is under work
(1:04:21 PM) RP__: Yocto Feature List for 1.2 is shaping up:
https://wiki.yoctoproject.org/wiki/Yocto_1.2_Features
(1:04:47 PM) RP__: Yocto -rc4 release build was successful, waiting on QA
now but its looking pretty much done
(1:05:07 PM) RP__: fray: no brainer, I agree we need it, just need the
patches
(1:05:23 PM) RP__: khem: this is a file at the top level of the tree saying
where patches should go etc.
(1:05:29 PM) Tartarus [trini@pixelshelf.com] entered the room.
(1:05:29 PM) mode (+v Tartarus) by ChanServ
(1:05:35 PM) Tartarus: Sorry I'm late
(1:05:38 PM) Tartarus: just got internet back up
(1:05:49 PM) Jefro: welcome back :)
(1:05:55 PM) fray: RP__ yup.. I think that'll take all of 2 minutes to
discuss.. I just want it in the minutes
(1:05:57 PM) khem: RP__: README at top says about this
(1:05:59 PM) ***RP__ has pasted the last few lines
(1:06:05 PM) Tartarus: no new items from me
(1:06:09 PM) RP__: khem: bitbake doesn't have one for example
(1:06:49 PM) khem: ok
(1:06:52 PM) khem: that should be added
(1:06:54 PM) RP__: Tartarus: we have four of us (koen isn't here)
(1:07:01 PM) RP__: + Jefro :)
(1:07:16 PM) RP__: ok, any other agenda items?
(1:07:23 PM) khem: and may be we can think of adding knowledge to pull
request scripts
(1:07:25 PM) RP__: We could quickly touch on PACKAGECONFIG I guess
(1:07:38 PM) khem: that may be a bit stretch
(1:07:40 PM) Jefro: 1. pick a chair (RP__ already fulfilling that function)
(1:08:33 PM) RP__: ELCE and TSC election?
(1:08:34 PM) khem: RP__: is PACKAGECONFIG same as gentoo's USE flags
(1:08:47 PM) RP__: khem: yes and no ;-)
(1:09:10 PM) khem: similar I would say
(1:09:19 PM) RP__: ok, we have an agenda then
(1:09:33 PM) RP__: do we need to talk about readme files in repos further?
(1:09:41 PM) RP__: We did already as a TSC advise README files
(1:09:56 PM) RP__: Stating how patches should be submitted seems like a good
thing to have there
(1:10:03 PM) fray: just wanted to mention the "problem"
(1:10:17 PM) khem: I think README are good since github displays them on
front page if repo is hosted on github
(1:10:18 PM) fray: I had a user download oe-core and they fixed a problem.
but they had to ask me where to send the fix..
(1:10:30 PM) khem: and kind of cool when one browses it
(1:10:44 PM) fray: a simple maintainers page or similar (readme is fine)
that says "here is the mailing list to use to send patches" or here is the
maintainer, etc.. is what is needed..
(1:10:59 PM) fray: they were able ot find (immediately) the commit
guidelines and policies on the oe page, but not where to send their patches
(1:11:09 PM) khem: fray: README are pretty common and easy for users to find
(1:11:12 PM) fray: so we should solve that...
(1:11:20 PM) RP__: fray: no argument here
(1:11:26 PM) fray: yup, no worries.. and this includes adding one to bitbake
-- assuming the maintainers there will accept it
(1:11:43 PM) khem: I think most of meta-* layers have it
(1:11:48 PM) RP__: fray: I suspect they will
(1:11:50 PM) fray: (I started to put together one, but wasn't sure what to
put into it.. so I stopped)
(1:11:53 PM) fray: RP ;)
(1:12:14 PM) fray: khem, ya I thought so too.. it's the main meta layer and
the oe-core stuff that doesn't seem to have one.. (if it does, I'm blind)
(1:12:30 PM) RP__: I suspect we just overlooked OE-Core
(1:12:36 PM) fray: ok, anyway that was the one issue I had.. we can move
on.. :)
(1:12:38 PM) RP__: and Poky could do with a variant of that
(1:12:41 PM) khem: yeah the layers in oe-core do need one I guess
(1:12:59 PM) RP__: khem: I don't think the layers do but the main repo
itself it would be good for...
(1:13:10 PM) fray: yup.. bitbake, main directory and oe-core layers (meta)
(1:13:16 PM) khem: RP__: collectively yes
(1:13:27 PM) fray: RP__ I would put one in the meta for consistency with
external layers.. but that's me
(1:14:00 PM) khem: they go to same ml but READMEs minght be different for
different layers thats what I though it wont harm to have the ml name
duplicated into them if Such READMEs existi
(1:14:19 PM) RP__: lets take the patches to the mailing lists
(1:14:23 PM) RP__: infra update?
(1:14:26 PM) fray: yup.. works for me
(1:15:07 PM) khem: We have a new server called opal
(1:15:16 PM) khem: where all services which are on melo
(1:15:21 PM) khem: currently are shifting
(1:15:28 PM) khem: its a 64bit VM
(1:15:45 PM) khem: currently wiki runs on it and we are moving git over
(1:15:54 PM) khem: currently working on configuring cgit
(1:16:07 PM) khem: since it uses nginx and not apache
(1:16:20 PM) khem: its a bit of challange to get CGI scripts running
(1:16:34 PM) khem: but we have figured out
(1:16:37 PM) Tartarus: What kind of nginx problems are we having?
(1:16:37 PM) RP__: yocto uses nginx too
(1:16:41 PM) Tartarus: I know a guy that's good with it..
(1:16:47 PM) RP__: causes problems with the caching :(
(1:16:49 PM) khem: RP__: cool
(1:17:04 PM) khem: then can you send the yocto config for cgit
(1:17:10 PM) khem: for nginx
(1:17:48 PM) khem: is needs spawn-fcgi
(1:17:52 PM) khem: too right ?
(1:18:06 PM) ***koen arrives
(1:18:11 PM) koen: apologies for being late
(1:18:19 PM) khem: welcome koen
(1:19:03 PM) khem: once cgit is configured then we will have only patchwork
left on melo
(1:19:23 PM) RP__: khem: I can try, I'm not familiar with where to find them
though
(1:19:41 PM) khem: RP__: /etc/nginx/sites-available/
(1:20:08 PM) khem: RP__: or whoever configured cgit with nginx can be handy
here
(1:20:18 PM) khem: so some HOWTO can speed it up
(1:20:25 PM) khem: instead of figuring out
(1:20:41 PM) Tartarus: So do we need configure help w/ nginx or no?
(1:20:48 PM) khem: yes
(1:20:48 PM) RP__: khem: looks like there is a fastcgi server configured on
localhost
(1:21:01 PM) khem: yeah that kind of info is needed
(1:21:13 PM) khem: how thats done and how it interfaces with nginx
(1:21:19 PM) Tartarus: OK, well if folks can give me context + questions I
can pass it along
(1:21:30 PM) Tartarus: and if you can hop on efnet instead might be able to
chat w/ the guy :)
(1:21:42 PM) khem: Tartarus: setting up cgit with nginx on ubuntu 10.10
64bit
(1:21:47 PM) RP__: khem: I'll see what I can pass on
(1:21:48 PM) khem: Tartarus: we need howto
(1:21:53 PM) khem: thanks
(1:22:06 PM) khem: errr 10.04 not 10.10
(1:22:40 PM) RP__: So, moving on, I think my comments earlier mentioned what
I wanted to say:
(1:22:41 PM) RP__: Yocto Feature List for 1.2 is shaping up:
https://wiki.yoctoproject.org/wiki/Yocto_1.2_Features
(1:22:41 PM) RP__: Yocto -rc4 release build was successful, waiting on QA
now but its looking pretty much done
(1:22:43 PM) Tartarus: Is it just not working or a specific error?
(1:22:55 PM) RP__: koen: any topics?
(1:23:08 PM) koen: we finally had our TI strategic meeting for what we want
in 1.2/1.3
(1:23:24 PM) koen: but that will go through yocto channels
(1:23:41 PM) khem: koen: ok anything thats interesting for oe-core ?
(1:23:47 PM) fray: as an OE TSC -- we need input from the OE members / users
on what they want/need..
(1:23:50 PM) RP__: koen: ok, cool. The sooner the better since planning is
well under way now ;-)
(1:23:59 PM) koen: for the oe-core release download page we need BSP
tarballs as well
(1:24:10 PM) fray: as a WR person for a second, we're going to be focusing
on workflow improvements...
(1:24:28 PM) koen: and vet the bsp to weed out crappy ones from the good
ones
(1:24:44 PM) khem: Tartarus: ground up would be good. We have nginx working
but not with cgit
(1:24:54 PM) Tartarus: ok
(1:24:59 PM) RP__: koen: The hard bit is defining crappy
(1:25:06 PM) Tartarus: I'll see how annoyed at me my friend is for nothing
more specific :)
(1:25:18 PM) khem: I think bsp's that are official would be preferred
(1:25:24 PM) khem: now define official
(1:25:37 PM) Tartarus: he's not done it before, heh
(1:25:48 PM) ***fray is simply happy with BSPs that have maintainers.. ;)
(1:27:24 PM) koen: and for the oe-core release, oe-core needs to get
promoted
(1:27:29 PM) RP__: ok, any input to the planning process is welcome, no
promises anything gets done but people are free to raise issues
(1:28:52 PM) khem: koen: I would say its distro choice to pick a bsp
(1:29:12 PM) koen: khem: try to find BSPs
(1:29:37 PM) koen: the yocto website is completely silent on !poky
(1:29:45 PM) koen: the OE website is...
(1:30:03 PM) ***Jefro notes meeting midpoint, still to discuss:
PACKAGECONFIG, ELCE, elections
(1:30:17 PM) koen: denys sent out a mail for the elections
(1:30:29 PM) khem: koen: thats something for yocto I guess
(1:30:33 PM) RP__: koen: Its a good point, Yocto has been driving the
release process but we haven't really got plans in place for the OE-Core
part of the release
(1:31:01 PM) RP__: It doesn't help that the OE infrastructure is moving
around and nobody seems to want to take the lead on some of the admin type
issues
(1:31:16 PM) RP__: Speaking of infrastrcture btw, Berlios is closing end of
the yewar
(1:31:24 PM) RP__: we need a new place for bitbake tarball downloads
(1:31:54 PM) khem: RP__: we can put them in sources.oe.org
(1:32:40 PM) RP__: khem: I think separating out the release tarballs might
be nicer for people
(1:33:26 PM) RP__: Is anyone willing to help sort an OE release process?
(1:33:29 PM) koen: can we get downloads.oe.org back?
(1:34:01 PM) khem: koen: isnt that now sources.oe.org ?
(1:34:06 PM) koen: no
(1:34:28 PM) koen: downloades.oe.org was for things like oe .deb and rpm
packages
(1:34:38 PM) RP__: We could use downloads.yoctoproject.org but I suspect
people would not like that
(1:34:47 PM) fray: RP__ I'm willing to help, but I fear ignorance on a lot
of the previous oe history.. so if we want to try to do things the way
they've been done, I'm not sure how helpful I can be
(1:35:14 PM) fray: how was the last oe-dev "released"? Was it more then
simply a tag/branch?
(1:35:15 PM) khem: RP__: I can help with oe parts on release
(1:35:28 PM) RP__: fray: no, but we need to do better
(1:35:40 PM) Tartarus: fray, pre oe-core we did weekly snapshots and asked
for testing then branched
(1:35:41 PM) fray: ok.. I hadn't realized people wanted more
(1:35:58 PM) RP__: khem: thanks. I think a dedicated downloads.oe.org might
be good and some way of placing tarballs there for people like me
(1:36:13 PM) khem: RP__: ok
(1:36:22 PM) khem: I will ask Tom to set one up
(1:36:34 PM) RP__: The rest of it is likely then getting an announcement
together and so on
(1:36:48 PM) khem: RP__: cgit also exports tarballs
(1:37:00 PM) koen: khem: that's not a real option
(1:37:04 PM) RP__: khem: which change checksum depending on the date
(1:37:09 PM) khem: I get it
(1:37:28 PM) RP__: khem: Also need to coordinate anyone else wanting to
release tarballs of layers etc
(1:37:35 PM) khem: OK,
(1:37:49 PM) RP__: khem: Thanks for helping there, I appreciate it :)
(1:37:59 PM) fray: RP__ isn't the release of layers made after the initial
oe-core release?
(1:38:34 PM) RP__: fray: yes, but people likely need to know about it and
may want to coordinate with the annoucement
(1:38:46 PM) RP__: we have a pretty good idea what the release will look
like now for example
(1:39:06 PM) RP__: If we have the site I can put the bitbake tarballs there
too
(1:39:45 PM) RP__: ok, PACKAGECONFIG - its a fairly major change
(1:40:01 PM) RP__: but we preciously discussed it and now looks like a good
time to bring it in
(1:40:19 PM) RP__: I just wanted to check if there were any strong feelings
or we just continue on list?
(1:40:20 PM) ***fray REALLY likes the concept of packageconfig
(1:41:08 PM) RP__: oh, bitbake release - a good idea alongside the oe-core
release?
(1:41:21 PM) fray: absolutely
(1:41:33 PM) RP__: elce is soon, I don't have anything specific to discuss
on that
(1:41:50 PM) fray: as far as attendance for elce goes, it doesnt look like I
will be there..
(1:41:58 PM) RP__: :(
(1:42:02 PM) ***Tartarus also won't be
(1:42:07 PM) RP__: I'd gently remind people about AGM proxy voting
(1:42:17 PM) fray: I'm still trying to figure out if I'll be able to fly in
for a day or so for the OE eV meeting and such..
(1:42:19 PM) ***khem wont be there either
(1:42:21 PM) RP__: er, s/AGM/GA/
(1:43:07 PM) ***RP__ will be there and has booked tickets now
(1:43:36 PM) khem: I have volunteered koen to be my proxy
(1:43:37 PM) RP__: election wise I was pleased to see the board has
announced another election
(1:43:44 PM) khem: koen: that pact still stands I believe
(1:43:51 PM) fray: ya, I've volunteers Saul Wold to be mine.. ;)
(1:44:39 PM) ***Jefro notes - so far there are 11 people who have announced
attendance at the GA
(1:44:54 PM) RP__: khem: I'm sorry to hear you're standing down but I'm
guessing you're standing again :)
(1:45:19 PM) RP__: Jefro: some may have replied offlist to philip (I did)
(1:45:52 PM) Jefro: RP__ good point (I am setting up a room and need to know
how big)
(1:47:02 PM) RP__: ok, we're through the topics - any other business?
(1:47:20 PM) RP__: I'm pressing on assuming people will jump in with
anything that they want to say
(1:47:30 PM) khem: RP__: I have to make my mind.
(1:47:35 PM) khem: RP__: havent decided yet
(1:47:36 PM) ***Tartarus has no other business
(1:48:28 PM) Jefro: I could chime in & say that I fulfilled my action item
to put together a wiki page with TSC minutes
(1:49:01 PM) RP__: khem: ok, your input has been valuable here but I can
understand its also a commitment and the TSC's role is kind of ever changing
(1:49:04 PM) khem: I am reading about gerrit and other similar tools and try
to make gold work on oe
(1:49:17 PM) RP__: Jefro: Thanks for doing that, its much appreciated!
(1:49:34 PM) fray: jefro, and a good wiki page it is....
(1:49:47 PM) Jefro: :) I only added links to minutes, someone else created
the page
(1:50:46 PM) koen: gerrit pretty much requires using repo
(1:50:57 PM) ***koen isn't a big fan of either
(1:51:31 PM) Jefro: RP__ meeting adjourned?
(1:51:37 PM) RP__: hmm, I didn;t know it needed repo
(1:51:44 PM) RP__: Jefro: yes, meeting closed
(1:51:48 PM) RP__: thanks all!
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
[-- Attachment #2: Type: text/html, Size: 21567 bytes --]
^ permalink raw reply
* [PATCH] farsight2, ldconfig-native, gnutls: There is no GPLv2.1, correct the fields
From: Khem Raj @ 2011-10-07 17:36 UTC (permalink / raw)
To: openembedded-core
The licenses were either LGPLv2.1 or GPLv2
make the changes appropriately
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
.../farsight/farsight2_0.0.9.bb | 4 ++--
meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb | 4 ++--
meta/recipes-support/gnutls/gnutls.inc | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb b/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
index a7bdc97..ee0ce8a 100644
--- a/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
+++ b/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
@@ -1,12 +1,12 @@
DESCRIPTION = "FarSight is an audio/video conferencing framework specifically designed for Instant Messengers."
HOMEPAGE = "http://farsight.sf.net"
SRC_URI = "http://farsight.freedesktop.org/releases/farsight2/${BPN}-${PV}.tar.gz"
-LICENSE = "GPLv2.1"
+LICENSE = "LGPLv2.1"
DEPENDS = "libnice glib-2.0 libxml2 zlib dbus gstreamer gst-plugins-base"
inherit autotools
-PR = "r1"
+PR = "r2"
EXTRA_OECONF = " \
--disable-debug \
diff --git a/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb b/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb
index 00edb6e..2a93913 100644
--- a/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb
+++ b/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb
@@ -1,6 +1,6 @@
DESCRIPTION = "A standalone native ldconfig build"
-LICENSE = "GPLv2.1"
+LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://${S}/ldconfig.c;endline=17;md5=1d15f20937c055cb5de2329a4c054399"
@@ -12,7 +12,7 @@ SRC_URI = "file://ldconfig-native-2.12.1.tar.bz2 \
file://flag_fix.patch \
file://endianess-header.patch"
-PR = "r1"
+PR = "r2"
inherit native
diff --git a/meta/recipes-support/gnutls/gnutls.inc b/meta/recipes-support/gnutls/gnutls.inc
index 9257880..d73c799 100644
--- a/meta/recipes-support/gnutls/gnutls.inc
+++ b/meta/recipes-support/gnutls/gnutls.inc
@@ -3,11 +3,11 @@ HOMEPAGE = "http://www.gnu.org/software/gnutls/"
BUGTRACKER = "https://savannah.gnu.org/support/?group=gnutls"
DEPENDS = "zlib lzo libtasn1 libgcrypt (>= 1.4.2) libcap"
-INC_PR = "r2"
+INC_PR = "r3"
LICENSE = "GPLv3+ & LGPLv2.1+"
LICENSE_${PN} = "LGPLv2.1+"
-LICENSE_${PN}-xx = "GPLv2.1+"
+LICENSE_${PN}-xx = "LGPLv2.1+"
LICENSE_${PN}-bin = "GPLv3+"
LICENSE_${PN}-extra = "GPLv3+"
LICENSE_${PN}-openssl = "GPLv3+"
--
1.7.5.4
^ permalink raw reply related
* [PATCHv3 12/31] xserver-xorg: replace hardcoded --enable-glx-tls with glx-use-tls.inc, which doesn't enable it for uClibc
From: Martin Jansa @ 2011-10-07 17:05 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1318007055.git.Martin.Jansa@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
.../recipes-graphics/xorg-xserver/xserver-xorg.inc | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index dfad8f3..726fbaa 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -3,6 +3,8 @@ require xserver-xorg-common.inc
PROTO_DEPS += "xf86driproto dri2proto"
LIB_DEPS += "virtual/libgl"
+require ../mesa/glx-use-tls.inc
+
EXTRA_OECONF += "--disable-static \
--disable-acfb \
--disable-ccfb \
@@ -16,7 +18,6 @@ EXTRA_OECONF += "--disable-static \
--disable-xnest \
--disable-xvfb \
--enable-composite \
- --enable-glx-tls \
--sysconfdir=/etc/X11 \
--localstatedir=/var \
--with-pic \
--
1.7.7
^ permalink raw reply related
* [PATCHv3 31/31] mesa: drop older 7.10.2 and 7.7+git recipes
From: Martin Jansa @ 2011-10-07 17:10 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1318007397.git.Martin.Jansa@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
meta/recipes-graphics/mesa/mesa-dri/cross2.patch | 46 ------
meta/recipes-graphics/mesa/mesa-dri/crossfix.patch | 18 ---
meta/recipes-graphics/mesa/mesa-dri/i586/matypes.h | 162 --------------------
meta/recipes-graphics/mesa/mesa-dri_7.10.2.bb | 40 -----
meta/recipes-graphics/mesa/mesa-dri_git.bb | 57 -------
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 22 ---
6 files changed, 0 insertions(+), 345 deletions(-)
delete mode 100644 meta/recipes-graphics/mesa/mesa-dri/cross2.patch
delete mode 100644 meta/recipes-graphics/mesa/mesa-dri/crossfix.patch
delete mode 100644 meta/recipes-graphics/mesa/mesa-dri/i586/matypes.h
delete mode 100644 meta/recipes-graphics/mesa/mesa-dri_7.10.2.bb
delete mode 100644 meta/recipes-graphics/mesa/mesa-dri_git.bb
delete mode 100644 meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb
diff --git a/meta/recipes-graphics/mesa/mesa-dri/cross2.patch b/meta/recipes-graphics/mesa/mesa-dri/cross2.patch
deleted file mode 100644
index 264c153..0000000
--- a/meta/recipes-graphics/mesa/mesa-dri/cross2.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-Upstream-Status: Pending
-
-Index: git/configure.ac
-===================================================================
---- git.orig/configure.ac 2009-09-01 16:38:26.000000000 +0100
-+++ git/configure.ac 2009-09-01 16:38:47.000000000 +0100
-@@ -269,15 +269,6 @@
- GLAPI_ASM_SOURCES=""
- AC_MSG_CHECKING([whether to enable assembly])
- test "x$enable_asm" = xno && AC_MSG_RESULT([no])
--# disable if cross compiling on x86/x86_64 since we must run gen_matypes
--if test "x$enable_asm" = xyes && test "x$cross_compiling" = xyes; then
-- case "$host_cpu" in
-- i?86 | x86_64)
-- enable_asm=no
-- AC_MSG_RESULT([no, cross compiling])
-- ;;
-- esac
--fi
- # check for supported arches
- if test "x$enable_asm" = xyes; then
- case "$host_cpu" in
-Index: git/src/mesa/x86/Makefile
-===================================================================
---- git.orig/src/mesa/x86/Makefile 2009-09-01 16:40:02.000000000 +0100
-+++ git/src/mesa/x86/Makefile 2009-09-01 16:40:13.000000000 +0100
-@@ -14,19 +14,6 @@
- -I../tnl
-
-
--default: gen_matypes matypes.h
--
--clean:
-- -rm -f matypes.h gen_matypes
--
--
--gen_matypes: gen_matypes.c
-- $(HOST_CC) $(ARCH_FLAGS) $(INCLUDE_DIRS) $(HOST_CFLAGS) gen_matypes.c -o gen_matypes
--
--# need some special rules here, unfortunately
--matypes.h: ../main/mtypes.h ../tnl/t_context.h gen_matypes
-- ./gen_matypes > matypes.h
--
- common_x86_asm.o: matypes.h
- 3dnow_normal.o: matypes.h
- 3dnow_xform1.o: matypes.h
diff --git a/meta/recipes-graphics/mesa/mesa-dri/crossfix.patch b/meta/recipes-graphics/mesa/mesa-dri/crossfix.patch
deleted file mode 100644
index d300e2f..0000000
--- a/meta/recipes-graphics/mesa/mesa-dri/crossfix.patch
+++ /dev/null
@@ -1,18 +0,0 @@
-Upstream-Status: Pending
-
-Index: Mesa-7.5/bin/mklib
-===================================================================
---- Mesa-7.5.orig/bin/mklib 2009-08-12 13:01:34.000000000 +0100
-+++ Mesa-7.5/bin/mklib 2009-08-12 13:04:19.000000000 +0100
-@@ -234,9 +234,9 @@
- if [ "x$LINK" = "x" ] ; then
- # -linker was not specified so set default link command now
- if [ $CPLUSPLUS = 1 ] ; then
-- LINK=g++
-+ LINK=$CXX
- else
-- LINK=gcc
-+ LINK=$CC
- fi
- fi
-
diff --git a/meta/recipes-graphics/mesa/mesa-dri/i586/matypes.h b/meta/recipes-graphics/mesa/mesa-dri/i586/matypes.h
deleted file mode 100644
index 98d2188..0000000
--- a/meta/recipes-graphics/mesa/mesa-dri/i586/matypes.h
+++ /dev/null
@@ -1,162 +0,0 @@
-/*
- * This file is automatically generated from the Mesa internal type
- * definitions. Do not edit directly.
- */
-
-#ifndef __ASM_TYPES_H__
-#define __ASM_TYPES_H__
-
-
-
-/* =============================================================
- * Offsets for GLcontext
- */
-
-#define CTX_DRIVER_CTX 996
-
-#define CTX_LIGHT_ENABLED 39404
-#define CTX_LIGHT_SHADE_MODEL 39408
-#define CTX_LIGHT_COLOR_MAT_FACE 39412
-#define CTX_LIGHT_COLOR_MAT_MODE 39416
-#define CTX_LIGHT_COLOR_MAT_MASK 39420
-#define CTX_LIGHT_COLOR_MAT_ENABLED 39424
-#define CTX_LIGHT_ENABLED_LIST 39432
-#define CTX_LIGHT_NEED_VERTS 43793
-#define CTX_LIGHT_FLAGS 43796
-#define CTX_LIGHT_BASE_COLOR 43800
-
-
-/* =============================================================
- * Offsets for struct vertex_buffer
- */
-
-#define VB_SIZE 0
-#define VB_COUNT 4
-
-#define VB_ELTS 8
-#define VB_OBJ_PTR 12
-#define VB_EYE_PTR 16
-#define VB_CLIP_PTR 20
-#define VB_PROJ_CLIP_PTR 24
-#define VB_CLIP_OR_MASK 28
-#define VB_CLIP_MASK 32
-#define VB_NORMAL_PTR 36
-#define VB_EDGE_FLAG 44
-#define VB_TEX0_COORD_PTR 48
-#define VB_TEX1_COORD_PTR 52
-#define VB_TEX2_COORD_PTR 56
-#define VB_TEX3_COORD_PTR 60
-#define VB_INDEX_PTR 80
-#define VB_COLOR_PTR 88
-#define VB_SECONDARY_COLOR_PTR 96
-#define VB_FOG_COORD_PTR 104
-#define VB_PRIMITIVE 108
-
-
-/*
- * Flags for struct vertex_buffer
- */
-
-#define VERT_BIT_OBJ 0x1
-#define VERT_BIT_NORM 0x4
-#define VERT_BIT_RGBA 0x8
-#define VERT_BIT_SPEC_RGB 0x10
-#define VERT_BIT_FOG_COORD 0x20
-#define VERT_BIT_TEX0 0x100
-#define VERT_BIT_TEX1 0x200
-#define VERT_BIT_TEX2 0x400
-#define VERT_BIT_TEX3 0x800
-
-
-/* =============================================================
- * Offsets for GLvector4f
- */
-
-#define V4F_DATA 0
-#define V4F_START 4
-#define V4F_COUNT 8
-#define V4F_STRIDE 12
-#define V4F_SIZE 16
-#define V4F_FLAGS 20
-
-/*
- * Flags for GLvector4f
- */
-
-#define VEC_MALLOC 0x10
-#define VEC_NOT_WRITEABLE 0x40
-#define VEC_BAD_STRIDE 0x100
-
-#define VEC_SIZE_1 0x1
-#define VEC_SIZE_2 0x3
-#define VEC_SIZE_3 0x7
-#define VEC_SIZE_4 0xf
-
-
-/* =============================================================
- * Offsets for GLmatrix
- */
-
-#define MATRIX_DATA 0
-#define MATRIX_INV 4
-#define MATRIX_FLAGS 8
-#define MATRIX_TYPE 12
-
-
-/* =============================================================
- * Offsets for struct gl_light
- */
-
-#define LIGHT_NEXT 0
-#define LIGHT_PREV 4
-
-#define LIGHT_AMBIENT 8
-#define LIGHT_DIFFUSE 24
-#define LIGHT_SPECULAR 40
-#define LIGHT_EYE_POSITION 56
-#define LIGHT_SPOT_DIRECTION 72
-#define LIGHT_SPOT_EXPONENT 88
-#define LIGHT_SPOT_CUTOFF 92
-#define LIGHT_COS_CUTOFF 100
-#define LIGHT_CONST_ATTEN 104
-#define LIGHT_LINEAR_ATTEN 108
-#define LIGHT_QUADRATIC_ATTEN 112
-#define LIGHT_ENABLED 116
-
-#define LIGHT_FLAGS 120
-
-#define LIGHT_POSITION 124
-#define LIGHT_VP_INF_NORM 140
-#define LIGHT_H_INF_NORM 152
-#define LIGHT_NORM_DIRECTION 164
-#define LIGHT_VP_INF_SPOT_ATTEN 180
-
-#define LIGHT_SPOT_EXP_TABLE 184
-#define LIGHT_MAT_AMBIENT 4280
-#define LIGHT_MAT_DIFFUSE 4304
-#define LIGHT_MAT_SPECULAR 4328
-
-#define SIZEOF_GL_LIGHT 4360
-
-/*
- * Flags for struct gl_light
- */
-
-#define LIGHT_SPOT 0x1
-#define LIGHT_LOCAL_VIEWER 0x2
-#define LIGHT_POSITIONAL 0x4
-
-#define LIGHT_NEED_VERTICES 0x6
-
-
-/* =============================================================
- * Offsets for struct gl_lightmodel
- */
-
-#define LIGHT_MODEL_AMBIENT 0
-#define LIGHT_MODEL_LOCAL_VIEWER 16
-#define LIGHT_MODEL_TWO_SIDE 17
-#define LIGHT_MODEL_COLOR_CONTROL 20
-
-
-#endif /* __ASM_TYPES_H__ */
diff --git a/meta/recipes-graphics/mesa/mesa-dri_7.10.2.bb b/meta/recipes-graphics/mesa/mesa-dri_7.10.2.bb
deleted file mode 100644
index 68f89a2..0000000
--- a/meta/recipes-graphics/mesa/mesa-dri_7.10.2.bb
+++ /dev/null
@@ -1,40 +0,0 @@
-include mesa-common.inc
-
-LIC_FILES_CHKSUM = "file://docs/license.html;md5=7a3373c039b6b925c427755a4f779c1d"
-
-PROTO_DEPS = "xf86driproto glproto dri2proto"
-LIB_DEPS = "libdrm virtual/libx11 libxext libxxf86vm libxdamage libxfixes expat \
- libxml2-native"
-
-DEPENDS = "${PROTO_DEPS} ${LIB_DEPS} makedepend-native python-native"
-
-PR = "r2"
-
-SRC_URI = "ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2 \
- file://crossfix.patch \
- file://uclibc.patch \
- "
-
-SRC_URI[md5sum] = "f5de82852f1243f42cc004039e10b771"
-SRC_URI[sha256sum] = "8ced2678ce11cf30804694a92ea3ca6b82f158ae8995bdc626c7e85aac71c7c1"
-
-# most of our targets do not have DRI so will use mesa-xlib
-DEFAULT_PREFERENCE = "-1"
-
-LEAD_SONAME = "libGL.so.1"
-
-EXTRA_OECONF += "--with-driver=dri --disable-egl --disable-gallium"
-
-python populate_packages_prepend() {
- import os.path
-
- dri_drivers_root = os.path.join(bb.data.getVar('libdir', d, 1), "dri")
-
- do_split_packages(d, dri_drivers_root, '^(.*)_dri\.so$', 'mesa-dri-driver-%s', 'Mesa %s DRI driver', extra_depends='')
-}
-
-COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'
-
-PACKAGES_DYNAMIC = "mesa-dri-driver-*"
-
-FILES_${PN}-dbg += "${libdir}/dri/.debug/*"
diff --git a/meta/recipes-graphics/mesa/mesa-dri_git.bb b/meta/recipes-graphics/mesa/mesa-dri_git.bb
deleted file mode 100644
index 9e32d0a..0000000
--- a/meta/recipes-graphics/mesa/mesa-dri_git.bb
+++ /dev/null
@@ -1,57 +0,0 @@
-include mesa-common.inc
-
-SRC_URI = "git://anongit.freedesktop.org/git/mesa/mesa;protocol=git \
- file://cross2.patch \
- file://matypes.h"
-# file://mesa-DRI2Swapbuffer.patch "
-S = "${WORKDIR}/git"
-
-PROTO_DEPS = "xf86driproto glproto dri2proto"
-LIB_DEPS = "libdrm virtual/libx11 libxext libxxf86vm libxdamage libxfixes expat"
-
-DEPENDS = "${PROTO_DEPS} ${LIB_DEPS}"
-
-SRCREV = "1bf94d419805538ac23a4d0b04d31ac5e4487aca"
-PV = "7.7+git${SRCPV}"
-PR = "r2"
-
-# most of our targets do not have DRI so will use mesa-xlib
-DEFAULT_PREFERENCE = "-1"
-
-PACKAGES =+ "${PN}-xprogs"
-PACKAGES_DYNAMIC = "mesa-dri-driver-*"
-
-FILES_${PN}-dbg += "${libdir}/dri/.debug/*"
-FILES_${PN}-xprogs = "${bindir}/glxdemo ${bindir}/glxgears ${bindir}/glxheads ${bindir}/glxinfo"
-
-LEAD_SONAME = "libGL.so.1"
-
-EXTRA_OECONF += "--with-driver=dri --disable-egl --disable-gallium"
-
-do_configure_prepend () {
- cp ${WORKDIR}/matypes.h ${S}/src/mesa/x86
- touch ${S}/src/mesa/x86/matypes.h
-}
-
-do_compile () {
- oe_runmake clean
- oe_runmake -C src/glsl CC='${BUILD_CC}' CFLAGS=""
- mv ${S}/src/glsl/apps/compile ${S}/host_compile
- oe_runmake clean
- oe_runmake GLSL_CL="${S}/host_compile"
-}
-
-do_install_append () {
- install -d ${D}/usr/bin
- install -m 0755 ${S}/progs/xdemos/{glxdemo,glxgears,glxheads,glxinfo} ${D}/usr/bin/
-}
-
-python populate_packages_prepend() {
- import os.path
-
- dri_drivers_root = os.path.join(bb.data.getVar('libdir', d, 1), "dri")
-
- do_split_packages(d, dri_drivers_root, '^(.*)_dri\.so$', 'mesa-dri-driver-%s', 'Mesa %s DRI driver', extra_depends='')
-}
-
-COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
diff --git a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb
deleted file mode 100644
index 511103d..0000000
--- a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb
+++ /dev/null
@@ -1,22 +0,0 @@
-include mesa-common.inc
-
-FILESPATH =. "${FILE_DIRNAME}/mesa-dri:"
-
-SRC_URI = "ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2 \
- file://uclibc.patch \
- "
-
-SRC_URI[md5sum] = "f5de82852f1243f42cc004039e10b771"
-SRC_URI[sha256sum] = "8ced2678ce11cf30804694a92ea3ca6b82f158ae8995bdc626c7e85aac71c7c1"
-
-LIC_FILES_CHKSUM = "file://docs/license.html;md5=7a3373c039b6b925c427755a4f779c1d"
-
-PROTO_DEPS = "xf86driproto glproto"
-LIB_DEPS = "virtual/libx11 libxext libxxf86vm libxdamage libxfixes libxml2-native"
-
-DEPENDS = "${PROTO_DEPS} ${LIB_DEPS} makedepend-native"
-
-PE = "1"
-PR = "r1"
-
-EXTRA_OECONF += "--with-driver=xlib"
--
1.7.7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox