To build: meson build && ninja -C build
To run tests: ninja -C build check
To install for packaging: DESTDIR=/var/tmp/inst ninja -C build install
To install for realz: sudo ninja -C build install
v2:
- Optional items are now based on the 'feature' feature in meson.
Built libraries which are disabled turn into disabler() objects
and also poison any executables which link to them.
What is there:
- building of the binaries and libs and the python module
- installation of binaries, libs, python module, localization files,
man pages, pkgconfig files
- running of tests
- most options to configure build equivalently to the
./configure settings
Partially implemented:
- disabling of stuff when things missing. In the C code, the defines
are all used, so that should be fine. In the build system, some
files should be skipped, but that is probably not always done properly.
Getting this right might require some testing of various build option
combinations to get the details right.
Not implemented:
- static builds of fdisk and other binaries
- things marked with XXX or FIXME
- ???
Differences:
- .la files are not created. They are useless and everybody hates them.
- Requires.private in pkgconfig files are not present in the
autogenerated .pc file. Not sure if they should be there or not. If
necessary, they can be added by hand.
- man pages and systemd units are installed by the install target. Not
sure why 'make install' doesn't do that.
- the split between / and /usr is probably wrong. But it's all pointless
anyway, so maybe we could simplify things but not implementing it at
all under meson?
Fix couple "initialization of ‘long int’ from ‘void *’ makes integer from
pointer without a cast" warnings.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
* 'clang' of https://github.com/neheb/util-linux:
[clang-tidy] fix misleading identation
[clang-tidy] use ceil
[clang-tidy] fix wrong *cmp usage
[clang-tidy] do not use else after return
[clang-tidy] do not return in void functions
[clang-tidy] fix mismatching declarations
A new API was added to libcryptsetup to make use of the kernel's new
CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG feature, which allows to sign
root hashes. Add a verity.roothashsig option to use it.
Device reuse will be allowed only if signatures are used by all, or
by none.
Allow users to point mount to a file to read the roothash, in addition
to passing it inline.
Allows a volume managed by a systemd mount unit to be updated without
changing the mount unit content itself, for easier and more user friendly
servicing.
The following new options are added:
verity.hashdevice
verity.roothash
verity.hashoffset
The source path will be used as a dm-verity object, and will be
opened using libcryptsetup APIs.
A new --with-cryptsetup build-time option is added, which adds a
dependency on libcryptsetup. To ease bootstrapping, given libcryptsetup
build-depends on util-linux for libuuid, if --with-cryptsetup=yes but
libcryptsetup is not installed only a warning will be printed at
configure time rather than an error. This way stage0/first stage/ring0
builds can use the same configure options but avoid installing
cryptsetup to get a working base set, and then rebuild util-linux in
the next step of the boostrapping process.
If verity options are selected but cannot be fullfilled due to lack of
dependencies, mounting a volume will fail even if using a loop device
would work as a fallback, to avoid silently skipping integrity checks.
Sorry detail-oriented people tend to wipe these out if they notice them.
Add in automated tools and lots of excess end-of-line spaces get wiped
out.
Addresses: https://github.com/karelzak/util-linux/pull/849
Signed-off-by: Karel Zak <kzak@redhat.com>
libmount/python/pylibmount.c:158:19: warning: cast between incompatible function types
from ‘PyObject * (*)(PyObject *)’ {aka ‘struct _object * (*)(struct _object *)’}
to ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object *)’}
[-Wcast-function-type]
This is generic problem in all Python C code and gcc v8. The another
possible (and probably more correct) way is to add unused argument to
all API functions. Unfortunately, this solution is pretty invasive. The
question is if gcc is not too paranoid in this case.
For more details see https://bugs.python.org/issue33012. It seems
Python guys also prefer CFLAGS modification for now.
Signed-off-by: Karel Zak <kzak@redhat.com>
The current implementation would return always 0, as it is the return
code of mnt_fs_get_propagation. Change the implementation to raise an
exception on an error and return the propagation flags otherwise.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
text-utils/tailf.c:69:21: warning: Using plain integer as NULL pointer
Since many 'struct option' has used zero as NULL make them more readable in
same go by reindenting, and using named argument requirements.
Reference: https://lwn.net/Articles/93577/
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Don't know why this was added in d78df0ac but it can't be right that
libmount/python removes these files in the toplevel builddir. Moreover
I've never seen such *.img files appearing during build at all.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
Fix various typos in error messages, warnings, debug strings,
comments and names of static functions.
Signed-off-by: Sebastian Rasmussen <sebras@gmail.com>
BSD/Linux systems stick major/minor/makedev in sysmacros.h. Newer Linux
libraries have been moving away from including sysmacros.h implicitly via
sys/types.h, so include it directly.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This fixes a failure of `make install DESTDIR=...` when trying to relink
pylibmount against libmount.la.
libtool will look for libmount.so under ${DESTDIR}/${libdir}, but if it
is not yet present, it will assume it is a system installed library and
use -lmount instead.
This makes the install order significant.
Automake lists the install entries in alphabetical order, and as
install-pylibmountexecLTLIBRARIES < install-usrlib_execLTLIBRARIES,
make will try to install pylibmount.so before libmount.so is present
in the DESTDIR, which will then cause libtool to fallback to -lmount
when relinking. This causes the error below:
libtool: install: warning: relinking `pylibmount.la'
libtool: install: (... libtool --mode=relink gcc -o pylibmount.la \
-rpath /usr/lib/python2.7/dist-packages/libmount \
libmount/python/*.lo libmount.la ... -lpython2.7 \
-inst-prefix-dir /path/to/destdir)
/usr/bin/ld: cannot find -lmount
collect2: error: ld returned 1 exit status
libtool: install: error: relink `pylibmount.la' ...
make[3]: *** [install-pylibmountexecLTLIBRARIES] Error 1
Work around this issue by using a zz_ prefix for the pylibmount exec
dir, in order to install it last.
This does not work if parallel make is used for the install step, but
that should be a minor issue (parallel install is probably not that
useful for util-linux, which is not that large a package to actually
benefit from it.) The proper fix should be to introduce a make
dependency of target install-pylibmountexecLTLIBRARIES on target
install-usrlib_execLTLIBRARIES, but unfortunately there is no good way
to accomplish that in automake without overriding it completely.
This issue seems to be previously encountered in automake context, since
automake includes a hack to insert such a dependency rule to install all
libLTLIBRARIES before attempting to install binPROGRAMS, initially
introduced in the commit below:
http://git.savannah.gnu.org/cgit/automake.git/commit/?id=bd4a1d5ad1a72fa780a8b7fd6c365a5dad2e6220
Also, a related bug from Ubuntu tracker:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1442076
Tested that `make install` starts working again after this commit, even
when libmount-dev is not installed on the system. Also confirmed that
`make distcheck` is now functional.
Confirmed that both __init__.py and the .so library are still installed
in the Python directory.
Tested that it still works without python-devel installed, also
inspected Makefile.in which looks correct.
Tested that `make install pylibmountexecdir=...` still works to override
destination directory at `make install` time.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Sometimes we use "behaviour" and "behavior" in the same text, let's
use "behavior" only everywhere.
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1011068
Signed-off-by: Karel Zak <kzak@redhat.com>
- add python helper scripts to the dist
- helper scripts are always in srcdir
- python libs are in builddir
- abort tests if helpers are missing
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
Actually the initial reason for this commit was to remove execute
permission from installed __init__.py.
Now after discovering automake's _PYTHON suffix we slightly cleanup
Makemodule.am and we will install byte compiled .pyc and .pyo files.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
"make dist" and "make distcheck" should work after a bare
./configure to give us a full featured tar ball.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
This change does not have any impact to in a standard way installed
libmount impact. It's simplification for in-tree tests.
Signed-off-by: Karel Zak <kzak@redhat.com>
Without this, python is unable to find the module:
$ python -c 'import libmount'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3.3/site-packages/libmount/__init__.py", line 1, in <module>
from pylibmount import *
ImportError: No module named 'pylibmount'
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
It seems we have to call AM_PATH_PYTHON() monster to get
pyexec (shared libs) and python (scripts) directories.
Signed-off-by: Karel Zak <kzak@redhat.com>
* we use pkg-config to get CGLAGS and LIBS, use package specific
config (e.g. python-config) is non-sense.
* default is to follow distribution and use pkg-config module name
"python". This is probably symlink to python2.pc or python3.pc.
* --with-python=2 forces to pkg-module "python2 >= 2"
* --with-python=3 forces to pkg-module "python3 >= 3"
Signed-off-by: Karel Zak <kzak@redhat.com>
It's better to follow libmnt_context status than allow to play any
nasty games with this important variables in Python.
Signed-off-by: Karel Zak <kzak@redhat.com>
Karel Zak
Zbigniew Jędrzejewski-Szmek
Sami Kerola
Rosen Penev
Luca Boccassi
Elliott Mitchell
Frank Schaefer
Giuseppe Scrivano
Zac Medico
Ruediger Meier
Sebastian Rasmussen
Ruediger Meier
Mike Frysinger
Filipe Brandenburger
Dave Reisner
Ondrej Oprala