- switches slot of dependency assertj-core 2 -> 3
- removes test restriction
- moves "test" from IUSE to JAVA_PKG_IUSE
- sets the "-verbose 3" option to get the PASSED/FAILED information
- uses older version of jcommander 0 -> 1.64
- uses the DOCS array instead of dodoc
- uses JAVA_RESOURCE_DIRS instead of java-pkg_addres which allows
removing src_compile()
- chops long lines
- adds MAVEN_ID so that java-ebuilder can find it
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
Solution of bug #906311 removes all test classes at beginning of
src_test() including test classes generated from the ebuild.
With this commit generated test classes will be copied from the new
generated-test directory into target/test-classes.
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
The etestng function is presently limited to running test classes and
has no option for running testng.xml files. Using testng.xml in an
ebuild requires manual coding in src_test().
This change adds a switch to the etestng function which allows running
default src_test() with either testng.xml files or test classes.
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
This has never been caused by the upstream binary install, which
installs to /opt and does not affect from-source installs under any
circumstances ever.
What did happen is back during the major version update from 2.85 to
3.0, upstream stopped including a vendored regex/ module, and started
expecting it to be installed as a system dependency.
Under most circumstances, this was fine, and simply installing the
dependency would get things working. One possible edge case occurred,
however, when the old version of the package did NOT byte-compile the
vendored regex module, but calibre was run as root. (There are reasons
it might end up being run as root, the most obvious being that a user
wanted to run the headless server or another command-line tool.)
If this happened, then the python interpreter would automatically
byte-compile every module on import, but the PM wouldn't track it for
removal. After an upgrade, the cached file could still be imported and
would effectively mask the system version of the regex module, but would
be missing the binary portion.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Zac Medico <zmedico@gentoo.org>
Historically, calibre has always supported this. Allow checking it. No
revbump needed.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Zac Medico <zmedico@gentoo.org>
Since calibre 3.3.0 the distfile has come with prebuilt manpages for the
CLI programs. Add them to the installation.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Zac Medico <zmedico@gentoo.org>
Since there is no real standard and no real detection method for zsh
completions (and Debian tunes this to be something that doesn't work
anywhere else) the build system probes for the common locations.
Also, this probe is carried out against staging-root, not /, which
means that it will NEVER work. Not even if you have zsh installed.
Unless you create the directory in advance in the staging-root, which
you have to do anyways because otherwise you would need zsh as a BDEPEND
which is silly. ;)
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Zac Medico <zmedico@gentoo.org>
calibre needs support for these image types, and tests for some of them,
but their USE flags aren't guaranteed to be enabled. Guarantee it, even
if until now people tended not to notice somehow. ;)
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Zac Medico <zmedico@gentoo.org>
Of note:
- dbus-python was deprecated and removed by the addition of jeepney
- cssselect was deprecated and removed by the addition of css-parser
The glib and libX* dependencies are an interesting bit of history. As
far as calibre is concerned, these have never been required (they are
not directly used). But the libheadless.so plugin which uses Qt private
APIs ends up inheriting a bunch of dependencies from Qt itself,
depending on whatever Qt internals get exposed by that private API. This
results in symbols inside libheadless.so linking to libraries that
QtCore also links to. We still have to rebuild libheadless.so on ever
update to Qt because private API, though. And the really fun bit is that
the dependencies do, of course, change over time. :) Currently libX* is
not actually used anymore, for example.
dbus-glib *looks* like it may have been superficially a recursive dep of
something else?
libwmf had extremely extremely old code in the calibre source tree which
could have compiled against it, but never really did so. There's a
custom encoder/decoder written in pure python.
zlib is not directly depended on by calibre, though some dependencies do
have to be built with USE=zlib which doesn't really help. For all direct
uses of zlib, calibre simply uses the python stdlib "zlib" module, which
is not optional anyway.
calibre has never been setuptools software, so that can be dropped.
There are two chardet modules of relevance: chardet and cchardet. At
runtime, calibre only uses the latter. The tests use both of them due to
reasons. We can avoid installing it except when USE=test.
PyQt-builder is used in the build system (and as the name implies, it is
a module for building code). It can be dropped to a build dependency.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Zac Medico <zmedico@gentoo.org>
Since 2012, calibre has stopped building a compiled binding for poppler,
and started using the command-line utils via subprocesses. Make sure
those are installed.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Zac Medico <zmedico@gentoo.org>
Volkmar W. Pogatzki
Arsen Arsenović
Michał Górny
Sam James
Joonas Niilola
Eli Schwartz