The old Makefile patch can no longer be applied; so I wrote a new patch
that applies to 0.14 that is also applied to the 9999 version for now,
and sent it upstream.
Additionally, I added an export NDEBUG=1 command in src_compile:
without this, -g and -Werror are added after CFLAGS by the Makefile
possibly shadowing options like -ggdb3 that user might have set, or
causing a build to fail just because a warning was reported.
Bump copyright of touched ebuild files.
Ref: https://github.com/curl/trurl/pull/322
Signed-off-by: Emanuele Torre <torreemanuele6@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
It defaults to tesseract anyway, and cuneiform hasn't been maintained
since 2011 and generally doesn't build. Unlikely anyone has any desire
to use it. Upstream only continues to support cuneiform at all because
they want to "exercise the code" with regard to its support for multiple
runtime-switchable backends.
cuneiform is being last-rited. In the unlikely event someone was using
it, they will be warned to uninstall it and install tesseract instead by
the mask. If they really don't want to, they can ignore the mask *and*
the pyocr rebuild. In the event that people were using tesseract, they are
perfectly fine anyway and don't need to rebuild (but changed-deps
and changed-use will both try to rebuild). No revbump.
Bug: https://bugs.gentoo.org/937994
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
I copied this comment from mingw64-toolchain and was waiting for
builds to finish on a few machines to see if it made any difference
before updating the number and apparently it.. barely does?
I'll come back to it another time in case I'm missing something though.
Signed-off-by: Sam James <sam@gentoo.org>
Note that unlike dev-util/mingw64-toolchain, we're enabling it by default
because it'll be pretty uncommon for anyone to have a crossdev-built
toolchain for it. This is needed to avoid conflicts if someone wants
to build a bpf-unknown-none toolchain via crossdev where an ebuild
depends on bpf-toolchain (wouldn't be possible before because of file
conflicts).
Also, with it off by default, we would have to add some hacks in e.g.
the systemd ebuild to make it work by mangling PATH and things get
tricky there especially given only a small part of the build would even use it.
May change mind on this later if needed though.
Signed-off-by: Sam James <sam@gentoo.org>
The real issue is intrinsic to Go (or cgo, anyway) and so we shouldn't
do it per-package, but rather in go-env.eclass. That's done now, so
drop the package-local workaround.
Bug: https://bugs.gentoo.org/924496
Signed-off-by: Sam James <sam@gentoo.org>
After experiencing the bug described in https://bugs.gentoo.org/924496,
I was surprised to see filter-flags "-ggdb3" in the ebuilds for this
package.
I did some digging and found that go's goc does not use CFLAGS, LDFLAGS,
etc by default; it only uses the GOC_*FLAGS environment variables.
What causes goc to use CFLAGS if GOC_FLAGS is unset or empty is the
go-env_set_compile_environment function from the go-env eclass, that is
indirectly called by the go-module_live_vendor and go-module_src_unpack
functions from the go-module eclass that are being called from the
src_unpack of this ebuild.
So, calling filter-lto , filter-flags "-ggdb3" , and unset LDFLAGS
from src_compile before emake seems completely useless since those will
only filter regular *FLAGS environment variable, and not the
GOC_*FLAGS environment variables initialised from the *FLAGS
variables earlier on in src_unpack.
Moving those filter/unset commands to the start of src_unpack makes
them filter/unset *FLAGS variables before GOC_*FLAGS variables are set,
and actually fix the build problem encountered when CFLAGS contains
-ggdb3.
Bump copyright of touched ebuild files.
Bug: https://bugs.gentoo.org/847991
Closes: https://bugs.gentoo.org/924496
Signed-off-by: Emanuele Torre <torreemanuele6@gmail.com>
Closes: https://github.com/gentoo/gentoo/pull/38140
Signed-off-by: Sam James <sam@gentoo.org>