Re: [PATCH 1/2] image_types.bbclass: implement jffs2 summary images (sum.jffs2)

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 19162 bytes --]

On Sun, Dec 11, 2011 at 11:20:25PM +0100, Andrea Adami wrote:
> On Sun, Dec 11, 2011 at 11:03 AM, Martin Jansa <martin.jansa@gmail.com> 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 <martin.jansa@gmail.com> 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 <andrea.adami@gmail.com> 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 <andrea.adami@gmail.com>
> >> >
> >> > 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 <tom.rini@gmail.com>
> >> >>
> >> >> > ---
> >> >> >  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
> >> >> > Openembedded-core@lists.openembedded.org
> >> >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Tom
> >> >>
> >> >> _______________________________________________
> >> >> Openembedded-core mailing list
> >> >> Openembedded-core@lists.openembedded.org
> >> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >> >
> >> > --
> >> > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> >> >
> >> > _______________________________________________
> >> > 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
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> 
> Regards
> Andrea
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]