On Sun, Dec 11, 2011 at 11:20:25PM +0100, Andrea Adami wrote: > On Sun, Dec 11, 2011 at 11:03 AM, Martin Jansa <[email protected]> wrote: > > On Thu, Dec 08, 2011 at 10:30:27PM +0100, Andrea Adami wrote: > >> On Thu, Dec 8, 2011 at 4:10 PM, Martin Jansa <[email protected]> > >> wrote: > >> > On Thu, Dec 08, 2011 at 07:57:52AM -0700, Tom Rini wrote: > >> >> On Tue, Dec 6, 2011 at 4:23 PM, Andrea Adami <[email protected]> > >> >> wrote: > >> >> > * Building the jffs2 filesystem to include summary information speeds > >> >> > up > >> >> > * the mount process considerably at the cost of increased size. > >> >> > * The rate of speedup is generally higher on NAND chips and on the > >> >> > chips > >> >> > * where the erase block size is large. > >> >> > > >> >> > Signed-off-by: Andrea Adami <[email protected]> > >> > > >> > I'll repeat my comment from yesterday, but IMHO it would be easier to > >> > see the difference between those 2 images if the IMAGE_CMD_jffs2 output > >> > is > >> > renamed to .jffs2.nosummary and IMAGE_CMD_sum.jffs2 (or renamed > >> > IMAGE_CMD_jffs2.summary) > >> > produces .jffs2.summary (or even just .jffs2 if we can agree that > >> > .summary is > >> > what enduser wants by default) > >> > >> I tried to keep the patch not too invasive and did not introduce a > >> special EXTRA string for sumtool. > >> The most widely used options (-p -l -e) are common, though. > >> > >> Unfortunately summary means we have a bigger image: > >> 44M Dec 8 16:14 core-image-sato-c7x0-20111208151047.rootfs.jffs2 > >> 57M Dec 8 16:14 core-image-sato-c7x0-20111208151047.rootfs.sum.jffs2 > >> > >> Being some devices have strict size requirements I think it is better > >> to build both kind of images. > > > > Today I've noticed that it doesn't work for me: > > > > I have changed EXTRA_IMAGECMD_jffs2 to use new sum.jffs2: > > http://git.shr-project.org/git/?p=meta-smartphone.git;a=blobdiff;f=meta-openmoko/conf/machine/om-gta02.conf;h=ad71d3db386b7d7df6ab484ea9ad80260da30373;hp=7cfb1b2a07b09ac3a35a27d209015ea8533ff632;hb=26d60e47358abe66d7d0fdbe6d5adea8f46bdbe2;hpb=043b5ac84794946e88e880b722fed445d3d985c5 > > > > Martin, > > the idea of the patch was to keep things simple. > > After all most machines only specify endianness, eraseblocksize and padding. > The few which are using summary jffs2 in meta-handhels appear to be > Zaurus and hx4700 (I'll send a patch to fix ipaq's too) and fwiw > beagleboard used '-npl' so I think we cover the most common case when > people are setting > > EXTRA_IMAGECMD_jffs2 = "-p -l --eraseblock=${ERASEBLOCKSIZE}" > > and for the rare case they add IMAGE_FSTYPES += "tar.gz jffs2 sum.jffs2": > EXTRA_IMAGECMD_sum.jffs2 = "${EXTRA_IMAGECMD_jffs2}" > > This happens to work just as intended, without adding another var for > sumtool args. > > mkfs.jffs2 > --root=/oe/oe-core/build/tmp-eglibc/work/c7x0-oe-linux-gnueabi/core-image-sato-1.0-r0/rootfs > --faketime > --output=/oe/oe-core/build/tmp-eglibc/deploy/images/core-image-sato-c7x0-20111210181230.rootfs.jffs2 > -n -p -l --eraseblock=0x4000 > cd /oe/oe-core/build/tmp-eglibc/deploy/images/ > rm -f > /oe/oe-core/build/tmp-eglibc/deploy/images/core-image-sato-c7x0.jffs2 > ln -s core-image-sato-c7x0-20111210181230.rootfs.jffs2 > /oe/oe-core/build/tmp-eglibc/deploy/images/core-image-sato-c7x0.jffs2 > # Image generation code for image type sum.jffs2 > ROOTFS_SIZE=`du -ks > /oe/oe-core/build/tmp-eglibc/work/c7x0-oe-linux-gnueabi/core-image-sato-1.0-r0/rootfs|awk > '{size = $1 * 1.3 + 0; OFMT = "%.0f" ; print (size > 65536 ? size : > 65536) }'` > mkfs.jffs2 > --root=/oe/oe-core/build/tmp-eglibc/work/c7x0-oe-linux-gnueabi/core-image-sato-1.0-r0/rootfs > --faketime > --output=/oe/oe-core/build/tmp-eglibc/deploy/images/core-image-sato-c7x0-20111210181230.rootfs.jffs2 > -n -p -l --eraseblock=0x4000 && sumtool -i /oe/ > oe-core/build/tmp-eglibc/deploy/images/core-image-sato-c7x0-20111210181230.rootfs.jffs2 > -o > /oe/oe-core/build/tmp-eglibc/deploy/images/core-image-sato-c7x0-20111210181230.rootfs.sum.jffs2 > -n -p -l --eraseblock=0x4000 > cd /oe/oe-core/build/tmp-eglibc/deploy/images/ > rm -f > /oe/oe-core/build/tmp-eglibc/deploy/images/core-image-sato-c7x0.sum.jffs2 > ln -s core-image-sato-c7x0-20111210181230.rootfs.sum.jffs2 > /oe/oe-core/build/tmp-eglibc/deploy/images/core-image-sato-c7x0.sum.jffs2 > > > > Being that IMAGE_CMD_sum.jffs2 cannot be overriden I adapted the > EXTRA_IMAGECMD_jffs2 and simplified it in the way the string can be > used by sumtool. > To have full customization you'd need a weak assignment in > image_types.bbclass.
It can be overriden and that's how I have fixed this (imho wrong) behavior http://git.shr-project.org/git/?p=meta-smartphone.git;a=blobdiff;f=meta-openmoko/conf/machine/om-gta02.conf;h=662080612add4269955a74db12e31cfe1d0102bc;hp=ad71d3db386b7d7df6ab484ea9ad80260da30373;hb=5cf4e7f98266d5d3543afb7957f4243dca42efd3;hpb=7f8f34488dba6a6f26bea323a50196be2f11a705 because with IMAGE_CMD_sum.jffs2 = "${IMAGE_CMD_jffs2} && sumtool -i ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \ -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.sum.jffs2 -n ${EXTRA_IMAGECMD}" I think it's common sense to expect EXTRA_IMAGECMD_sum.jffs2 being applied to sumtool not mkfs.jffs2 Regards, > > OE om-gta02@shr ~/shr-core $ bitbake -e shr-lite-image | tee -a image.log > > > > OE om-gta02@shr ~/shr-core $ grep ^EXTRA_IMAGECMD image.log | grep jffs2 > > EXTRA_IMAGECMD_sum.jffs2="--eraseblock=0x20000 --no-cleanmarkers > > --littleendian --pad" > > EXTRA_IMAGECMD_jffs2="--little-endian --eraseblock=0x20000 --pagesize=0x800 > > --no-cleanmarkers --pad; mv > > /OE/shr-core/tmp-eglibc/deploy/images/om-gta02/shr-lite-20111211-om-gta02.rootfs.jffs2 > > > > /OE/shr-core/tmp-eglibc/deploy/images/om-gta02/shr-lite-20111211-om-gta02.rootfs.jffs2.nosummary;" > > > > This looks right (notice that sumtool is using different > > --little-endian/--littleendian). > > Pls use -l ;) > > > > > OE om-gta02@shr ~/shr-core $ grep IMAGE_CMD image.log | grep jffs2 > > # IMAGE_CMD_sum.jffs2=${IMAGE_CMD_jffs2} && sumtool -i > > ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 -o > > ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.sum.jffs2 -n ${EXTRA_IMAGECMD} > > IMAGE_CMD_sum.jffs2="mkfs.jffs2 > > --root=/OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/shr-lite-image/2.0-r20/rootfs > > --faketime > > --output=/OE/shr-core/tmp-eglibc/deploy/images/om-gta02/shr-lite-20111211-om-gta02.rootfs.jffs2 > > -n && sumtool -i > > /OE/shr-core/tmp-eglibc/deploy/images/om-gta02/shr-lite-20111211-om-gta02.rootfs.jffs2 > > -o > > /OE/shr-core/tmp-eglibc/deploy/images/om-gta02/shr-lite-20111211-om-gta02.rootfs.sum.jffs2 > > -n" > > # IMAGE_CMD_jffs2=mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime > > --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 -n ${EXTRA_IMAGECMD} > > IMAGE_CMD_jffs2="mkfs.jffs2 > > --root=/OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/shr-lite-image/2.0-r20/rootfs > > --faketime > > --output=/OE/shr-core/tmp-eglibc/deploy/images/om-gta02/shr-lite-20111211-om-gta02.rootfs.jffs2 > > -n" > > > > Here we can see that bitbake -e didn't expand EXTRA_IMAGECMD right, but it > > seems like do_rootfs have them not empty: > > > > shr-core/tmp/work/om_gta02-oe-linux-gnueabi/shr-image/2.0-r18/temp/run.do_rootfs.688: > > # Image generation code for image type sum.jffs2 > > ROOTFS_SIZE=`du -ks > > /OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/shr-image/2.0-r18/rootfs|awk > > '{size = $1 * 1.3 + 0; OFMT = "%.0f" ; print (size > 65536 ? size : 65536) > > }'` > > mkfs.jffs2 > > --root=/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/shr-image/2.0-r18/rootfs > > --faketime > > --output=/OE/shr-core/tmp/deploy/images/om-gta02/shr-full-20111210-om-gta02.rootfs.jffs2 > > -n --eraseblock=0x20000 --no-cleanmarkers --littleendian --pad && sumtool > > -i > > /OE/shr-core/tmp/deploy/images/om-gta02/shr-full-20111210-om-gta02.rootfs.jffs2 > > -o > > /OE/shr-core/tmp/deploy/images/om-gta02/shr-full-20111210-om-gta02.rootfs.sum.jffs2 > > -n --eraseblock=0x20000 --no-cleanmarkers --littleendian --pad > > cd /OE/shr-core/tmp/deploy/images/om-gta02/ > > rm -f /OE/shr-core/tmp/deploy/images/om-gta02/full-om-gta02.sum.jffs2 > > ln -s shr-full-20111210-om-gta02.rootfs.sum.jffs2 > > /OE/shr-core/tmp/deploy/images/om-gta02/full-om-gta02.sum.jffs2 > > > > Notice that IMAGE_CMD_jffs2 is using EXTRA_IMAGECMD_sum.jffs2 (so params > > for sumtool not mkfs.jffs2) when it's expanded > > inside IMAGE_CMD_sum.jffs2 variable > > > > openembedded-core/meta/classes/image_types.bbclass: > > IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime > > --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 -n > > ${EXTRA_IMAGECMD}" > > IMAGE_CMD_sum.jffs2 = "${IMAGE_CMD_jffs2} && sumtool -i > > ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \ > > -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.sum.jffs2 -n > > ${EXTRA_IMAGECMD}" > > > > And causing > > mkfs.jffs2: unrecognized option '--littleendian' > > mkfs.jffs2: error!: Usage: mkfs.jffs2 [OPTIONS] > > > > And using EXTRA_IMAGECMD_jffs2 in IMAGE_CMD_jffs2 breaks parsing.. > > > > ERROR: Unable to parse > > /OE/shr-core/openembedded-core/meta/recipes-core/images/core-image-minimal-initramfs.bb > > > > | ETA: --:--:-- > > Traceback (most recent call last): > > File "/usr/lib64/python2.7/site-packages/bb/codeparser.py", line 268, in > > ShellParser.parse_shell(value='\t#set -x\n\trm -rf > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs\n\trm > > -rf > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/multilib\n\tmkdir > > -p > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs\n\tmkdir > > -p /OE/shr-core/tmp-eglibc/deploy/images/om-gta02\n\n\tcp > > /OE/shr-core/openembedded-core/meta/files/deploydir_readme.txt > > /OE/shr-core/tmp-eglibc/deploy/images/om-gta02/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt\n\n\tif > > [ "0" != "1" ]; then\n\t\tfor devtable in > > /OE/shr-core/meta-handheld/files/device_table-minimal.txt; > > do\n\t\t\tmakedevs -r > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs > > -D > > $devtable\n\t\tdone\n\tfi\n\n\trootfs_ipk_do_rootfs\n\n\tinsert_feed_uris\n\n\tif > > [ "xldconfig-native:do_populate_sysroot" != "x" ]; then\n\t\t# Run > > ldconfig on the image to create a valid cache\n\t\t# (new format for cross > > arch compatibility)\n\t\techo executing: ldconfig -r > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs > > -c new -v\n\t\tldconfig -r > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs > > -c new -v\n\tfi\n\n\t# (re)create kernel modules dependencies\n\t# This > > part is done by kernel-module-* postinstall scripts but if image do\n\t# > > not contains modules at all there are few moments in boot sequence > > with\n\t# "unable to open modules.dep" message.\n\tif [ -e > > /OE/shr-core/tmp-eglibc/sysroots/om-gta02/kernel/kernel-abiversion ]; > > then\n\t\tKERNEL_VERSION=`cat > > /OE/shr-core/tmp-eglibc/sysroots/om-gta02/kernel/kernel-abiversion`\n\n\t\tmkdir > > -p > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs/lib/modules/$KERNEL_VERSION\n\t\tarm-oe-linux-gnueabi-depmod > > -a -b /OE/shr-core/tmp- > > try: > > > tokens, _ = pyshyacc.parse(value, eof=True, debug=False) > > except pyshlex.NeedMore: > > File "/usr/lib64/python2.7/site-packages/bb/pysh/pyshyacc.py", line 673, > > in parse(input='\t#set -x\n\trm -rf > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs\n\trm > > -rf > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/multilib\n\tmkdir > > -p > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs\n\tmkdir > > -p /OE/shr-core/tmp-eglibc/deploy/images/om-gta02\n\n\tcp > > /OE/shr-core/openembedded-core/meta/files/deploydir_readme.txt > > /OE/shr-core/tmp-eglibc/deploy/images/om-gta02/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt\n\n\tif > > [ "0" != "1" ]; then\n\t\tfor devtable in > > /OE/shr-core/meta-handheld/files/device_table-minimal.txt; > > do\n\t\t\tmakedevs -r > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs > > -D > > $devtable\n\t\tdone\n\tfi\n\n\trootfs_ipk_do_rootfs\n\n\tinsert_feed_uris\n\n\tif > > [ "xldconfig-native:do_populate_sysroot" != "x" ]; then\n\t\t# Run > > ldconfig on the image to create a valid cache\n\t\t# (new format for cross > > arch compatibility)\n\t\techo executing: ldconfig -r > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs > > -c new -v\n\t\tldconfig -r > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs > > -c new -v\n\tfi\n\n\t# (re)create kernel modules dependencies\n\t# This > > part is done by kernel-module-* postinstall scripts but if image do\n\t# > > not contains modules at all there are few moments in boot sequence > > with\n\t# "unable to open modules.dep" message.\n\tif [ -e > > /OE/shr-core/tmp-eglibc/sysroots/om-gta02/kernel/kernel-abiversion ]; > > then\n\t\tKERNEL_VERSION=`cat > > /OE/shr-core/tmp-eglibc/sysroots/om-gta02/kernel/kernel-abiversion`\n\n\t\tmkdir > > -p > > /OE/shr-core/tmp-eglibc/work/om_gta02-oe-linux-gnueabi/core-image-minimal-initramfs/1.0-r0/rootfs/lib/modules/$KERNEL_VERSION\n\t\tarm-oe-linux-gnueabi-depmod > > -a -b /OE/shr-core/tmp-eglibc/work/om_ > > debug = 2 > > > return yacc.parse(lexer=lexer, debug=debug), remaining > > > > File "/usr/lib64/python2.7/site-packages/ply/yacc.py", line 265, in > > LRParser.parse(input=None, lexer=<bb.pysh.pyshlex.PLYLexer instance at > > 0x9638248>, debug=False, tracking=0, tokenfunc=None): > > else: > > > return > > self.parseopt_notrack(input,lexer,debug,tracking,tokenfunc) > > > > File "/usr/lib64/python2.7/site-packages/ply/yacc.py", line 1047, in > > LRParser.parseopt_notrack(input=None, lexer=<bb.pysh.pyshlex.PLYLexer > > instance at 0x9638248>, debug=False, tracking=0, tokenfunc=None): > > errtoken.lexer = lexer > > > tok = self.errorfunc(errtoken) > > del errok, token, restart # Delete special > > functions > > File "/usr/lib64/python2.7/site-packages/bb/pysh/pyshyacc.py", line 646, > > in p_error(p=LexToken(AND_IF,'&&',0,0)): > > w(' %r\n' % n) > > > raise sherrors.ShellSyntaxError(''.join(msg)) > > > > ShellSyntaxError: LexToken(AND_IF,'&&',0,0) > > followed by: > > LexToken(TOKEN,'sumtool',0,0) > > LexToken(TOKEN,'-i',0,0) > > LexToken(TOKEN,'/OE/shr-core/tmp-eglibc/deploy/images/om-gta02/shr-core-image-minimal-initramfs-20111211-om-gta02.rootfs.jffs2',0,0) > > LexToken(TOKEN,'-o',0,0) > > LexToken(TOKEN,'/OE/shr-core/tmp-eglibc/deploy/images/om-gta02/shr-core-image-minimal-initramfs-20111211-om-gta02.rootfs.sum.jffs2',0,0) > > > > > > > >> > >> Cheers > >> > >> Andrea > >> > >> > > >> > But other than that it looks fine and will make my IMAGE_DEPENDS_jffs2 a > >> > bit shorter. > >> > > >> > Regards, > >> > > >> >> > >> >> Acked-by: Tom Rini <[email protected]> > >> >> > >> >> > --- > >> >> > meta/classes/image_types.bbclass | 5 ++++- > >> >> > 1 files changed, 4 insertions(+), 1 deletions(-) > >> >> > > >> >> > diff --git a/meta/classes/image_types.bbclass > >> >> > b/meta/classes/image_types.bbclass > >> >> > index 29b6380..bd4b7bc 100644 > >> >> > --- a/meta/classes/image_types.bbclass > >> >> > +++ b/meta/classes/image_types.bbclass > >> >> > @@ -35,6 +35,8 @@ XZ_COMPRESSION_LEVEL ?= "-e -9" > >> >> > XZ_INTEGRITY_CHECK ?= "crc32" > >> >> > > >> >> > IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime > >> >> > --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 > >> >> > ${EXTRA_IMAGECMD}" > >> >> > +IMAGE_CMD_sum.jffs2 = "${IMAGE_CMD_jffs2} && sumtool -i > >> >> > ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \ > >> >> > + -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.sum.jffs2 > >> >> > ${EXTRA_IMAGECMD}" > >> >> > > >> >> > IMAGE_CMD_cramfs = "mkcramfs ${IMAGE_ROOTFS} > >> >> > ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cramfs ${EXTRA_IMAGECMD}" > >> >> > > >> >> > @@ -138,6 +140,7 @@ EXTRA_IMAGECMD_btrfs ?= "" > >> >> > > >> >> > IMAGE_DEPENDS = "" > >> >> > IMAGE_DEPENDS_jffs2 = "mtd-utils-native" > >> >> > +IMAGE_DEPENDS_sum.jffs2 = "mtd-utils-native" > >> >> > IMAGE_DEPENDS_cramfs = "cramfs-native" > >> >> > IMAGE_DEPENDS_ext2 = "genext2fs-native" > >> >> > IMAGE_DEPENDS_ext2.gz = "genext2fs-native" > >> >> > @@ -157,4 +160,4 @@ IMAGE_DEPENDS_ubi = "mtd-utils-native" > >> >> > IMAGE_DEPENDS_ubifs = "mtd-utils-native" > >> >> > > >> >> > # This variable is available to request which values are suitable > >> >> > for IMAGE_FSTYPES > >> >> > -IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 ext3.gz > >> >> > ext2.lzma live squashfs squashfs-lzma ubi tar tar.gz tar.bz2 tar.xz > >> >> > cpio cpio.gz cpio.xz cpio.lzma" > >> >> > +IMAGE_TYPES = "jffs2 sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 > >> >> > ext3.gz ext2.lzma live squashfs squashfs-lzma ubi tar tar.gz tar.bz2 > >> >> > tar.xz cpio cpio.gz cpio.xz cpio.lzma" > >> >> > -- > >> >> > 1.7.3.4 > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Openembedded-core mailing list > >> >> > [email protected] > >> >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > >> >> > >> >> > >> >> > >> >> -- > >> >> Tom > >> >> > >> >> _______________________________________________ > >> >> Openembedded-core mailing list > >> >> [email protected] > >> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > >> > > >> > -- > >> > Martin 'JaMa' Jansa jabber: [email protected] > >> > > >> > _______________________________________________ > >> > Openembedded-core mailing list > >> > [email protected] > >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > >> > > >> > >> _______________________________________________ > >> Openembedded-core mailing list > >> [email protected] > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > -- > > Martin 'JaMa' Jansa jabber: [email protected] > > > > _______________________________________________ > > Openembedded-core mailing list > > [email protected] > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > > Regards > Andrea > > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
