| Submitter | Leon Woestenberg |
|---|---|
| Date | 2009-11-18 00:33:33 |
| Message ID | <1258504413-25056-1-git-send-email-leon@sidebranch.com> |
| Download | mbox | patch |
| Permalink | /patch/1283/ |
| State | Applied |
| Headers | show |
Comments
Hello Leon, On Tue, Nov 17, 2009 at 10:33 PM, Leon Woestenberg <leon.woestenberg@gmail.com> wrote: > In OpenEmbedded we used squashfs 4.0 with external patch for LZMA > compression support. In the meantime, squashfs has mainlined LZMA > support in its CVS version. > > This patches switches to the upstream squashfs-tools and modifies > bitbake.conf to match the slightly different arguments to mksquashfs. I agree with the move to mainline version however your recipe changes might need some improvement. You don't use the lzma recipe available in OE and instead grab it again ... IMO this is wrong since it duplicates the lzma source and also make more difficult to us to "share" fixes. Besides that I think it is ok. Can you fix it and send a new patch for review? Cheers,
Hello Otavio, On Wed, Nov 18, 2009 at 2:09 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > On Tue, Nov 17, 2009 at 10:33 PM, Leon Woestenberg > <leon.woestenberg@gmail.com> wrote: >> In OpenEmbedded we used squashfs 4.0 with external patch for LZMA >> compression support. In the meantime, squashfs has mainlined LZMA >> support in its CVS version. >> >> This patches switches to the upstream squashfs-tools and modifies >> bitbake.conf to match the slightly different arguments to mksquashfs. > > I agree with the move to mainline version however your recipe changes > might need some improvement. You don't use the lzma recipe available > in OE and instead grab it again ... IMO this is wrong since it > duplicates the lzma source and also make more difficult to us to > "share" fixes. > Yes, I noticed this. However, this is *exactl*y how the squashfs author designed his integration of LZMA; simply referring to a specific extracted archive of the LZMA SDK. (consider this is a lazy man's way of static linking) > Besides that I think it is ok. Can you fix it and send a new patch for review? > I will not fix it. Instead I will contact the squashfs author to ask if he want to consider the neat approach (if of course LZMA provides this). In the meantime, should I apply the patch as-is? Regards,
Hello, On Wed, Nov 18, 2009 at 2:14 PM, Leon Woestenberg <leon.woestenberg@gmail.com> wrote: >> I agree with the move to mainline version however your recipe changes >> might need some improvement. You don't use the lzma recipe available >> in OE and instead grab it again ... IMO this is wrong since it >> duplicates the lzma source and also make more difficult to us to >> "share" fixes. >> > Yes, I noticed this. > > However, this is *exactl*y how the squashfs author designed his > integration of LZMA; simply referring to a specific extracted archive > of the LZMA SDK. > > (consider this is a lazy man's way of static linking) Anyway I think it is worth fixing it. Duplicating sources (and the needed fixes, in case LZMA requires one) is wrong if avoidable so I'd say it would be nice to fix it. >> Besides that I think it is ok. Can you fix it and send a new patch for review? >> > I will not fix it. Instead I will contact the squashfs author to ask > if he want to consider the neat approach (if of course LZMA provides > this). Look above. > In the meantime, should I apply the patch as-is? You already did but I'd expect some time to reply before you pushing it. :-(
Hello Otavio, On Wed, Nov 18, 2009 at 7:29 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > On Wed, Nov 18, 2009 at 2:14 PM, Leon Woestenberg > <leon.woestenberg@gmail.com> wrote: >>> I agree with the move to mainline version however your recipe changes >>> might need some improvement. You don't use the lzma recipe available >>> in OE and instead grab it again ... IMO this is wrong since it >>> duplicates the lzma source and also make more difficult to us to >>> "share" fixes. >>> >> Yes, I noticed this. >> >> However, this is *exactl*y how the squashfs author designed his >> integration of LZMA; simply referring to a specific extracted archive >> of the LZMA SDK. >> >> (consider this is a lazy man's way of static linking) > > Anyway I think it is worth fixing it. > Yes, agreed, only if that approach would work (i.e. the needed functions are correctly exported into the static library) with the current code base. > Duplicating sources (and the needed fixes, in case LZMA requires one) > is wrong if avoidable so I'd say it would be nice to fix it. > Duplicating effort working against the upstream package is wrong too. I would rather go through the author to see this approach mainlined. >> In the meantime, should I apply the patch as-is? > You already did but I'd expect some time to reply before you pushing it. > Sorry I misunderstood your "good and thx" reply on IRC. The current lzma recipe has some problems (use of dos2unix, not building for target) that we need to fix first. The currently committed recipe is pure metadata, builds the same way as the upstream package does, and is tested for -native on a target, by booting a squashfs-lzma compressed rootfs. I propose to keep it as-is, then see if we can fix lzma, neaten the squashfs-tools build, and bring it upstream. Regards,
Patch
diff --git a/conf/bitbake.conf b/conf/bitbake.conf index 96e7799..bb99d3c 100644 --- a/conf/bitbake.conf +++ b/conf/bitbake.conf @@ -345,7 +345,7 @@ IMAGE_CMD_ext2.gz = "install -d ${DEPLOY_DIR_IMAGE}/tmp.gz ; genext2fs -b ${ROOT IMAGE_CMD_ext3 = "genext2fs -b ${ROOTFS_SIZE} -d ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3 ${EXTRA_IMAGECMD}; tune2fs -j ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3" IMAGE_CMD_ext3.gz = "install -d ${DEPLOY_DIR_IMAGE}/tmp.gz ; genext2fs -b ${ROOTFS_SIZE} -d ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext3 ${EXTRA_IMAGECMD}; tune2fs -j ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext3; gzip -f -9 ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext3; mv ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext3.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3.gz" IMAGE_CMD_squashfs = "mksquashfs ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs ${EXTRA_IMAGECMD} -noappend" -IMAGE_CMD_squashfs-lzma = "mksquashfs ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs-lzma ${EXTRA_IMAGECMD} -noappend -lzma" +IMAGE_CMD_squashfs-lzma = "mksquashfs ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs-lzma ${EXTRA_IMAGECMD} -noappend -comp lzma" IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar ." IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS} && tar -zcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ." IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ." diff --git a/conf/distro/include/sane-srcdates.inc b/conf/distro/include/sane-srcdates.inc index 422145c..4ea318f 100644 --- a/conf/distro/include/sane-srcdates.inc +++ b/conf/distro/include/sane-srcdates.inc @@ -41,6 +41,7 @@ SRCDATE_rdesktop ?= "20080917" SRCDATE_roadster ?= "20060814" SRCDATE_rosetta ?= "20090514" SRCDATE_sctzap ?= "20060814" +SRCDATE_squashfs ?= "20091110" SRCDATE_tslib ?= "20051101" SRCDATE_waimea ?= "20060814" SRCDATE_xcompmgr ?= "20060814" diff --git a/recipes/squashfs-tools/squashfs-tools-native_4.0.bb b/recipes/squashfs-tools/squashfs-tools-native_4.0.bb index 8fc80a6..cc01604 100644 --- a/recipes/squashfs-tools/squashfs-tools-native_4.0.bb +++ b/recipes/squashfs-tools/squashfs-tools-native_4.0.bb @@ -1,13 +1,12 @@ -require squashfs-tools_${PV}.bb +require squashfs-tools_4.0.bb inherit native -DEPENDS = "zlib-native lzma-native " - -PR = "${INC_PR}.1" +DEPENDS = "zlib-native" PACKAGES = "" do_stage () { install -m 0755 mksquashfs ${STAGING_BINDIR}/ } + diff --git a/recipes/squashfs-tools/squashfs-tools_4.0.bb b/recipes/squashfs-tools/squashfs-tools_4.0.bb index 17ab6dc..4e18489 100644 --- a/recipes/squashfs-tools/squashfs-tools_4.0.bb +++ b/recipes/squashfs-tools/squashfs-tools_4.0.bb @@ -1,14 +1,36 @@ -require squashfs-tools.inc -DEPENDS += "lzma" -PR = "${INC_PR}.1" +DESCRIPTION = "Squashfs is a highly compressed read-only filesystem for Linux." +SECTION = "base" +LICENSE = "GPLv2" +DEPENDS = "zlib" +PR = "r2" -EXTRA_OEMAKE = "USE_LZMA=1 \ - LZMA_CFLAGS='-I${STAGING_INCDIR}/lzma -DUSE_LZMA' \ - LZMA_LIB='${STAGING_LIBDIR}/liblzma.a'" +# 2009-10-22 snapshot +#SRC_URI = "http://www.kernel.org/pub/linux/kernel/people/pkl/squashfs4.0-lzma-snapshot.tgz" +#S = "${WORKDIR}/squashfs4.0-lzma-snapshot/squashfs-tools" -DEFAULT_PREFERENCE = "-1" -DEFAULT_PREFERENCE_angstrom = "1" +SRC_URI = "cvs://anonymous@squashfs.cvs.sourceforge.net/cvsroot/squashfs;module=squashfs;date=${SRCDATE}" +S = "${WORKDIR}/squashfs/squashfs-tools" -SRC_URI += " file://portability.patch;patch=1;pnum=2 \ - file://lzma-support.patch;patch=1;pnum=2" +SRC_URI += "http://downloads.sourceforge.net/sevenzip/lzma465.tar.bz2" + +COMP_DEFAULT = gzip + +EXTRA_OEMAKE += "LZMA_SUPPORT=1 LZMA_DIR=../.." + +TARGET_CC_ARCH += "${LDFLAGS}" + +# the COMP_DEFAULT macro should result in a string including quotes: "gzip" +CFLAGS_append = ' -I. -I../../C -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE \ + -D_GNU_SOURCE -DLZMA_SUPPORT -DCOMP_DEFAULT=\\"${COMP_DEFAULT}\\" ' + +prefix = "" + +do_compile() { + oe_runmake mksquashfs +} + +do_install () { + install -d ${D}${sbindir} + install -m 0755 mksquashfs ${D}${sbindir}/ +}
In OpenEmbedded we used squashfs 4.0 with external patch for LZMA compression support. In the meantime, squashfs has mainlined LZMA support in its CVS version. This patches switches to the upstream squashfs-tools and modifies bitbake.conf to match the slightly different arguments to mksquashfs. Signed-off-by: Leon Woestenberg <leon@sidebranch.com> --- conf/bitbake.conf | 2 +- conf/distro/include/sane-srcdates.inc | 1 + .../squashfs-tools/squashfs-tools-native_4.0.bb | 7 +-- recipes/squashfs-tools/squashfs-tools_4.0.bb | 42 +++++++++++++++----- 4 files changed, 37 insertions(+), 15 deletions(-)