June 2009 - crux-devel - lists.crux.nu

[PATCH] Do not attempt to build a package if the resulting file can't be written.
by Antti Nykanen 15 Jul '09

15 Jul '09

--- pkgmk.in | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/pkgmk.in b/pkgmk.in index 9fdf768..de50c95 100755 --- a/pkgmk.in +++ b/pkgmk.in @@ -350,6 +350,11 @@ remove_work_dir() { build_package() { local BUILD_SUCCESSFUL="no" + + if [ ! -w "$TARGET" ]; then + error "'$TARGET' is not writable." + exit 1 + fi make_work_dir -- 1.6.2.4

4 3

CRUX 2.6, LVM2 support
by Juergen Daubert 28 Jun '09

28 Jun '09

Hello, one of the more then once requested features [1] for 2.6 is to have LVM (logical volume manager) [2] available on our installation ISO. I've done the needed modifications to the 2.6 branches yesterday: a) add lvm2 to iso.git http://tinyurl.com/n89geg b) remove opt/libdevmapper http://tinyurl.com/nwee3x c) add opt/lvm2 http://tinyurl.com/nqvt9x d) additions to core/rc http://tinyurl.com/ktqayw I don't see a real reason to split out libdevmapper from lvm2, the package isn't big at all (400 KiB), so I've done b) and imported c) from contrib with slight modifications. Btw, I'd be more than happy to hand over the port c) to someone else, Simon? d) is a very minimalistic approach, it calls lvm if the package is installed. If lvm is installed but the kernel is missing device- mapper support (CONFIG_BLK_DEV_DM), you get a warning at system boot, not a big issue IMO. Adding a configuration variable to /etc/rc.conf might be an option as well. Not sure if it is worth the effort, as the typical CRUX user installs only packages he needs ;) Comments, better ideas? thanks, Juergen [1] http://crux.nu/bugs/index.php?do=details&task_id=342 [2] http://sourceware.org/lvm2/ -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux

1 0

libarchive, xz and pkgutils
by Tilman Sauerbeck 17 Jun '09

17 Jun '09

Hi, CRUX 2.6 will ship with XZ (http://tukaani.org/xz/) in core. That package implements the XZ compression algorithm, which is the successor to LZMA. I believe that LZMA isn't in use in the free software world anymore, so I will only talk about XZ here. To extract an xz'ed tarball, you can do as follows: $ tar xJf coreutils-7.4.tar.xz This is obviously independent of libarchive ;) To extract an xz'ed tarball using bsdtar (libarchive), there's two choices basically: a) tell bsdtar to invoke unxz on the file to uncompress it, then just extract the uncompressed tarball: $ bsdtar --use-compress-program unxz xf coreutils-7.4.tar.xz b) do both uncompression and extraction using libarchive. $ bsdtar xf coreutils-7.4.tar.xz You can optionally specify the J flag to force XZ compression. This requires that libarchive was built with XZ support. Since xz is in core anyway, I would like to build our libarchive with XZ support. Your opinion? What does that mean for pkgutils? At the moment, in pkgutils we initialize libarchive so that support for all supported archive formats and compression algorithms gets included. This means that if compression algorithm foo is implemented in libfoo and libarchive uses libfoo to handle foo we need to link pkgutils statically to libfoo. Until now, this only meant we needed to pull in libz and libbz2. Now, if your copy of libarchive is built with XZ support it will be linked to liblzma (liblzma implements the XZ compression format. Yes, the name is confusing). So if you initialize libarchive to support all known archive/compression formats but only link to libz and libbz2 you'll get a linker error because the XZ stuff isn't found. There's two possible solutions for this: a) link to liblzma (XZ!) too. This will increase the size of our pkgadd binary since now a few more object files from liblzma.a will be included. b) initialize libarchive so that support for XZ is disabled -> no need to link to liblzma. This means that pkgadd/pkginfo will not be able to open xz'ed tarballs. Note that this does NOT apply to pkgmk. pkgmk doesn't use libarchive obviously, but instead calls out to tar to extract stuff. In case we decide to build bsdtar with libarchive support, I would like to change pkgmk so that it uses bsdtar to extract *.tar.gz, *.tar.Z, *.tgz, *.tar.bz2, *.tar.xz, *.zip Let me know what you think. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?

3 4

portdb now has xml support
by lucas 12 Jun '09

12 Jun '09

I wrote a new implementation of the portdb some time ago that supports XML output. This has now gone live on the portdb page[1]. This should make it easier for non browser based interaction with the portdb, for example, I have also written a CLI tool for making queries with the portdb[2][3]. [1] http://crux.nu/portdb/?f=xml [2] http://git.die.net.au/cgit/crux/tools/pdb [3] http://git.die.net.au/cgit/crux/tools/crux-python -- Lucas Hazel <lucas(a)die.net.au>

1 0