[OE-core] perl-native: do_compile failed: pod/buildtoc: no pods at pod/buildtoc line 305
Hi, I got this ERROR today when running bitbake perl-native -c compile against today's latest poky master(I got the same issue when I tried the denzil branch). Any one has the same issue? Build Configuration: BB_VERSION= 1.15.2 TARGET_ARCH = i586 TARGET_OS = linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.2+snapshot-20120507 TUNE_FEATURES = m32 i586 TARGET_FPU= meta meta-yocto= master:3b78ad8041e0ea232b8363e120595cab85b30507 ... | make all PERL_CORE=1 LIBPERL_A=libperl.so LINKTYPE=dynamic | make[1]: Entering directory `/distro/dcui/t/p2/build/tmp/work/x86_64-linux/perl-native-5.14.2-r0/perl-5.14.2/dist/threads-shared' | cp lib/threads/shared.pm ../../lib/threads/shared.pm | ../../miniperl -I../../lib -I../../lib ../../lib/ExtUtils/xsubpp -typemap ../../lib/ExtUtils/typemap shared.xs shared.xsc mv shared.xsc shared.c | ccache gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\1.37\ -DXS_VERSION=\1.37\ -fPIC -I../.. shared.c | Running Mkbootstrap for threads::shared () | chmod 644 shared.bs | rm -f ../../lib/auto/threads/shared/shared.so | ccache gcc -shared -O2 -L/distro/dcui/t/p2/build/tmp/sysroots/x86_64-linux/usr/lib -L/distro/dcui/t/p2/build/tmp/sysroots/x86_64-linux/lib -L/usr/local/lib -fstack-protector shared.o -o ../../lib/auto/threads/shared/shared.so \ |-lpthread \ | | chmod 755 ../../lib/auto/threads/shared/shared.so | cp shared.bs ../../lib/auto/threads/shared/shared.bs | chmod 644 ../../lib/auto/threads/shared/shared.bs | make[1]: Leaving directory `/distro/dcui/t/p2/build/tmp/work/x86_64-linux/perl-native-5.14.2-r0/perl-5.14.2/dist/threads-shared' | LD_LIBRARY_PATH=/distro/dcui/t/p2/build/tmp/work/x86_64-linux/perl-native-5.14.2-r0/perl-5.14.2:/distro/dcui/t/p2/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib:/distro/dcui/t/p2/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64 ./perl -f -Ilib pod/buildtoc --build-toc -q | pod/buildtoc: no pods at pod/buildtoc line 305. | make: *** [pod/perltoc.pod] Error 255 | ERROR: oe_runmake failed Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Do we have a package that installs the kernel headers and config into the target?
Darren Hart wrote on 2012-04-07: On 04/06/2012 12:48 AM, Cui, Dexuan wrote: It seems to me some work is needed at ESDC to account for proper development techniques and not reward sloppy development. Writing maintainable code is an important part of professional software engineers do every day. Rewarding shortcuts and deliverables by any means necessary does students and the industry a disservice. I agree. Actually we delivered a 5-hour Yocto training (consisting of 4 sessions) to the sophomore and junior students, but the feedbacks show many students think, with the limited time, they only want to focus on developing things that could make them win a prize, and they feel Yocto isn't so easy as they expected -- they actually don't care Yocto's powerful capability of customization and they only want a distribution that has integrated every possible library or tool they need... Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Do we have a package that installs the kernel headers and config into the target?
Daniel Lazzari wrote on 2012-04-07: On 04/05/2012 09:41 PM, Cui, Dexuan wrote: Surely, the standard way is: we should write a recipe to cross-compile and install the driver. But this is difficult to the students: 1) They're not familiar with Poky at all, and actually the downloaded wifi driver's code here seems indeed complex. 2) The students only have limited time so they intend to spend most of the time on things that could make them win a prize or money. :-) So this actually makes Yocto less appealing to them though the goal of Yocto is making developing on embedded easy... That said, there are valid use cases, but I don't consider this a particularly high priority at the moment. I'm happy to hear other thoughts on why this should be bumped in prio though. Currently I have suggested them that they should manually copy The kernel headers and .config into the target. Hope this can work around the issue for them. Any chance the students could cross compile the wifi module using an external toolchain? We could try this. But even I didn't try this before, so this needs efforts to find it out. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Do we have a package that installs the kernel headers and config into the target?
Darren Hart wrote on 2012-04-06: On 04/05/2012 09:41 PM, Cui, Dexuan wrote: Darren Hart wrote on 2012-04-06: On 04/05/2012 08:20 PM, Cui, Dexuan wrote: In a typical Linux distribution, there is a build link(or directory) that specifies the directory where the kernel headers and kernel config are put. E.g. in my Ubuntu 11.04, a package linux-headers-2.6.38-8-generic installs .config, include/ and Kconfig into /usr/src/linux-headers-2.6.38-8-generic/ and makes a link /lib/modules/2.6.38-8-generic/build to point to the directory. However, looks in Yocto, we don't have such a package? Do we have a plan to add it? I'm asking the question because in the ESDC contest, the students found in Yocto they couldn't build the wifi driver's source code that was downloaded from realtek.com: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PFid=4 8Level=5Conn=4ProdID=226DownTypeID=3GetDown=falseDownloads =true In Ubuntu, they can build the driver fine. There is an open bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614 Glad to know this is a know bug. I personally think it would be pretty nice if we can fix this bug soon since the students are being frustrated by this... And, in the Build Appliance (self-hosted-image) work, we want to enable the vmware guest's VMware Tools. This also requires the ability to build kernel module in the target. While I understand there are valid use cases, I think this is generally contrary to workflow of the project. We build the OS, it runs on the target. This is building a general purpose OS, and then having it build itself out more. It doesn't feel like an embedded workflow. I totally agree with you. Unluckily we'll have to face an imperfect world: E.g., in the ESDC contest, after the students boot the board with Yocto Linux, they attach a Realtek wifi device and try to build and install the driver. What's bad is: the driver's source code is not integrated into the upstream linux. The students can only run a makefile of the driver tarball to build the driver. To the students' surprise, there is no kernel headers in the running Yocto linux! :-( Surely, the standard way is: we should write a recipe to cross-compile and install the driver. But this is difficult to the students: 1) They're not familiar with Poky at all, and actually the downloaded wifi driver's code here seems indeed complex. 2) The students only have limited time so they intend to spend most of the time on things that could make them win a prize or money. :-) So this actually makes Yocto less appealing to them though the goal of Yocto is making developing on embedded easy... That said, there are valid use cases, but I don't consider this a particularly high priority at the moment. I'm happy to hear other thoughts on why this should be bumped in prio though. Currently I have suggested them that they should manually copy The kernel headers and .config into the target. Hope this can work around the issue for them. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Do we have a package that installs the kernel headers and config into the target?
Cui, Dexuan wrote on 2012-04-06: Darren Hart wrote on 2012-04-06: On 04/05/2012 09:41 PM, Cui, Dexuan wrote: While I understand there are valid use cases, I think this is generally contrary to workflow of the project. We build the OS, it runs on the target. This is building a general purpose OS, and then having it build itself out more. It doesn't feel like an embedded workflow. BTW, my question might be simplified as: If we strictly follow the rule the target OS shouldn't build itself out more, why do we supply a recipe core-image-sato-sdk.bb that can create an image with tools-sdk that includes development tools like gcc? :-) Or, while we recommend the common embedded workflow, we also somewhat support (or tolerate) the way the target builds itself out more? Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] dexuan: more build appliance patches: [Apr 1, 2012]
Koen Kooi wrote on 2012-04-06: Op 5 apr. 2012 om 10:21 heeft Cui, Dexuan dexuan@intel.com het volgende geschreven: Koen Kooi wrote on 2012-04-04: are available in the git repository at: git://git.yoctoproject.org/poky-contrib dcui/master http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=dcui/master Dexuan Cui (5): genext2fs: support large files and filesystems without using large amounts of memory I've merged these to master, thanks. Whilst I'm reluctant to do so at this point in the release process for such major changes, I think in this case it does make sense since the genext2fs changes seem to fix a number of problematic issues. I'm getting: | genext2fs: set_file_size: ftruncate: Invalid argument Trying to see why that happens and find out how to fix it. Hi Koen, did you get the cause? This is the prototype of the function: int ftruncate(int fd, off_t length); I suppose you're using a 32-bit building host so the off_t in your host can't exceed 4G? no, 64bit host Strange... I use x86-64 Ubuntu 11.04 and x86-64 openSUSE 11.4 and I don't see the issue. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] self-hosted-image: decrease reserved space to 0.5%
Hi Paul,
This reminds me of something slightly similar:
Can we enable the -z option of genext2fs in IMAGE_CMD_ext3()?
For a 40G image, this would save the building host many giga bytes, and make
the conversion from .ext3 to .hdddirect faster.
Thanks,
-- Dexuan
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Paul Eggleton
Sent: Thursday, April 05, 2012 4:08 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 1/1] self-hosted-image: decrease reserved space to
0.5%
The default amount of reserved space for ext2/3 is 5% - this amounts to
about 2GB of a 40GB filesystem that the builder user can't make use of.
We don't need this much reserved so peg it back to 0.5% which should be
more than enough.
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/recipes-core/images/self-hosted-image.bb |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/images/self-hosted-image.bb
b/meta/recipes-core/images/self-hosted-image.bb
index d2faa66..84c5faf 100644
--- a/meta/recipes-core/images/self-hosted-image.bb
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -4,7 +4,7 @@ LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de
20420
-PR = r9
+PR = r10
CORE_IMAGE_EXTRA_INSTALL = \
task-self-hosted \
@@ -25,6 +25,11 @@ inherit core-image
SRCREV = 8691a588267472eb5a32b978a0eb9ddfd0c91733
SRC_URI = git://git.yoctoproject.org/poky;protocol=git
+IMAGE_CMD_ext3_append () {
+ # We don't need to reserve much space for root, 0.5% is more than
enough
+ tune2fs -m 0.5 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3
+}
+
fakeroot do_populate_poky_src () {
# Because fetch2's git's unpack uses -s cloneflag, the unpacked git repo
# will become invalid in the target.
--
1.7.5.4
___
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] [PATCH 2/3] xterm: port the recipe from OE and upgrade to v278
Paul Eggleton wrote on 2012-04-06: On Friday 06 April 2012 00:10:12 Dexuan Cui wrote: The recipe is ported from OE: http://git.openembedded.org/openembedded/tree/recipes/xorg-app/xterm_2 66.bb I upgraded it from v266 to v278. I added LICENSE, LIC_FILES_CHKSUM and updated SRC_URI checksums. I think it's unfortunate we have to pull in xterm just for the sake of showing the qemu output - can we not use matchbox-terminal for this? Thanks for the suggestion! I suppose we could, but we need to fix bitbake as it uses /usr/bin/xterm by hardcode... If we have to have it, Dexuan can you please compare this to the meta-oe xterm recipe as that is likely to be more up-to-date than the one in OE-Classic? Ok, I'll investigate this. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] dexuan: more build appliance patches: [Apr 1, 2012]
Koen Kooi wrote on 2012-04-04: are available in the git repository at: git://git.yoctoproject.org/poky-contrib dcui/master http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=dcui/master Dexuan Cui (5): genext2fs: support large files and filesystems without using large amounts of memory I've merged these to master, thanks. Whilst I'm reluctant to do so at this point in the release process for such major changes, I think in this case it does make sense since the genext2fs changes seem to fix a number of problematic issues. I'm getting: | genext2fs: set_file_size: ftruncate: Invalid argument Trying to see why that happens and find out how to fix it. Hi Koen, did you get the cause? This is the prototype of the function: int ftruncate(int fd, off_t length); I suppose you're using a 32-bit building host so the off_t in your host can't exceed 4G? We do need to test it in a 32-bit host and at least we need to document the issue. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Do we have a package that installs the kernel headers and config into the target?
In a typical Linux distribution, there is a build link(or directory) that specifies the directory where the kernel headers and kernel config are put. E.g. in my Ubuntu 11.04, a package linux-headers-2.6.38-8-generic installs .config, include/ and Kconfig into /usr/src/linux-headers-2.6.38-8-generic/ and makes a link /lib/modules/2.6.38-8-generic/build to point to the directory. However, looks in Yocto, we don't have such a package? Do we have a plan to add it? I'm asking the question because in the ESDC contest, the students found in Yocto they couldn't build the wifi driver's source code that was downloaded from realtek.com: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PFid=48Level=5Conn=4ProdID=226DownTypeID=3GetDown=falseDownloads=true In Ubuntu, they can build the driver fine. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] libxaw: move it from meta-demoapps/ into meta/ and upgrade it to 1.0.10
Martin Jansa wrote on 2012-04-06: On Fri, Apr 06, 2012 at 12:10:11AM +0800, Dexuan Cui wrote: Add LICENSE and LIC_FILES_CHKSUM; Add SRC_URI checksums; Remove do_install_append since 1.0.10's Makefile has done the work. This is also in meta-oe meta-openembedded/meta-oe/recipes-graphics/xorg-lib/libxaw_1.0.9.bb as with xterm, can you compare and merge those changes? Hi Martin, thanks for the suggestion! Now I try to avoid introducing new recipes at this phase of release cycle. I'm trying to use a poky variable to tell bitbake which terminal should be used(currently the Run image functionality in hob uses /usr/bin/xterm by hardcode). Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Do we have a package that installs the kernel headers and config into the target?
Darren Hart wrote on 2012-04-06: On 04/05/2012 08:20 PM, Cui, Dexuan wrote: In a typical Linux distribution, there is a build link(or directory) that specifies the directory where the kernel headers and kernel config are put. E.g. in my Ubuntu 11.04, a package linux-headers-2.6.38-8-generic installs .config, include/ and Kconfig into /usr/src/linux-headers-2.6.38-8-generic/ and makes a link /lib/modules/2.6.38-8-generic/build to point to the directory. However, looks in Yocto, we don't have such a package? Do we have a plan to add it? I'm asking the question because in the ESDC contest, the students found in Yocto they couldn't build the wifi driver's source code that was downloaded from realtek.com: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PFid=4 8Level=5Conn=4ProdID=226DownTypeID=3GetDown=falseDownloads =true In Ubuntu, they can build the driver fine. There is an open bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614 Glad to know this is a know bug. I personally think it would be pretty nice if we can fix this bug soon since the students are being frustrated by this... And, in the Build Appliance (self-hosted-image) work, we want to enable the vmware guest's VMware Tools. This also requires the ability to build kernel module in the target. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk
Cui, Dexuan wrote on 2012-03-31: Cui, Dexuan wrote on 2012-03-31: Paul Eggleton wrote on 2012-03-30: On Monday 26 March 2012 22:42:54 Saul Wold wrote: Updated comments per Darren's request, added cleanup to image-types to only use one -i (inode-count) parameter. Sau! The following changes since commit 644b7503c37fd73730dd3d7841463b158b8934ed: guile: Deal with hardcoded path issues (2012-03-27 00:28:41 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib sgw/self http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log / ?h =sgw/ self So these patches have been merged now; I updated to latest master and re-ran bitbake self-hosted-image; unfortunately the output doesn't appear to be usable. I don't know what has gone wrong but during boot there are complaints that the filesystem is corrupt: SYSLINUX 4.03 2010-10-22 EDD Copyright (C) 1994-2010 H. Peter Anvin et al EXT3-fs error (device hda2): ext3_lookup: deleted inode referenced: 581713 EXT3-fs error (device hda2): ext3_lookup: deleted inode referenced: 610383 Kernel panic - not syncing: no init found. Try passing init= option to kernel. Running e2fsck -fn on the rootfs.ext3 file shows quite a number of errors. There were no unusual errors in the log.do_rootfs. Hi Paul, I can reproduce the same I issue, too... I'll try to look into this, but at the first glance, I don't know what has gone wrong, either... Can we make a conclusion the current genext2fs is buggy here when creating a big image(e.g., 4GB)? Hi Paul, I believe this is true: genext2fs-1.4.1 can create a corrupt file system when the size of the file system exceeds some limit. e.g., when I create an image of 2.8GB, the image can be mounted properly, but when I create an image of about 4.5GB(yes, I found genext2fs-1.4.1 is actually able to create an image of 4.5GB; I also found it's unable to create an image of about 5.5GB, always reporting couldn't allocate a block (no free space)), the generated image can show something like this when it's booted: EXT3-fs error (device hda2): ext3_lookup: deleted inode referenced... However, with Corey's patches (from the genext2fs's mailing list) applied, I can't see the issues. You can try the patch too to see if this would also works for you: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/masterid=c76f9db84c2eabe0bf704b253a957f695f421936 Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] genext2fs: support large files and filesystems without using large amounts of memory
BTW, we can see http://sourceforge.net/mailarchive/message.php?msg_id=29071716 for what Corey, the author of the patches to genext2fs, said: We (MontaVista) and our customers have been using these patches in production since the time I sent them out and we haven't had any issues So, the quality of the patches seems pretty good. Thanks, -- Dexuan -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Dexuan Cui Sent: Monday, April 02, 2012 12:10 AM To: openembedded-core@lists.openembedded.org Subject: [OE-core] [PATCH 1/5] genext2fs: support large files and filesystems without using large amounts of memory update_to_1.95.patch was generated by making a diff bewteen the 1.4.1 release and the latest 1.9.5 version in the cvs repo: http://genext2fs.cvs.sourceforge.net/viewvc/genext2fs/genext2fs/genext2fs.c? revision=1.95 The patches 0001-0019 come from mailing list of genext2fs-devel http://sourceforge.net/mailarchive/forum.php?forum_name=genext2fs-devel; max_rows=100style=flatviewmonth=201106 Signed-off-by: Dexuan Cui dexuan@intel.com --- ...01-Fix-warnings-remove-some-unused-macros.patch | 72 ++ .../0002-Add-put_blk-and-put_nod-routines.patch| 1123 .../0003-Add-get_blkmap-and-put_blkmap.patch | 222 ...lker-for-walking-through-directory-entrie.patch | 357 +++ ...05-Make-filesystem-struct-not-an-overloay.patch | 374 +++ ...0006-Improve-the-efficiency-of-extend_blk.patch | 272 + ...ove-hdlinks-into-the-filesystem-structure.patch | 175 +++ ...t-the-creation-of-the-filesystem-structur.patch | 95 ++ ...e-byte-swapping-into-the-get-put-routines.patch | 421 ...rt-over-to-keeping-the-filesystem-on-disk.patch | 839 +++ ...les-into-the-filesystem-a-piece-at-a-time.patch | 103 ++ ...upport-large-file-support-and-rework-hole.patch | 211 .../0013-Add-volume-id-support.patch | 86 ++ ...014-Remove-unneeded-setting-of-s_reserved.patch | 28 + ...-Rework-creating-the-lost-found-directory.patch | 57 + ...ix-the-documentation-for-the-new-L-option.patch | 29 + .../0017-Fix-file-same-comparison.patch| 30 + ...andle-files-changing-while-we-are-working.patch | 89 ++ ...ke-sure-superblock-is-clear-on-allocation.patch | 42 + .../genext2fs-1.4.1/fix-nbblocks-cast.patch| 18 +- .../genext2fs/genext2fs-1.4.1/update_to_1.95.patch | 119 ++ meta/recipes-devtools/genext2fs/genext2fs_1.4.1.bb | 24 +- 22 files changed, 4776 insertions(+), 10 deletions(-) ... ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] genext2fs: support large files and filesystems without using large amounts of memor
Darren Hart wrote on 2012-03-30: On 03/29/2012 03:07 PM, Richard Purdie wrote: On Thu, 2012-03-29 at 00:51 +0800, Dexuan Cui wrote: Hi RP, Saul, Paul, Darren, Mark, Josh and joaohf and all, please comment. Let's figure out if this big patch is acceptable or not... With this patch, I can successfully create a 8.5GB .ext3 file with genext2fs. The speed is slow -- I spent about 1.5 hours. If these patches solved all the problems and made things work wonderfully I'd probably say we'd take them. Unfortunately I don't consider taking 1.5 hours to build am 8GB filesystem wonderful, its rather worrying and I don't think its performing any where need fast enough for our needs :(. Patching genext2fs at this point in the cycle is a rather risky undertaking too and I'm getting very concerned about this. I agree. I understand the risk. But, BTW, I personally tend to think the quality of the patches (which Come from the genext2fs mailing list) are good: please see my test results http://sourceforge.net/mailarchive/message.php?msg_id=29062014 We might have to look at alternative ways to solve this problem. I think Darren said he might help look at this and has some other ideas. Darren? Without having looked into this very far, I seem to recall this was generating sparse files. This means every time we copy something into the filesystem it has to allocate the space on the drive. This is great for building big filesystems that will be mostly empty - but for big filesystems that we plan to mostly populate, I believe we would be better off doing pre-allocation (I'm taking this from my experience creating VMs in virtmanager). However, since using dd to create the file would require mounting it in order to copy files across (and we want to avoid requiring root permissions during build), this may not be an option. Have we tried without the -z option? (-z allows holes in files - I presume this means sparse files). I tried the -z option of genext2fs, but the speed to create the filesystem is the same. Depending on how much of the 8.5 GB image we are filling, we may get a significant speed increase by first generating a smaller image and then using resize2fs to grow it to the desired size (referencing http://landley.livejournal.com/47024.html). A quick test without passing an initial rootfs showed no difference between -z and no -z. It may still be worth trying with the actual population to see if that makes a difference. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk
Paul Eggleton wrote on 2012-03-30: On Monday 26 March 2012 22:42:54 Saul Wold wrote: Updated comments per Darren's request, added cleanup to image-types to only use one -i (inode-count) parameter. Sau! The following changes since commit 644b7503c37fd73730dd3d7841463b158b8934ed: guile: Deal with hardcoded path issues (2012-03-27 00:28:41 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib sgw/self http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/ ?h =sgw/ self So these patches have been merged now; I updated to latest master and re-ran bitbake self-hosted-image; unfortunately the output doesn't appear to be usable. I don't know what has gone wrong but during boot there are complaints that the filesystem is corrupt: SYSLINUX 4.03 2010-10-22 EDD Copyright (C) 1994-2010 H. Peter Anvin et al EXT3-fs error (device hda2): ext3_lookup: deleted inode referenced: 581713 EXT3-fs error (device hda2): ext3_lookup: deleted inode referenced: 610383 Kernel panic - not syncing: no init found. Try passing init= option to kernel. Running e2fsck -fn on the rootfs.ext3 file shows quite a number of errors. There were no unusual errors in the log.do_rootfs. Hi Paul, I can reproduce the same I issue, too... I'll try to look into this, but at the first glance, I don't know what has gone wrong, either... Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk
Cui, Dexuan wrote on 2012-03-31: Paul Eggleton wrote on 2012-03-30: On Monday 26 March 2012 22:42:54 Saul Wold wrote: Updated comments per Darren's request, added cleanup to image-types to only use one -i (inode-count) parameter. Sau! The following changes since commit 644b7503c37fd73730dd3d7841463b158b8934ed: guile: Deal with hardcoded path issues (2012-03-27 00:28:41 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib sgw/self http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log / ?h =sgw/ self So these patches have been merged now; I updated to latest master and re-ran bitbake self-hosted-image; unfortunately the output doesn't appear to be usable. I don't know what has gone wrong but during boot there are complaints that the filesystem is corrupt: SYSLINUX 4.03 2010-10-22 EDD Copyright (C) 1994-2010 H. Peter Anvin et al EXT3-fs error (device hda2): ext3_lookup: deleted inode referenced: 581713 EXT3-fs error (device hda2): ext3_lookup: deleted inode referenced: 610383 Kernel panic - not syncing: no init found. Try passing init= option to kernel. Running e2fsck -fn on the rootfs.ext3 file shows quite a number of errors. There were no unusual errors in the log.do_rootfs. Hi Paul, I can reproduce the same I issue, too... I'll try to look into this, but at the first glance, I don't know what has gone wrong, either... Can we make a conclusion the current genext2fs is buggy here when creating a big image(e.g., 4GB)? Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/6] self-hosted-image: pre-populate the builder user with poky source
Saul Wold wrote on 2012-03-29: On 03/28/2012 08:35 AM, Cui, Dexuan wrote: Hi Saul, Did you test bitbake core-image-minimal inside the vmware guest? I got the following ERROR immediately: Pseudo is not functioning correctly, which will cause failures I suspect in the guest, pseudo is not setup properly? This should be addressed by the 5/6 patch that adds the correct PSEUDO_* setup into the minix session script. I guess that you tried to run this on the command line and as you might notice I modified the bashrc, but for some reason that did not get picked up when the shell started up, I think we need to force the builder user to get /bin/bash as a shell not /bin/sh Hi Saul, I'm sorry -- this is actually a false alarm -- I didn't use the updated branch... With the latest poky master, bitbake in cmd line can work fine. Hob is automatically started and can work fine, too. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk
Hi joaohf, Thank for the hint! I have got the patches from genext2fs-devel mailing list and did some tests: I can successfully create a .ext2 file of 8.5GB with genext2fs now! I’ll send an update to the genext2fs recipe later. Thanks, -- Dexuan From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Jo?o Henrique Freitas Sent: Wednesday, March 28, 2012 4:46 AM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk Hi, I guess we can just put that in the docs for now. For future improvement though I wonder if we can trick the fetcher into just pulling across the current files into the rootfs. I'll put that on my todo list for later. The following thread suggest a patch to fix it: http://sourceforge.net/mailarchive/forum.php?thread_name=1307458172.10974.64.camel%40skunkforum_name=genext2fs-devel Thanks. -- --- João Henrique Freitas - joaohf_at_gmail.comhttp://joaohf_at_gmail.com Campinas-SP-Brasil BSD051283 LPI 1 http://www.joaohfreitas.eti.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/6] self-hosted-image: pre-populate the builder user with poky source
Hi Saul,
Did you test bitbake core-image-minimal inside the vmware guest?
I got the following ERROR immediately:
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker
(see sanity.conf).
Following is the list of potential problems / advisories:
Pseudo is not functioning correctly, which will cause failures during
package installation. Please check your configuration.
ERROR: Execution of event handler 'check_sanity_eventhandler' failed
I suspect in the guest, pseudo is not setup properly?
Thanks,
-- Dexuan
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.com]
Sent: Tuesday, March 27, 2012 1:43 PM
To: openembedded-core@lists.openembedded.org
Cc: Cui, Dexuan
Subject: [PATCH 1/6] self-hosted-image: pre-populate the builder user with
poky source
From: Dexuan Cui dexuan@intel.com
This patch installs the poky source into the /home/builder/poky/ of the
self-hosted-image.
This makes the user of self-hosted-image easier to start a build.
I think the recent poky master is stable enough, so I specify a commit number
by SRCREV -- we may want to update this number before releasing 1.2.
This patch fixes [YOCTO #2065]
Signed-off-by: Dexuan Cui dexuan@intel.com
Added code for supporting target based pseudo fixed indentation
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-core/images/self-hosted-image.bb | 41
+++-
1 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/images/self-hosted-image.bb
b/meta/recipes-core/images/self-hosted-image.bb
index d56c2cb..5aa670d 100644
--- a/meta/recipes-core/images/self-hosted-image.bb
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -4,7 +4,7 @@ LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de
20420
-PR = r5
+PR = r6
CORE_IMAGE_EXTRA_INSTALL = \
task-self-hosted \
@@ -13,7 +13,10 @@ CORE_IMAGE_EXTRA_INSTALL = \ IMAGE_FEATURES
+= x11-mini package-management
# Ensure there's enough space to do a core-image-minimal build, with
rm_work enabled -IMAGE_ROOTFS_EXTRA_SPACE = 2621440
+IMAGE_ROOTFS_EXTRA_SPACE = 1048576
+#IMAGE_ROOTFS_EXTRA_SPACE = 2621440
+#IMAGE_ROOTFS_EXTRA_SPACE = 20971520
+#IMAGE_ROOTFS_EXTRA_SPACE = 5242880
# Do a quiet boot with limited console messages APPEND += quiet
@@ -21,3 +24,37 @@ APPEND += quiet
IMAGE_FSTYPES = vmdk
inherit core-image
+
+SRCREV = 26a46938d3ea1821e7bec4fa6cc8379babad238b
+SRC_URI = git://git.yoctoproject.org/poky;protocol=git
+
+fakeroot do_populate_poky_src () {
+ # Because fetch2's git's unpack uses -s cloneflag, the unpacked git repo
+ # will become invalid in the target.
+ rm -rf ${WORKDIR}/git/.git
+ rm -f ${WORKDIR}/git/.gitignore
+
+ cp -Rp ${WORKDIR}/git ${IMAGE_ROOTFS}/home/builder/poky
+
+ mkdir -p ${IMAGE_ROOTFS}/home/builder/poky/build/conf
+ cp -Rp ${DL_DIR} ${IMAGE_ROOTFS}/home/builder/poky/build
+ echo /usr/bin
${IMAGE_ROOTFS}/home/builder/poky/build/pseudodone
+ echo BB_NO_NETWORK = \1\
${IMAGE_ROOTFS}/home/builder/poky/build/conf/auto.conf
+ echo INHERIT += \rm_work\
${IMAGE_ROOTFS}/home/builder/poky/build/conf/auto.conf
+mkdir -p ${IMAGE_ROOTFS}/home/builder/pseudo
+echo export PSEUDO_PREFIX=/usr
${IMAGE_ROOTFS}/home/builder/.bashrc
+echo export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo
${IMAGE_ROOTFS}/home/builder/.bashrc
+echo export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64
+${IMAGE_ROOTFS}/home/builder/.bashrc
+
+chown builder.builder ${IMAGE_ROOTFS}/home/builder/pseudo
+
+ chown -R builder.builder ${IMAGE_ROOTFS}/home/builder/poky }
+
+IMAGE_PREPROCESS_COMMAND += do_populate_poky_src;
+
+python do_get_poky_src () {
+bb.build.exec_func('base_do_fetch', d)
+bb.build.exec_func('base_do_unpack', d) } addtask do_get_poky_src
+before do_rootfs
--
1.7.7.6
___
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] self-hosted-image: pre-populate the builder user with poky source
Koen Kooi wrote on 2012-03-18: Op 18 mrt. 2012, om 06:41 heeft Dexuan Cui het volgende geschreven: [YOCTO #2065] What does that mean? Sorry, I should have made it more clear. :-) It means bug 2065 is addressed by the patch: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2065 Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] self-hosted-image: pre-populate the builder user with poky source
Koen Kooi wrote on 2012-03-18: Op 18 mrt. 2012, om 10:52 heeft Cui, Dexuan het volgende geschreven: Koen Kooi wrote on 2012-03-18: Op 18 mrt. 2012, om 06:41 heeft Dexuan Cui het volgende geschreven: [YOCTO #2065] What does that mean? Sorry, I should have made it more clear. :-) It means bug 2065 is addressed by the patch: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2065 So add that and (part of) the bug description into the commit message OK, please review and use the updated commit(only the commit description was updated): http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/selfid=0882b5e0adb05d4f950c721fcb80b4cff42ce079 Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] image_types: ensure .rootfs.ext3 is created before vmdk is created.
Saul Wold wrote on 2012-03-09: On 03/08/2012 11:19 PM, Dexuan Cui wrote: In the case of self-hosted-image.bb, IMAGE_FSTYPES = vmdk, so the variables alltypes and subimages don't contain ext3, and .rootfs.ext3 won't be created, and finally the generated .hddimg and .vmdk don't have an actual rootfs -- the size of the .vmdk file is only about 9MB. [YOCTO #2067] Signed-off-by: Dexuan Cuidexuan@intel.com Nice Catch! Acked-by: Saul Wold s...@linux.intel.com BTW, I didn't find the bug in my previous test because I didn't build From scratch, so actually I already had a file tmp/deploy/image/self-hosted-image-qemux86.ext3, and according to bootimg.bbclass's populate(), we used it -- but we should use a new .ext3 file. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/1] self-hosted-image: generate the .hdddirect and .vmdk image files
Darren Hart wrote on 2012-01-17:
On 01/17/2012 01:35 AM, Cui, Dexuan wrote:
Darren Hart wrote on 2012-01-13:
So, I think here we should change the = to ?= like the below -APPEND
= root=/dev/sda2
+APPEND ?= root=/dev/sda2
And in meta/conf/machine/include/qemu.inc, I can add a line APPEND =
root=/dev/hda2.
Does this sound ok?
That seems appropriate to me.
I decide not to change the line in boot-directdisk.bbclass and I think adding
a line
APPEND_${MACHINE} = root=/dev/hda2
in qemu.inc should be ok.
This is because ?= can have some side effort, i.e., in the case of atom, in
atom-pc.conf, APPEND is already assigned a value that isn't suitable for
syslinux.
TIMEOUT = 10
SYSLINUXCFG = ${HDDDIR}/syslinux.cfg
SYSLINUXMENU = ${HDDDIR}/menu
@@ -50,6 +51,7 @@ build_boot_dd() {
install -d ${HDDDIR}
install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage
${HDDDIR}/vmlinuz
+ install -m 0644 ${S}/syslinux.cfg ${HDDDIR}/syslinux.cfg
Hrm... syslinux.cfg wasn't installed before at all?
I'm not very clear about the history, but according to
syslinux.bbclass, iso and hddimg do invoke syslinux_populate, but
hdddirect doesn't -- I suppose hdddirect doesn't need all the
functionality of build_syslinux_menu, so it tries to install the
files itself, and unluckily it misses syslinux.cfg. Now there is no
user of .hdddirect in poky, and I don't know there is any actual
external user. This may explain why nobody complains. :-)
This sounds like an opportunity to modularize and reuse to me.
Agree. We should try to improve the code here in future.
install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys
${HDDDIR}/ldlinux.sys
BLOCKS=`du -bks ${HDDDIR} | cut -f 1` @@ -83,6 +85,12 @@
build_boot_dd() { cd ${DEPLOY_DIR_IMAGE} rm -f
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect ln -s
${IMAGE_NAME}.hdddirect
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
+
+ if [ ${NOVMDK} != 1 ] ; then
+ ${STAGING_BINDIR_NATIVE}/qemu-img convert -O vmdk \
You've added a dependency on qemu-img, please add the appropriate
DEPENDS above.
I have added the line in my patch:
do_bootdirectdisk[depends] += qemu-native:do_populate_sysroot
I think this is enough?
Need I add DEPENDS += qemu-native, too?
No, I don't think so. Is do_populate_sysroot the right task? That
would be my guess as well, but we should be confident.
I think it should be ok: do_populate_sysroot installs the utility qemu-img
into the sysroot and this is all we need.
+ ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect \
+ ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk + fi
}
python do_bootdirectdisk() {
Darren Hart wrote on 2012-01-13:
On 01/10/2012 10:53 AM, Dexuan Cui wrote:
A couple additional thoughts about the boot-directdisk class in general:
So build_boot_dd needs a careful audit to ensure the various dd
commands do not stomp on eachother iirc, the dd of syslinux/mbr.bin
was stomping on the partition table or some such.
Hi Darren, The dd-ing of mbr.bin actually writes only the first 440
bytes of $IMAGE -- please note the size of mbr.bin(generated by the
recipe syslinux, I think) is 440 bytes rather than 512 bytes. :-) I
think 440 is safe enough because it's even smaller than 512-16*4=448
bytes.
Also note that it uses mkdosfs -d which we have purged (and it
aint coming back if my NACK is worth anything ;-). Sounds like we
need to abstract building msdos images into an msdosfs.bbclass. No
reason to
Would you volunteer to make a msdosfs.bbclass? :-)
Not in the near future unfortunately, I'm heavily overloaded as it is.
That said, please open a bug and we can find an appropriate owner.
Ok, I opened a bug http://bugzilla.pokylinux.org/show_bug.cgi?id=1913.
duplicate all the fatfs overhead calculations I did yesterday (See
the patch I sent yesterday to bootimg.bbclass).
I agree.
I see your patch has been in poky master now.
If you could help to make msdosfs.bbclass, I would appreciate that a lot.
Now I'm stick in something else and I'm afraid I can't start to work
on this immediately. :-(
Understood. Open the bug and explain what's needed and we'll
prioritize and assign it. There may also be others who would like this
feature that would be willing to pick up the task.
Hi Darren,
Thanks for all the comments!
I'll send out the v2 patch and Cc you.
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/1][v2] self-hosted-image: generate the .hdddirect and .vmdk image files
Saul Wold wrote on 2012-01-19:
On 01/18/2012 06:18 AM, Dexuan Cui wrote:
The self-hosted-image work needs a live-bootable and r/w-able image
format. The existing .iso isn't ok since it's readonly. The existing
.hddimg is not a good choice, since it has a two-option(boot, install)
syslinux function that we don't need: we don't hope a user to be
potentially able to install, and I think it may be not suitble to
hack build_hddimg to hide the install? Moreever, .hddimg is not that
compatibible with some devices and we hope to have the most
compatibility.
Please use a spell checker here
suitable
Moreover
compatible
I'm very sorry about this... I'll be more careful in future. :-)
So I think the .hdddirect format is a good choice and I made this patch
to adopt it and also enhanced boot-directdisk.bbclass to generate .vmdk
image so we can run it on vmware, too. BTW, currently self-hosted-image
is the only user of boot-directdisk.bbclass; with the adoption of
.hdddirect and .vmdk formats, a user can still use IMAGE_FSTYPES +=
'live' to generate the .iso and .hddimg format.
Signed-off-by: Dexuan Cuidexuan@intel.com
---
meta/classes/boot-directdisk.bbclass |8
meta/conf/machine/include/qemu.inc|2 ++
meta/recipes-core/images/self-hosted-image.bb | 11 +--
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/meta/classes/boot-directdisk.bbclass
b/meta/classes/boot-directdisk.bbclass index 8879ba8..7f14225 100644
--- a/meta/classes/boot-directdisk.bbclass +++
b/meta/classes/boot-directdisk.bbclass @@ -24,6 +24,7 @@
do_bootdirectdisk[depends] += dosfstools-native:do_populate_sysroot \
syslinux-native:do_populate_sysroot \
parted-native:do_populate_sysroot \
mtools-native:do_populate_sysroot +do_bootdirectdisk[depends] +=
qemu-native:do_populate_sysroot
PACKAGES =
EXCLUDE_FROM_WORLD = 1
@@ -50,6 +51,7 @@ build_boot_dd() {
install -d ${HDDDIR}
install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage
${HDDDIR}/vmlinuz
+install -m 0644 ${S}/syslinux.cfg ${HDDDIR}/syslinux.cfg
install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys
${HDDDIR}/ldlinux.sys
BLOCKS=`du -bks ${HDDDIR} | cut -f 1` @@ -83,6 +85,12 @@
build_boot_dd() { cd ${DEPLOY_DIR_IMAGE} rm -f
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect ln -s
${IMAGE_NAME}.hdddirect
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
+
+if [ ${NOVMDK} != 1 ] ; then
Why make this a double negative, Why not have a CREATE_VMDK check?
+${STAGING_BINDIR_NATIVE}/qemu-img convert -O vmdk \
+${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect \
+${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk
+fi
}
python do_bootdirectdisk() {
diff --git a/meta/conf/machine/include/qemu.inc
b/meta/conf/machine/include/qemu.inc index 3cebfab..a5b563b 100644 ---
a/meta/conf/machine/include/qemu.inc +++
b/meta/conf/machine/include/qemu.inc @@ -5,6 +5,8 @@ MACHINE_FEATURES =
kernel26 apm alsa pcmcia bluetooth irda usbgadget screen
IMAGE_FSTYPES ?= tar.bz2 ext3
+APPEND_${MACHINE} = root=/dev/hda2
+
I thought this was to become ?=
There is some side effort with ?=.
Darren expressed his concern in a later mail. I have to think more about this.
ROOT_FLASH_SIZE = 280
# Don't include kernels in standard images diff --git
a/meta/recipes-core/images/self-hosted-image.bb
b/meta/recipes-core/images/self-hosted-image.bb
index 111c057..df6c81f 100644
--- a/meta/recipes-core/images/self-hosted-image.bb
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -6,6 +6,13 @@ POKY_EXTRA_INSTALL = \
IMAGE_FEATURES += x11-mini
-inherit core-image +# Needed by boot-directdisk +ROOTFS ?=
${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.ext3
-PR = r2
+inherit core-image boot-directdisk
+
+do_bootimg[depends] += ${INITRD_IMAGE}:do_rootfs
+do_bootimg[depends] += ${IMAGE_BASENAME}:do_rootfs
+do_bootdirectdisk[depends] += ${PN}:do_rootfs
+
+PR = r3
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/1][v2] self-hosted-image: generate the .hdddirect and .vmdk image files
Saul Wold wrote on 2012-01-19:
+if [ ${NOVMDK} != 1 ] ; then
Why make this a double negative, Why not have a CREATE_VMDK check?
+${STAGING_BINDIR_NATIVE}/qemu-img convert -O vmdk \
+${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect \
+${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk
+fi
}
Hi Saul,
I thought it's better to create .vmdk by default.
So do you think this is better?
if [ ${CREATE_VMDK} == 1 ] ; then
#create the .vmdk image.
fi
In this way we don't create .vmdk by default and I'll define
CREATE_VMDK = 1
in self-hosted-image.bb to generate the .vmdk.
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/1][v2] self-hosted-image: generate the .hdddirect and .vmdk image files
Darren Hart wrote on 2012-01-19:
On 01/18/2012 06:18 AM, Dexuan Cui wrote:
The self-hosted-image work needs a live-bootable and r/w-able image
format. The existing .iso isn't ok since it's readonly. The existing
.hddimg is not a good choice, since it has a two-option(boot, install)
syslinux function that we don't need: we don't hope a user to be
potentially able to install, and I think it may be not suitble to
hack build_hddimg to hide the install?
bootimg.bbclass should probably be renamed liveimg.bbclass to keep
it's meaning clear.
Good suggestion.
Moreever, .hddimg is not that compatibible with some devices and we
hope to have the most compatibility.
So I think the .hdddirect format is a good choice and I made this patch
to adopt it and also enhanced boot-directdisk.bbclass to generate .vmdk
image so we can run it on vmware, too. BTW, currently self-hosted-image
is the only user of boot-directdisk.bbclass; with the adoption of
.hdddirect and .vmdk formats, a user can still use IMAGE_FSTYPES +=
'live' to generate the .iso and .hddimg format.
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/classes/boot-directdisk.bbclass |8
meta/conf/machine/include/qemu.inc|2 ++
meta/recipes-core/images/self-hosted-image.bb | 11 +--
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/meta/classes/boot-directdisk.bbclass
b/meta/classes/boot-directdisk.bbclass index 8879ba8..7f14225 100644
--- a/meta/classes/boot-directdisk.bbclass +++
b/meta/classes/boot-directdisk.bbclass @@ -24,6 +24,7 @@
do_bootdirectdisk[depends] += dosfstools-native:do_populate_sysroot \
syslinux-native:do_populate_sysroot \
parted-native:do_populate_sysroot \
mtools-native:do_populate_sysroot +do_bootdirectdisk[depends] +=
qemu-native:do_populate_sysroot
As a point of style, just add the new dependencies to the preceding
assignment rather than creating a new assignment.
Ok, I'll add the new dependency into the existing
do_bootdirectdisk[depends] rather than creating a new += line.
PACKAGES =
EXCLUDE_FROM_WORLD = 1
@@ -50,6 +51,7 @@ build_boot_dd() {
install -d ${HDDDIR}
install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage
${HDDDIR}/vmlinuz
+install -m 0644 ${S}/syslinux.cfg ${HDDDIR}/syslinux.cfg
install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys
${HDDDIR}/ldlinux.sys
BLOCKS=`du -bks ${HDDDIR} | cut -f 1` @@ -83,6 +85,12 @@
build_boot_dd() { cd ${DEPLOY_DIR_IMAGE} rm -f
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirectln -s
${IMAGE_NAME}.hdddirect
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
+
+if [ ${NOVMDK} != 1 ] ; then
+${STAGING_BINDIR_NATIVE}/qemu-img convert -O vmdk \
+${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect \
+${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk
+fi
}
python do_bootdirectdisk() {
diff --git a/meta/conf/machine/include/qemu.inc
b/meta/conf/machine/include/qemu.inc index 3cebfab..a5b563b 100644 ---
a/meta/conf/machine/include/qemu.inc +++
b/meta/conf/machine/include/qemu.inc @@ -5,6 +5,8 @@ MACHINE_FEATURES =
kernel26 apm alsa pcmcia bluetooth irda usbgadget screen
IMAGE_FSTYPES ?= tar.bz2 ext3
+APPEND_${MACHINE} = root=/dev/hda2
+
This concerns me. How does this interact with other recipes and configs
that may set this? What happens if the machine config adds a console
parameter to the APPEND? For example, the meta-intel n450 does the
following:
APPEND += console=ttyS0,115200 console=tty0
If I understand correctly, your assignment above will override this.
My change (the below line) is only in qemu.inc
+ APPEND_${MACHINE} = root=/dev/hda2
So n450 is not affected here.
However, I do need to think more about the interact with others, e.g.,
in the case of n450, the APPEND in boot-directdisk.bbclass actually
overrides the value assigned in atom-pc.conf -- this is an existing issue.
I think nobody tested this before, so we didn't notice this.
I'll try to work out a new version.
ROOT_FLASH_SIZE = 280
# Don't include kernels in standard images diff --git
a/meta/recipes-core/images/self-hosted-image.bb
b/meta/recipes-core/images/self-hosted-image.bb
index 111c057..df6c81f 100644
--- a/meta/recipes-core/images/self-hosted-image.bb
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -6,6 +6,13 @@ POKY_EXTRA_INSTALL = \
IMAGE_FEATURES += x11-mini
-inherit core-image +# Needed by boot-directdisk +ROOTFS ?=
${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.ext3
-PR = r2
+inherit core-image boot-directdisk
+
+do_bootimg[depends] += ${INITRD_IMAGE}:do_rootfs
+do_bootimg[depends] += ${IMAGE_BASENAME}:do_rootfs
+do_bootdirectdisk[depends] += ${PN}:do_rootfs
+
+PR = r3
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http
Re: [OE-core] [RFC PATCH 1/1] self-hosted-image: generate the .hdddirect and .vmdk image files
Darren Hart wrote on 2012-01-13:
Hi Dexuan,
Please include a complete patch header. Much of your 0/1 content can
go here.
(Sorry for the late reply! I overlooked the mails...)
Ok, I'll pay attention to this in future.
Comments below...
On 01/10/2012 10:53 AM, Dexuan Cui wrote:
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/classes/boot-directdisk.bbclass | 10 +-
meta/recipes-core/images/self-hosted-image.bb | 11 +--
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/meta/classes/boot-directdisk.bbclass
b/meta/classes/boot-directdisk.bbclass index 8879ba8..83ec929 100644
--- a/meta/classes/boot-directdisk.bbclass +++
b/meta/classes/boot-directdisk.bbclass @@ -24,6 +24,7 @@
do_bootdirectdisk[depends] += dosfstools-native:do_populate_sysroot \
syslinux-native:do_populate_sysroot \
parted-native:do_populate_sysroot \
mtools-native:do_populate_sysroot +do_bootdirectdisk[depends] +=
qemu-native:do_populate_sysroot
PACKAGES =
EXCLUDE_FROM_WORLD = 1
@@ -38,7 +39,7 @@ BOOTDD_EXTRA_SPACE ?= 16384
AUTO_SYSLINUXCFG = 1
LABELS = boot
-APPEND = root=/dev/sda2
+APPEND = root=/dev/hda2
This seems like it had the potential to break other uses of hdddirect.
Qemu may use hda2, but other hdddirect users (external layers for
Hi Darren, thanks for pointing this out!
I thought it's ok since now I'm the only user ofhdddirect, but I didn't realize
I might break external layers...
example) may not. This feels like a MACHINE config to me. In fact,
machine's do already set APPEND for things like the console.
I agree.
So, I think here we should change the = to ?= like the below
-APPEND = root=/dev/sda2
+APPEND ?= root=/dev/sda2
And in meta/conf/machine/include/qemu.inc, I can add a line
APPEND = root=/dev/hda2.
Does this sound ok?
TIMEOUT = 10
SYSLINUXCFG = ${HDDDIR}/syslinux.cfg
SYSLINUXMENU = ${HDDDIR}/menu
@@ -50,6 +51,7 @@ build_boot_dd() {
install -d ${HDDDIR}
install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage
${HDDDIR}/vmlinuz
+install -m 0644 ${S}/syslinux.cfg ${HDDDIR}/syslinux.cfg
Hrm... syslinux.cfg wasn't installed before at all?
I'm not very clear about the history, but according to syslinux.bbclass,
iso and hddimg do invoke syslinux_populate, but hdddirect doesn't -- I suppose
hdddirect doesn't need all the functionality of build_syslinux_menu, so it
tries to install the files itself, and unluckily it misses syslinux.cfg. Now
there is no user of .hdddirect in poky, and I don't know there is any actual
external user. This may explain why nobody complains. :-)
install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys
${HDDDIR}/ldlinux.sys
BLOCKS=`du -bks ${HDDDIR} | cut -f 1` @@ -83,6 +85,12 @@
build_boot_dd() { cd ${DEPLOY_DIR_IMAGE} rm -f
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirectln -s
${IMAGE_NAME}.hdddirect
${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
+
+if [ ${NOVMDK} != 1 ] ; then
+${STAGING_BINDIR_NATIVE}/qemu-img convert -O vmdk \
You've added a dependency on qemu-img, please add the appropriate
DEPENDS above.
I have added the line in my patch:
do_bootdirectdisk[depends] += qemu-native:do_populate_sysroot
I think this is enough?
Need I add DEPENDS += qemu-native, too?
+${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect \
+${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk
+fi
}
python do_bootdirectdisk() {
Darren Hart wrote on 2012-01-13:
On 01/10/2012 10:53 AM, Dexuan Cui wrote:
A couple additional thoughts about the boot-directdisk class in general:
So build_boot_dd needs a careful audit to ensure the various dd
commands do not stomp on eachother iirc, the dd of syslinux/mbr.bin
was stomping on the partition table or some such.
Hi Darren,
The dd-ing of mbr.bin actually writes only the first 440 bytes of $IMAGE --
please note
the size of mbr.bin(generated by the recipe syslinux, I think) is 440 bytes
rather than 512 bytes. :-)
I think 440 is safe enough because it's even smaller than 512-16*4=448 bytes.
Also note that it uses mkdosfs -d which we have purged (and it aint
coming back if my NACK is worth anything ;-). Sounds like we need to
abstract building msdos images into an msdosfs.bbclass. No reason to
Would you volunteer to make a msdosfs.bbclass? :-)
duplicate all the fatfs overhead calculations I did yesterday (See the
patch I sent yesterday to bootimg.bbclass).
I agree.
I see your patch has been in poky master now.
If you could help to make msdosfs.bbclass, I would appreciate that a lot.
Now I'm stick in something else and I'm afraid I can't start to work on this
immediately. :-(
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] distro_tracking_fields.inc: upgrade tcf-agent
Sorry, please use the new commit: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/manual_checkid=54282a3d4109fe4e97f0acf3b848dc04e68c7d7f (I have force pushed to my dcui/manual_check already) In the old commit MANUAL_CHECK_DATE, the year is 2011 and now it's 2012! :-) Thanks, -- Dexuan -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Dexuan Cui Sent: Tuesday, January 10, 2012 12:23 PM To: openembedded-core@lists.openembedded.org Subject: [OE-core] [PATCH 1/1] distro_tracking_fields.inc: upgrade tcf-agent Upgraded the field RECIPE_MANUAL_CHECK_DATE. Also changed the MAINTAINER to Lianhao who volunteered to take the recipe. Signed-off-by: Dexuan Cui dexuan@intel.com --- .../conf/distro/include/distro_tracking_fields.inc |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index cc87d5c..d1f0c82 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -2891,8 +2891,8 @@ RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-tcf-agent = 1+ years RECIPE_LATEST_RELEASE_DATE_pn-tcf-agent = Jul 07, 2011 RECIPE_COMMENTS_pn-tcf-agent = RECIPE_LAST_UPDATE_pn-tcf-agent = Jul 21, 2011 -RECIPE_MANUAL_CHECK_DATE_pn-tcf-agent = Nov 17, 2011 -RECIPE_MAINTAINER_pn-tcf-agent = Dexuan Cui dexuan@intel.com +RECIPE_MANUAL_CHECK_DATE_pn-tcf-agent = Jan 10, 2011 +RECIPE_MAINTAINER_pn-tcf-agent = Lianhao Lu lianhao...@intel.com RECIPE_STATUS_pn-liburcu = green DISTRO_PN_ALIAS_pn-liburcu = Fedora=userspace-rcu Ubuntu=liburcu0 -- 1.7.6 ___ 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] Recent xserver-kdrive failure and util-macros update
Xiaofeng Yan wrote on 2012-01-04: On 2012年01月04日 15:28, Saul Wold wrote: We seem to have a relatively new failure in xserver-kdrive, which appeared in the last set of change. I tried to run though a bisect but was not able to find the problem. The problem seems to be related to configure.ac setting of XSERVER_CFLAGS='$(CWARNFLAGS)' and then using -Werror=address, which is what causes the failure. Hi Saul, Can we patch this to make it not fail? I'll try to look into this... This seems to be related to the util-macros update to 1.16, which adds more warnings to errors. Since we are still using the older xserver-kdrive, there are warnings that are now errors with the update. We could patch the current xserver-kdrive, revert the 1.16 update to util-macros or update xserver-kdrive (which is in the works, but I think had some issues). This also seems to affect the libxp package on x86-64. I don't see any libxp failure(I build libxp with MACHINE=qemux86 on an X86-64 host). By saying on x86-64, did you mean qemux86-64? Thoughts, I know we don't like to revert, but we may have to in this case as we don't have the kdrive update yet and would need to further investigate the libxp failure. Hi Saul, Do you have any suggestion my previous patches to update xserver-kdrive ? http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/update I can build Xiaofeng's xserver-kdrive 1.11.2 fine with util-macro_1.16. Can we use the new xserver-kdriver and remove the old one? Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] opkg still breaks meta-toolchain-gmae
Cui, Dexuan wrote on 2011-12-21:
Hi all,
After I upgraded to the latest poky master (commit 4648aadf),
core-image-sato-sdk can build file, but meta-toolchain-gmae (with ipk
packaging) still doesn't work. Now the failure is:
| error: Failed dependencies:
| libsdl-nativesdk is needed by qemu-nativesdk-0.15.1-r1.x86_64
NOTE: package meta-toolchain-gmae-1.0-r6: task do_populate_sdk: Failed
Sorry, I need to correct this above:
It's actually rpm packaging(rpm did work fine with the slightly older commit
45987c5135) rather than ipk.
If I use ipk packaging, I get the similar mkdir failure:
mkdir: cannot create directory `/var/lib/opkg': Permission denied
and, I finally got a libsdl failure, too:
| Collected errors:
| * satisfy_dependencies_for: Cannot satisfy the following dependencies for
task-sdk-host-nativesdk:
| *libsdl-nativesdk *
So I suppose the libsdl patch( fix packaging) is suspicious.
BTW, I use MACHINE=qemux86.
If I built with a slightly older commit 45987c5135, the failure is: |
mkdir: cannot create directory `/var/lib/opkg'\'': Permission denied |
Configuring libc6. ... | + install -m 0644
/distro/dcui/1220/p1/build/tmp/work/i586-poky-linux/meta-toolchain-gma
e- 1.0-r6/opkg-sdk.conf
/distro/dcui/1220/p1/build/tmp/work/i586-poky-linux/meta-toolchain-gma
e- 1.0-r6/sdk/image//opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-l' |
mkdir: cannot create directory `/var/lib/opkg': Permission denied ... |
gtk-update-icon-cache: Failed to open file |
/usr/share/icons/whiteglass/.icon-theme.cache : Permission denied ... |
+ do_exit=1 | + test 1 = 1 | + exit 1 NOTE: package
meta-toolchain-gmae-1.0-r6: task do_populate_sdk: Failed
Looks somewhat the ${D} is empty, so the host directories are being
installed into???
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] opkg still breaks meta-toolchain-gmae
Hi all,
After I upgraded to the latest poky master (commit 4648aadf),
core-image-sato-sdk can build file, but meta-toolchain-gmae (with ipk
packaging) still doesn't work. Now the failure is:
| error: Failed dependencies:
| libsdl-nativesdk is needed by qemu-nativesdk-0.15.1-r1.x86_64
NOTE: package meta-toolchain-gmae-1.0-r6: task do_populate_sdk: Failed
If I built with a slightly older commit 45987c5135, the failure is:
| mkdir: cannot create directory `/var/lib/opkg'\'': Permission denied
| Configuring libc6.
...
| + install -m 0644
/distro/dcui/1220/p1/build/tmp/work/i586-poky-linux/meta-toolchain-gmae-1.0-r6/opkg-sdk.conf
/distro/dcui/1220/p1/build/tmp/work/i586-poky-linux/meta-toolchain-gmae-1.0-r6/sdk/image//opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-l'
| mkdir: cannot create directory `/var/lib/opkg': Permission denied
...
| gtk-update-icon-cache: Failed to open file
/usr/share/icons/whiteglass/.icon-theme.cache : Permission denied
...
| + do_exit=1
| + test 1 = 1
| + exit 1
NOTE: package meta-toolchain-gmae-1.0-r6: task do_populate_sdk: Failed
Looks somewhat the ${D} is empty, so the host directories are being installed
into???
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] socat: add the latest stable version 1.7.2.0
Koen Kooi wrote on 2011-12-19: Op 19 dec. 2011, om 06:22 heeft Dexuan Cui het volgende geschreven: +DEPENDS = openssl + +LICENSE = GPLv2+ Hi Koen, Thanks very much for the comment! Linking GPL and openssl is not allowed due to the advertising clause in BSD. The socat people realized that and say: the advertising clause in BSD? I suppose you meant the advertising clause in openssl license? license --- socat is distributed under the terms of the GNU GPL; except for install-sh, which is copyright MIT, with its own license; In addition, as a special exception, the copyright holder gives permission to link the code of this program with any version of the OpenSSL library which is distributed under a license identical to that listed in the included COPYING.OpenSSL file, and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. My understanding is: the author of socat allows us to link socat to the lib openssl? Koen, I'm really not good at the license stuff at all. Could you please explain the situation in more details? What need we do if we want to add the socat recipe into poky? It has already been in OE for a long period of time. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] socat: add the latest stable version 1.7.2.0
Koen Kooi wrote on 2011-12-19: Op 19 dec. 2011, om 10:16 heeft Cui, Dexuan het volgende geschreven: Koen Kooi wrote on 2011-12-19: Op 19 dec. 2011, om 06:22 heeft Dexuan Cui het volgende geschreven: +DEPENDS = openssl + +LICENSE = GPLv2+ Hi Koen, Thanks very much for the comment! Linking GPL and openssl is not allowed due to the advertising clause in BSD. The socat people realized that and say: the advertising clause in BSD? I suppose you meant the advertising clause in openssl license? Yes, indeed license --- socat is distributed under the terms of the GNU GPL; except for install-sh, which is copyright MIT, with its own license; In addition, as a special exception, the copyright holder gives permission to link the code of this program with any version of the OpenSSL library which is distributed under a license identical to that listed in the included COPYING.OpenSSL file, and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. My understanding is: the author of socat allows us to link socat to the lib openssl? Correct. I don't know what happens when you include socat in a GPL product, but that's for other people to worry about :) Koen, I'm really not good at the license stuff at all. Could you please explain the situation in more details? From what I've understood the advertising clause is consired a restriction by the GPL and hence incompatible. Since openssl is so widespread and gnutls so buggy the exception was invented to allow openssl to link with gpl software. What need we do if we want to add the socat recipe into poky? It has already been in OE for a long period of time. Some googling suggests that 'GPL-2.0+-with-OpenSSL-exception' is SPDX compatible, so we could put that in LICENSE. Thanks a lot for the suggestion! Please review/use the new patch: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/socat-v2id=896e5e9f9ca387d832d423a1e16ad918d473c4cc Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 15/17] wget: enable https and openssl
Steve Sakoman wrote on 2011-12-19: On Fri, Dec 9, 2011 at 12:21 PM, Khem Raj raj.k...@gmail.com wrote: On Thu, Dec 8, 2011 at 12:44 AM, Saul Wold s...@linux.intel.com wrote: Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-extended/wget/wget.inc | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-extended/wget/wget.inc b/meta/recipes-extended/wget/wget.inc index 91400cc..7083569 100644 --- a/meta/recipes-extended/wget/wget.inc +++ b/meta/recipes-extended/wget/wget.inc @@ -2,13 +2,13 @@ DESCRIPTION = A console URL download utility featuring HTTP, FTP, and more. SECTION = console/network LICENSE = GPL LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504 +DEPENDS = openssl -INC_PR = r11 +INC_PR = r12 inherit autotools gettext update-alternatives -# Disable checking for SSL since that searches the system paths -EXTRA_OECONF = --with-libc --enable-ipv6 --without-ssl +EXTRA_OECONF = --with-libc --enable-ipv6 --with-ssl=openssl this deserves to be a configurable thing IMO Agreed. Also, this seems to break the wget build for non x86 processors. For example, on arm builds the config phase fails: configure:30042: checking for libssl configure:30072: ccache arm-poky-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/media/Work/yocto-tmp/sysroots/omap3-multi -o conftest -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c -ldl -lz -lssl -lcrypto /usr/lib/libz.so 5 /usr/lib/libz.so: could not read symbols: File in wrong format Hi, Steve, I found this issue, too. I've made a patch for this and will send it out soon. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] wget: fix a host intrusion issue introduced by adding --with-ssl=openssl.
Eric Bénard wrote on 2011-12-19:
inherit autotools gettext update-alternatives
-EXTRA_OECONF = --with-libc --enable-ipv6 --with-ssl=openssl
+EXTRA_OECONF = --with-libc --enable-ipv6
--with-libssl-prefix=${STAGING_DIR_HOST} --with-ssl=openssl
do_install_append () {
mv ${D}${bindir}/wget ${D}${bindir}/wget.${PN}
this also fix a problem I just met (angstrom, armv5 target) :
| configure: error: --with-ssl=openssl was given, but SSL is not available.
Tested-by: Eric Bénard e...@eukrea.com
Hi Eric,
This is actually the same issue Steve and I met with. :-)
Eric and Steve, thank you both for the testings!
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/9] consolekit: fix sdk generation issues
Richard Purdie wrote on 2011-12-15:
On Tue, 2011-12-13 at 20:19 +0400, Dmitry Eremin-Solenikov wrote:
Currently sdk generation might fail with the following error:
| Collected errors:
| * extract_archive: Cannot create symlink from ./var/log to
'volatile/log': File exists.
ERROR: Function 'do_populate_sdk' failed
This happens as consolekit package will include both
/var/log/ConsoleKit and /var/volatile/log/ConsoleKit files:
lumag@fangorn:~/OE-scripts$ dpkg-deb -c
build/tmp--eglibc/deploy/ipk/core2/consolekit_0.4.5-r7_core2.ipk |
grep var
drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/ drwxr-xr-x
root/root 0 2011-12-07 22:12 ./var/log/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/log/ConsoleKit/ lrwxrwxrwx root/root
0 2011-12-07 22:12 ./var/run - volatile/run drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/ drwxr-xr-x root/root 0
2011-12-07 22:12 ./var/volatile/log/ drwxr-xr-x root/root 0
2011-12-07 22:12 ./var/volatile/log/ConsoleKit/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/run/ drwxr-xr-x root/root
0 2011-12-07 22:12 ./var/volatile/run/ConsoleKit/
Inclusion of both log directories causes this error. Drop the
/var/log/ConsoleKit in favour of /var/volatile/log
Hi Dmitry,
Could you please explain how and where the extract_archive error is caused?
Where is /var/log linked to /var/volatile/log?
Do you mean RP's patch consolekit: Fix ${localstatedir} race didn't fix the
issue?
(I suspect so)
This effectively reverts:
http://git.openembedded.org/openembedded-core/commit/?id=5608a748
af2c754f60137ab7c3010ccce6bf9e40 so I think this fixes one problem at
the expense of causing another. Koen: Any comments?
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/9] consolekit: fix sdk generation issues
Koen Kooi wrote on 2011-12-15: Op 15 dec. 2011, om 15:58 heeft Richard Purdie het volgende geschreven: On Tue, 2011-12-13 at 20:19 +0400, Dmitry Eremin-Solenikov wrote: Currently sdk generation might fail with the following error: | Collected errors: | * extract_archive: Cannot create symlink from ./var/log to 'volatile/log': File exists. ERROR: Function 'do_populate_sdk' failed This happens as consolekit package will include both /var/log/ConsoleKit and /var/volatile/log/ConsoleKit files: lumag@fangorn:~/OE-scripts$ dpkg-deb -c build/tmp--eglibc/deploy/ipk/core2/consolekit_0.4.5-r7_core2.ipk | grep var drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/log/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/log/ConsoleKit/ lrwxrwxrwx root/root 0 2011-12-07 22:12 ./var/run - volatile/run drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/log/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/log/ConsoleKit/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/run/ drwxr-xr-x root/root 0 2011-12-07 22:12 ./var/volatile/run/ConsoleKit/ Inclusion of both log directories causes this error. Drop the /var/log/ConsoleKit in favour of /var/volatile/log Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com This effectively reverts: http://git.openembedded.org/openembedded-core/commit/?id=5608a748 af2c7 54f60137ab7c3010ccce6bf9e40 so I think this fixes one problem at the expense of causing another. Koen: Any comments? If you revert it consolekit won't work at runtime because it fails to start. We need to find the proper fix. meta-toolchain-gmae building (at least with ipk packaging) has been broken by this for half a month... Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] meta-toolchain-gmae can't build: Cannot create symlink from ./var/log to 'volatile/log': File exists
Richard Purdie wrote on 2011-12-05: On Mon, 2011-12-05 at 15:35 +0800, Cui, Dexuan wrote: Hi, recently, I found meta-toolchain-gmae failed to build on poky master if I use ipk packaging(I didn't try rpm/deb): task do_populate_sdk: Failed | Configuring avahi-dev. | Configuring task-core-standalone-gmae-sdk-target. | Configuring libtelepathy-dbg. | Configuring task-core-standalone-gmae-sdk-target-dbg. | Configuring util-linux-blkid. | Collected errors: | * extract_archive: Cannot create symlink from ./var/log to 'volatile/log': File exists. ERROR: Function 'do_populate_sdk' failed Now I have no time to look into this issue at once. It would be great, if somebody can give some quick hint. Is this with the latest master? http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f340e3937fd5ac396 3 de6c6b29d56dd92d962864 was added to avoid an error very like this that was showing up with rpm... Yes. I was using yesterday's latest poky master (9be6d59b78510443d0944513503d515df13caa45), so the fix you mentioned above was already in. There must be some recent change that causes the issue, because IIRC it was fine in my side 2~3 weeks ago. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] meta-toolchain-gmae can't build: Cannot create symlink from ./var/log to 'volatile/log': File exists
Hi, recently, I found meta-toolchain-gmae failed to build on poky master if I use ipk packaging(I didn't try rpm/deb): task do_populate_sdk: Failed | Configuring avahi-dev. | Configuring task-core-standalone-gmae-sdk-target. | Configuring libtelepathy-dbg. | Configuring task-core-standalone-gmae-sdk-target-dbg. | Configuring util-linux-blkid. | Collected errors: | * extract_archive: Cannot create symlink from ./var/log to 'volatile/log': File exists. ERROR: Function 'do_populate_sdk' failed Now I have no time to look into this issue at once. It would be great, if somebody can give some quick hint. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/8] libxfont: upgrade from 1.4.3 to 1.4.4
Khem Raj wrote on 2011-12-01:
On Wed, Nov 30, 2011 at 6:12 AM, Dexuan Cui dexuan@intel.com
wrote:
updated LIC_FILES_CHKSUM:
only Copyright holder change in COPYING -- no actual license change.
Signed-off-by: Dexuan Cui dexuan@intel.com ---
.../{libxfont_1.4.3.bb = libxfont_1.4.4.bb} | 8 +++- 1
files changed, 3 insertions(+), 5 deletions(-) rename
meta/recipes-graphics/xorg-lib/{libxfont_1.4.3.bb = libxfont_1.4.4.bb}
(62%)
diff --git a/meta/recipes-graphics/xorg-lib/libxfont_1.4.3.bb
b/meta/recipes-graphics/xorg-lib/libxfont_1.4.4.bb similarity index 62%
rename from meta/recipes-graphics/xorg-lib/libxfont_1.4.3.bb rename to
meta/recipes-graphics/xorg-lib/libxfont_1.4.4.bb index 43a628e..8af0ac9
100644 --- a/meta/recipes-graphics/xorg-lib/libxfont_1.4.3.bb +++
b/meta/recipes-graphics/xorg-lib/libxfont_1.4.4.bb @@ -7,7 +7,7 @@ such
as freetype). require xorg-lib-common.inc
LICENSE= MIT MIT-style BSD -LIC_FILES_CHKSUM =
file://COPYING;md5=d1c29f32ca774cecf0c83b46bb5c +LIC_FILES_CHKSUM
= file://COPYING;md5=a46c8040f2f737bcd0c435feb2ab1c2c
DEPENDS += freetype fontcacheproto xtrans fontsproto libfontenc
PROVIDES = xfont
@@ -15,11 +15,9 @@ PROVIDES = xfont
PR = r0
PE = 1
-#SRC_URI += file://no-scalable-crash.patch
-
Please rm the patch as well.
Thanks for the reminder! I didn't find the patch somehow... sorry.
I'll send a new commit to remove the patch.
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/8] lzo: upgrade from 2.05 to the latest version 2.06
Khem Raj wrote on 2011-12-01:
On Wed, Nov 30, 2011 at 6:12 AM, Dexuan Cui dexuan@intel.com
wrote:
Signed-off-by: Dexuan Cui dexuan@intel.com
---
.../lzo/{lzo-2.05 = lzo-2.06}/acinclude.m4 | 0
.../lzo/{lzo-2.05 = lzo-2.06}/autoconf.patch | 9 -
---
diff --git a/configure.ac b/configure.ac
index 650749a..2a78845 100644
@@ -16,6 +23,6 @@ index 650749a..2a78845 100644
-AC_PREREQ(2.67)
+AC_PREREQ(2.65)
is this patch needed still. We use newer autoconf so why do we go back
to 2.65 in this case ?
Hi Khem,
Thanks a lot for the reminder!
You're correct. We don't need the patch any longer according to my test.
I'll send a new commit to remove the patch.
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/8] xcb-util: upgrade from 0.3.6 to 0.3.8
Khem Raj wrote on 2011-12-01: On Wed, Nov 30, 2011 at 6:12 AM, Dexuan Cui dexuan@intel.com wrote: updated LIC_FILES_CHKSUM since the code was re-organized, but the license remains the same. --- /dev/null +++ b/meta/recipes-graphics/xcb/xcb-util_0.3.8.bb @@ -0,0 +1,9 @@ +file://src/xcb_aux.c;endline=30;md5=ae305b9c2a38f9ba27060191046a64 60 +\ + file://src/xcb_event.h;endline=27;md5=627be35 5aee59e1b8ade80d5bd90fad9 if license remains same then why do we not check for the remaining files from there new location wherever they moved to after code reorg ? Some files in 0.3.6 doesn't exist in 0.3.8. According the Changelog, they seem to be demo code, or obsolete code. I reserved the 2 files of LIC_FILES_CHKSUM since they're still in 0.3.8, but with a different directory. The other files don't exist now. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] runqemu-ifup, runqemu-internal: be wiser when locating the network tools
Richard Purdie wrote on 2011-12-01:
On Thu, 2011-12-01 at 17:21 +0800, Dexuan Cui wrote:
When working on the self-hosted-image work, I found the PATH
variable in the
Level-1 target doesn't have /sbin and /usr/sbin, so runqemu can't
run properly since the tools are installeld at /sbin/ifconfig
/sbin/route /usr/sbin/iptables
The patch is used to fix the issue by setting a temp PATH when running
which.
Signed-off-by: Dexuan Cui dexuan@intel.com
---
scripts/runqemu-ifup |8 +---
scripts/runqemu-internal |3 ++-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup index
870cb6b..9e697a8 100755
--- a/scripts/runqemu-ifup
+++ b/scripts/runqemu-ifup
@@ -64,7 +64,9 @@ if [ $STATUS -ne 0 ]; then
exit 1
fi
-IFCONFIG=`which ifconfig 2 /dev/null`
+PATH_TMP=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
+
+IFCONFIG=`{ PATH=$PATH:$PATH_TMP; which ifconfig 2 /dev/null; }`
if [ x$IFCONFIG = x ]; then
# better than nothing...
IFCONFIG=/sbin/ifconfig
I don't really like this, its getting hard to understand whats going on.
Can we abstract this to a function which tries PATH, then tries our
own PATH_TMP? This would reduce code duplication and makes it clearer
what the code is doing...
Good suggestion!
I'll re-make the patch and re-send it out.
BTW, since I'll be on leave later today, I might not be able to finish this
today.
I discussed with Saul and he could kindly help me to finish this. :-)
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] make: expand MAKEFLAGS before we re-exec after rebuilding makefiles.
Richard Purdie wrote on 2011-12-01: On Thu, 2011-12-01 at 10:22 +0100, Koen Kooi wrote: Op 1 dec. 2011, om 10:21 heeft Dexuan Cui het volgende geschreven: This patch was got from the upstream cvs repo of make to fix the bug of make-3.82: http://savannah.gnu.org/bugs/?30723 Signed-off-by: Dexuan Cui dexuan@intel.com --- .../make/make-3.82/expand_MAKEFLAGS.patch | 39 meta/recipes-devtools/make/make_3.82.bb |4 ++- 2 files changed, 42 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch diff --git a/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch b/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch new file mode 100644 index 000..4184937 --- /dev/null +++ b/meta/recipes-devtools/make/make-3.82/expand_MAKEFLAGS.patch @@ -0,0 +1,39 @@ +Upstream-Status: Inappropriate [The fix is already in upstream +cvs repo, but not in the stable release] Isn't 'backport' a better description than 'inappropriate'? Agreed, I've taken this patch but changed the patch status to backport. Thanks a lot, Richard and Koen! Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/8] xcb-util: upgrade from 0.3.6 to 0.3.8
Martin Jansa wrote on 2011-12-01: On Wed, Nov 30, 2011 at 10:12:32PM +0800, Dexuan Cui wrote: updated LIC_FILES_CHKSUM since the code was re-organized, but the license remains the same. meta/recipes-graphics/xcb/xcb-util_0.3.6.bb | 18 -- meta/recipes-graphics/xcb/xcb-util_0.3.8.bb |9 + 2 files changed, 9 insertions(+), 18 deletions(-) delete mode 100644 meta/recipes-graphics/xcb/xcb-util_0.3.6.bb create mode 100644 meta/recipes-graphics/xcb/xcb-util_0.3.8.bb Because there is only one .so lib now after: http://cgit.freedesktop.org/xcb/util/commit/?id=118a3c86b3d3b2fab20f36 5e4a5703e40ad2e1b1 the resulting package is renamed from Package xcb-util (0.3.6-r0) is installed on root and has the following files: /usr/lib/libxcb-aux.so.0 /usr/lib/libxcb-keysyms.so.1 /usr/lib/libxcb-icccm.so.1 /usr/lib/libxcb-image.so.0.0.0 /usr/lib/libxcb-atom.so.1.0.0 /usr/lib/libxcb-icccm.so.1.0.0 /usr/lib/libxcb-event.so.1 /usr/lib/libxcb-reply.so.1.0.0 /usr/lib/libxcb-property.so.1.0.0 /usr/lib/libxcb-render-util.so.0.0.0 /usr/lib/libxcb-property.so.1 /usr/lib/libxcb-reply.so.1 /usr/lib/libxcb-image.so.0 /usr/lib/libxcb-atom.so.1 /usr/lib/libxcb-event.so.1.0.0 /usr/lib/libxcb-render-util.so.0 /usr/lib/libxcb-aux.so.0.0.0 /usr/lib/libxcb-keysyms.so.1.0.0 Now it's libxcb-util0, because of only one .so packages-split/xcb-util packages-split/xcb-util/usr packages-split/xcb-util/usr/lib packages-split/xcb-util/usr/lib/libxcb-util.so.0.0.0 packages-split/xcb-util/usr/lib/libxcb-util.so.0 So we need at least PR bumps for recipes which were RDEPENDing on xcb-util (ie because of shlibs). I'll send patches later for recipes which are failing for me now.. Hi Martin, thanks very much for helping on this! :-) Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/8] [Dexuan]: upgrades for 7 recipes
Richard Purdie wrote on 2011-12-01: On Wed, 2011-11-30 at 22:12 +0800, Dexuan Cui wrote: The following changes since commit 00d121aad3a4263bc0e3a004a3a479e6352e063d: clutter-box2d: drop unbuildable clutter-box2d-1.6_0.10.0 (2011-11-30 22:06:00 +0800) are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master Dexuan Cui (8): pixman: upgrade from 0.22.0 to the latest stable 0.24.0 libxrandr: upgrade from 1.3.1 to the latest version 1.3.2 lzo: upgrade from 2.05 to the latest version 2.06 libxfont: upgrade from 1.4.3 to 1.4.4 libxcursor: upgrade from 1.1.11 to 1.1.12 xcb-util: upgrade from 0.3.6 to 0.3.8 I merged these, thanks. inputproto: upgrade from 2.0.2 to the latest stable 2.0.99.1 I was a bit worried about this one - is 20.0.99.1 stable or a prerelease version? Should we just wait for the final release of that one? Thanks for the remind! It's a development snapshot of 2.1. 2.1.x (like 2.1.99.1) is not stable yet, either. So, I think we can use the current 2.0.2 until 2.2 is out. I'll update the RECIPE_NO_UPDATE_REASON field in distro_tracking_fields.inc. distro_tracking_fields.inc: update the info This failed to apply. Could you rebase and resubmit please? I don't know the cause, but it did apply in my side, against poky master, or oe-core master. Anyway, I'll rebase it against poky master(I'll also ensure it can apply fine against oe-core master). Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/4] gcc-package-target.inc: add the symbol link /lib/cpp
Richard Purdie wrote on 2011-11-24:
On Thu, 2011-11-24 at 18:08 +0800, Dexuan Cui wrote:
--- a/meta/recipes-devtools/gcc/gcc-package-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-package-target.inc
@@ -122,6 +122,8 @@ do_install () {
ln -sf ${TARGET_PREFIX}g++ g++
ln -sf ${TARGET_PREFIX}gcc gcc
ln -sf ${TARGET_PREFIX}cpp cpp
+install -d ${D}${base_libdir}
+ln -sf ${bindir}/${TARGET_PREFIX}cpp ${D}${base_libdir}/cpp
ln -sf g++ c++
ln -sf gcc cc
Why do we need this change?
When I was trying self-hosted-image, eglibc's do_install failed in the target:
ERROR: cannot stat bootparam_prot.h: the cause is: rpcgen doesn't work
properly: rpcgen can't exec /lib/cpp since it doesn't exist.
According to http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lib.html, if
a C preprocessor is installed, /lib/cpp must be a reference to it, for
historical reasons. The usual placement of this binary is /usr/bin/cpp.
Typical distros, like Ubuntu, openSuSE, Fedora, RHEL, all comply with the rule.
Actually in meta/recipes-devtools/gcc/gcc-package-target.inc, we do try to
package ${base_libdir}/cpp:
FILES_cpp = \
${bindir}/${TARGET_PREFIX}cpp \
${base_libdir}/cpp \
${libexecdir}/gcc/${TARGET_SYS}/${BINV}/cc1
But unluckily we didn't to create a symbol link in do_install. This patch adds
the symbol link.
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/4] gcc-package-target.inc: add the symbol link /lib/cpp
Richard Purdie wrote on 2011-11-25:
On Thu, 2011-11-24 at 23:37 +0800, Cui, Dexuan wrote:
Richard Purdie wrote on 2011-11-24:
On Thu, 2011-11-24 at 18:08 +0800, Dexuan Cui wrote:
--- a/meta/recipes-devtools/gcc/gcc-package-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-package-target.inc
@@ -122,6 +122,8 @@ do_install () {
ln -sf ${TARGET_PREFIX}g++ g++
ln -sf ${TARGET_PREFIX}gcc gcc
ln -sf ${TARGET_PREFIX}cpp cpp
+ install -d ${D}${base_libdir}
+ ln -sf ${bindir}/${TARGET_PREFIX}cpp ${D}${base_libdir}/cpp
ln -sf g++ c++
ln -sf gcc cc
Why do we need this change?
When I was trying self-hosted-image, eglibc's do_install failed in the
target: ERROR: cannot stat bootparam_prot.h: the cause is: rpcgen
doesn't work properly: rpcgen can't exec /lib/cpp since it doesn't
exist.
According to
http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lib.html,
if a C preprocessor is installed, /lib/cpp must be a reference to it,
for historical reasons. The usual placement of this binary is /usr/bin/cpp.
Typical distros, like Ubuntu, openSuSE, Fedora, RHEL, all comply with
the rule.
Actually in meta/recipes-devtools/gcc/gcc-package-target.inc, we do
try to
package ${base_libdir}/cpp:
FILES_cpp = \
${bindir}/${TARGET_PREFIX}cpp \
${base_libdir}/cpp \
${libexecdir}/gcc/${TARGET_SYS}/${BINV}/cc1
But unluckily we didn't to create a symbol link in do_install. This
patch
adds the symbol link.
Ok, this sounds great. Put this in the commit message though please!
Hi RP,
Please use the new commit(the only change is the updated commit message):
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/self-hosted-v2id=f6001f0b12cb561f5e08d3a5b0d61ab5fa924f40
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 17/17] python: skip setup.py 'import check' when cross-compiling
Zanussi, Tom wrote on 2011-11-10: On Wed, 2011-11-09 at 16:57 -0800, Cui, Dexuan wrote: Zanussi, Tom wrote on 2011-11-09: On Wed, 2011-11-09 at 02:34 -0800, Cui, Dexuan wrote: How I wish I could notice the patch this morning so I could save 1 day! ??? Can you please explain what you mean? I meant I spent 1 day on debugging the same issue and got the cause but wasn't sure how the patch should be made, so I wanted to ask for suggestion in the ML and before that I tried to find out if anybody reported the same issue and I saw your patch that was sent 1.5 days ago... :-) Yeah, sure - I'm just kind of curious since I'd never seen it before until I added the avx instruction support. Actually I think the issue is always there(at least from when python was upgrade to 2.7.x). e.g., in target, run python and try import grp, we'll get an error saying the built-in module grp couldn't be found; in python's log.do_compile, we can see the obvious warnings. Just out of curiosity, what were your host and target arches? I'm trying the task self hosted image(https://wiki.yoctoproject.org/wiki/Build_Appliance_Design): in target, I found bitbake's do_package failed because import grp failed, so I had to look into the issue. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] bash: make job control really work
Richard Purdie wrote on 2011-11-01:
On Tue, 2011-11-01 at 16:05 +0800, Dexuan Cui wrote:
It turns out 9393ff833f44570fd5f500bc9de6c72db94b0296 didn't really
fix the bug.
This patch is made and tested after I read the link below
http://www.mail-archive.com/bug-bash@gnu.org/msg03107.html
[YOCTO #487]
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/recipes-extended/bash/bash.inc|1 +
meta/recipes-extended/bash/bash_4.2.bb |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/bash/bash.inc
b/meta/recipes-extended/bash/bash.inc
index d55e517..d495538 100644
--- a/meta/recipes-extended/bash/bash.inc
+++ b/meta/recipes-extended/bash/bash.inc
@@ -23,6 +23,7 @@ ALTERNATIVE_LINK = ${base_bindir}/sh
ALTERNATIVE_PRIORITY = 100
do_configure () { + export bash_cv_job_control_missing=present
gnu-configize oe_runconf }
This really should go into the common site files...
Hi Richard,
I found we do define the variable:
meta/site/common-linux:33:bash_cv_job_control_missing=${bash_cv_job_control_missing=present}
but looks autoconf doesn't realize the variable has been assigned the value
'present'?
I think this is because of the below do_configure in bash.inc -- looks
autoreconf is skipped?
do_configure () {
gnu-configize
oe_runconf
}
Why do we need a customized do_configure to replace autotools_do_configure?
Later, after I added
do_configure_prepend () {
autoreconf -f -i -s
}
The generated config.log does show bash_cv_job_control_missing is assigned with
'present'.
(BTW, common-linux also introduces many other variables -- would this be safe?
Actually here I only need to introduce bash_cv_job_control_missing.)
However, finally, do_compile got a strange failure:
| shell.c: In function 'shell_reinitialize':
| shell.c:1742:20: error: 'PPROMPT' undeclared (first use in this function)
| shell.c:1742:20: note: each undeclared identifier is reported only once for
each function it appears in
| shell.c:1743:22: error: 'SPROMPT' undeclared (first use in this function)
Could you please give some suggestions?
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] bash: make job control really work
Richard Purdie wrote on 2011-11-02:
On Wed, 2011-11-02 at 15:10 +0800, Cui, Dexuan wrote:
Richard Purdie wrote on 2011-11-01:
On Tue, 2011-11-01 at 16:05 +0800, Dexuan Cui wrote:
I had a go at this problem myself and it took a bit of figuring out.
The problem is that bash ships config.h.in but autoheader overwrites it.
This removes the start/end includes from config.h or config-bot.h and
config-top.h. We can do something like this:
export AUTOHEADER = true
do_configure_prepend () {
if [ ! -e acinclude.m4 ]; then
cat aclocal.m4 acinclude.m4
fi
}
instead of the current do_configure override. The _prepend ensures the
bash specific macros are preserved and the export AUTOHEADER stops
autoheader from running at all.
Could you test those changes against bash 4.x and bash 3.x (replacing
the current do_configure in bash.inc) and then if that works send a patch
please?
Looks bug 487 only happens to bash 4.x and bash 3.x doesn't have such a bug (the
recipe of bash 3.x doesn't use bash.inc, either)
RP, thanks a lot for the help! Here is the new patch:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bug487id=b524337ed5670de2c0d294c3f6970e24f23847eb
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCHv3 01/31] xserver-xf86(-dri)-lite: rename to xserver-xorg and xserver-xorg-lite
BTW, I sent out 2 patches (to p...@yoctoproject.org) for bug 1670:
http://bugzilla.pokylinux.org/show_bug.cgi?id=1670#c2
Thanks,
-- Dexuan
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Cui, Dexuan
Sent: Wednesday, October 12, 2011 11:49 AM
To: Patches and discussions about the oe-core layer
Cc: Martin Jansa
Subject: Re: [OE-core] [oe-core][PATCHv3 01/31] xserver-xf86(-dri)-lite:
rename
to xserver-xorg and xserver-xorg-lite
Glad to see the patches to upgrade xserver and libx11. Good work! :-)
BTW, we also need to upgrade meta-intel's side since BSP can't build now:
http://bugzilla.pokylinux.org/show_bug.cgi?id=1670
I'm working on this bug.
Thanks,
-- Dexuan
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
Of
Martin Jansa
Sent: Saturday, October 08, 2011 1:05 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [oe-core][PATCHv3 01/31] xserver-xf86(-dri)-lite: rename
to
xserver-xorg and xserver-xorg-lite
* xserver-xorg is closer to upstream naming and
that's how it's named in OE-classic and meta-oe? It would make meta-oe
transition easier and better to do it now then convert meta-oe to
xserver-xf86 and then rename it back later.
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/distro/include/default-providers.inc |4 ++--
.../conf/distro/include/distro_tracking_fields.inc | 20
++--
meta/conf/machine/qemux86-64.conf |6 +++---
meta/conf/machine/qemux86.conf |6 +++---
meta/conf/multilib.conf|2 +-
...ver-xf86-common.inc = xserver-xorg-common.inc} |1 +
...xserver-xf86-lite.inc = xserver-xorg-lite.inc} |4 +---
.../crosscompile.patch |0
.../fix_open_max_preprocessor_error.patch |0
.../macro_tweak.patch |2 +-
...-lite_1.10.1.bb = xserver-xorg-lite_1.10.1.bb} |2 +-
...{xserver-xf86-dri-lite.inc = xserver-xorg.inc} |2 +-
.../cache-xkbcomp-output-for-fast-start-up.patch |0
.../crosscompile.patch |0
.../fix_macros1.patch |0
.../fix_open_max_preprocessor_error.patch |0
.../macro_tweak.patch |2 +-
...6-dri-lite_1.10.1.bb = xserver-xorg_1.10.1.bb} |2 +-
...er-xf86-dri-lite_git.bb = xserver-xorg_git.bb} |2 +-
19 files changed, 27 insertions(+), 28 deletions(-)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-common.inc =
xserver-xorg-common.inc} (96%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite.inc =
xserver-xorg-lite.inc} (95%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg-lite}/crosscompile.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite =
xserver-xorg-lite}/fix_open_max_preprocessor_error.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite =
xserver-xorg-lite}/macro_tweak.patch (93%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite_1.10.1.bb
=
xserver-xorg-lite_1.10.1.bb} (89%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite.inc =
xserver-xorg.inc} (97%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/cache-xkbcomp-output-for-fast-start-up.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite =
xserver-xorg}/crosscompile.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/fix_macros1.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/fix_open_max_preprocessor_error.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/macro_tweak.patch (93%)
rename
meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite_1.10.1.bb =
xserver-xorg_1.10.1.bb} (93%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite_git.bb =
xserver-xorg_git.bb} (94%)
diff --git a/meta/conf/distro/include/default-providers.inc
b/meta/conf/distro/include/default-providers.inc
index d51ac64..a5cdb5b 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -3,8 +3,8 @@
#
PREFERRED_PROVIDER_virtual/db ?= db
PREFERRED_PROVIDER_virtual/db-native ?= db-native
-PREFERRED_PROVIDER_virtual/xserver ?= xserver-xf86
-PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xf86-dri-lite
+PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg
+PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xorg
Re: [OE-core] [oe-core][PATCHv3 01/31] xserver-xf86(-dri)-lite: rename to xserver-xorg and xserver-xorg-lite
Glad to see the patches to upgrade xserver and libx11. Good work! :-)
BTW, we also need to upgrade meta-intel's side since BSP can't build now:
http://bugzilla.pokylinux.org/show_bug.cgi?id=1670
I'm working on this bug.
Thanks,
-- Dexuan
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Martin Jansa
Sent: Saturday, October 08, 2011 1:05 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [oe-core][PATCHv3 01/31] xserver-xf86(-dri)-lite: rename to
xserver-xorg and xserver-xorg-lite
* xserver-xorg is closer to upstream naming and
that's how it's named in OE-classic and meta-oe? It would make meta-oe
transition easier and better to do it now then convert meta-oe to
xserver-xf86 and then rename it back later.
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/distro/include/default-providers.inc |4 ++--
.../conf/distro/include/distro_tracking_fields.inc | 20
++--
meta/conf/machine/qemux86-64.conf |6 +++---
meta/conf/machine/qemux86.conf |6 +++---
meta/conf/multilib.conf|2 +-
...ver-xf86-common.inc = xserver-xorg-common.inc} |1 +
...xserver-xf86-lite.inc = xserver-xorg-lite.inc} |4 +---
.../crosscompile.patch |0
.../fix_open_max_preprocessor_error.patch |0
.../macro_tweak.patch |2 +-
...-lite_1.10.1.bb = xserver-xorg-lite_1.10.1.bb} |2 +-
...{xserver-xf86-dri-lite.inc = xserver-xorg.inc} |2 +-
.../cache-xkbcomp-output-for-fast-start-up.patch |0
.../crosscompile.patch |0
.../fix_macros1.patch |0
.../fix_open_max_preprocessor_error.patch |0
.../macro_tweak.patch |2 +-
...6-dri-lite_1.10.1.bb = xserver-xorg_1.10.1.bb} |2 +-
...er-xf86-dri-lite_git.bb = xserver-xorg_git.bb} |2 +-
19 files changed, 27 insertions(+), 28 deletions(-)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-common.inc =
xserver-xorg-common.inc} (96%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite.inc =
xserver-xorg-lite.inc} (95%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg-lite}/crosscompile.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite =
xserver-xorg-lite}/fix_open_max_preprocessor_error.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite =
xserver-xorg-lite}/macro_tweak.patch (93%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite_1.10.1.bb =
xserver-xorg-lite_1.10.1.bb} (89%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite.inc =
xserver-xorg.inc} (97%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/cache-xkbcomp-output-for-fast-start-up.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite =
xserver-xorg}/crosscompile.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/fix_macros1.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/fix_open_max_preprocessor_error.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/macro_tweak.patch (93%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite_1.10.1.bb =
xserver-xorg_1.10.1.bb} (93%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite_git.bb =
xserver-xorg_git.bb} (94%)
diff --git a/meta/conf/distro/include/default-providers.inc
b/meta/conf/distro/include/default-providers.inc
index d51ac64..a5cdb5b 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -3,8 +3,8 @@
#
PREFERRED_PROVIDER_virtual/db ?= db
PREFERRED_PROVIDER_virtual/db-native ?= db-native
-PREFERRED_PROVIDER_virtual/xserver ?= xserver-xf86
-PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xf86-dri-lite
+PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg
+PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xorg
PREFERRED_PROVIDER_virtual/libgl ?= mesa-xlib
PREFERRED_PROVIDER_virtual/update-alternatives ?=
update-alternatives-cworth
PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-native
diff --git a/meta/conf/distro/include/distro_tracking_fields.inc
b/meta/conf/distro/include/distro_tracking_fields.inc
index 7b6c4a9..8af80c7 100644
--- a/meta/conf/distro/include/distro_tracking_fields.inc
+++ b/meta/conf/distro/include/distro_tracking_fields.inc
@@ -3683,14 +3683,14 @@ RECIPE_INTEL_SECTION_pn-mesa-xlib=graphic
core
RECIPE_LAST_UPDATE_pn-mesa-xlib = Nov 27, 2010
RECIPE_MAINTAINER_pn-mesa-xlib=Yu Ke ke...@intel.com
Re: [OE-core] [PATCH V2] bluez4: Added new recipe 4.96 and removed 4.82 version
Martin Jansa wrote on 2011-08-16: On Tue, Aug 16, 2011 at 10:40:38AM +0800, Cui, Dexuan wrote: Saul Wold wrote on 2011-08-16: On 08/12/2011 01:04 AM, Noor, Ahsan wrote: From: Noor Ahsannoor_ah...@mentor.com * Added new recipe 4.96 and removed 4.82 version and its files. Signed-off-by: Noor Ahsannoor_ah...@mentor.com Merged into OE-Core The patch causes a failure: NOTE: package bluez-hcidump-2.0-r0: task do_compile: Failed I reported http://bugzilla.pokylinux.org/show_bug.cgi?id=1371 for this. You need patch from this commit http://git.openembedded.org/cgit.cgi/meta-openembedded/commit/?id=852 ac4b589adb186191ad70a2fa3472d5b351ec4 or upgrade to 2.1 Martin, thanks for the suggestion! Yes, I found 2.1 had integrated the fix, so I think we should choose to upgrade the package to 2.1 (I compared the source codes of 2.0 and 2.1 and looks they don't have many differences in other aspects). I'll send out a patch later today. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] bluez4: Added new recipe 4.96 and removed 4.82 version
Cui, Dexuan wrote on 2011-08-16: Martin Jansa wrote on 2011-08-16: On Tue, Aug 16, 2011 at 10:40:38AM +0800, Cui, Dexuan wrote: Saul Wold wrote on 2011-08-16: On 08/12/2011 01:04 AM, Noor, Ahsan wrote: From: Noor Ahsannoor_ah...@mentor.com * Added new recipe 4.96 and removed 4.82 version and its files. Signed-off-by: Noor Ahsannoor_ah...@mentor.com Merged into OE-Core The patch causes a failure: NOTE: package bluez-hcidump-2.0-r0: task do_compile: Failed I reported http://bugzilla.pokylinux.org/show_bug.cgi?id=1371 for this. You need patch from this commit http://git.openembedded.org/cgit.cgi/meta-openembedded/commit/?id=852 ac4b589adb186191ad70a2fa3472d5b351ec4 or upgrade to 2.1 Martin, thanks for the suggestion! Yes, I found 2.1 had integrated the fix, so I think we should choose to upgrade the package to 2.1 (I compared the source codes of 2.0 and 2.1 and looks they don't have many differences in other aspects). I'll send out a patch later today. This is the patch. http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/masterid=17e0fb707e9ad926058898d39d32168f4e582ed1 I'm testing my branch with other patches. So I'll wait for several hours (2~4 hours) and send out all the patches together. :-) Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] tcf-agent: Add openssl to DEPENDS
Khem Raj wrote on 2011-08-17:
It ends in errors like below otherwise
| framework/channel_tcp.c:34:27: fatal error: openssl/ssl.h: No such
file or directory
| compilation terminated.
| make: *** [obj/GNU/Linux/arm/Debug/framework/channel_tcp.o] Error 1
| make: *** Waiting for unfinished jobs
| + die 'oe_runmake failed'
| + bbfatal 'oe_runmake failed'
| + echo 'ERROR: oe_runmake failed'
| ERROR: oe_runmake failed
| + exit 1
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-devtools/tcf-agent/tcf-agent_svn.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_svn.bb
b/meta/recipes-devtools/tcf-agent/tcf-agent_svn.bb index
3f97f69..37591c2 100644 ---
a/meta/recipes-devtools/tcf-agent/tcf-agent_svn.bb +++
b/meta/recipes-devtools/tcf-agent/tcf-agent_svn.bb @@ -8,7 +8,7 @@
LIC_FILES_CHKSUM =
file://../epl-v10.html;md5=7aa4215a330a0a4f6a1cbf8da1a0879f
SRCREV = 1855
PV = 0.0+svnr${SRCPV}
-PR = r0
+PR = r1
SRC_URI =
svn://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk;module=ag
ent;p roto=http \
http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/epl-v10.h
tml;na me=epl \ @@ -19,7 +19,7 @@ SRC_URI =
svn://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk;module=ag
SRC_URI[epl.md5sum] = 7aa4215a330a0a4f6a1cbf8da1a0879f
SRC_URI[epl.sha256sum] =
4fd64aeed340d62a64a8da4b371efe0f6d0d745f4d2dbefacba86c646d36bc7 2
-DEPENDS = util-linux
+DEPENDS = util-linux openssl
RDEPENDS_${PN} = bash
S = ${WORKDIR}/agent
Hi, I have sent out the same patch 8+ hours ago. :-)
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] bluez4: Added new recipe 4.96 and removed 4.82 version
Saul Wold wrote on 2011-08-16: On 08/12/2011 01:04 AM, Noor, Ahsan wrote: From: Noor Ahsannoor_ah...@mentor.com * Added new recipe 4.96 and removed 4.82 version and its files. Signed-off-by: Noor Ahsannoor_ah...@mentor.com Merged into OE-Core The patch causes a failure: NOTE: package bluez-hcidump-2.0-r0: task do_compile: Failed I reported http://bugzilla.pokylinux.org/show_bug.cgi?id=1371 for this. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
Darren Hart wrote on 2011-08-09: On 08/08/2011 07:13 PM, Cui, Dexuan wrote: From 593e3506f4d4d9f6030100eac8c8e0af7f8ce3eb Mon Sep 17 00:00:00 2001 From: Dexuan Cui dexuan@intel.com Date: Thu, 04 Aug 2011 06:53:20 + Subject: scripts/oe-buildenv-internal: improve the error detecting for $BDIR Thanks a lot to Darren Hart and Paul Eggleton's suggestions! A description of this improvement from Darren is: Drop the above two lines, we don't need these in the permanent git history :-) Simply adding a pair of CC lines below the Signed-off-by for Paul and myself is sufficient to indicate our involvement. If a significant portion of the patch had been authored by either Paul or myself, then getting our permission to include our Signed-off-by would be appropriate. In this case, a simple CC will suffice. Ok, got it. 2 Error: / is not supported as a build directory. I understand wanting to use stderr, but I don't see the 2 very often in our shell scripts. Is this common practice? If so, it's fine, I'm just wondering. I'm not sure this is common practice. I'm just following the existing style in scripts/oe-buildenv-internal and scripts/oe-setup-builddir. :-) + # buggy readlink of Ubuntu 10.04 that doesn't ignore + trailing slash a buggys/of/in/ slashes Thanks for pointing my mistakes +# and hence readlink -f new_dir_to_be_created/ returns empty. +# See YOCTO #671 for details. Please don't include references to bug numbers in the code. Imagine what it would look like if we included every bug in the source! :-) Reference the bug in the git commit comment header. OK, got it. +BDIR=`echo $BDIR | sed -re 's|/+$||'` + +BDIR=`readlink -f $BDIR` +if [ -z $BDIR ]; then +PARENTDIR=`dirname $1` +echo 2 Error: the directory $PARENTDIR does not exist? return 1 fi fi With the trivial changes mentioned above, this looks good to me. Hi Darren, thanks a lot for all the suggestions! I appreciate your efforts to help to make the patch better. Below is the updated patch (also pasted at the end of the mail): http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bug-671id=2ece3a84d646bb4bf83f3c8aa3067cb99989da47 Please review it. Thanks, -- Dexuan commit 2ece3a84d646bb4bf83f3c8aa3067cb99989da47 Author: Dexuan Cui dexuan@intel.com Date: Thu Aug 4 14:53:20 2011 +0800 scripts/oe-buildenv-internal: improve the error detecting for $BDIR The previous fix for a bug in Ubuntu 10.04 readlink, be2a2764d8ceb398d81714661e6f199c8b11946c, notified the user when a trailing slash was used. As there is no semantic difference, simply remove any trailing slashes and proceed without nagging the user. See [YOCTO #671] for more details. Signed-off-by: Dexuan Cui dexuan@intel.com Cc: Darren Hart dvh...@linux.intel.com Cc: Paul Eggleton paul.eggle...@linux.intel.com diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index 117b0c5..61ac18c 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -28,14 +28,21 @@ if [ x$BDIR = x ]; then if [ x$1 = x ]; then BDIR=build else -BDIR=`readlink -f $1` -if [ -z $BDIR ]; then -if expr $1 : '.*/$' /dev/null; then -echo 2 Error: please remove any trailing / in the argument. -else -PARENTDIR=`dirname $1` -echo 2 Error: the directory $PARENTDIR doesn't exist? -fi +BDIR=$1 +if [ $BDIR = / ]; then +echo 2 Error: / is not supported as a build directory. +return 1 +fi + +# Remove any possible trailing slashes. This is used to work around +# buggy readlink in Ubuntu 10.04 that doesn't ignore trailing slashes +# and hence readlink -f new_dir_to_be_created/ returns empty. +BDIR=`echo $BDIR | sed -re 's|/+$||'` + +BDIR=`readlink -f $BDIR` +if [ -z $BDIR ]; then +PARENTDIR=`dirname $1` +echo 2 Error: the directory $PARENTDIR does not exist? return 1 fi fi ___ 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] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
Darren Hart wrote on 2011-08-09: On 08/09/2011 07:04 AM, Cui, Dexuan wrote: Hi Darren, thanks a lot for all the suggestions! I appreciate your efforts to help to make the patch better. Below is the updated patch (also pasted at the end of the mail): http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcu i/ bug-671id=2ece3a84d646bb4bf83f3c8aa3067cb99989da47 -- Dexuan commit 2ece3a84d646bb4bf83f3c8aa3067cb99989da47 Author: Dexuan Cui dexuan@intel.com Date: Thu Aug 4 14:53:20 2011 +0800 scripts/oe-buildenv-internal: improve the error detecting for $BDIR The previous fix for a bug in Ubuntu 10.04 readlink, be2a2764d8ceb398d81714661e6f199c8b11946c, notified the user when a trailing slash was used. As there is no semantic difference, simply remove any trailing slashes and proceed without nagging the user. See [YOCTO #671] for more details. Signed-off-by: Dexuan Cui dexuan@intel.com Cc: Darren Hart dvh...@linux.intel.com Cc: Paul Eggleton paul.eggle...@linux.intel.com Looks good, Acked-by: Darren Hart dvh...@linux.intel.com Thanks, Darren! Hi RP, could you please pull the patch? http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bug-671id=2ece3a84d646bb4bf83f3c8aa3067cb99989da47 Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
Cui, Dexuan wrote on 2011-08-04: Darren Hart wrote on 2011-08-04: On 08/04/2011 12:37 AM, Cui, Dexuan wrote: Please remember to include a description of the problem and the approach taken to fix it. This eliminates wasted time trying to decipher it later or by people unfamiliar with the history. This is important even for simple changes. In this case something like: The previous fix for a bug in Ubuntu 10.04 readlink, $COMMIT_ID, notified the user when a trailing slash was used. As there is no semantic difference, simply remove any trailing slashes and proceed without nagging the user. Thanks! I'll use the description. diff --git a/scripts/oe-buildenv-internal This shouldn't be a question. If the documented behavior of readlink is to return empty when the path doesn't exist, then assume this to be the case. The latest manual of readlink says readlink should ignore trailing slash. Also, it is a good idea to avoid contractions in printed error messages. echo 2 Error: the directory $PARENTDIR does not exist. Ok, I'll change doesn't to does not. Otherwise, this looks good to me. Please review the new patch (I paste it at the end of the mail, too) http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bug-671id=593e3506f4d4d9f6030100eac8c8e0af7f8ce3eb Hi Darren, Could you please comment on this new version of patch? I sent it out for several days ago. Maybe it was drowned in the mailing list. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
Darren Hart wrote on 2011-08-04: On 08/04/2011 12:37 AM, Cui, Dexuan wrote: Please remember to include a description of the problem and the approach taken to fix it. This eliminates wasted time trying to decipher it later or by people unfamiliar with the history. This is important even for simple changes. In this case something like: The previous fix for a bug in Ubuntu 10.04 readlink, $COMMIT_ID, notified the user when a trailing slash was used. As there is no semantic difference, simply remove any trailing slashes and proceed without nagging the user. Thanks! I'll use the description. diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index 117b0c5..4a44174 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -28,14 +28,16 @@ if [ x$BDIR = x ]; then if [ x$1 = x ]; then BDIR=build else -BDIR=`readlink -f $1` -if [ -z $BDIR ]; then - if expr $1 : '.*/$' /dev/null; then -echo 2 Error: please remove any trailing / in the argument. - else -PARENTDIR=`dirname $1` -echo 2 Error: the directory $PARENTDIR doesn't exist? -fi + BDIR=$1 +if [ $BDIR = / ]; then +echo 2 Error: / is not supported as a build directory. + return 1 +fi +BDIR=`echo $BDIR | sed -re 's|/+$||'` + BDIR=`readlink -f $BDIR` +if [ -z $BDIR ]; then + PARENTDIR=`dirname $1` +echo 2 Error: the directory $PARENTDIR doesn't exist? This shouldn't be a question. If the documented behavior of readlink is to return empty when the path doesn't exist, then assume this to be the case. The latest manual of readlink says readlink should ignore trailing slash. Also, it is a good idea to avoid contractions in printed error messages. echo 2 Error: the directory $PARENTDIR does not exist. Ok, I'll change doesn't to does not. Otherwise, this looks good to me. Please review the new patch (I paste it at the end of the mail, too) http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bug-671id=593e3506f4d4d9f6030100eac8c8e0af7f8ce3eb Thanks! -- Dexuan commit 593e3506f4d4d9f6030100eac8c8e0af7f8ce3eb Author: Dexuan Cui dexuan@intel.com Date: Thu Aug 4 14:53:20 2011 +0800 scripts/oe-buildenv-internal: improve the error detecting for $BDIR Thanks a lot to Darren Hart and Paul Eggleton's suggestions! A description of this improvement from Darren is: The previous fix for a bug in Ubuntu 10.04 readlink, be2a2764d8ceb398d81714661e6f199c8b11946c, notified the user when a trailing slash was used. As there is no semantic difference, simply remove any trailing slashes and proceed without nagging the user. Signed-off-by: Dexuan Cui dexuan@intel.com diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index 117b0c5..9988c9f 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -28,14 +28,22 @@ if [ x$BDIR = x ]; then if [ x$1 = x ]; then BDIR=build else -BDIR=`readlink -f $1` -if [ -z $BDIR ]; then -if expr $1 : '.*/$' /dev/null; then -echo 2 Error: please remove any trailing / in the argument. -else -PARENTDIR=`dirname $1` -echo 2 Error: the directory $PARENTDIR doesn't exist? -fi +BDIR=$1 +if [ $BDIR = / ]; then +echo 2 Error: / is not supported as a build directory. +return 1 +fi + +# Remove possible trailing slash. This is used to work around +# buggy readlink of Ubuntu 10.04 that doesn't ignore trailing slash +# and hence readlink -f new_dir_to_be_created/ returns empty. +# See YOCTO #671 for details. +BDIR=`echo $BDIR | sed -re 's|/+$||'` + +BDIR=`readlink -f $BDIR` +if [ -z $BDIR ]; then +PARENTDIR=`dirname $1` +echo 2 Error: the directory $PARENTDIR does not exist? return 1 fi fi ___ 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] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
Phil Blundell wrote on 2011-08-04: On Thu, 2011-08-04 at 22:49 +0800, Cui, Dexuan wrote: +BDIR=`readlink -f $BDIR` +if [ -z $BDIR ]; then +PARENTDIR=`dirname $1` +echo 2 Error: the directory $PARENTDIR does not exist? return 1 fi fi Just out of curiosity, could you not just do mkdir -p $BDIR and avoid this whole set of complicated tests? Or is there some reason why it's actually important to know whether the parent directory existed already? Hi Phil, Actually in scripts/oe-setup-builddir, we do have a line mkdir -p $BUILDDIR/conf . The issue is: readlink -f not_existent_dir/build returns empty, so BUILDDIR would be assigned with `pwd` and this is not expected. I don't really know why the test readlink -f is here -- readlink -f is used 3 times in scripts/oe-buildenv-internal. Maybe RP knows the history? I also think we can drop the tests readlink -f since we use mkdir -p? Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Add basic PowerPC core tune config (bug?)
Saul Wold wrote on 2011-07-28:
On 07/27/2011 10:25 PM, Kumar Gala wrote:
For some reason when I get to do_rootfs for core-image-sato when using
rpms I run into an issue in that:
${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
Isn't expanding or taking the assignment in
meta/conf/machine/include/tune-ppcFOO.inc but just using what it
found in meta/conf/bitbake.conf
I believe that I am seeing this also with an atom-pc build, where the
PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
list of ARCHS that includes core2 (which atom-pc should be).
Hi, I'm suffering from the exactly same issue... :-(
I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending yet.
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] tcf-agent: upgrade to the latest stable revision 0.0+svnr1855
Saul Wold wrote on 2011-07-22: There seems to be a compile issue with this patch. For an X86 Build fatal error: uuid/uuid.h: No such file or directory | compilation Hi Saul, Sorry! We didn't do enough test... Lianhao and I have got the causes of the failures. This uuid.h issue is due to the lackness of util-linux in DEPENDS -- the new tcf-agent code introduces the dependency. And then for an ARM build: services/dwarfframe.c | In file included from framework/cpudefs.c:33:0: | ././machine/cpudefs-ext.h:23:26: fatal error: cpudefs-mdep.h: No | such file or directory | compilation terminated. | make: *** The new tcf-agent code by default enables some services we don't actually need, and the they cause the ARM build failure. We added the following to fix the issue: +CFLAGS += -DSERVICE_RunControl=0 -DSERVICE_Breakpoints=0 \ +-DSERVICE_Memory=0 -DSERVICE_Registers=0 -DSERVICE_MemoryMap=0 \ +-DSERVICE_StackTrace=0 -DSERVICE_Symbols=0 -DSERVICE_LineNumbers=0 \ +-DSERVICE_Expressions=0 Below is the new commit(in the same branch dcui/tcf-agent) http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/tcf-agentid=ba36534bfc048d7bd2b15dc55ba253cc98c3e037 Currently Lianhao and I are doing more testing and will report back asap. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] tcf-agent: upgrade to the latest stable revision 0.0+svnr1855
Cui, Dexuan wrote on 2011-07-22: Saul Wold wrote on 2011-07-22: There seems to be a compile issue with this patch. Hi Saul, Lianhao and I have made the v2 patches and did tests. I sent out the patches just now. Please review them. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] powertop: inherit update-alternatives and use a higher priority than busybox
Tom Rini wrote: On 07/07/2011 01:39 AM, Dexuan Cui wrote: busybox-1.18.4 installs /bin/powertop and the powertop recipe installs /usr/bin/powertop. So, in PATH, if /bin appears before /usr/bin, we would run the version offered by busybox, which has a very limited function (e.g., no parameter is accepted) and this causes trouble to eclipse plugin. We can use update-alternatives for powertop with higher priority to resolve the issue. Fixes [YOCTO #1208] Signed-off-by: Dexuan Cui dexuan@intel.com This fix seems a bit incomplete. Why is busybox putting powertop into /bin when it almost certainly belongs in /usr/bin like the real recipe was placing it. busybox needs a fix here too. Thanks for the comment! I was hesitant about fixing busybox as I wasn't sure if it's worthy to make a patch to only fix the path for busybox. I don't know why busybox puts it into /bin. I think the best place may be /usr/sbin/. A little unluckily this patch to powertop has been already in poky master... So maybe we could try to fix the recipes in future, e.g., when upgrading them. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] The swap partition's size is too big for BSP?
Richard Purdie wrote: On Mon, 2011-07-04 at 13:35 +0800, Cui, Dexuan wrote: In meta/recipes-core/initrdscripts/files/init-install.sh, we have # 5% for the swap swap_ratio=5 # dexuan: this variable is not used at all! ... swap_size=$((disk_size*5/100)) This algorithm seems too wasty -- e.g., for a CrownBay box with a 160GB disk, we would create a 8GB swap partition while the box has only 1GB memory. What's the proper swap size? This link http://www.cyberciti.biz/tips/linux-swap-space.html discussed this and I think the below algorithm seems suitable for us: Systems with 2GB of ram or less require the same size of swap space Systems with 2GB to 4GB of ram require a minimum of 2GB of swap space Systems with 4GB to 16GB of ram require a minimum of 4GB of swap space Systems with 16GB to 64GB of ram require a minimum of 8GB of swap space Systems with 64GB to 256GB of ram require a minimum of 16GB of swap space Any comment? Looks like a much better idea to me, I'll take patches :) Ok, I'll try to make a patch for this algorithm. For reference if you want to do suspend to disk (swap) you need a lot of swap space btw. Still no where near that much though! Does (or should )Yocto Linux support suspend-to-disk? I'm not sure about this. BTW: Linux can alse use a regular file as swap area. So in case the swap size is not enough (e.g., for suspend-to-disk), I think a user could create a big enough file to meet the need (I didn't test this with Linux yet). Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] The swap partition's size is too big for BSP?
Richard Purdie wrote: On Mon, 2011-07-04 at 20:02 +0800, Cui, Dexuan wrote: Richard Purdie wrote: For reference if you want to do suspend to disk (swap) you need a lot of swap space btw. Still no where near that much though! Does (or should )Yocto Linux support suspend-to-disk? I'm not sure about this. BTW: Linux can alse use a regular file as swap area. So in case the swap size is not enough (e.g., for suspend-to-disk), I think a user could create a big enough file to meet the need (I didn't test this with Linux yet). I don't think we've supported it in the past, its just a datapoint to keep in mind. Ok, so I can put a comment when I make the patch, saying this new algorithm doesn't work with suspend-to-disk in future. For reference, you can't use a file easily since the VM data needs to be available as the kernel boots to be able to resume from it. I admit I didn't try this on Linux. Windows does use a regular file when doing suspend-to-disk, so I thought Linux could do it, too... :-) Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [Draft design][RFC] Running postinst at rootfs generation time
Hauser, Wolfgang (external) wrote: Beside the discussed changes, the postinst scripts should be executed in the dependency order. At the time, the scripts are executed in alphabetic order, which breaks the image generation if depended packages are not in alphabetic order. e.g. busybox and busybox subpackages (busybox-mdev). Regards Wolfgang Hauser Thank all for the suggestions! I created a wiki page to summarize the mail threads: https://wiki.yoctoproject.org/wiki/Run_postinst_during_rootfs_generation Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] The swap partition's size is too big for BSP?
In meta/recipes-core/initrdscripts/files/init-install.sh, we have # 5% for the swap swap_ratio=5 # dexuan: this variable is not used at all! ... swap_size=$((disk_size*5/100)) This algorithm seems too wasty -- e.g., for a CrownBay box with a 160GB disk, we would create a 8GB swap partition while the box has only 1GB memory. What's the proper swap size? This link http://www.cyberciti.biz/tips/linux-swap-space.html discussed this and I think the below algorithm seems suitable for us: Systems with 2GB of ram or less require the same size of swap space Systems with 2GB to 4GB of ram require a minimum of 2GB of swap space Systems with 4GB to 16GB of ram require a minimum of 4GB of swap space Systems with 16GB to 64GB of ram require a minimum of 8GB of swap space Systems with 64GB to 256GB of ram require a minimum of 16GB of swap space Any comment? Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] busybox: bump PR to enable largefile support
Cui, Dexuan wrote: The following changes since commit 4d60d32a60ae0fae1002b27cd7d20c28532f4932: poky.conf: add largefile support into DISTRO_FEATURES (2011-07-01 17:35:26 +0800) Dexuan Cui (1): busybox: bump PR to enable largefile support are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/mkswap http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/mkswap meta/recipes-core/busybox/busybox_1.18.4.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) BTW: please see my first commit in p...@yoctoproject.org. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] bump PR to fix the perl-native issue
Cui, Dexuan wrote:
I did a core-image-sato-sdk and meta-toolchain-gmae building using a
commit of May 12 between 605141a9(the perl-native workaround patch)
and 3ba6d018(populate perl-native into its own dir), and grepped
${STAGING_BINDIR_NATIVE}/perl in
${STAGING_BINDIR_NATIVE} to find out all the scripts needed to
address. Some recipes' PRs have been bumped, so this patch only bumps
the omitted ones.
Please review the patch.
The following changes since commit
2163461ec94528ecf046a04edc5db3d2dd3a6b8b:
systemtap: remove non-core COMPATIBLE_MACHINES (2011-06-16 22:14:06
+0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dcui/bump_PR
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/bump_PR
Dexuan Cui (1):
glib-2.0,intltool,rpm,sgmlspl-native: Bump PR to resolve perl-native
issue
meta/recipes-core/glib-2.0/glib-2.0_2.27.5.bb |2 +-
meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb |2 +-
meta/recipes-devtools/intltool/intltool_0.40.6.bb |2 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb |2 +-
.../sgmlspl/sgmlspl-native_1.03ii.bb |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] bump PR to fix the perl-native issue
Cui, Dexuan wrote:
Cui, Dexuan wrote:
I did a core-image-sato-sdk and meta-toolchain-gmae building using a
commit of May 12 between 605141a9(the perl-native workaround patch)
and 3ba6d018(populate perl-native into its own dir), and grepped
${STAGING_BINDIR_NATIVE}/perl in
${STAGING_BINDIR_NATIVE} to find out all the scripts needed to
address. Some recipes' PRs have been bumped, so this patch only
bumps the omitted ones.
Please review the patch.
The following changes since commit
2163461ec94528ecf046a04edc5db3d2dd3a6b8b:
systemtap: remove non-core COMPATIBLE_MACHINES (2011-06-16
22:14:06 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dcui/bump_PR
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/bump_PR
Dexuan Cui (1):
glib-2.0,intltool,rpm,sgmlspl-native: Bump PR to resolve
perl-native issue
meta/recipes-core/glib-2.0/glib-2.0_2.27.5.bb |2 +-
meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb |2 +-
meta/recipes-devtools/intltool/intltool_0.40.6.bb |2 +-
meta/recipes-devtools/rpm/rpm_5.4.0.bb |2 +-
.../sgmlspl/sgmlspl-native_1.03ii.bb |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
(Sorry for my previous empty reply to this thead. I pressed enter too
hastily...)
Looks the patch was neglected somehow, either? :-)
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] grub: add -fno-reorder-functions into STAGE2_COMPILE
Cui, Dexuan wrote:
This is used to work around a gcc-4.6's bug about the option.
[YOCTO #1099]
diff --git a/meta/recipes-bsp/grub/grub_0.97.bb
b/meta/recipes-bsp/grub/grub_0.97.bb
index 131d942..ffacb61 100644
--- a/meta/recipes-bsp/grub/grub_0.97.bb
+++ b/meta/recipes-bsp/grub/grub_0.97.bb
RDEPENDS_${PN} = diffutils
-PR = r3
+PR = r6
Sorry, PR should be r4 here... I used r6 in my debugging.
I forgot to clean this up when I sent the patch.
I've re-pushed my branch.
Please use the new commit:
http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=dcui/masterid=5c670ef29d828e76ae101fcfe9234732af759dfa
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] prelink_git.bb: Only block the postinst script when no image-prelink (v2)
Mark Hatle wrote:
[V2 - fix a small typo in the comment]
If image-prelink is being used, the system will automatically prelink
the target image. This avoids the need to run the postinst prelink
script at first boot. However, if the user has not enabled image
prelinking -- then we do enable the script to run on first boot.
# The cron script attempts to re-prelink the system daily -- on
@@ -58,11 +58,13 @@ do_install_append () {
install -m 0644 ${WORKDIR}/macros.prelink
${D}${sysconfdir}/rpm/macros.prelink }
+# If we're using image-prelink, we want to skip this on the host side
+# but still do it if the package is installed on the target...
pkg_postinst_prelink() {
#!/bin/sh
if [ x$D != x ]; then
- exit 1
+ ${@base_contains('USER_CLASSES', 'image-prelink', 'exit 0', 'exit
1', d)} fi
prelink -a
Even if without the patch, we still skip this on the host side -- previously we
skipped with exit 1, and with the patch now we skip with exit 1 or exit 0.
So IMHO looks the patch doesn't actually help? :-)
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] prelink_git.bb: Only block the postinst script when no image-prelink (v2)
Mark Hatle wrote: On 6/29/11 9:42 AM, Phil Blundell wrote: On Wed, 2011-06-29 at 22:39 +0800, Cui, Dexuan wrote: Even if without the patch, we still skip this on the host side -- previously we skipped with exit 1, and with the patch now we skip with exit 1 or exit 0. So IMHO looks the patch doesn't actually help? :-) If the script exits with 0 in offline mode then it won't get rerun at first boot on the target. If it exits with 1 then it will. Yes. Since we've already run the equivalent of the script in the image-prelink, we can safely exit with a '0' telling the image preinst code that this was successfully run and to ignore it at first boot. Ok, got it! Thanks very much for the explanation! Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Khem Raj wrote: On 06/28/2011 04:07 AM, Paul Eggleton wrote: On Tuesday 28 June 2011 07:45:09 Koen Kooi wrote: So it works as expected, but the output is a bit confusing. I have a few (conflicting) suggestions: 1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.: meta-archos branch = master meta-archos revision= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad 2) for the extra layers put branch and revision on a single line: meta-archos = master/413933fb5f62574e38a9a1e38905ba6e9c1be4ad I'd go with option 2 over 1, personally - the list gets rather long on something like Angstrom, better to keep it short. I would say to do it uniformly and treat oe-core as one of layers too when emitting this info Ok. I'll make a new version for this. BTW: meta and mete-yocto belong to the same git repo actually, so do you think showing them in one line like this meta,meta-yocto = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 is better than showing 2 lines like this: meta = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 meta-yocto= master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 ? Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Koen Kooi wrote: Op 29 jun 2011, om 18:14 heeft Cui, Dexuan het volgende geschreven: Khem Raj wrote: On 06/28/2011 04:07 AM, Paul Eggleton wrote: On Tuesday 28 June 2011 07:45:09 Koen Kooi wrote: BTW: meta and mete-yocto belong to the same git repo actually, so do you think showing them in one line like this meta,meta-yocto = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 is better than showing 2 lines like this: meta = master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 meta-yocto= master:2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 That breaks with repos like meta-intel and meta-oe. Maybe something Could you please explain a bit more? like this: METADATA_BRANCH = master METADATA_REVISION = 16f84804cfbe472833ff00bfd2694947eabf8e20 meta-angstrom = master:fd68a073e9669fdee0a9dc0483b3d39d3e3e0b46 meta-oe = master:8a12ecca32766ecdceb72cae76e93f8aadcf3669 meta-efl same meta-gpe same meta-gnome same meta-texasinstruments = master:2e16e2fbd93bc00bc0a0afaf86975da7778eaa43 meta-efikamx = master:70cff8742d629fd32463e3ef1bddb83f04d08dc5 meta-nslu2 = master:aaf918b85d7a8155d6e7c0ff042808346998fbea meta-htc = master:f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-nokia same meta-openmoko same meta-palm same meta-zaurus same meta-sugarbay = master:50661bf038a34702f3aa139c3ea0d67fbb0ce5db meta-crownbay same meta-emenlowsame meta-fishriver same meta-jasperforest same meta-n450 same meta-ettus = master:c34c30fa29f7ab484cc90efb9713325da8e01460 meta-openpandora = master:edaf6e751f873ed7a82c1116d3d58b9a070052dc meta-archos = master:4b689944d968b0ef4d0e9928e76c54f8a76a919a I think the below is a better format(but the line may be too long?)? meta,meta-yocto = master:16f84804cfbe472833ff00bfd2694947eabf8e20 meta-angstrom = master:fd68a073e9669fdee0a9dc0483b3d39d3e3e0b46 meta-oe,meta-efl,meta-gpe,meta-gnome = master:8a12ecca32766ecdceb72cae76e93f8aadcf3669 meta-texasinstruments = master:2e16e2fbd93bc00bc0a0afaf86975da7778eaa43 meta-efikamx= master:70cff8742d629fd32463e3ef1bddb83f04d08dc5 meta-nslu2 = master:aaf918b85d7a8155d6e7c0ff042808346998fbea meta-htc,meta-nokia,meta-openmoko,meta-palm,meta,zaurus = master:f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-sugarbay,meta-crownbay,meta-emenlow,meta-fishriver,meta-jasperforest,meta-n450, = master:50661bf038a34702f3aa139c3ea0d67fbb0ce5db meta-ettus = master:c34c30fa29f7ab484cc90efb9713325da8e01460 meta-openpandora= master:edaf6e751f873ed7a82c1116d3d58b9a070052dc meta-archos = master:4b689944d968b0ef4d0e9928e76c54f8a76a919a Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Mark Hatle wrote: On 6/28/11 1:45 AM, Koen Kooi wrote: Op 28 jun 2011, om 07:37 heeft Dexuan Cui het volgende geschreven: ... So it works as expected, but the output is a bit confusing. I have a few (conflicting) suggestions: 1) replace _BRANCH and _REVISION with ' branch' and ' revision', e.g.: meta-archos branch = master meta-archos revision= 413933fb5f62574e38a9a1e38905ba6e9c1be4ad 2) for the extra layers put branch and revision on a single line: meta-archos = master/413933fb5f62574e38a9a1e38905ba6e9c1be4ad 3) Move the revision info down, e..g OE Build Configuration: BB_VERSION = 1.13.1 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = beagleboard DISTRO = angstrom DISTRO_VERSION = v2011.06-core TARGET_FPU = hard METADATA_BRANCH = master METADATA_REVISION = 364ca0d2d0399c8cc6d3b3fc28308e1e14673544 meta-angstrom_BRANCH= master meta-angstrom_REVISION = c19c342c62416752117c2dce4696840bc864f647 etc. What do you think about that? I think my preference is either 3 or a combination of 2 3. To me the important bits are the configuration settings, followed by the components that are being used as a secondary concern. It will all help in debugging and issue, but if the target/distro isn't correct then it doesn't matter what the rest is. --Mark Hi, thank you very much for the suggestions! I worked out a vesion 2 patch that combines 2 and 3: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/banner_v2id=2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 Please note I use a colon mark rather than a slash mark for better readabability since a branch name can contain colon. An output result in my side is: OE Build Configuration: BB_VERSION = 1.13.1 TARGET_ARCH = i586 TARGET_OS = linux MACHINE = qemux86 DISTRO = poky DISTRO_VERSION = 1.0+snapshot-20110628 TARGET_FPU = METADATA_BRANCH = dcui/banner_v2 METADATA_REVISION = 2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 meta-sugarbay = dcui/test1:76d1178ba1a43cf6457c89717134aeb9f1275fae Please let me know if this new output looks ok. BTW, Koen, even with this v2 patch, the list looks still pretty long in your side. I noticed there are some layers with the same revision: e.g., meta-htc_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-nokia_BRANCH = master meta-nokia_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-openmoko_BRANCH= master meta-openmoko_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-palm_BRANCH= master meta-palm_REVISION = f37d05ca7450f85642cea0e43a75df10663bd8f6 meta-zaurus_BRANCH = master meta-zaurus_REVISION= f37d05ca7450f85642cea0e43a75df10663bd8f6 I guess they actually belong to the same repo. In this case, maybe we can further improve the output format to: meta-htc,nokia,openmoko,palm,zaurus:f37d05ca7450f85642cea0e43a75df10663bd8f6 ? Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Koen Kooi wrote: Op 28 jun 2011, om 16:52 heeft Cui, Dexuan het volgende geschreven: Hi, thank you very much for the suggestions! I worked out a vesion 2 patch that combines 2 and 3: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/banner_v2id=2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 Could you in the future please base them on oe-core instead of poky? I just did 'git merge 2c2d9d7c0e942b6748bc8bd7d5980113bae9a836' and git blew up. Sorry... but to basing them on oe-core, do I need the permission to push my commits to my own branch in git://git.openembedded.org/openembedded-core-contrib? I suppose so and I should put my public key somewhere into the server? Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base.bbclass: show layer's branches/revisions in the banner info
Mark Hatle wrote: On 6/28/11 10:21 AM, Cui, Dexuan wrote: Koen Kooi wrote: Op 28 jun 2011, om 16:52 heeft Cui, Dexuan het volgende geschreven: Hi, thank you very much for the suggestions! I worked out a vesion 2 patch that combines 2 and 3: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/banner_v2id=2c2d9d7c0e942b6748bc8bd7d5980113bae9a836 Could you in the future please base them on oe-core instead of poky? I just did 'git merge 2c2d9d7c0e942b6748bc8bd7d5980113bae9a836' and git blew up. Sorry... but to basing them on oe-core, do I need the permission to push my commits to my own branch in git://git.openembedded.org/openembedded-core-contrib? I suppose so and I should put my public key somewhere into the server? You can push oe-core (based) changes to the poky-contrib tree. Many of us do this regularly. I base my changes usually on oe-core, unless they contain poky specific code.. I push both types to the same poky-contrib repository (in different branches of course). (I also always avoid merge, and always use cherry-pick when pulling code from someone else's branches into my own..) Thank Mark and Phil a lot for the explanation! I'll base my change to oe-core in future. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [Draft design][RFC] Running postinst at rootfs generation time
Hi all, below is an initial investigation about the task and we'll continue to further look into it. In poky we have 2 types of postinst scripts: one (type-1) can be (and has already been) run at rootfs generation time and the other (type-2) has to be delayed to the first-boot of target device. Type-2 makes target device's first-boot slow and it would be great if we can fix it and convert it to type-1. We can instrument a first-boot with minimal/sato first to see which postinstalls take the most time and then prioritise those ones to fix. I figurerd out a list of 33 recipes in total(recipes with the same name but with different versions are counted once) we possibly need to fix. For the recipes, we need try to find recipe-specific ways(use appropriately modified native utilities to generate caches, files, etc as necessary on the target filesystem). 11 recipes: these could be easily fixed if we add the properly-adjusted utilities adduser, addgroup, pwconv, etc. Scott is actually adding the utilites: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/useradd-rebasedid=99e54d9696104ed38ec1e3464e17aa1f9b8d98ac meta/recipes-devtools/distcc/distcc_2.18.3.bb meta/recipes-extended/cronie/cronie_1.4.7.bb meta/recipes-extended/at/at_3.1.12.bb:47 meta/recipes-support/hal/hal.inc:45 meta/recipes-core/dbus/dbus.inc:49 meta/recipes-connectivity/openssh/openssh_5.8p2.bb meta/recipes-connectivity/ppp-dialin/ppp-dialin_0.1.bb meta/recipes-graphics/x11-common/xserver-nodm-init.bb meta/recipes-multimedia/pulseaudio/pulseaudio.inc:87 meta/recipes-extended/shadow/shadow_4.1.4.3.bb:125 meta/classes/libc-package.bbclass 6 recipes: these should be easily fixed since the scripts are not related to special native utilites. meta/recipes-extended/sudo/sudo.inc meta/recipes-extended/sysklogd/sysklogd.inc meta/classes/update-rc.d.bbclass meta/recipes-connectivity/ppp/ppp_2.4.5.bb meta/recipes-graphics/pango/pango.inc meta/recipes-gnome/gtk+/gtk+.inc 4 recipes: we may need to add gtk-update-icon-cache-native. meta/classes/gtk-icon-cache.bbclass meta/recipes-gnome/librsvg/librsvg_2.32.1.bb meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.22.1.bb meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc 3 recipes: need to add gconftool-2-native? meta/classes/gconf.bbclass meta/recipes-graphics/mutter/mutter.inc meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb 3 recipes: dpkg --configure, opkg-cl configure: looks it's possible to fix them if we specify proper parematers? meta/recipes-devtools/dpkg/dpkg.inc meta/recipes-devtools/opkg/opkg_svn.bb meta/recipes-devtools/opkg/opkg_0.1.8.bb 1 recipe: prelink: we could propablly fix it, but I'm not sure yet. meta/recipes-devtools/prelink/prelink_git.bb 1 recipe: /etc/init.d/populate-volatile.sh update ; DBUSPID=`pidof dbus-daemon`: We can't fix this one. meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc The below 4 recipes need the related utilities and need more investigation. 1 recipe: update-modules meta/recipes-kernel/update-modules/update-modules_1.0.bb 1 recipe: systemctl meta/recipes-connectivity/avahi/avahi.inc 1 recipe: fc-cache meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb:37 1 recipe: gtk-query-immodules-2.0 meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_git.bb Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] linux-yocto: update meta SRCREV for new config groups
Tom Zanussi wrote: On Mon, 2011-06-27 at 05:56 -0700, Bruce Ashfield wrote: 2011/6/27 Cui, Dexuan dexuan@intel.com: Cui, Dexuan wrote: Hi, I got the following ERROR with the patch: Log data follows: Unstaged changes after reset: M arch/powerpc/boot/dts/mpc8315erdb.dts Deleted branch meta-temp (was cf7d7e5). WARNING: addon feature features/taskstats was not found ERROR: required features were not found. aborting ERROR: Function 'do_patch' failed Maybe we forgot to push the proper commits into the linux-yocto git repo? BTW, I'm building emenlow with today's poky master (commit a1f79a7896b) and mete-intel (commit 76d1178ba). Just noticed that you were using emenlow so updated the meta-intel SRCREVs, maybe that was the problem? Hi Tom, Yes, that is just the problem. With the new commit Update kernel SRCREVs in meta-intel repo, I don't have the issue now. Thank you and Bruce a lot for the quick fixing! Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] linux-yocto: update meta SRCREV for new config groups
Hi, I got the following ERROR with the patch:
Log data follows:
| Unstaged changes after reset:
| M arch/powerpc/boot/dts/mpc8315erdb.dts
| Deleted branch meta-temp (was cf7d7e5).
| WARNING: addon feature features/taskstats was not found
| ERROR: required features were not found. aborting
| ERROR: Function 'do_patch' failed
Maybe we forgot to push the proper commits into the linux-yocto git repo?
Thanks,
-- Dexuan
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Bruce
Ashfield
Sent: 2011年6月23日 5:29
To: richard.pur...@linuxfoundation.org
Cc: dvh...@linux.intel.com; openembedded-core@lists.openembedded.org;
k...@dominion.thruhere.net; Wold, Saul
Subject: [OE-core] [PATCH 1/2] linux-yocto: update meta SRCREV for new config
groups
Updating the SRCREV for the kernel repo's meta branch to capture
the following commits:
94fa015 meta: add taskstats experimental feature group
4fb2ed5 meta: enable freezer support
88d619e meta: enable fuse and cuse as modules
f465827 meta: add namespaces + experimental configs
fbdd376 meta: add devtmpfs config group
b04f6d9 meta: re-enable cgroups options in the standard kernel
There's also a change to the recipe itself to trigger the taskstats
optional config items by default. This is to allow the introduction
of these changes gradually, since other recipes inheriting the kernel
can add or ignore these options at their convenience.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto_2.6.37.bb |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
b/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
index 2ee801e..90943c2 100644
--- a/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
@@ -20,9 +20,9 @@ SRCREV_machine_qemuppc =
9d278962ff228ea9627a85b0d21ed717246ebf1f
SRCREV_machine_qemux86 = 57545699dff0b384bb16be74b0358059da5cce6a
SRCREV_machine_qemux86-64 = 5d36c23eecdc9663c9c3a2a511d4872d3b3fd669
SRCREV_machine = 12646d158aced2ba0122787bd56ff554e371091c
-SRCREV_meta = d948e0ddbc5f37bd3dc23cc1b398ab230e2e
+SRCREV_meta = 94fa015b130e96a3b6242a8ac4ff4cca9406951f
-PR = r18
+PR = r19
PV = ${LINUX_VERSION}+git${SRCPV}
SRCREV_FORMAT = meta_machine
@@ -33,6 +33,7 @@ COMPATIBLE_MACHINE =
(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)
# Functionality flags
KERNEL_REVISION_CHECKING ?= t
KERNEL_FEATURES=features/netfilter
+KERNEL_FEATURES_append= features/taskstats
KERNEL_FEATURES_append_qemux86= cfg/sound
KERNEL_FEATURES_append_qemux86-64= cfg/sound
--
1.7.0.4
___
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] [PATCH 1/2] linux-yocto: update meta SRCREV for new config groups
Cui, Dexuan wrote:
Hi, I got the following ERROR with the patch:
Log data follows:
Unstaged changes after reset:
M arch/powerpc/boot/dts/mpc8315erdb.dts
Deleted branch meta-temp (was cf7d7e5).
WARNING: addon feature features/taskstats was not found
ERROR: required features were not found. aborting
ERROR: Function 'do_patch' failed
Maybe we forgot to push the proper commits into the linux-yocto git
repo?
BTW, I'm building emenlow with today's poky master (commit a1f79a7896b) and
mete-intel (commit 76d1178ba).
After I reverted the line
KERNEL_FEATURES_append= features/taskstats,
at least linux-yocto's do_patch can work.
Thanks,
-- Dexuan
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
Of Bruce Ashfield Sent: 2011年6月23日 5:29
To: richard.pur...@linuxfoundation.org
Cc: dvh...@linux.intel.com; openembedded-core@lists.openembedded.org;
k...@dominion.thruhere.net; Wold, Saul
Subject: [OE-core] [PATCH 1/2] linux-yocto: update meta SRCREV for
new config groups
Updating the SRCREV for the kernel repo's meta branch to capture
the following commits:
94fa015 meta: add taskstats experimental feature group
4fb2ed5 meta: enable freezer support
88d619e meta: enable fuse and cuse as modules
f465827 meta: add namespaces + experimental configs
fbdd376 meta: add devtmpfs config group
b04f6d9 meta: re-enable cgroups options in the standard kernel
There's also a change to the recipe itself to trigger the taskstats
optional config items by default. This is to allow the introduction
of these changes gradually, since other recipes inheriting the kernel
can add or ignore these options at their convenience.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto_2.6.37.bb |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
b/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
index 2ee801e..90943c2 100644
--- a/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb
@@ -20,9 +20,9 @@ SRCREV_machine_qemuppc =
9d278962ff228ea9627a85b0d21ed717246ebf1f SRCREV_machine_qemux86 =
57545699dff0b384bb16be74b0358059da5cce6a SRCREV_machine_qemux86-64
= 5d36c23eecdc9663c9c3a2a511d4872d3b3fd669 SRCREV_machine =
12646d158aced2ba0122787bd56ff554e371091c -SRCREV_meta =
d948e0ddbc5f37bd3dc23cc1b398ab230e2e +SRCREV_meta =
94fa015b130e96a3b6242a8ac4ff4cca9406951f
-PR = r18
+PR = r19
PV = ${LINUX_VERSION}+git${SRCPV}
SRCREV_FORMAT = meta_machine
@@ -33,6 +33,7 @@ COMPATIBLE_MACHINE =
(qemuarm|qemux86|qemuppc|qemumips|qemux86-64) # Functionality flags
KERNEL_REVISION_CHECKING ?= t
KERNEL_FEATURES=features/netfilter
+KERNEL_FEATURES_append= features/taskstats
KERNEL_FEATURES_append_qemux86= cfg/sound
KERNEL_FEATURES_append_qemux86-64= cfg/sound
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] BUG: intltool depends on libxml-parser-perl to be installed on host
Otavio Salvador wrote: On Tue, Jun 21, 2011 at 12:20, Cui, Dexuan dexuan@intel.com wrote: I think I can reproduce the issue with the same steps on a Ubuntu 10.10 host. I'm going to further look into this. Please report a bug on the bugzilla, so we can better track it. :-) Sorry but I don't have an account on the tracking system and prefer if you do it. Hi, I reported http://bugzilla.yoctoproject.org/show_bug.cgi?id=1191 for the issue. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] fix the mesa-dri build failure after upgrading to newer glproto and dri2proto
Martin Jansa wrote: On Wed, Jun 15, 2011 at 9:19 AM, Dexuan Cui dexuan@intel.com wrote: Please review them. Acked-by: Martin.Jansa martin.ja...@gmail.com with sort of deja vu :) http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=de74afec8a067071d17365438d6c462664bc5054 http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=f02e320146c701ad0f02f7daf52acac6389c71fd http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=f2a73450a70d113d77fbf703772fbf0db81e8e61 Yes, I made the same mistake... I should be more careful. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] autoconf/automake: Bump PR to resolve perl-native issue
Saul Wold wrote: On 06/14/2011 12:48 AM, Koen Kooi wrote: To be clear: does the PR bump fix the issues or was there a fix earlier that lacked a PR bump? The fix was earlier and lacked the PR bump to these recipes. Sorry for the issue and thanks Saul for the fix! I knew the issue but I was not clear I should have bumped the PRs. I thought autoconf/aumake-native themselves didn't change... I'll be more careful. Thanks, -- Dexuan ___ 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 01/16] native.bbclass: allow a native package to be populated into its own dir
Phil Blundell wrote:
On Wed, 2011-06-01 at 21:18 +0800, Dexuan Cui wrote:
+PACKAGE_OWN_DIR =
+bindir .= ${PACKAGE_OWN_DIR}
+libdir .= ${PACKAGE_OWN_DIR}
+libexecdir .= ${PACKAGE_OWN_DIR}
I think the general idea of this patch is a good one but I'm not
terribly fond of the name of that variable. If this is meant to be a
path suffix that you can optionally set for native packages then how
about calling it something like NATIVE_PACKAGE_PATH_SUFFIX?
Hi Phil,
Thanks a lot for the suggestion.
Surely NATIVE_PACKAGE_PATH_SUFFIX is a much better naming! :-)
I'll change to use it.
Thanks,
-- Dexuan
___
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
Tom Rini wrote: On 06/01/2011 01:05 PM, Phil Blundell wrote: On Wed, 2011-06-01 at 12:39 -0700, Tom Rini wrote: Maybe race isn't quite the right word. But recipe A depends on lib$something-perl-native, and brings in perl-native. It also checks for perl in its auto-foo and finds our perl. It now also uses our perl when it wants a host perl and all of the potential bad things happen, yes? What are the circumstances in which it would want a host perl? I don't quite understand the issue here. Surely anything that the host perl can do, perl-native plus some combination of libfoo-perl-native can also do, right? So, here's the two things going on: - In some cases (libfoo-perl-native) we need to install various perl modules in order to build other target apps. This is the cpan case, iirc. We don't currently (and can't?) just play whatever games perl would like to do to use system-wide perl and a local to TMPDIR cpan directory. We instead go down the path of having perl-native. - In order to build perl for the target we need to have the same perl version available for use. What we do in oe-core (and oe.dev, historically) is provide perl-native for both of these cases. What falls down in this case is that once perl-native is built (and in our PATH), if it's a different version than system-wide perl, stuff starts failing on version mis-match. The patch series here fixes that by saying stuff must opt-in to having perl-native be in PATH rather than just system-wide perl. What I'm saying is that while in oe-core nothing falls down here (since nothing that gets perl-native also tries to just run 'perl') meta-oe is or will have failures. Unfortunately I don't have the test cases that drove me to make oe.dev like it is handy but I have a feeling that if we go down this path it won't be the last we see of the problem, but it might well pop up again. There is another option here, which is to make perl-native be perl-cross, live in its own special directory and figure out how to make a TMPDIR-specific cpan repository available for use by system-wide perl. Hi Tom, Thank you very much for the detailed explanation! However I'm actually new to cpan and know few about the history of that in oe.dev, so I'm not sure I know enough about the background to make a proper decision now. I suppose Richard would comment here. :-) Thanks, -- Dexuan ___ 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 01/16] native.bbclass: allow a native package to be populated into its own dir
Cui, Dexuan wrote:
Phil Blundell wrote:
On Wed, 2011-06-01 at 21:18 +0800, Dexuan Cui wrote:
+PACKAGE_OWN_DIR =
+bindir .= ${PACKAGE_OWN_DIR}
+libdir .= ${PACKAGE_OWN_DIR}
+libexecdir .= ${PACKAGE_OWN_DIR}
I think the general idea of this patch is a good one but I'm not
terribly fond of the name of that variable. If this is meant to be a
path suffix that you can optionally set for native packages then how
about calling it something like NATIVE_PACKAGE_PATH_SUFFIX?
Hi Phil,
Thanks a lot for the suggestion.
Surely NATIVE_PACKAGE_PATH_SUFFIX is a much better naming! :-)
I'll change to use it.
Hi RP, Phil,
A new branch dcui/master_perl-native_v2 was created for this better naming(this
is the only difference compared with the previous version):
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=dcui/master_perl-native_v2
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] dpkg's admindir: /var/dpkg or /var/lib/dpkg?
Hi, I happened to find a bug: in target, dpkg --list shows dpkg-query:
failed to open package info file `/var/lib/dpkg/status' for reading: No such
file or directory
Actually the files(status and available) does exist, but not in /var/lib/dpkg/
-- they're in /var/dpkg/. ln -s /var/dpkg/{status, available} /var/lib/dpkg
can resolve the issue.
grepping '/var/dpkg' shows there are many files(package_deb.bbclass,
rootfs_deb.bbclass, populate_sdk_deb.bbclas, apt.conf ) in which '/var/dpkg' is
used and /var/lib/dpkg is not used at all.
However, looks dpkg's default admindir is /var/lib/dpkg -- e.g., Ubuntu uses
this.
What should we do? Looks fixing the package dpkg's admindir in the do_configure
needs the least coding.
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] dpkg's admindir: /var/dpkg or /var/lib/dpkg?
Mark Hatle wrote:
On 5/18/11 4:27 AM, Cui, Dexuan wrote:
Hi, I happened to find a bug: in target, dpkg --list shows
dpkg-query: failed to open package info file `/var/lib/dpkg/status'
for reading: No such file or directory
Actually the files(status and available) does exist, but not in
/var/lib/dpkg/ -- they're in /var/dpkg/. ln -s /var/dpkg/{status,
available} /var/lib/dpkg can resolve the issue.
grepping '/var/dpkg' shows there are many files(package_deb.bbclass,
rootfs_deb.bbclass, populate_sdk_deb.bbclas, apt.conf ) in which
'/var/dpkg' is used and /var/lib/dpkg is not used at all.
However, looks dpkg's default admindir is /var/lib/dpkg -- e.g.,
Ubuntu uses this.
What should we do? Looks fixing the package dpkg's admindir in the
do_configure needs the least coding.
I would say that /var/lib/dpkg is the correct directory to use.
This matches the behavior on other deb bases systems. (It also
mimics other pkg managers who place their data into /var/lib/...)
Mark, thank you for the comment!
So looks we should fix any recipe that uses /var/dpkg?
The fact in poky /var/dpkg is widely used and /var/lib/dpkg is not used at all
may imply we chose /var/dpkg for some reason? Even
meta/recipes-devtools/dpkg/run-postinsts/run-postinsts and
meta/recipes-devtools/dpkg/run-postinsts/run-postinsts.awk use /var/dpkg.
Is it possible there is some story behind this? Please let me Cc more people
who touched this.
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [meta-intel] n450-audio.bb: ${POKYBASE} -- ${COREBASE}
Currently n450 can't build due to the issue:
diff --git a/meta-n450/recipes-bsp/n450-audio/n450-audio.bb
b/meta-n450/recipes-bsp/n450-audio/n450-audio.bb
index 90ec267..27904e3 100644
--- a/meta-n450/recipes-bsp/n450-audio/n450-audio.bb
+++ b/meta-n450/recipes-bsp/n450-audio/n450-audio.bb
@@ -2,7 +2,7 @@ SUMMARY = Provide a basic init script to enable audio
DESCRIPTION = Set the volume and unmute the Front mixer setting during boot.
SECTION = base
LICENSE = MIT
-LIC_FILES_CHKSUM =
file://${POKYBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58
+LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58
PR = r4
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][v2] [PATCH 1/1] package-index.bb: add support for deb and rpm.
Saul Wold wrote:
On 05/13/2011 02:53 AM, Dexuan Cui wrote:
From: Dexuan Cuidexuan@intel.com
diff --git a/meta/classes/package_deb.bbclass
b/meta/classes/package_deb.bbclass
index 4faeb4a..4cc0b69 100644
--- a/meta/classes/package_deb.bbclass
+++ b/meta/classes/package_deb.bbclass
@@ -431,3 +431,12 @@ python do_package_write_deb () {
do_package_write_deb[dirs] = ${PKGWRITEDIRDEB}
addtask package_write_deb before do_package_write after do_package
+
+do_package_index[depends] += dpkg-native:do_populate_sysroot
apt-native:do_populate_sysroot +do_package_index[recrdeptask] +=
package_update_index_deb + +do_package_index() {
+ set -ex
+ package_update_index_deb
+ set +ex
+}
Why do you continue to include the do_package_index here, it's no
longer needed with the setting of do_package_index[recrdeptask], this
is true below also.
Sorry, I didn't use the recrdeptask flag and I guess I still don't quite
understand it.
Here removing the do_package_index() I will get such an ERROR:
ERROR: Task do_package_index from
/distro/dcui/pc1/meta/recipes-core/meta/package-index.bb seems to be
empty?!## | ETA: 00:00:00
ERROR: Error parsing /distro/dcui/pc1/meta/recipes-core/meta/package-index.bb:
md5() argument 1 must be string or read-only buffer, not None |
ETA: 00:00:00
About the recrdeptask flag: These are specified with the 'recrdeptask' flag
and is used signify the task(s) of each RDEPENDS which must have completed
before that task can be executed. It applies recursively so also, the RDEPENDS
of each item in the original RDEPENDS must be met and so on. It also runs all
DEPENDS first too.
I even added RDEPENDS += package-index in package-index.bb, but no change.
I'm trying to figure this out. Please point out my issue once this is obvious
to you. :-)
BTW: using the recrdeptask method, we have no chance to do set -ex and as a
result we lose some debug info in the log file. Is this ok?
+
diff --git a/meta/classes/package_rpm.bbclass
b/meta/classes/package_rpm.bbclass
index 70170d1..d9470d6 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -814,3 +814,10 @@ python do_package_write_rpm () {
do_package_write_rpm[dirs] = ${PKGWRITEDIRRPM}
addtask package_write_rpm before do_package_write after do_package
+do_package_index[depends] +=
createrepo-native:do_populate_sysroot +do_package_index() { +
set -ex +package_update_index_rpm
+createrepo ${DEPLOY_DIR_RPM}
+set +ex
+}
Nor this do_package_index() function, why no
do_package_index[recrdeptask] setting in RPM? If you need a special
function here them call it do_package_index_rpm() and set the
do_package_index[recrdeptask] to that function.
Yes, I should have added a new function including package_update_index_rpm and
createrepo ${DEPLOY_DIR_RPM}. and set do_package_index[recrdeptask] to it.
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] Automatically generate package repos for rpm and deb [bug #1024]
Dexuan Cui wrote:
From: Dexuan Cui dexuan@intel.com
This was made to address
http://bugzilla.yoctoproject.org/show_bug.cgi?id=1024. Please comment.
Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: dcui/master
Browse:
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master
This is an improved and simple version that keeps 1 package-index recipe and
updates the 3 kinds of packages at the same time:
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/package-indexid=fb26e81dcb6e27e2908294e406a3011baed0120d
This avoids forcing the user to remember which package type they enabled when
running bitbake package-index.
(I also past the new version at the end of this mail for easy reviewing)
Thanks!
-- Dexuan
commit fb26e81dcb6e27e2908294e406a3011baed0120d
Author: Dexuan Cui dexuan@intel.com
Date: Thu May 12 19:15:59 2011 +0800
package-index.bb: also add the support for rpm/deb
[YOCTO #1024]
---
(I'll make a new patch to add the below description to the manual).
How to generate and use repos:
1) run bitbake package-index after building some target;
2) export ${DEPLOY_DIR_RPM} and ${DEPLOY_DIR_IPK} by a webserver on the host
(let's assume the host IP is 192.168.7.1) at
http://192.168.7.1/rpm
http://192.168.7.1/ipk
3) inside the target, according to the packaging system (ipk, rpm, deb) used
when we generate the target image, we can use different ways to manage
packages:
3.1) RPM: zypper addrepo http://192.168.7.1/rpm main; zypper refresh
to retrieve info about the repo; next, we can use zypper install/remove to
manage packages.
3.2) IPK: add the repo info into opkg config file, i.e., in
/etc/opkg/arch.conf, we can add something like
src i586 http://192.168.7.1/ipk/i586, and next we run opkg update to make
opkg update the list of available packages, and next we can use
opkg install/remove to manage packages.
3.3) DEB:(To be added)
Signed-off-by: Dexuan Cui dexuan@intel.com
diff --git a/meta/recipes-core/meta/package-index.bb
b/meta/recipes-core/meta/package-index.bb
index 3c642cb..969430b 100644
--- a/meta/recipes-core/meta/package-index.bb
+++ b/meta/recipes-core/meta/package-index.bb
@@ -22,10 +22,14 @@ do_package_index[nostamp] = 1
do_package_index[dirs] = ${DEPLOY_DIR_IPK}
do_package_index[depends] += opkg-utils-native:do_populate_sysroot
do_package_index[depends] += opkg-native:do_populate_sysroot
+do_package_index[depends] += createrepo-native:do_populate_sysroot
+do_package_index[depends] += dpkg-native:do_populate_sysroot
apt-native:do_populate_sysroot
do_package_index() {
set -ex
package_update_index_ipk
+ createrepo ${DEPLOY_DIR_RPM}
+ package_update_index_deb
set +ex
}
addtask do_package_index before do_build
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] Automatically generate package repos for rpm and deb [bug #1024]
Wold, Saul wrote: On 05/12/2011 04:38 AM, Cui, Dexuan wrote: Dexuan Cui wrote: From: Dexuan Cuidexuan@intel.com This was made to address http://bugzilla.yoctoproject.org/show_bug.cgi?id=1024. Please comment. Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: dcui/master Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master This is an improved and simple version that keeps 1 package-index recipe and updates the 3 kinds of packages at the same time: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/package-indexid=fb26e81dcb6e27e2908294e406a3011baed0120d This avoids forcing the user to remember which package type they enabled when running bitbake package-index. (I also past the new version at the end of this mail for easy reviewing) Dexuan, I am not sure that this is the correct approach. I think that you should look at how the packages get generated based on which package classes are included via PACKAGE_CLASSES, then in each of those classes set it up so that when the package-index task is called you know which indexer to run. This would be moving what you have in the package-index-packager.bb files to their respective package_packager.bbclass files and use do_package_index[recrdeptask] += package_index_packager in the case of ipk it would be in package_ipk.bbclass do_package_index[recrdeptask] += package_update_index_ipk You will also need to move the do_package_index[depends] OK, thanks very much for the detailed suggestion! I'll change to this better method. Another thing to verify is the current package_update_index_* correct for the different package types? Looking at package_update_index_rpm, I am not sure since it does not call createrepo, there might be a reason for this that Mark H or Qing can comment on. My understanding about package_update_index_rpm vs. createrepo is: both can be used to generate rpm repo; package_update_index_rpm generates the metadata about the packages in solvedb to have rpm install the packages into target rootfs. This is the current method used in do_rootfs for rpm. This is complex and the generated repo is not suitable to be exported (e.g., via http) for general use; createrepo generated the metadata in .xml files and the generated repo can be easily exported via http and can be used easily by standard zypper (and yum) tools. So in package-index.bb, I adopt createrepo for rpm. Let me Cc Qing and Mark for comments about this. Thanks! -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 37/58] gnu-config-native: add dependency on perl-native
Richard Purdie wrote:
On Fri, 2011-05-06 at 16:52 +0800, Cui, Dexuan wrote:
Howeve, there is a sed replacement in gnu-config-native's do_install:
-e 's,@autom4te_perllibdir@,${datadir}/autoconf,g
Don't confuse the data files that autoconf installs and references
with a program that is mixing the perl-native binary and libraries
with the host system ones. I think the above change is harmless as
its just linking in some perl files.
Sorry, but I might not make me clear here(?)
I meant: due to the sed replacing and the
unshift @INC, $datadir(@INC is a path list
from which a perl module is being searched for) in
${STAGING_BINDIR_NATIVE}/gnu-configize, /usr/bin/perl will try to use
perl modues in ${STAGING_DATADIR_NATIVE}/perl/ if the gnu-configize
is executed by /usr/bin/perl.
That's just bug 941, I think.
If we keep the sed replacing, I think we have to make gnu-config-native
depend on perl-native so we're sure gnu-config-native's do_configure will
find perl-native rather than /usr/bin/perl, but as you said, gnu-config-native
should not depend on perl-native. That's what confused me.
and meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in is
intened
to be run with #! /usr/bin/env perl -- this incurs some race
conditions:
This is more problematic though as it does this but also references
perl's full path more directly further in the file. This is the real
problem as its mixing and matching two different perl versions.
1) if perl-natvie does populate_sysroot later than
${STAGING_BINDIR_NATIVE}/gnu-configize is invoked, /usr/bin/perl is
used
but perl-native's modules are used due to the unshift @INC,
$datadir in gnu-configize.in. This is just
http://bugzilla.pokylinux.org/show_bug.cgi?id=941 2) if perl-natvie
does populate_sysroot earlier than the gnu-configize
is invokded, we don't meet bug 941.
The above is the current situation. If we install perl-native into
its own
sysroot, in the gnu-configize, the system perl is always found and
used,
and we always meet with bug 941.
It doesn't matter which perl we use but we do need to use the same
perl consistently.
How can we fix bug 941 then?
BTW: the 2 lines at the beginning of gnu-configize.in is suspicious:
eval 'case $# in 0) exec /usr/bin/perl -S $0;; *) exec
/usr/bin/perl -S $0 $@;; esac' if 0; I'm new to the synax of
perl, but I believe the string after the eval is
not executed due to if 0.
Can we remove the 2 lines?
I ended up getting some other opinions on this code as it makes no
sense to me either. The best guess I've heard is its allowing the
script to work in shell and perl. I then looked at other autoconf
scripts and they use this same construct so its obviously copied from
there. I agree the style is pointless and we could remove it but it
is at least consistent with the rest of autoconf.
I went digging and was surprised to see many hardcoded paths to perl
in the autoconf scripts. It turns out path_prog_fixes.patch isn't
being applied to autoconf-native, only the target version. When we do
apply it, it turns out the patch is buggy in the native case and I
had to change @bindir@/env to /usr/bin/env to make it work since we
don't have a env in the STAGING_BINDIR_NATIVE.
My point is that we need to be consistent about which perl version we
use in these scripts. Either we use one from the environment using env
Yes, I agree.
or we hardcode to /usr/bin/perl. Since the perl-native binary won't be
in the path for any of these, autodetecting and letting it hardcode is
probably fine. It has the advantage that if there are any binary
modules ever involved, they'll match the version of perl they were
built for regardless of whether perl-native is a dependency or not.
If someone adds a perl-native dependency to autoconf-native, it will
also still select the correct perl.
Whilst doing this we need to keep bug #968 in mind and ensure that if
perl-native is used, all of perl-native is in the sysroot. That bug is
where the perl binary was installed, the library was not and an error
occurred. If it is in its own directory which is only added to the
PATH for users with the correct dependency, we avoid this.
As for bug #941, the bottom line is that however autoconf-native
selects its perl version, the strings encoded in gnu-config should
really match those in the other autoconf-native scripts.
I saw a commit that was once suspended was pushed into poky
master yesterday:
http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=605141a93443df042634b2219a8628a9004be023
Actually it does fix(or at least workaround) bug #941 and bug #968.
Looks there are much work to do if we install perl-native to its own sysroot.
At present we can use the above commit as a workaround.
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo
Re: [OE-core] [PATCH 37/58] gnu-config-native: add dependency on perl-native
Tom Rini wrote:
On 05/05/2011 03:34 PM, Richard Purdie wrote:
On Thu, 2011-05-05 at 22:18 +0800, Cui, Dexuan wrote:
Recently I have been looking into it and I've made some commits (the
top 5 small commits) in
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=dcui/master_perl-native
BTW: the work is not done completely as some recipes don't build
with the changes. Please have a look anyway to see if I'm in the
correct direction.
However, I've got some difficulties and hope to get your help:
1) As you said, after we install perl-native into its own
directory,
any recipe not depending on perl-native doesn't see
${STAGING_BINDIR_NATIVE}/perl-native/perl unnecessarily.
However, if we keep the current code, what's the bad consequence if
the recipe not depending on perl-native does see perl of
perl-native?
looks no?
We have an assumption that perl is already on the system we're
building on. Perl is a relatively stable language with defined
compatibility and interoperability. Most recipes are therefore fine
using perl from the build system directly and don't need
perl-native. I think we defined a special name for the build system
perl (perl-native-runtime?). Better names are welcome but we should
ensure we use the right dependency in the right places.
The time to use perl-native instead of perl-native-runtime is where
any perl module is being built, perl itself is being built or
anything that has an explicit dependency on the perl version present.
The problem that follows up is that once we have built any sort of
perl-native we then have to go and be really really really careful
that nothing that's not (a) target perl (b) some perl module we built
and need to run uses it. Otherwise we run into the problems I think
that've been hit here. Problems like this are why for OE I just made
perl-native be the perl we rely on for everything.
I know we talked about this before and you had a strong desire to try
and do something else but I think this shows maybe we need to try
going down the perl-native everywhere path first and then see if we
can't do something different.
Hi Tom, do you mean we should try to use perl-native first and try the
best to avoid using /usr/bin/perl?
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
