Debian Patches

Status for brial/1.2.15-1

Patch Description Author Forwarded Bugs Origin Last update
typo.patch fix a trivial typo in a source file Julien Puydt yes
fix_ftbfs_m4ri_cflags_substitution.patch Accept m4ri < 20250128 and strip unsubstituted @VAR@ tokens m4ri.pc.in references @SIMD_CFLAGS@ in its Cflags line, but m4ri's
configure.ac (before 20250128) never calls AC_SUBST(SIMD_CFLAGS). The
installed m4ri.pc therefore contains a literal "@SIMD_CFLAGS@" string in
the Cflags field, which pkg-config returns as part of M4RI_CFLAGS. The
compiler then treats @SIMD_CFLAGS@ as a file argument and fails with
"linker input file not found: @SIMD_CFLAGS@".
.
Upstream 1.2.15 handles this by requiring m4ri >= 20250128, which is not
yet available in Debian. Drop that version constraint and, after
M4RI_CFLAGS is (re)assigned from pkg_cv_M4RI_CFLAGS, strip any remaining
unsubstituted @VAR@ tokens with sed. This is safe: valid compiler flags
never take the @TOKEN@ form.
.
This patch can be dropped once m4ri >= 20250128 is in Debian.		 Azeez Syed <azeezalishah@gmail.com> not-needed debian 2026-09-29
fix_brial_pc_m4ri_cflags.patch Don't propagate m4ri's broken Cflags through brial.pc brial.pc has "Requires: m4ri", so "pkg-config --cflags brial" includes the
Cflags of m4ri.pc, which for m4ri < 20250128 contain a literal
"@SIMD_CFLAGS@" token (Debian: #1093321). Every package building against
brial through pkg-config would then fail the same way brial itself did.
.
Instead of requiring m4ri, embed the m4ri flags found at configure time.
M4RI_CFLAGS has already been cleaned of @VAR@ tokens by
fix_ftbfs_m4ri_cflags_substitution.patch.
.
This patch can be dropped together with that one once m4ri >= 20250128 is
in Debian.		 Maximiliano Curia <maxy@debian.org> not-needed debian 2026-09-29
fix_c++20_compilation.patch Fix compilation and tests with C++20 (#64)
GCC 16 defaults to C++20, which breaks BRiAl in two places.

std::accumulate now invokes the binary operation as
binary_op(std::move(acc), *i). AddEliminationDegree::operator() took a
non-const size_type& that cannot bind to that rvalue. Take the
accumulator by value and return the updated count instead. The numeric
result is unchanged.

operator==(bool, const BoolePolynomial&) is implemented as
`return (rhs == lhs)`. In C++20 that expression also considers the
reversed candidate, which is this same function, so the comparison
recurses instead of calling BoolePolynomial::operator==(constant_type).
The same issue applies to operator!=. Call the member operators
directly. This keeps the existing semantics and unbreaks tests such as
`true == BoolePolynomial(true, ring)`.		 Xeonacid <h.dwwwwww@gmail.com> no 2026-09-01

All known versions for source package 'brial'

Links