The C libbtrfsutil library isn't very useful for scripting, so we also
want bindings for Python. Writing unit tests in Python is also much
easier than doing so in C. Only Python 3 is supported; if someone really
wants Python 2 support, they can write their own bindings. This commit
is just the scaffolding.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Right now the pkg-config command is hard-coded in configure.ac, which may
result in build errors on system and cross environments that have prefixed
toolchains, e.g. /usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-pkg-config.
Please see the attached patch, it has been written a while ago but it seems it
hasn't been submitted for upstream inclusion.
0001-configure.ac-Consistently-use-PKG_CONFIG.txt
Submitted by Timo Gurr.
Author: Wulf C. Krueger <philantrop@exherbo.org>
Issue: #101
Signed-off-by: David Sterba <dsterba@suse.com>
We've been using asciidoc that's written in python2, which is going to
be phased out and deprecated next year. There's a replacement,
asciidoctor. Add a configure-time detection which tool is available,
update Documentation/Makefile.in.
The original asciidoc tool is still preferred as it produces slightly
better output. The file asciidoc.conf does not have a direct equivalten
in asciidoct and would need to be replaced by extension written in ruby.
The differences:
- the <literal> are not automatically underlined and are less visible in
the generated manual page, but it's still acceptable
- the inline CSS for the html output looks subjectively worse, is less
compact and colourful
Issue: #89
Signed-off-by: David Sterba <dsterba@suse.com>
There will be a plain file tracking the last released version.
The rest will be simplified to print it where needed. The version
augmented by the current git status was not working anyway since we've
switched to autoconf. The result of version.h with the potential git
status was generated at configure time, which does not mean it's
accurate regarding the git status.
Signed-off-by: David Sterba <dsterba@suse.com>
The kernel 4.14 supports zstd, for version parity the btrfs-progs now
require libzstd by default. This can still be disabled by
./configure --disable-zstd.
Signed-off-by: David Sterba <dsterba@suse.com>
Before the change configure refused to accept it's defaults explicitly:
$ ./configure --enable-convert --with-convert=ext2,reiserfs
...
configure: error: unknown tokens for --with-convert: ,
After the change both converters are enabled:
$ ./configure --enable-convert --with-convert=ext2,reiserfs
...
btrfs-convert: yes (ext2,reiserfs)
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: David Sterba <dsterba@suse.com>
Adds zstd support to the btrfs program. An optional dependency on libzstd
>= 1.0.0 is added. Autoconf accepts `--enable-zstd' or `--disable-zstd' and
defaults to detecting if libzstd is present using `pkg-config'.
The patch is also available in my fork of btrfs-progs [1], which passes
Travis-CI with the new tests. The prebuilt binary is available there.
I haven't updated Android.mk.
[1] https://github.com/terrelln/btrfs-progs/tree/devel
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This patch adds support to convert reiserfs file systems in-place to btrfs.
It will convert extended attribute files to btrfs extended attributes,
translate ACLs, coalesce tails that consist of multiple items into one item,
and convert tails that are too big into indirect files.
This requires that libreiserfscore 3.6.27 be available.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
It's not really necessary to configure and regenerate Makefiles in cases
like adding a new source file. The build environment and optional
features are not affected by that.
Signed-off-by: David Sterba <dsterba@suse.com>
The FIEMAP_EXTENT_SHARED fiemap flag was introduced in 2.6.33. If the
headers do not provide the definition, the build will fail. The support
of the fiemap sharing depends on the running kernel. There are still
systems with 2.6.32 kernel headers but running newer versions.
To support such environment, don't fail build, provide own defintion of
the structure and detect if there's an old kernel in use in the relevant
command (btrfs fi du).
Reported-by: Abhay Sachan <lkp.abhay@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Prior to udev v190, there was no btrfs builtin helper. Installing it on
systems with an older udev will cause problems.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add --with-convert[=VALUE] option to configure. Accepts ext2, auto, yes,
or no, but will be extended to more in the future. The configure-time
defines are not used in the code, ext2 is built-in unconditionally.
Signed-off-by: David Sterba <dsterba@suse.com>
The new convert framework copies code from current dumpe2fs, which uses
BIGALLOC feature introduced in e2fsprogs v1.42.
While there are a lot of enterprise distributions which are still using
v1.41 e2fsprogs, this will cause compile error for them.
This patch introduces backward compatibility for new convert framework,
by manually introduce macros for ext2 BIGALLOC feature.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
btrfs-progs build failed in CentOS 6 and 7:
#./autogen.sh
...
configure.ac:131: error: possibly undefined macro: PKG_CHECK_VAR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
...
Seems PKG_CHECK_VAR is new in pkgconfig 0.28 (24-Jan-2013):
http://redmine.audacious-media-player.org/boards/1/topics/736
And the max available version for CentOS 7 in yum-repo and
rpmfind.net is: pkgconfig-0.27.1-4.el7
http://rpmfind.net/linux/rpm2html/search.php?query=pkgconfig&submit=Search+...&system=centos&arch=
I updated my pkgconfig to 0.30, but still failed at above error.
(Maybe it is my setting problem)
To make user in centos 6 and 7 building btrfs-progs without
more changes, we can avoid using PKG_CHECK_VAR in following
way found in:
f95ab6f939
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Systemd's btrfs rule runs btrfs dev ready on each device
as it's discovered. The btrfs command is executed as a builtin
command via an IMPORT{builtin} rule, which means it gets
executed at rule evaluation time, not rule execution time. That
means that the device mapper links haven't been setup yet and the only
nodes that can be depended upon are /dev/dm-#. That we see
/dev/mapper/name names in /proc/mounts is only because we replace the
device name we have cached with the one passed in via mount. If
we have a multi-device file system and the primary device is removed,
the remaining devices will show /dev/dm-#. In addition, if the
udev rule is executed again by someone generating a change event (e.g.
partprobe), the names are also replaced by the /dev/dm-# names.
This patch adds a new rule that adds a run rule that calls btrfs dev
ready again using the device mapper links once they're created.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We want to support version 1.41 due to longterm and enterprise distros,
make the check explicit.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
AC_CHECK_TOOL takes the --host option into account for cross-compiling.
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: David Sterba <dsterba@suse.com>
The conversion to autotools changed the default prefix to /usr. There's
no reason to diverge. Distributions builds set prefix the /usr path and
local builds are supposed to go to /usr/local .
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=108571
Reported-by: Karl Richter <krichter722@aol.de>
Signed-off-by: David Sterba <dsterba@suse.com>
AC_ARG_ENABLE(convert) sets $enable_convert, not $enable_btrfsconvert.
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: David Sterba <dsterba@suse.cz>
The PACKAGE_URL is set from optional parameter of AC_INIT starting in
autoconf 2.64. There are enterprise distros with version 2.63, we can
make the build work there easily as well.
Fixes build failure:
mkfs.c: In function ?main?:
mkfs.c:1492: error: ?PACKAGE_URL? undeclared (first use in this function)
Reported-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Keep only flags that are required to build properly, current fine
tunings are moved to the optional defaults in configure and can be
overriden by the user.
Signed-off-by: David Sterba <dsterba@suse.cz>
The expected way to define custom CFLAGS is
$ export CFLAGS=...
$ ./configure ...
the build will use them. No not override the make variables directly
from now on.
Signed-off-by: David Sterba <dsterba@suse.cz>
- define basic default CFLAGS in configure.ac, because:
* autoconf default is -g -O2, but btrfs uses -g -O1
* it's better to follow autoconf; standard way to modify
CFLAGS is to call: CFLAGS="foo bar" ./configure
- move all flags to one place in Makefile.in
- don't use AM_CFLAGS, the CFLAGS and STATIC_CFLAGS are enough
- don't mix objects and flags in $LIBS, it's more readable to
add $(libs) to make rules
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
The original homemade solution is unnecessary, autotools provides better
infrastructure to generate files.
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
- add ./autogen.sh script (necessary after git clean/clone)
- add ./configure.ac
- copy autotool helper scripts from automake
- modify version.sh to be usable from the configure script
- rename Makefile to Makefile.in and use basic variables from configure.ac
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
David Sterba
Omar Sandoval
Sergei Trofimovich
Nick Terrell
Jeff Mahoney
Qu Wenruo
Zhao Lei
Mike Gilbert
David Sterba
Karel Zak