[OE-core] [CONSOLIDATED PULL 1/4] ghostscript: update SRC_URI
From: Kang Kai kai.k...@windriver.com
Build ghostscript-native fails on a i686 machine because it can't get
the source objarch.h and soobjarch.h, and .h files are not needed for
native package, so update the SRC_URI to fix it.
Signed-off-by: Kang Kai kai.k...@windriver.com
---
.../ghostscript/ghostscript_9.02.bb|7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
index e3d32dd..bee5684 100644
--- a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
+++ b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
@@ -15,17 +15,20 @@ SECTION = console/utils
LICENSE = GPLv3
LIC_FILES_CHKSUM = file://LICENSE;md5=d151214b3131251dfc9d858593acbd24
-PR = r1
+PR = r2
DEPENDS = ${PN}-native tiff jpeg fontconfig cups
DEPENDS_virtclass-native =
-SRC_URI = http://downloads.ghostscript.com/public/ghostscript-${PV}.tar.bz2 \
+SRC_URI_BASE =
http://downloads.ghostscript.com/public/ghostscript-${PV}.tar.bz2;
+
+SRC_URI = ${SRC_URI_BASE} \
file://ghostscript-9.02-prevent_recompiling.patch \
file://ghostscript-9.02-genarch.patch \
file://objarch.h \
file://soobjarch.h \
+SRC_URI_virtclass-native = ${SRC_URI_BASE}
SRC_URI[md5sum] = f67151444bd56a7904579fc75a083dd6
SRC_URI[sha256sum] =
03ea2cad13a36f8f9160912012b79619a826e7148fada6d3531feb25409ee05a
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [junk] test posting
Just for testing whether I can post to this mailing list. -- Thanks Robert ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] sysklogd.inc: Check for package-management in IMAGE_FEATURES
Op 10 jun 2011, om 02:57 heeft Khem Raj het volgende geschreven:
ONLINE_PACKAGE_MANAGEMENT does not exist on oe-core
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-extended/sysklogd/sysklogd.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc
b/meta/recipes-extended/sysklogd/sysklogd.inc
index f2b1c15..f6a56ec 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
# syslog initscript is handled explicitly because order of
# update-rc.d and update-alternatives is important (see below)
DEPENDS_append = update-rc.d update-rc.d-native
-RDEPENDS_${PN}_append = ${@base_conditional(ONLINE_PACKAGE_MANAGEMENT,
none, , update-rc.d, d)}
+RDEPENDS_${PN}_append = ${@oe.utils.contains(IMAGE_FEATURES,
package-management, update-rc.d, , d)}
You can't do IMAGE_FEATURES in RDEPENDS, consider what happens when I build 2
images, one with package-management and one without. Phils changes to catch
update-rc.d usage in the image* classes should be enough to fix this.
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] git: restore the dependency on perl-native
[YOCTO #1155]
I thought git-native could depend on perl-native-runtime and tests on
Ubuntu 9.04/10.10 and Fedora 13 show it could buid fine (looks these distros
install perl-ExtUtils-MakeMaker by default).
However Joshua reported on Fedora 15 i686 host, git-native can't build unless
he manually installed perl-ExtUtils-MakeMaker to the host.
This makes me think we may as well make git-native depend on perl-native.
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/recipes-devtools/git/git.inc|6 +++---
meta/recipes-devtools/git/git_1.7.5.1.bb |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-devtools/git/git.inc
b/meta/recipes-devtools/git/git.inc
index 3cdd1fa..5d77880 100644
--- a/meta/recipes-devtools/git/git.inc
+++ b/meta/recipes-devtools/git/git.inc
@@ -1,16 +1,16 @@
DESCRIPTION = The git revision control system used by the Linux kernel
developers
SECTION = console/utils
LICENSE = GPLv2
-DEPENDS = perl-native-runtime openssl curl zlib expat
+DEPENDS = openssl curl zlib expat
SRC_URI = ${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.bz2
S = ${WORKDIR}/git-${PV}
LIC_FILES_CHKSUM = file://COPYING;md5=7c0d7ef03a7eb04ce795b0f60e68e7e1
-EXTRA_OECONF = --without-tcltk
+EXTRA_OECONF = --with-perl=${STAGING_BINDIR_NATIVE}/perl-native/perl
--without-tcltk
-inherit autotools
+inherit autotools perlnative
do_install () {
oe_runmake install DESTDIR=${D} bindir=${bindir} \
diff --git a/meta/recipes-devtools/git/git_1.7.5.1.bb
b/meta/recipes-devtools/git/git_1.7.5.1.bb
index 9aa2bdf..04d1d56 100644
--- a/meta/recipes-devtools/git/git_1.7.5.1.bb
+++ b/meta/recipes-devtools/git/git_1.7.5.1.bb
@@ -1,6 +1,6 @@
require git.inc
-PR = r1
+PR = r2
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.7.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 4/4] multiple recipes converted to -staticdev packages
On Fri, 2011-06-10 at 10:25 +0100, Phil Blundell wrote: This can't be right. I guess that would be a good thing for recipe-sanity to test for in fact. ... except that this wouldn't have helped because oe-core doesn't currently have recipe_sanity at all. Heh. I'll send a patch for that later, and then maybe we can add the bogus DEPENDS checking as a future enhancement. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1]libQtopenGL: Add library libQtOpenGL* to lsb image
From: Xiaofeng Yan xiaofeng@windriver.com Hi Saul, I submit this patch for adding library libQtopenGL* to lsb image. We make lsb test on the following platform with default setting mesa-xlib so far. emenlow, mpc8315e, qemux86,qemux86-64 ,jasperforest Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: xiaofeng/opengl Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/opengl Thanks, Xiaofeng Yan xiaofeng@windriver.com --- Xiaofeng Yan (1): task-core-lsb: Install libQtOpenGL* to lsb meta/recipes-extended/tasks/task-core-lsb.bb | 15 ++- 1 files changed, 2 insertions(+), 13 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] task-core-lsb: Install libQtOpenGL* to lsb
From: Xiaofeng Yan xiaofeng@windriver.com
Fix bug [#YOCTO 1020]
It is part of fixing bug [YOCTO #1020]. If another patch to add configuration
for compiling qtopengl to poky-lsb.conf is merged to poky, \
then this bug will be fixed. LSB Test Suite need library libQtOpenGL* in an
lsb image. If an image has mesa-xlib or mesa-dri,\
then opegl will run on target platform.
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
meta/recipes-extended/tasks/task-core-lsb.bb | 15 ++-
1 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/meta/recipes-extended/tasks/task-core-lsb.bb
b/meta/recipes-extended/tasks/task-core-lsb.bb
index 9fbacf9..0ee4627 100644
--- a/meta/recipes-extended/tasks/task-core-lsb.bb
+++ b/meta/recipes-extended/tasks/task-core-lsb.bb
@@ -3,7 +3,7 @@
#
DESCRIPTION = Create Small Image Tasks
-PR = r4
+PR = r5
LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
@@ -156,6 +156,7 @@ RDEPENDS_task-core-lsb-graphic-add = \
libqtsvg4 \
libqtxml4 \
libqtnetwork4 \
+libqtopengl4 \
libxt \
libxxf86vm \
libdrm \
@@ -171,18 +172,6 @@ RDEPENDS_task-core-lsb-graphic-add = \
liberation-fonts \
-RDEPENDS_task-core-lsb-graphic-add_qemux86 = \
-libqtopengl4 \
-
-RDEPENDS_task-core-lsb-graphic-add_atom-pc = \
-libqtopengl4 \
-
-RDEPENDS_task-core-lsb-graphic-add_qemuppc = \
-libqtopengl4 \
-
-RDEPENDS_task-core-lsb-graphic-add_emenlow = \
-libqtopengl4 \
-
RDEPENDS_task-core-lsb-graphic-add_mpc8315e-rdb = \
libqtopengl4 \
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] The design document for ccache-native
On Fri, 2011-06-10 at 08:09 -0500, Mike Westerhof wrote:
I fear that the use of ccache is inherently risky with OE. Given the
(relatively common) case where the user blows away their TMPDIR in order
to get a full, clean rebuild after an update to the toolchain is make,
it is possible that ccache will erroneously re-use an object created by
the earlier version of the toolchain.
While imperfect, I would suggest that we would do better if we would
somehow embed the PV (or something like that) for the toolchain into the
CCACHE_DIR, thus ensuring that we don't risk the re-use of old objects
when the toolchain is updated.
ccache does already include the mtime and file size of the compiler in
the hash that it uses to determine whether two compilations are the
same. I'm not sure that mangling the compiler version into ${PV} is
going to buy much.
(Frankly, given my experiences with it, I'd prefer we just disable
ccache entirely with OE.)
I agree that it should probably be disabled by default. I've also had
some slightly bad experiences with ccache although I don't think I have
ever encountered the failure mode you mentioned above.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] The design document for ccache-native
On 6/10/2011 8:09 AM, Mike Westerhof wrote:
On 6/10/2011 12:48 AM, Robert Yang wrote:
On 06/10/2011 11:26 AM, wenzong fan wrote:
Original Message
On Thu, 2011-06-09 at 15:40 -0700, Saul Wold wrote:
On 06/02/2011 08:11 PM, wenzong fan wrote:
Hi Folks,
Please help me to review the design document for ccache-native, and
I also have two questions about it, any answers or suggestions are
appreciated.
* Feature name: ccache-native
Priority: P3; M2
Owner: Wenzong Fan
Summary: Integrate ccache-native to yocto
* Description:
Bitbake supports the 'CCACHE Mechanism', but 'ccache' hasn't been
included by poky/yocto, just add it as a native tool.
* Usage:
Build ccache as a native tool by default and enable it for speeding
target packages build.
* Implementation:
1) Copy bb file from OE upstream to:
meta/recipes-devtools/ccache/
2) Update bb file to get the latest ccache_3.1.5 and split the single
bb file to:
'ccache_3.1.5.bb', 'ccache.inc'
3) Enable ccache in the native tools building.
You will need to have it be a dependency pretty early on in the build.
Additionally, this is a bit a new part to this task, we want to have the
default CCACHE_DIR for the build default to a directory in TMPDIR
instead of the user's home directory. This will mean setting an
environment variable somewhere early also.
There is a little more detail on:
https://wiki.yoctoproject.org/wiki/Yocto_1.1_Schedule
Specifically, c) Set CCACHE on a per recipe basis. need to figure out
whether ccache data can be shared and under what circumstances.
so something like adding:
export CCACHE_DIR = ${TMPDIR}/ccache/${TARGET_SYS}/${PN}
I think that set CCACHE_DIR on per recipe basis would degrade hit
efficiency,
the following ccache data can be shared if they they use the same
CCACHE_DIR,
but if we set CACHE_DIR on a per recipe basis, then they can't be shared:
1) Most pkg's configure will run gcc foo.c for checking the C compiler,
these compiling are the same between different pkgs at most time.
2) Some recipes' compiling are similar, for example: gcc-cross,
gcc-corss-initial and gcc-cross-intermediate.
I think that:
export CCACHE_DIR = ${TMPDIR}/ccache/${TARGET_SYS}/
would be better.
I fear that the use of ccache is inherently risky with OE. Given the
(relatively common) case where the user blows away their TMPDIR in order
(Replying to my own message, because I didn't have enough coffee to be
clear in the original!) I'm agreeing with the suggestion that it be in
TMPDIR, and offering the suggestion that if we don't put it there, we
need to qualify it with the toolchain version. (Now I'm going to get
another cup of coffee -- sorry for any confusion!)
-Mike (mwester)
to get a full, clean rebuild after an update to the toolchain is make,
it is possible that ccache will erroneously re-use an object created by
the earlier version of the toolchain.
While imperfect, I would suggest that we would do better if we would
somehow embed the PV (or something like that) for the toolchain into the
CCACHE_DIR, thus ensuring that we don't risk the re-use of old objects
when the toolchain is updated.
(Frankly, given my experiences with it, I'd prefer we just disable
ccache entirely with OE.)
-Mike (mwester)
// Robert
to bitbake.conf with a bit more thought into working out the right
components to add to the variable.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] uclibc: fix compile error on i586
Without this you get:
| libc/sysdeps/linux/common/epoll.c: In function '__libc_epoll_pwait':
| libc/sysdeps/linux/common/epoll.c:71:80: error: memory input 7 is not
directly addressable
| libc/sysdeps/linux/common/epoll.c:75:86: error: memory input 7 is not
directly addressable
| make: *** [libc/sysdeps/linux/common/epoll.o] Error 1
Signed-off-by: Phil Blundell ph...@gnu.org
---
.../uclibc/uclibc-git/epoll-asm-fix.patch | 25
meta/recipes-core/uclibc/uclibc_git.bb |1 +
create mode 100644 meta/recipes-core/uclibc/uclibc-git/epoll-asm-fix.patch
diff --git a/meta/recipes-core/uclibc/uclibc-git/epoll-asm-fix.patch
b/meta/recipes-core/uclibc/uclibc-git/epoll-asm-fix.patch
new file mode 100644
index 000..bcd834d
--- /dev/null
+++ b/meta/recipes-core/uclibc/uclibc-git/epoll-asm-fix.patch
@@ -0,0 +1,25 @@
+Fix a compile error due to last argument to syscall() not being memory
addressable.
+
+Upstream-Status: Pending
+Signed-off-by: Phil Blundell ph...@gnu.org
+
+diff --git a/libc/sysdeps/linux/common/epoll.c
b/libc/sysdeps/linux/common/epoll.c
+index 85b0cfd..c034b2c 100644
+--- a/libc/sysdeps/linux/common/epoll.c
b/libc/sysdeps/linux/common/epoll.c
+@@ -67,12 +67,13 @@ extern __typeof(epoll_pwait) __libc_epoll_pwait;
+ int __libc_epoll_pwait(int epfd, struct epoll_event *events, int maxevents,
+ int timeout, const sigset_t
*set)
+ {
++ int nsig = _NSIG / 8;
+ if (SINGLE_THREAD_P)
+- return INLINE_SYSCALL(epoll_pwait, 6, epfd, events, maxevents,
timeout, set, _NSIG / 8);
++ return INLINE_SYSCALL(epoll_pwait, 6, epfd, events, maxevents,
timeout, set, nsig);
+ # ifdef __UCLIBC_HAS_THREADS_NATIVE__
+ else {
+ int oldtype = LIBC_CANCEL_ASYNC ();
+- int result = INLINE_SYSCALL(epoll_pwait, 6, epfd, events,
maxevents, timeout, set, _NSIG / 8);
++ int result = INLINE_SYSCALL(epoll_pwait, 6, epfd, events,
maxevents, timeout, set, nsig);
+ LIBC_CANCEL_RESET (oldtype);
+ return result;
+ }
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index c1bc422..a2c6ee5 100644
diff --git a/meta/recipes-core/uclibc/uclibc_git.bb
b/meta/recipes-core/uclibc/uclibc_git.bb
index eded2fb..54babca 100644
--- a/meta/recipes-core/uclibc/uclibc_git.bb
+++ b/meta/recipes-core/uclibc/uclibc_git.bb
@@ -29,5 +29,6 @@ SRC_URI =
git://uclibc.org/uClibc.git;branch=master;protocol=git \
file://remove_attribute_optimize_Os.patch \
file://append_UCLIBC_EXTRA_CFLAGS.patch \
file://compile-arm-fork-with-O2.patch \
+ file://epoll-asm-fix.patch \
S = ${WORKDIR}/git
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] meta-gnome update
Hi, For people not keeping an eye on meta-gnome, it reached a milestone this week: a usefull looking[1] GNOME 2.32 desktop. With the current bits in oe-core, meta-oe and meta-gnome you can build an image with gdm, gnome-panel, gnome-session, nautilus metacity and gnome-disk-utility. It's still lacking things like gnome-control-center, gnome-settings-daemon, totem, etc. If you're using meta-angstrom you can build systemd-gnome-image which willl give you the above. Give it all a try and send lots of patches to move over your favourite GNOME recipes :) regards, Koen [1] It's not actually usefull, it just looks that way :) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] bitbake -b busted
Since updating this morning, it seems that oe-core master now requires bitbake 1.13.1 to be installed. (I don't recall any discussion of that change or the reasons for it, but no doubt they are good ones.) I couldn't find a 1.13.1 tag (or in fact any tags after 1.12.0) in the bitbake repository so I pulled the head of master. Judging from the contents of the log this is pretty close to 1.13.1 if not identical. Unfortunately, this update seems to have broken bitbake -b file altogether. Any such command now seems to give me: ERROR: Command execution failed: Traceback (most recent call last): File /home/pb/oe/bitbake/lib/bb/command.py, line 102, in runAsyncCommand commandmethod(self.cmds_async, self, options) File /home/pb/oe/bitbake/lib/bb/command.py, line 190, in buildFile command.cooker.buildFile(bfile, task) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 774, in buildFile fn = self.matchFile(fn) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 752, in matchFile matches = self.matchFiles(buildfile) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 735, in matchFiles filelist, masked = self.collect_bbfiles() File /home/pb/oe/bitbake/lib/bb/cooker.py, line 994, in collect_bbfiles files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) ) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 994, in lambda files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) ) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 463, in calc_bbfile_priority for _, _, regex, pri in self.status.bbfile_config_priorities: AttributeError: 'NoneType' object has no attribute 'bbfile_config_priorities' p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] sysklogd.inc: Check for package-management in IMAGE_FEATURES
On Thu, 2011-06-09 at 17:57 -0700, Khem Raj wrote:
-RDEPENDS_${PN}_append = ${@base_conditional(ONLINE_PACKAGE_MANAGEMENT,
none, , update-rc.d, d)}
+RDEPENDS_${PN}_append = ${@oe.utils.contains(IMAGE_FEATURES,
package-management, update-rc.d, , d)}
This sort of thing shouldn't be necessary in oe-core. See previous
discussions between me and Richard as to why IMAGE_FEATURES is not the
right thing, and code in package_ipk.bbclass which ought to be taking
care of it. If you're using a different package manager then it should
be fairly straightforward to adapt that logic to suit.
You're right though the the reference to O_P_M is clearly wrong and
should be removed. I'm not quite sure how that got in there in the
first place; must have been some oversight during patch review I guess.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] bitbake -b busted
Op 10 jun 2011, om 16:09 heeft Phil Blundell het volgende geschreven: Since updating this morning, it seems that oe-core master now requires bitbake 1.13.1 to be installed. (I don't recall any discussion of that change or the reasons for it, but no doubt they are good ones.) I couldn't find a 1.13.1 tag (or in fact any tags after 1.12.0) in the bitbake repository so I pulled the head of master. Judging from the contents of the log this is pretty close to 1.13.1 if not identical. Unfortunately, this update seems to have broken bitbake -b file altogether. Any such command now seems to give me: ERROR: Command execution failed: Traceback (most recent call last): File /home/pb/oe/bitbake/lib/bb/command.py, line 102, in runAsyncCommand commandmethod(self.cmds_async, self, options) File /home/pb/oe/bitbake/lib/bb/command.py, line 190, in buildFile command.cooker.buildFile(bfile, task) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 774, in buildFile fn = self.matchFile(fn) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 752, in matchFile matches = self.matchFiles(buildfile) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 735, in matchFiles filelist, masked = self.collect_bbfiles() File /home/pb/oe/bitbake/lib/bb/cooker.py, line 994, in collect_bbfiles files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) ) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 994, in lambda files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) ) File /home/pb/oe/bitbake/lib/bb/cooker.py, line 463, in calc_bbfile_priority for _, _, regex, pri in self.status.bbfile_config_priorities: AttributeError: 'NoneType' object has no attribute 'bbfile_config_priorities' Known problem: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-June/003721.html ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] iproute2: update to 2.6.38
Op 9 jun 2011, om 14:53 heeft Paul Eggleton het volgende geschreven: Fixes ip route get not producing any output (a regression in 2.6.35). See http://marc.info/?l=linux-netdevm=129442470405398w=2 and http://marc.info/?l=linux-netdevm=130038222321440w=2 for a list of other changes since 2.6.35. Fixes [YOCTO #1006] (reopened) Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com When building I get this: WARNING: the following files were installed but not shipped in any package: WARNING: /lib/tc/m_xt.so WARNING: /lib/tc/m_ipt.so I don't know anything about iproute2, so I can't say if it's bad or good to leave these out :) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory
On 06/09/2011 01:08 AM, Richard Purdie wrote:
On Thu, 2011-06-09 at 09:04 +0100, Richard Purdie wrote:
On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote:
On 06/02/2011 09:35 AM, Richard Purdie wrote:
On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
Even if we're using the sstate
cache from /foo/oecore/tmp over in /bar/oecore/tmp (and /foo/oecore/tmp
is rm -rf'd) ? Since we've got a create_wrapper around perl and
perl${PV} it should be I suppose (or is easily added there), but I'd
feel a lot better with some testing of the above case (and the updates
to cpan*bbclass).
I only took the perl-native DEPENDS patch on the condition this gets
fixed properly. The patches that are there look to do that, at least for
OE-Core. If there are further issues we're going to have to take them as
they arise as I have an objection to crippling the build dependencies
because perl is broken. Really this could use some TLC from someone with
experience in the area...
Well, I guess I'd boil down what I said above into a request like this
for v3:
- Modify cpan.bbclass to NOT set PERL_INC / PERL_LIB / PERL_ARCHLIB /
PERLHOSTLIB.
The first three of these are all about the *target* perl location and I
think we still need them due the mess that perl's build system is. With
the patch series in question they won't actually point at perl-native in
the target case and they are only really used for cross compiling
purposes.
PERLHOSTLIB is used by the target perl when cross compiling to find
native .so files. perl-native will always be present at this point and
again, it seems like a valid use case.
Summary is that I don't think perl-native is broken in any way but we do
need those variables.
- In /scratch/oecore/tmp0 build the images that were built for v1
- In /scratch/oecore/tmp1 build perl-native's full sstate cache.
- Keep the sstate cache from tmp1 and otherwise rm -rf tmp1.
- In /scratch/oecore/tmp2 using the sstate from tmp1, build the same
images that were built for tmp0.
I'm confused by this test cycle. What do you mean by build
perl-native's full sstate cache?
I suspect you've asking for some partial sstate cache to be shared
between two builds?
Put simpler, you probably want:
in tmp0 bitbake perl-native
in tmp1, different location to tmp0, bitbake core-image-sato but
sharing the same sstate cache
I meant to add that tmp0 should be renamed before this second step so if
there are hardcoded references in any of the sstate packages they
couldn't find anything in tmp0 as it would no longer exist.
Yes, this is what I'm asking for.
--
Tom Rini
Mentor Graphics Corporation
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory
On 06/09/2011 01:04 AM, Richard Purdie wrote:
On Thu, 2011-06-02 at 09:55 -0700, Tom Rini wrote:
On 06/02/2011 09:35 AM, Richard Purdie wrote:
On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
Even if we're using the sstate
cache from /foo/oecore/tmp over in /bar/oecore/tmp (and /foo/oecore/tmp
is rm -rf'd) ? Since we've got a create_wrapper around perl and
perl${PV} it should be I suppose (or is easily added there), but I'd
feel a lot better with some testing of the above case (and the updates
to cpan*bbclass).
I only took the perl-native DEPENDS patch on the condition this gets
fixed properly. The patches that are there look to do that, at least for
OE-Core. If there are further issues we're going to have to take them as
they arise as I have an objection to crippling the build dependencies
because perl is broken. Really this could use some TLC from someone with
experience in the area...
Well, I guess I'd boil down what I said above into a request like this
for v3:
- Modify cpan.bbclass to NOT set PERL_INC / PERL_LIB / PERL_ARCHLIB /
PERLHOSTLIB.
The first three of these are all about the *target* perl location and I
think we still need them due the mess that perl's build system is. With
the patch series in question they won't actually point at perl-native in
the target case and they are only really used for cross compiling
purposes.
PERLHOSTLIB is used by the target perl when cross compiling to find
native .so files. perl-native will always be present at this point and
again, it seems like a valid use case.
Summary is that I don't think perl-native is broken in any way but we do
need those variables.
Maybe I'm having a dense morning here, but isn't that the point? The
combination of perl's build system is messy and if we bring in cpan it
needs not only target perl locations (to dump things into) but may call
'perl' to do things and if we're on perl 5.14 and your host is only 5.10
or 5.12, bad things can happen. And since cpan.bbclass isn't brought in
by target perl recipe, what now? :)
--
Tom Rini
Mentor Graphics Corporation
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] import recipe_sanity.bbclass from oe master
This is a verbatim copy of the corresponding class from oe master.
Signed-off-by: Phil Blundell ph...@gnu.org
---
meta/classes/recipe_sanity.bbclass | 179
1 files changed, 179 insertions(+), 0 deletions(-)
create mode 100644 meta/classes/recipe_sanity.bbclass
diff --git a/meta/classes/recipe_sanity.bbclass
b/meta/classes/recipe_sanity.bbclass
new file mode 100644
index 000..bb60ffa
--- /dev/null
+++ b/meta/classes/recipe_sanity.bbclass
@@ -0,0 +1,179 @@
+def __note(msg, d):
+bb.note(%s: recipe_sanity: %s % (d.getVar(P, 1), msg))
+
+__recipe_sanity_badruntimevars = RDEPENDS RPROVIDES RRECOMMENDS RCONFLICTS
+def bad_runtime_vars(cfgdata, d):
+if bb.data.inherits_class(native, d) or \
+ bb.data.inherits_class(cross, d):
+return
+
+for var in d.getVar(__recipe_sanity_badruntimevars, 1).split():
+val = d.getVar(var, 0)
+if val and val != cfgdata.get(var):
+__note(%s should be %s_${PN} % (var, var), d)
+
+__recipe_sanity_reqvars = DESCRIPTION
+__recipe_sanity_reqdiffvars = LICENSE
+def req_vars(cfgdata, d):
+for var in d.getVar(__recipe_sanity_reqvars, 1).split():
+if not d.getVar(var, 0):
+__note(%s should be set % var, d)
+
+for var in d.getVar(__recipe_sanity_reqdiffvars, 1).split():
+val = d.getVar(var, 0)
+cfgval = cfgdata.get(var)
+
+# Hardcoding is bad, but I'm lazy. We don't care about license being
+# unset if the recipe has no sources!
+if var == LICENSE and d.getVar(SRC_URI, 1) ==
cfgdata.get(SRC_URI):
+continue
+
+if not val:
+__note(%s should be set % var, d)
+elif val == cfgval:
+__note(%s should be defined to something other than default (%s)
% (var, cfgval), d)
+
+def var_renames_overwrite(cfgdata, d):
+renames = d.getVar(__recipe_sanity_renames, 0)
+if renames:
+for (key, newkey, oldvalue, newvalue) in renames:
+if oldvalue != newvalue and oldvalue != cfgdata.get(newkey):
+__note(rename of variable '%s' to '%s' overwrote existing
value '%s' with '%s'. % (key, newkey, oldvalue, newvalue), d)
+
+def incorrect_nonempty_PACKAGES(cfgdata, d):
+if bb.data.inherits_class(native, d) or \
+ bb.data.inherits_class(cross, d):
+if d.getVar(PACKAGES, 1):
+return True
+
+def can_use_autotools_base(cfgdata, d):
+cfg = d.getVar(do_configure, 1)
+if not bb.data.inherits_class(autotools, d):
+return False
+
+for i in [autoreconf] + [%s_do_configure % cls for cls in
[gnomebase, gnome, e, autotools, efl, gpephone, openmoko,
openmoko2, xfce, xlibs]]:
+if cfg.find(i) != -1:
+return False
+
+import os
+for clsfile in d.getVar(__inherit_cache, 0):
+(base, _) = os.path.splitext(os.path.basename(clsfile))
+if cfg.find(%s_do_configure % base) != -1:
+__note(autotools_base usage needs verification, spotted
%s_do_configure % base, d)
+
+return True
+
+def can_remove_FILESPATH(cfgdata, d):
+expected = cfgdata.get(FILESPATH)
+#expected = ${@':'.join([os.path.normpath(os.path.join(fp, p, o)) for fp
in d.getVar('FILESPATHBASE', 1).split(':') for p in d.getVar('FILESPATHPKG',
1).split(':') for o in (d.getVar('OVERRIDES', 1) + ':').split(':') if
os.path.exists(os.path.join(fp, p, o))])}:${FILESDIR}
+expectedpaths = bb.data.expand(expected, d)
+unexpanded = d.getVar(FILESPATH, 0)
+filespath = d.getVar(FILESPATH, 1).split(:)
+filespath = [os.path.normpath(f) for f in filespath if os.path.exists(f)]
+for fp in filespath:
+if not fp in expectedpaths:
+# __note(Path %s in FILESPATH not in the expected paths %s %
+# (fp, expectedpaths), d)
+return False
+return expected != unexpanded
+
+def can_remove_FILESDIR(cfgdata, d):
+expected = cfgdata.get(FILESDIR)
+#expected = ${@bb.which(d.getVar('FILESPATH', 1), '.')}
+unexpanded = d.getVar(FILESDIR, 0)
+if unexpanded is None:
+return False
+
+expanded = os.path.normpath(d.getVar(FILESDIR, 1))
+filespath = d.getVar(FILESPATH, 1).split(:)
+filespath = [os.path.normpath(f) for f in filespath if os.path.exists(f)]
+
+return unexpanded != expected and \
+ os.path.exists(expanded) and \
+ (expanded in filespath or
+expanded == bb.data.expand(expected, d))
+
+def can_remove_others(p, cfgdata, d):
+for k in [S, PV, PN, DESCRIPTION, LICENSE, DEPENDS,
+ SECTION, PACKAGES, EXTRA_OECONF, EXTRA_OEMAKE]:
+#for k in cfgdata:
+unexpanded = d.getVar(k, 0)
+cfgunexpanded = cfgdata.get(k)
+if not cfgunexpanded:
+continue
+
+try:
+expanded = d.getVar(k, 1)
+cfgexpanded = bb.data.expand(cfgunexpanded, d)
+except bb.fetch.ParameterError:
+continue
+
+if unexpanded !=
Re: [OE-core] [Yocto] The design document for ccache-native
On 06/09/2011 07:54 PM, Khem Raj wrote: On 06/09/2011 04:51 PM, Tom Rini wrote: On 06/09/2011 03:40 PM, Saul Wold wrote: On 06/02/2011 08:11 PM, wenzong fan wrote: Hi Folks, Please help me to review the design document for ccache-native, and I also have two questions about it, any answers or suggestions are appreciated. * Feature name: ccache-native Priority: P3; M2 Owner: Wenzong Fan Summary: Integrate ccache-native to yocto * Description: Bitbake supports the 'CCACHE Mechanism', but 'ccache' hasn't been included by poky/yocto, just add it as a native tool. * Usage: Build ccache as a native tool by default and enable it for speeding target packages build. * Implementation: 1) Copy bb file from OE upstream to: meta/recipes-devtools/ccache/ 2) Update bb file to get the latest ccache_3.1.5 and split the single bb file to: 'ccache_3.1.5.bb', 'ccache.inc' 3) Enable ccache in the native tools building. You will need to have it be a dependency pretty early on in the build. Additionally, this is a bit a new part to this task, we want to have the default CCACHE_DIR for the build default to a directory in TMPDIR instead of the user's home directory. This will mean setting an environment variable somewhere early also. Can we instead veto ccache and remove it from the bitbake docs? I can't count the number of times I've run into what I can only imagine are ccache conflicts to explain why a random build failure with ccache in use. It works on some hosts somewhat reliably and is unpredictable on some as you say. I think keeping it optional is probably the right thing but making it default may not be a good thing. I'm pretty sure it's not reliable so much as lucky, but shoving the cache somewhere else and making it per-recipe makes me less worried. -- Tom Rini Mentor Graphics Corporation ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] iproute2: update to 2.6.38
On Friday 10 June 2011 15:19:00 Koen Kooi wrote: When building I get this: WARNING: the following files were installed but not shipped in any package: WARNING: /lib/tc/m_xt.so WARNING: /lib/tc/m_ipt.so I don't know anything about iproute2, so I can't say if it's bad or good to leave these out :) From some searching I think we may want those if we want tc to be able to handle xtables/iptables; however one packager I found chose to install m_ipt.so as a symlink to m_xt.so. This needs a little further research. Thanks for pointing this out, I should really have seen it myself. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] pseudo: Fix problem related to realpath
On Thursday 09 June 2011 18:15:45 Mark Hatle wrote: --- a/meta/recipes-devtools/pseudo/pseudo_1.1.1.bb +++ b/meta/recipes-devtools/pseudo/pseudo_1.1.1.bb @@ -1,9 +1,10 @@ require pseudo.inc -PR = r0 +PR = r1 I may be mistaken, but it seems to me that every time we need to rebuild pseudo it results in a race when an older version of pseudo is present. We handle building pseudo on its own first if it's not present, however if it just needs updating we go ahead and rebuild it at the same time as building other packages, and if it just happens that pseudo is needed when it's being built - bang. At least that's my assumption given that since the last batch of updates, my rebuild of perl-native failed at the same time as pseudo's do_compile with a large number of ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored messages. Am I right in that there's currently no mechanism to work around this? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] import recipe_sanity.bbclass from oe master
On 6/10/11 9:28 AM, Phil Blundell wrote: This is a verbatim copy of the corresponding class from oe master. Signed-off-by: Phil Blundell ph...@gnu.org --- One of the new features we have in oe-core (likely not well publicized) is SUMMARY information. If this patch goes in, we likely should check for the existence of a SUMMARY as well. Not all recipes have package summaries, but in the end they all should. --Mark +__recipe_sanity_reqvars = DESCRIPTION +__recipe_sanity_reqdiffvars = LICENSE ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] pseudo: Fix problem related to realpath
On 6/10/11 10:02 AM, Paul Eggleton wrote: On Thursday 09 June 2011 18:15:45 Mark Hatle wrote: --- a/meta/recipes-devtools/pseudo/pseudo_1.1.1.bb +++ b/meta/recipes-devtools/pseudo/pseudo_1.1.1.bb @@ -1,9 +1,10 @@ require pseudo.inc -PR = r0 +PR = r1 I may be mistaken, but it seems to me that every time we need to rebuild pseudo it results in a race when an older version of pseudo is present. We handle building pseudo on its own first if it's not present, however if it just needs updating we go ahead and rebuild it at the same time as building other packages, and if it just happens that pseudo is needed when it's being built - bang. At least that's my assumption given that since the last batch of updates, my rebuild of perl-native failed at the same time as pseudo's do_compile with a large number of ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored messages. Am I right in that there's currently no mechanism to work around this? Cheers, Paul Theoretically updating pseudo shouldn't happen very often. But yes, currently there is an issue that pseudo updates are not caused and cause the pseudo rebuild. We can work around this by: * removing the pseudodone file in the build directory * manually running the first stage build: BBFETCH2=True PSEUDO_BUILD=1 ../bitbake/bin/bitbake pseudo-native * manually running bitbake pseudo-native, (still does it as a second stage, but usually works) Likely what we need to do is figure out a (quick) way in the bitbake wrapper to determine if the pseudo has changed... timestamp match to pseudodone? That of course still won't be fool proof. What has been discussed in the past is adding the capabilities for a staged build to bitbake. Being able to re-invoke the bitbake process after given stages [automatically] so that in the end bitbake is in charge of the build steps. So far though not much has been done with this idea, as we're really not sure how practical this is. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] uclibc: remove redundant python code
On 06/10/2011 07:01 AM, Phil Blundell wrote:
This chunk of python code has been around for a while (witness the
comment about gcc 3.4.0) and predates the availability of
COMPATIBLE_HOST. Rewrite it using a more modern idiom.
Signed-off-by: Phil Blundellph...@gnu.org
Acked-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-core/uclibc/uclibc.inc| 12 +
diff --git a/meta/recipes-core/uclibc/uclibc.inc
b/meta/recipes-core/uclibc/uclibc.inc
index c1bc422..a2c6ee5 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -36,21 +36,11 @@ cp ${SYSROOT_DESTDIR}${libdir}/libc.so
${WORKDIR}/site_config_libc; \
sed -i -e 's# ${base_libdir}# ${SYSROOT_DESTDIR}${base_libdir}#g' -e 's#
${libdir}# ${SYSROOT_DESTDIR}${libdir}#g' ${WORKDIR}/site_config_libc/libc.so; \
-#
# For now, we will skip building of a gcc package if it is a uclibc one
# and our build is not a uclibc one, and we skip a glibc one if our build
# is a uclibc build.
-#
-# See the note in gcc/gcc_3.4.0.oe
-#
+COMPATIBLE_HOST = .*-uclibc.*
-python __anonymous () {
-import bb, re
-uc_os = (re.match('.*uclibc*', bb.data.getVar('TARGET_OS', d, 1)) != None)
-if not uc_os:
-raise bb.parse.SkipPackage(incompatible with target %s %
- bb.data.getVar('TARGET_OS', d, 1))
-}
PROVIDES += virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc
DEPENDS = virtual/${TARGET_PREFIX}binutils \
virtual/${TARGET_PREFIX}gcc-intermediate \
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 0/4] 10-June
On Thu, 2011-06-09 at 23:26 -0700, Saul Wold wrote: Kang Kai (1): ghostscript: update SRC_URI Nitin A Kamble (1): gcc: rebase the patch to avoid patch rejection This was a disaster. It breaks the build and is huge, thereby clogging up the source control system web interface etc. I applied it, then had to revert it. Please test things like this more carefully in future. I also think we need to put these kind of patches on the website or in a repo, we shouldn't be carrying them around in the main repo. Phil Blundell (1): busybox: backport distro-features handling from oe master Saul Wold (1): multiple recipes converted to -staticdev packages I'm with Phil on this one, needs more work. I haven't got to the other two since the gcc issue distracted me :/. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 0/4] 10-June
On 06/10/2011 09:33 AM, Richard Purdie wrote: On Thu, 2011-06-09 at 23:26 -0700, Saul Wold wrote: Kang Kai (1): ghostscript: update SRC_URI Nitin A Kamble (1): gcc: rebase the patch to avoid patch rejection This was a disaster. It breaks the build and is huge, thereby clogging up the source control system web interface etc. I applied it, then had to revert it. Please test things like this more carefully in future. I also think we need to put these kind of patches on the website or in a repo, we shouldn't be carrying them around in the main repo. Phil Blundell (1): busybox: backport distro-features handling from oe master Saul Wold (1): multiple recipes converted to -staticdev packages I'm with Phil on this one, needs more work. Sorry about this one, I thought I had it further along, I guess I had a cut and paste failure (dropping the R from RDEPENDS). I haven't got to the other two since the gcc issue distracted me :/. I did run multiple builds without failure, so I am not sure what happened with the gcc failure. Sau! Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 0/4] 10-June
Op 10 jun 2011, om 18:33 heeft Richard Purdie het volgende geschreven: On Thu, 2011-06-09 at 23:26 -0700, Saul Wold wrote: Kang Kai (1): ghostscript: update SRC_URI Nitin A Kamble (1): gcc: rebase the patch to avoid patch rejection This was a disaster. It breaks the build and is huge, thereby clogging up the source control system web interface etc. I applied it, then had to revert it. Please test things like this more carefully in future. I also think we need to put these kind of patches on the website or in a repo, we shouldn't be carrying them around in the main repo. Having patches external to the layer is a recipe for failure, if you excude the pun. I've had to deal with patches disappearing/changing/etc a lot during the past months in the .dev world and I don't look forward to continuing those mistakes in the oe-core world. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 4/4] multiple recipes converted to -staticdev packages
On 06/10/2011 02:25 AM, Phil Blundell wrote:
On Thu, 2011-06-09 at 23:26 -0700, Saul Wold wrote:
+DEPENDS_libpci-staticdev = libpci-dev (= ${EXTENDPKGV})
This can't be right. I guess that would be a good thing for
recipe-sanity to test for in fact.
It's not, I did not catch the cut and paste error on the RDEPENDS vs
DEPENDS.
+FILES_eglibc-dev_append += ${bindir}/rpcgen ${base_libdir}/*.o
${datadir}/aclocal
+FILES_eglibc-staticdev_append += ${libdir}/*.a ${base_libdir}/*.a
You need to make sure that libc_nonshared.a goes into -dev rather than
-staticdev somehow. I didn't immediately spot any mechanism which would
do this, though I haven't tested the package to find out what happens.
+FILES_uclibc-staticdev_append = \
+${libdir}/*_nonshared.a \
+${libdir}/lib*.a \
In similar vein, this doesn't look right.
I think I should be able to remove nonshared from a list.
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index b77266a..ed4bcdb 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -13,6 +13,8 @@ LIC_FILES_CHKSUM =
file://README.licensing;md5=9c920d811858a74b67a36ba23cbaa95f
file://licenses/COPYING.UCB;md5=263860f8968d8bafa5392cab74285262 \
file://getopt/COPYING;md5=8ca43cbc842c2336e835926c2166c28b
+INC_PR = r0
+
diff --git a/meta/recipes-core/util-linux/util-linux_2.19.1.bb
b/meta/recipes-core/util-linux/util-linux_2.19.1.bb
index 132f28b..3c5747c 100644
--- a/meta/recipes-core/util-linux/util-linux_2.19.1.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.19.1.bb
@@ -1,5 +1,5 @@
MAJOR_VERSION = 2.19
-PR = r1
+PR = ${INC_PR}.0
This looks like it will cause PR to go backwards.
require util-linux.inc
# note that `lscpu' is under GPLv3+
diff --git a/meta/recipes-devtools/binutils/binutils.inc
b/meta/recipes-devtools/binutils/binutils.inc
index 08c14b2..82d9511 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -24,7 +24,6 @@ FILES_${PN} = \
FILES_${PN}-dev = \
${includedir} \
- ${libdir}/*.a \
${libdir}/*.la \
${libdir}/libbfd.so \
${libdir}/libopcodes.so
This one is a bit odd: it seems to just be dropping the .a files
altogether without introducing a -staticdev package for them.
I thought that maybe the default rule provided in bitbake.conf should
accomplish this since it is FILES_${PN}-staticdev = ${libdir}/*.a
${base_libdir}/*.a
+DEPENDS_libg2c-staticdev = libg2c-dev (= ${EXTENDPKGV})
+DEPENDS_libstdc++-staticdev = libstdc++-dev (= ${EXTENDPKGV})
+DEPENDS_libssp-staticdev = libssp-dev (= ${EXTENDPKGV})
+DEPENDS_libfortran-staticdev = libfortran-dev (= ${EXTENDPKGV})
+DEPENDS_libmudflap-staticdev = libmudflap-dev (= ${EXTENDPKGV})
+DEPENDS_libopkg${PKGSUFFIX}-staticdev = libopkg${PKGSUFFIX}-dev (=
${EXTENDPKGV})
Those all look wrong.
Cut and paste issue
--- a/meta/recipes-multimedia/liba52/liba52_0.7.4.bb
+++ b/meta/recipes-multimedia/liba52/liba52_0.7.4.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://include/a52.h;beginline=1;endline=12;md5=81152ceb3562bf20a60d1b6018175dd1
SECTION = libs
PRIORITY = optional
-PR = r2
+PR = r3
inherit autotools
@@ -21,7 +21,8 @@ EXTRA_OECONF = --enable-shared
PACKAGES =+ a52dec a52dec-dbg a52dec-doc
FILES_${PN} = ${libdir}/liba52.so.0 ${libdir}/liba52.so.0.0.0
-FILES_${PN}-dev = ${includedir}/a52dec/*.h ${libdir}/liba52.so
${libdir}/liba52.la ${libdir}/liba52.a
+#FILES_${PN}-dev = ${includedir}/a52dec/*.h ${libdir}/liba52.so
${libdir}/liba52.la
+#FILES_${PN}-staticdev = ${libdir}/liba52.a
This is a bit weird. What's going on here?
As above, trying to ensure that the default bitbake.conf rules would work.
+DEPENDS_lib${PN}-staticdev = lib${PN}-dev (= ${EXTENDPKGV})
As above.
+DEPENDS_lib${PN}-staticdev = lib${PN}-dev (= ${EXTENDPKGV})
Ditto.
All in all I think this patch needs a bit more work. It was quite a big
diff so I only skimmed it rather than reviewing it thoroughly but I
don't think it is quite ready to go in yet. Also, can't a lot of this
be done in bitbake.conf without quite so much recipe patching?
Most of it is done there, I was looking at adding a staticdev.bbclass
that would handle the lib${PN} case generically, as a second phase of this.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] perl-native: fix download url
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/recipes-devtools/perl/perl-native_5.12.3.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/perl/perl-native_5.12.3.bb
b/meta/recipes-devtools/perl/perl-native_5.12.3.bb
index cbb4e78..1751516 100644
--- a/meta/recipes-devtools/perl/perl-native_5.12.3.bb
+++ b/meta/recipes-devtools/perl/perl-native_5.12.3.bb
@@ -9,7 +9,7 @@ PR = r2
LIC_FILES_CHKSUM = file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
file://Artistic;md5=f921793d03cc6d63ec4b15e9be8fd3f8
-SRC_URI = http://ftp.funet.fi/pub/CPAN/src/perl-${PV}.tar.gz \
+SRC_URI = http://ftp.funet.fi/pub/CPAN/src/5.0/perl-${PV}.tar.gz \
file://Configure-multilib.patch \
file://perl-configpm-switch.patch \
file://parallel_build_fix_1.patch \
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Directory Ownership - RFC
A follow-up with this.
For an RPM based system this should be fairly easy to implement. However, after
doing investigation on deb and opkg (related), I'm not sure this is going to
work.
From my investigation, deb formatted packages have no concept of directory
ownership. Directories just exist in the system. Whoever creates the
directories sets the permissions, owner and group. In Debian they have a number
of helpers that ensure the permissions/owner/group of directories are
reasonable, and if there is a mismatch it indicates a bug in the two packages
that has to be corrected.
So at this point, I'm not exactly sure how to continue. If we decide to take
the approach of the Debian systems, we need to likely add some type of QA/Sanity
checking for directories to avoid the sudo problem mentioned below, as well as
add some helper functionality to ensure the base directory set is reasonable at
all times.
We could also do a hybrid approach, use the mechanism mentioned below or
something similar when using RPM packaging, but fall back to just including
everything for Deb / opkg and resolving mismatches when found.
Right now I'm leaning toward the hybrid approach.
* Add tooling that ensures base directories always match a distro policy
- Likely a distro set of owned directories with their modes, owners and
groups
- This would likely need to also be used by the base-files package as well
* Add RPM packaging exceptions that base directories are ignored when packaging
(except when specifically included)
- We would only own directories not in the distro list mentioned above -- or
when the feature was disabled.
- For RPM this helps the installer better order the installation based on
directory dependencies and also eliminates some of the metadata that has to be
carried around
Any comments, suggestions?
On 6/6/11 4:32 PM, Mark Hatle wrote:
I've spoken to a few people on this.. Revision and comments below in-line...
On 6/6/11 11:31 AM, Mark Hatle wrote:
I'm starting to work on an enhancement that will allow (binary) packages
produced from the recipes to clearly own directories. I'm trying to find a
simple enough solution that avoids having to change most recipes, while still
giving the developer and distribution designers flexibility to establish
clear
lines of ownership and system/distribution policy.
Problem
---
Currently directories are owned by whatever packages use them. This works
for
the most part, but can lead to problems when many different packages use the
same directory -- such as /bin, /sbin, /etc, /lib, /usr/lib, etc
When packaging (at least with RPM), the directory permissions, owners and
groups
are automatically included into the package using the existing FILES_pkg
globbing.
The primary issue is that the first package that creates/uses the directory
is
generally the one that sets the permissions, owner and group. For many
directories 0755, root, root is perfectly fine, however other standard
directories may require specific modes, owners and groups... (We recently
had
an issue with sudo creating /var and /var/lib as 0700... which caused
failures
in other packages.)
This causes issues with consistency between recipes as well as potential
security implications on multi-user systems.
Proposed solution
-
Remove the items below
Add a new DIRS variable, similar to the existing FILES, that will specify
the directories for a package to own. By default DIRS = FILES, i.e.
DIRS_${PN}
?= FILES_${PN}
The purpose of this is to automatically inherit the files list and walk the
directories in the same way that existing recipes do it. Resulting in no
change
to most recipes, but also giving a package a clear way to override the values
and specify select directories to own.
A key difference in behavior between the DIRS and FILES methods would be any
directory specified with a / at the end of the name would avoid walking the
directory. For example, DIRS = /usr/share/foo would include foo and all
of
the directories under it. While DIRS = /usr/share/foo/ would simply include
foo, and avoid walking the subdirectories. Q: Is this confusing behavior?
In addition to the above, a new way to exclude directories from being
included
-- even if in the DIRS list is needed to keep things simple.
Remove the items above
This is thought to be way too confusing, as DIRS is the same as FILES 99% of
the
time. Instead, the portion below on the EXCLUDEDIRS would be modified to work
like FILES. It would attempt to use globbing to walk directories and such.
So if you didn't want all of the directories in say ${mandir}, you would add:
${mandir}/*
to the EXCLUDEDIRS.
This would have the effect of excluding all directories in and under the
${mandir} path.
The only difference in behavior between FILES and EXCLUDEDIRS is that
directories specified w/o globbing at the end would be
Re: [OE-core] [CONSOLIDATED PULL 4/4] multiple recipes converted to -staticdev packages
On Fri, 2011-06-10 at 11:36 -0700, Saul Wold wrote:
+FILES_eglibc-dev_append += ${bindir}/rpcgen ${base_libdir}/*.o
${datadir}/aclocal
+FILES_eglibc-staticdev_append += ${libdir}/*.a ${base_libdir}/*.a
You need to make sure that libc_nonshared.a goes into -dev rather than
-staticdev somehow. I didn't immediately spot any mechanism which would
do this, though I haven't tested the package to find out what happens.
+FILES_uclibc-staticdev_append = \
+${libdir}/*_nonshared.a \
+${libdir}/lib*.a \
In similar vein, this doesn't look right.
I think I should be able to remove nonshared from a list.
I'm not entirely sure I understand what you said there. Just to be
totally clear, for eglibc and glibc at least (and I imagine uclibc too),
libc_nonshared.a needs to go into the -dev package and not -staticdev.
So I don't think it should ever be appearing in a FILES...staticdev
list.
This one is a bit odd: it seems to just be dropping the .a files
altogether without introducing a -staticdev package for them.
I thought that maybe the default rule provided in bitbake.conf should
accomplish this since it is FILES_${PN}-staticdev = ${libdir}/*.a
${base_libdir}/*.a
Ah yes, right.
+#FILES_${PN}-dev = ${includedir}/a52dec/*.h ${libdir}/liba52.so
${libdir}/liba52.la
+#FILES_${PN}-staticdev = ${libdir}/liba52.a
This is a bit weird. What's going on here?
As above, trying to ensure that the default bitbake.conf rules would work.
Okay, fair enough. But in that case please don't leave the old bits
commented out.
All in all I think this patch needs a bit more work. It was quite a big
diff so I only skimmed it rather than reviewing it thoroughly but I
don't think it is quite ready to go in yet. Also, can't a lot of this
be done in bitbake.conf without quite so much recipe patching?
Most of it is done there, I was looking at adding a staticdev.bbclass
that would handle the lib${PN} case generically, as a second phase of this.
Can the RDEPENDS_${PN}-staticdev not go in bitbake.conf? That would
avoid all these cut and paste errors that seem to be plaguing that
particular area.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 4/4] multiple recipes converted to -staticdev packages
On (09/06/11 23:26), Saul Wold wrote:
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-bsp/pciutils/pciutils_3.1.7.bb|7 -
.../wireless-tools/wireless-tools_29.bb|9 +--
meta/recipes-core/eglibc/eglibc-package.inc|8 --
meta/recipes-core/eglibc/eglibc_2.12.bb|2 +-
meta/recipes-core/gettext/gettext_0.18.1.1.bb | 16 ++--
meta/recipes-core/glibc/glibc-package.inc |9 +--
meta/recipes-core/glibc/glibc_2.10.1.bb|2 +-
.../meta/external-csl-toolchain_2008q3-72.bb |8 --
meta/recipes-core/uclibc/uclibc.inc| 10 +--
meta/recipes-core/udev/udev-new.inc| 14 ---
meta/recipes-core/udev/udev_164.bb |2 +-
meta/recipes-core/util-linux/util-linux.inc| 11 +++-
meta/recipes-core/util-linux/util-linux_2.19.1.bb |2 +-
meta/recipes-devtools/binutils/binutils.inc|1 -
meta/recipes-devtools/gcc/gcc-4.6.0.inc|2 +-
meta/recipes-devtools/gcc/gcc-package-runtime.inc | 24 ++-
meta/recipes-devtools/gcc/libgcc_4.6.0.bb |2 +-
meta/recipes-devtools/opkg/opkg_0.1.8.bb |8 --
meta/recipes-devtools/opkg/opkg_svn.bb |8 --
meta/recipes-devtools/python/python_2.6.6.bb |2 -
meta/recipes-devtools/rpm/rpm_5.4.0.bb | 18 --
meta/recipes-extended/augeas/augeas.inc|4 ++-
meta/recipes-extended/augeas/augeas_0.8.1.bb |2 +-
meta/recipes-extended/gamin/gamin_0.1.10.bb|9 ---
.../tcp-wrappers/tcp-wrappers_7.6.bb |9 +--
meta/recipes-graphics/cairo/cairo_1.10.2.bb|9 ---
meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb |7 +
meta/recipes-multimedia/liba52/liba52_0.7.4.bb |5 ++-
meta/recipes-support/attr/acl_2.2.51.bb|2 +-
meta/recipes-support/attr/attr_2.4.46.bb |2 +-
meta/recipes-support/attr/ea-acl.inc |8 --
meta/recipes-support/curl/curl_7.21.6.bb |8 --
meta/recipes-support/sqlite/sqlite3.inc|7 +++--
meta/recipes-support/sqlite/sqlite3_3.7.6.2.bb |2 +-
34 files changed, 146 insertions(+), 93 deletions(-)
diff --git a/meta/recipes-bsp/pciutils/pciutils_3.1.7.bb
b/meta/recipes-bsp/pciutils/pciutils_3.1.7.bb
index 4e6d4e1..f2bbe99 100644
--- a/meta/recipes-bsp/pciutils/pciutils_3.1.7.bb
+++ b/meta/recipes-bsp/pciutils/pciutils_3.1.7.bb
@@ -9,7 +9,7 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
DEPENDS = zlib
RDEPENDS_${PN} = ${PN}-ids
-PR = r1
+PR = r2
SRC_URI =
${KERNELORG_MIRROR}/software/utils/pciutils/pciutils-${PV}.tar.bz2 \
file://configure.patch \
@@ -49,9 +49,12 @@ do_install () {
ln -s ../sbin/lspci ${D}${bindir}/lspci
}
-PACKAGES =+ pciutils-ids libpci libpci-dev libpci-dbg
+PACKAGES =+ pciutils-ids libpci libpci-dev libpci-dbg libpci-staticdev
FILES_pciutils-ids = ${datadir}/pci.ids*
FILES_libpci = ${libdir}/libpci.so.*
FILES_libpci-dbg = ${libdir}/.debug
FILES_libpci-dev = ${libdir}/libpci.a ${libdir}/libpci.la
${libdir}/libpci.so \
${includedir}/pci ${libdir}/pkgconfig
+FILES_libpci-staticdev = ${libdir}/libpci.a
+DEPENDS_libpci-staticdev = libpci-dev (= ${EXTENDPKGV})
+
diff --git a/meta/recipes-connectivity/wireless-tools/wireless-tools_29.bb
b/meta/recipes-connectivity/wireless-tools/wireless-tools_29.bb
index 70bf91b..d5b0f98 100644
--- a/meta/recipes-connectivity/wireless-tools/wireless-tools_29.bb
+++ b/meta/recipes-connectivity/wireless-tools/wireless-tools_29.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
SECTION = base
PRIORITY = optional
PE = 1
-PR = r1
+PR = r2
SRC_URI =
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/wireless_tools.29.tar.gz
\
file://man.patch;apply=yes \
@@ -41,14 +41,17 @@ do_install() {
}
PACKAGES = libiw-dbg ifrename-dbg ${PN}-dbg \
-libiw libiw-dev libiw-doc ifrename-doc ifrename ${PN} ${PN}-doc
+libiw libiw-dev libiw-doc libiw-staticdev ifrename-doc ifrename ${PN}
${PN}-doc
FILES_libiw-dbg = ${libdir}/.debug/*.so.*
FILES_ifrename-dbg = ${sbindir}/.debug/ifrename
FILES_libiw = ${libdir}/*.so.*
-FILES_libiw-dev = ${libdir}/*.a ${libdir}/*.so ${includedir}
+FILES_libiw-dev = ${libdir}/*.so ${includedir}
FILES_libiw-doc = ${mandir}/man7
+FILES_libiw-staticdev = ${libdir}/*.a
+RDEPENDS_libiw-staticdev = libiw-dev (= ${EXTENDPKGV})
FILES_ifrename = ${sbindir}/ifrename
FILES_ifrename-doc = ${mandir}/man8/ifrename.8 ${mandir}/man5/iftab.5
FILES_${PN} = ${bindir} ${sbindir}/iw* ${base_sbindir} ${base_bindir}
${sysconfdir}/network
FILES_${PN}-doc = ${mandir}
+
[OE-core] OE-TSC minutes 26-May-2011
OE-TSC minutes 26-May-2011
Attending: Tom, Khem, Koen, Richard, Mark
Apologies: Stefan
Sitting in on drums: Jefro
01) Meeting chair
Jefro
02) Ask for topics
RP - bitbake and override expansion
03) Action items from last week:
-- GNOME discussion to ml (all)
hasn't happened yet
-- release issues to ml, interest in 2011.06 (stefan)
not yet? didn't see it, Tom will start discussion soon if it doesn't appear
discussion here of bitbake, override expansion - take to ml
-- look at migrating bitbake mailing list (RP)
done
04) TSC structure, voting for members, etc.
still waiting on board
RP suggests a less formal IRC meeting weekly
discussion of role of the TSC and this meeting - becoming a SIG?
discussion of Yocto SIG vs. OE SIG
continue discussion
05) Status updates:
- oe-core
meta-oe now has sytemd support
- contrib guidelines
- bsp guidelines
- metadata layer splitting
- infrastructure
Tom King working with Linux Foundation, Jefro helping
Raw Transcript
(12:58:11 PM) fray: ha
(12:58:16 PM) Tartarus: Ha
(12:58:31 PM) Jefro: I'm taking roll call with has
(1:01:44 PM) koen: stefan sent his apologies iirc
(1:01:53 PM) Jefro: ah, ok - thanks
(1:02:06 PM) RP__: ha!
(1:02:43 PM) Tartarus: 4 is a quorum yes?
(1:03:06 PM) fray: ya
(1:03:06 PM) Jefro: I believe so - do you guys want to wait a bit for khem?
(1:03:31 PM) RP__: I'd suggest we start at 5 past
(1:03:37 PM) Tartarus: As I said, I've gotta leave at half past for another
meeting that came up this morning
(1:03:46 PM) Tartarus: but sure, 2 min
(1:03:49 PM) RP__: meantime we can decide on the chair
(1:04:12 PM) Jefro: what do you guys think of appointing a chair for 1 month
or so? not that this takes up a large amount of time, but still
(1:04:24 PM) RP__: Jefro: I'm indifferent
(1:04:34 PM) ***RP__ volunteers if nobody else does
(1:04:39 PM) Jefro: RP__ did it last time
(1:04:48 PM) ***RP__ did do it last week but doesn't really mind
(1:04:55 PM) Jefro: I can take the duty if no one minds a non-voting member
(1:05:11 PM) ***RP__ doesn't object
(1:05:17 PM) Tartarus: same
(1:05:24 PM) Jefro: ok
(1:05:47 PM) Jefro: then as chair I will move on to #2 and ask for any
topics that didn't go out in last email
(1:06:04 PM) Jefro: http://pastebin.com/JADncdCV
(1:06:22 PM) Tartarus: nothing from me
(1:06:36 PM) Jefro: fray?
(1:06:40 PM) fray: yes, here
(1:06:44 PM) fray: sorry.. got interupted
(1:06:44 PM) Jefro: any new topics?
(1:06:51 PM) RP__: I don't have anything to add
(1:06:55 PM) fray: no i didn't see anything from what you sent out
(1:06:59 PM) RP__: ah, maybe one thing
(1:06:59 PM) Jefro: ok
(1:07:06 PM) RP__: bitbake and override expansion
(1:07:15 PM) Jefro: added. anything from koen?
(1:07:25 PM) koen: not really
(1:07:32 PM) Jefro: cool
(1:07:38 PM) Jefro: that effective meeting stuff actually works
(1:07:51 PM) Jefro: moving on to #3, action items - GNOME discussion to
mailing list, did that happen?
(1:08:19 PM) RP__: not yet
(1:09:05 PM) Jefro: ok. stefan was to discuss interest in a 2011.06 release
on the ml, did that happen?
(1:09:13 PM) ***RP__ doesn't know
(1:09:17 PM) Jefro: I didn't see it
(1:09:24 PM) ***RP__ did migrate the bitbake mailing list
(1:09:44 PM) Jefro: very cool
(1:09:56 PM) Jefro: do you want to now launch into discussing bitbake and
override expansion?
(1:10:14 PM) Tartarus: Real quick
(1:10:32 PM) Tartarus: 2011.06 or so is something we have talked about doing
before, but If it doesn't pop up on the ML soon
(1:10:36 PM) Tartarus: I'll try and start it
(1:10:47 PM) RP__: Tartarus: I think the feeling last week was there might
not be a need
(1:10:53 PM) Tartarus: OK
(1:10:56 PM) RP__: Tartarus: but needs public discussion
(1:10:57 PM) Tartarus: I also need to read the minutes
(1:11:10 PM) ***Tartarus is still in un-bury mode
(1:11:12 PM) RP__: re: the override expansion, I just wanted to highlight
the email on the oe-core list
(1:11:15 PM) koen: .03 is working well and time is better spent on oe-core
(1:11:28 PM) RP__: [OE-core] RDEPENDS_${PN} and virtclass-native
(1:11:35 PM) fray: ya.. if there is a desire for .06, it can/should be
done.. but right now I see everything around oe-core and .03
(1:11:36 PM) ***RP__ agrees with koen
(1:11:56 PM) Tartarus: AI, I need to read the minutes of last week ;)
(1:11:58 PM) RP__: fwiw Yocto finds 6 month cycles to be better than 3 month
ones
(1:12:13 PM) RP__: still too much to get done in 6 month ones
(1:12:30 PM) ***Jefro remembers 3-month release cycles at Cygnus back in
early days, with a shudder
(1:12:32 PM) koen: the idea was to do lightweight releases
(1:12:48 PM) ***RP__ knows, I was just commenting
(1:12:58 PM) RP__: DId anyone read that thread I mentioned on the oe-core
list?
(1:13:09 PM) koen: I did
(1:13:26 PM) koen: and it went woosh over my head
(1:13:31 PM) RP__: The reason I ask is that we have some inconsistencies in
what bitbake is doing and they hurt us and are likely going to stop us
cleaning up native.bbclass
(1:13:47 PM) RP__:
[OE-core] OE-TSC minutes 02-Jun-2011
OE-TSC minutes 02-Jun-2011 Attending: Koen, Khem, Richard, Tom, Mark (had to leave early) Apologies: Stefan Agenda: 01) Meeting chair RP 02) Ask for topics infrastructure SIG mailinglist police -- RP to send email to yocto folks khem notes that oe-core ml does not enable patch attachments -- mailman needs to be patched (koen) 03) Action items from last week: -- GNOME discussion to ml (all) still needs to happen -- release issues to ml, interest in 2011.06 (stefan) 04) TSC structure, voting for members, etc. members elections should be done now and we're waiting on the result, then the TSC elections should happen -- discuss one member standing down next week, RP volunteers 05) Status updates: - oe-core - contrib guidelines - bsp guidelines - metadata layer splitting - infrastructure Raw Transcript (12:59:30 PM) Tartarus: roll call? (12:59:34 PM) Jefro: is it just me, or does this channel now log activity for a day or so? (12:59:35 PM) koen: aye (12:59:59 PM) Jefro: I see fray khem koen RP__ Tartarus - a quorum. is stefan still out? (1:00:13 PM) fray: I'm here this minute, but I have to leave... (1:00:32 PM) fray: I'll stick around as long as I can... (1:01:07 PM) khem: I am here (1:01:16 PM) Jefro: fray ok - I think that still leaves 4 (1:01:29 PM) ***RP__ is here (1:01:55 PM) Tartarus: yeah, at least 4, did stefan say anything before hand?? (1:02:27 PM) Jefro: not to me (1:02:46 PM) ***RP__ doesn't remember anything (1:02:55 PM) Tartarus: Give him 'till 5 past? (1:03:19 PM) Tartarus: do we have an agenda up yet? (1:03:21 PM) Jefro: ok. fray, any burning issues you need to discuss before you go? (1:03:26 PM) Jefro: Tartarus I was just building one (1:03:51 PM) ***Jefro 's week has been plagued with hardware issues, both computer and human (1:03:51 PM) fray: Just that I havn't gotten to the final rev of the commit guidelines yet.. I won't be able to get to that until the morning (1:03:59 PM) fray: (but I finally cleared everything else off my schedule) (1:04:10 PM) RP__: fray: lucky you :) (1:04:17 PM) Jefro: fray I was going to get together with you for some guidelines of some kind... (1:04:56 PM) fray: yes we still need to do that.. (1:05:08 PM) fray: Most of my day tomorrow is open, except around noon.. (well as of right now) (1:05:23 PM) Jefro: fray cool, I'll try to contact you relatively early given the time dif (1:05:51 PM) Jefro: anyone have a problem following the same agenda as last time? (1:05:56 PM) Jefro: meeting chair is #1 (1:06:37 PM) fray: ok, I've got to go.. sorry. (1:06:47 PM) Jefro: fray seeya (1:06:48 PM) Tartarus: Jefro, didn't we talk about letting you chair last week? (1:06:51 PM) Tartarus: or am I crazy? (1:06:54 PM) koen: didn't we volunteer Jefro ? (1:07:00 PM) ***RP__ volunteers this week (1:07:02 PM) Jefro: Tartarus you may be crazy.. :) I thought that was for last week (1:07:08 PM) Jefro: http://pastebin.com/JADncdCV is last week's agenda. any modifications or additions? (1:07:08 PM) RP__: jefro did last week I think (1:07:35 PM) koen: tom k ask for an hw IG (1:08:07 PM) RP__: ok, I'll chair (1:08:11 PM) Tartarus: s/hw/infrastructure/ (1:08:17 PM) RP__: agenda looks good apart from listing things we've closed on (1:08:30 PM) ***Jefro notes RP__ as chair (1:08:47 PM) RP__: Koen wants to add the hw IG to the agenda (1:08:53 PM) RP__: anything else for 03? (1:08:56 PM) RP__: we 02? (1:08:59 PM) RP__: er, 02 (1:09:26 PM) Tartarus: not here (1:09:33 PM) koen: yeah, mailinglist police (1:09:44 PM) koen: e.g. stop people from posting oe-core stuff to poky only (1:10:00 PM) RP__: koen: Yocto folks are working on that (1:10:37 PM) ***Jefro notes infrastructure SIG discussion topic (1:10:37 PM) RP__: koen: Most have got the message but those who haven't are getting reminded (1:10:47 PM) khem: and sometimes cross posting too much (1:10:57 PM) khem: patches in particular (1:11:00 PM) RP__: khem: emails have been sent about that too (1:11:20 PM) Jefro: does that cover the mailinglist police topic? (1:11:35 PM) RP__: I will sent out a reminder to the yocto people. I think that covers it unless anyone has anything else to add? (1:11:43 PM) khem: oe-core does not allow attaching patches (1:11:47 PM) khem: is that intentional (1:11:52 PM) RP__: khem: no (1:12:18 PM) RP__: koen: any idea why its doing that (as our mailman admin ;-)) ? (1:12:21 PM) khem: so if I compose email and add patch as attachment it strips out the patch and sends the bare message (1:12:33 PM) khem: more than 1 person has seen this problem (1:12:39 PM) koen: either the mime type is messed up or the attachment is too large (1:12:55 PM) khem: no patches are 1-2 liners (1:13:13 PM) khem: and patch can be generated by git diff (1:13:21 PM) khem: it strips it (1:13:44 PM) koen: the cases I've seen is where the mime type is messed up (1:14:17 PM) koen: since I'm not fluent in mailman, can't we just tell people to not attach patches? (1:14:18 PM) khem: for me same mutt sends it
Re: [OE-core] shadow errors related to login.defs
Op 11 jun 2011, om 00:22 heeft Scott Garman het volgende geschreven: On 06/09/2011 02:25 PM, Koen Kooi wrote: Op 9 jun 2011, om 23:23 heeft Scott Garman het volgende geschreven: On 06/09/2011 01:50 PM, Koen Kooi wrote: Op 3 jun 2011, om 01:50 heeft Scott Garman het volgende geschreven: The passwd, group, and login.defs files in the target sysroot will be used when recipes create custom user and group permissions in their packages. Signed-off-by: Scott Garmanscott.a.gar...@intel.com --- .../base-passwd/base-passwd-3.5.22/login.defs | 386 I'm now getting tons and tons of the following when using shadow: [ 900.349395] grpconv[682]: unknown configuration item `FAILLOG_ENAB' [ 900.357391] grpconv[682]: unknown configuration item `LASTLOG_ENAB' [ 900.364196] grpconv[682]: unknown configuration item `OBSCURE_CHECKS_ENAB' [ 900.371734] grpconv[682]: unknown configuration item `PORTTIME_CHECKS_ENAB' [ 900.381042] grpconv[682]: unknown configuration item `QUOTAS_ENAB' [ 900.387878] grpconv[682]: unknown configuration item `MOTD_FILE' [ 900.394256] grpconv[682]: unknown configuration item `FTMP_FILE' [ 900.400634] grpconv[682]: unknown configuration item `NOLOGINS_FILE' [ 900.407348] grpconv[682]: unknown configuration item `ENV_HZ' [ 900.413452] grpconv[682]: unknown configuration item `PASS_MIN_LEN' [ 900.420104] grpconv[682]: unknown configuration item `SU_WHEEL_ONLY' [ 900.426849] grpconv[682]: unknown configuration item `CRACKLIB_DICTPATH' [ 900.433929] grpconv[682]: unknown configuration item `PASS_CHANGE_TRIES' [ 900.441040] grpconv[682]: unknown configuration item `PASS_ALWAYS_WARN' [ 900.448028] grpconv[682]: unknown configuration item `CHFN_AUTH' [ 900.454376] grpconv[682]: unknown configuration item `ENVIRON_FILE' which seems to be related to the login.defs change. What context is this happening in? Runtime, or during a buildstep? Runtime, during things like adduser and addgroup. I think I'm also seeing it during login, but I need to doublecheck. Hmmm...I'm not running into these errors at all. I'm testing it against core-image-sato, which does not come with shadow by default. So I copy over and install the shadow RPM and start creating users and groups, and I'm not getting any errors back. I've also tried running grpconv, with the same results. I need more information about your setup to duplicate the error. Which image, how was it built, what customizations, etc. I get them with any image that has shadow installed, the easiest way to reproduce would be to build systemd-image with an angstrom setup ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 4/4] multiple recipes converted to -staticdev packages
On 06/10/2011 02:36 PM, Phil Blundell wrote:
On Fri, 2011-06-10 at 11:36 -0700, Saul Wold wrote:
+FILES_eglibc-dev_append += ${bindir}/rpcgen ${base_libdir}/*.o
${datadir}/aclocal
+FILES_eglibc-staticdev_append += ${libdir}/*.a ${base_libdir}/*.a
You need to make sure that libc_nonshared.a goes into -dev rather than
-staticdev somehow. I didn't immediately spot any mechanism which would
do this, though I haven't tested the package to find out what happens.
+FILES_uclibc-staticdev_append = \
+${libdir}/*_nonshared.a \
+${libdir}/lib*.a \
In similar vein, this doesn't look right.
I think I should be able to remove nonshared from a list.
I'm not entirely sure I understand what you said there. Just to be
totally clear, for eglibc and glibc at least (and I imagine uclibc too),
libc_nonshared.a needs to go into the -dev package and not -staticdev.
So I don't think it should ever be appearing in a FILES...staticdev
list.
I understand that, Khem also mentioned it. It a matter of doing some
python RE stuff to drop them from the -staticdev list.
This one is a bit odd: it seems to just be dropping the .a files
altogether without introducing a -staticdev package for them.
I thought that maybe the default rule provided in bitbake.conf should
accomplish this since it is FILES_${PN}-staticdev = ${libdir}/*.a
${base_libdir}/*.a
Ah yes, right.
+#FILES_${PN}-dev = ${includedir}/a52dec/*.h ${libdir}/liba52.so
${libdir}/liba52.la
+#FILES_${PN}-staticdev = ${libdir}/liba52.a
This is a bit weird. What's going on here?
As above, trying to ensure that the default bitbake.conf rules would work.
Okay, fair enough. But in that case please don't leave the old bits
commented out.
Right, that was a goof on my part.
All in all I think this patch needs a bit more work. It was quite a big
diff so I only skimmed it rather than reviewing it thoroughly but I
don't think it is quite ready to go in yet. Also, can't a lot of this
be done in bitbake.conf without quite so much recipe patching?
Most of it is done there, I was looking at adding a staticdev.bbclass
that would handle the lib${PN} case generically, as a second phase of this.
Can the RDEPENDS_${PN}-staticdev not go in bitbake.conf? That would
avoid all these cut and paste errors that seem to be plaguing that
particular area.
Arealy in bitbake.conf, it's the RDEPENDS_lib${PN}-staticdev (note the
'lib' prefix), this is special for a hand full, if I can set up the
inherit than it done that way.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
