Note that this ebuild fails the test phase when linked against
<net-libs/librsync-2.0.1. Upstream has been notified and already
fixed the problem in the master branch, meanwhile however just let it
slide - it only occurs if you combine an unstable version of burp with a
stable version of librsync.
Package-Manager: Portage-2.3.13, Repoman-2.3.3
This release fixes a significant issue in the s6 integration which could
cause supervised services to not be stopped successfully.
I am committing this straight to stable where 0.34.7 is stable because
it is the only change from 0.34.7 and imo is high priority if you are
using the s6 integration.
Package-Manager: Portage-2.3.13, Repoman-2.3.3
RepoMan-Options: --force
- eutils.eclass not needed
- one sed not two for gtk/makefile
- consistent sed paths and error messages
- Encoding now removed from desktop file
- ensure variable declared in src_compile is local
- dodir's in src_install not needed
Closes: https://bugs.gentoo.org/637518
Package-Manager: Portage-2.3.13, Repoman-2.3.3
Modify the ebuild to no longer enforce externally installed
dev-python/lit for tests, effectively causing the build system to use
the bundled copy of lit (along with llvm-lit). While using the external
package is more canonical, its disadvantages outweight the gain.
Most notably, lit is not slotted in Gentoo and the behavior of lit
frequently changes subtly which caused us to require a major version
match between LLVM and lit. As a result, attempting to build multiple
slots of LLVM with tests enabled cause package collisions. Building both
LLVM and lit simultaneously causes a circular dependency.
Since lit comes from the same package as LLVM and clang requires it
anyway for gtest, using the bundled copy has no added cost.
However, the live ebuild is currently broken as it requires llvm-lit
that is not created in the stand-alone build. This will be fixed
upstream.
Modify the ebuild to no longer enforce externally installed
dev-python/lit for tests, effectively causing the build system to use
the bundled copy of lit (along with llvm-lit). While using the external
package is more canonical, its disadvantages outweight the gain.
Most notably, lit is not slotted in Gentoo and the behavior of lit
frequently changes subtly which caused us to require a major version
match between LLVM and lit. As a result, attempting to build multiple
slots of LLVM with tests enabled cause package collisions. Building both
LLVM and lit simultaneously causes a circular dependency.
Since lit comes from the same package as LLVM itself and LLVM requires
explicit python-any-r1 use anyway, using the bundled copy has no added
cost. Furthermore, in the current git version the additional
(fine-grained) test rules do not work correctly without llvm-lit, making
it impossible to run LLVM binding tests separately.
Modify the ebuild to no longer enforce externally installed
dev-python/lit for tests, effectively causing the build system to use
the bundled copy of lit (along with llvm-lit). While using the external
package is more canonical, its disadvantages outweight the gain.
Most notably, lit is not slotted in Gentoo and the behavior of lit
frequently changes subtly which caused us to require a major version
match between LLVM and lit. As a result, attempting to build multiple
slots of LLVM with tests enabled cause package collisions. Building both
LLVM and lit simultaneously causes a circular dependency.
Since lit comes from the same package as LLVM itself and LLVM requires
explicit python-any-r1 use anyway, using the bundled copy has no added
cost. It reduces the risk of breakage resulting from skipping llvm-lit
wrapper and solves the forementioned problems caused by depending
on dev-python/lit.
The external package is still useful for projects that do not require
LLVM sources.
Adds support for Python 3 and recent versions of PostgreSQL. Uses the
new postgres eclass to manage dependency on dev-db/postgresql.
Closes: https://bugs.gentoo.org/580668
Package-Manager: Portage-2.3.13, Repoman-2.3.3