[gentoo-dev] Java issue with a proprietary game
Hi, Recently I’ve run into an issue with a proprietary java game called The Count Lucanor. It is distributed on GOG.com with a bundled Java 8 binary. Since bundled libraries are evil™, I’ve tried getting rid of it in favor of my system java binary. If the latter is Java 8, everything works as expected. However, using Java 17 the game crashes on start with the following error: Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed! This happened with dev-java/openjdk:17 but to my surprise didn’t with dev-java/openjdk-bin:17. I figured Eclipse Temurin had to build OpenJDK with different flags than I did, which fixed the issue. After running a bunch of tests, I managed to build a working java binary by removing -Wl,--as-needed from my LDFLAGS (or adding -Wl,--no-as-needed). This flag is set by my profile — default/linux/amd64/17.1 — so I expect mostly everyone to have it. Should I propose a patch to dev-java/openjdk:17 in order to filter out -Wl,--as-needed? I have no idea what this flag is for nor if removing it might result in other issues, which is why I’m asking on this mailing-list before doing so. Moreover, that would be in order to fix an issue with a proprietary game, and I don’t know what is Gentoo policy regarding that kind of bug. If I am to propose a patch, should I do so using filter-flag from flag-o-matic.eclass, or no-as-needed which is provided by the same eclass and is a no-op on clang? (My C compiler is gcc and I haven’t tested building OpenJDK17 with clang.) If I should propose a patch, should I first open a bug in gentoo bugtracker so that it may be referenced in the ebuild? Thanks Hoël PS: Using dev-java/openjdk:11 to run the game also fails, but with a different error which I did not try to fix. So this discussion is only about dev-java/openjdk:17. signature.asc Description: PGP signature
[gentoo-dev] [PATCH 5/5] toolchain-funcs.eclass: consistently pass CPPFLAGS before C{,XX}FLAGS
This is generally what we do in patches and such.
Signed-off-by: Sam James
---
eclass/toolchain-funcs.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 9bb660e4f71f3..c2c2d1199155d 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -1211,7 +1211,7 @@ tc-get-cxx-stdlib() {
#endif
'
local res=$(
- $(tc-getCXX) ${CXXFLAGS} ${CPPFLAGS} -x c++ -E -P - \
+ $(tc-getCXX) ${CPPFLAGS} ${CXXFLAGS} -x c++ -E -P - \
<<<"${code}" 2>/dev/null
)
@@ -1239,7 +1239,7 @@ tc-get-cxx-stdlib() {
# If the runtime is not recognized, the function returns 1.
tc-get-c-rtlib() {
local res=$(
- $(tc-getCC) ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} \
+ $(tc-getCC) ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} \
-print-libgcc-file-name 2>/dev/null
)
--
2.39.1
[gentoo-dev] [PATCH 4/5] toolchain-funcs.eclass: style tweaks
Signed-off-by: Sam James
---
eclass/toolchain-funcs.eclass | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 840111f6cc30d..9bb660e4f71f3 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -422,19 +422,19 @@ tc-env_build() {
# src_configure() {
# ECONF_SOURCE=${S}
# if tc-is-cross-compiler ; then
-# mkdir "${WORKDIR}"/${CBUILD}
-# pushd "${WORKDIR}"/${CBUILD} >/dev/null
+# mkdir "${WORKDIR}"/${CBUILD} || die
+# pushd "${WORKDIR}"/${CBUILD} >/dev/null || die
# econf_build --disable-some-unused-stuff
-# popd >/dev/null
+# popd >/dev/null || die
# fi
# ... normal build paths ...
# }
# src_compile() {
# if tc-is-cross-compiler ; then
-# pushd "${WORKDIR}"/${CBUILD} >/dev/null
+# pushd "${WORKDIR}"/${CBUILD} >/dev/null || die
# emake one-or-two-build-tools
-# ln/mv build-tools to normal build paths in ${S}/
-# popd >/dev/null
+# ln/mv build-tools to normal build paths in ${S}/ || die
+# popd >/dev/null || die
# fi
# ... normal build paths ...
# }
@@ -676,7 +676,7 @@ tc-has-tls() {
# Parse information from CBUILD/CHOST/CTARGET rather than
# use external variables from the profile.
tc-ninja_magic_to_arch() {
-ninj() { [[ ${type} == "kern" ]] && echo $1 || echo $2 ; }
+ ninj() { [[ ${type} == "kern" ]] && echo $1 || echo $2 ; }
local type=$1
local host=$2
@@ -815,8 +815,8 @@ tc-get-compiler-type() {
case ${res} in
*HAVE_PATHCC*) echo pathcc;;
*HAVE_CLANG*) echo clang;;
- *HAVE_GCC*) echo gcc;;
- *) echo unknown;;
+ *HAVE_GCC*) echo gcc;;
+ *) echo unknown;;
esac
}
@@ -834,11 +834,11 @@ tc-is-clang() {
# Internal func. The first argument is the version info to expand.
# Query the preprocessor to improve compatibility across different
-# compilers rather than maintaining a --version flag matrix. #335943
+# compilers rather than maintaining a --version flag matrix, bug #335943.
_gcc_fullversion() {
local ver="$1"; shift
set -- $($(tc-getCPP "$@") -E -P - <<<"__GNUC__ __GNUC_MINOR__
__GNUC_PATCHLEVEL__")
- eval echo "$ver"
+ eval echo "${ver}"
}
# @FUNCTION: gcc-fullversion
@@ -871,7 +871,7 @@ gcc-micro-version() {
_clang_fullversion() {
local ver="$1"; shift
set -- $($(tc-getCPP "$@") -E -P - <<<"__clang_major__ __clang_minor__
__clang_patchlevel__")
- eval echo "$ver"
+ eval echo "${ver}"
}
# @FUNCTION: clang-fullversion
@@ -1098,7 +1098,7 @@ gen_usr_ldscript() {
# is referenced ... makes multilib saner
local flags=( ${CFLAGS} ${LDFLAGS} -Wl,--verbose )
if $(tc-getLD) --version | grep -q 'GNU gold' ; then
- # If they're using gold, manually invoke the old bfd. #487696
+ # If they're using gold, manually invoke the old bfd, bug
#487696
local d="${T}/bfd-linker"
mkdir -p "${d}"
ln -sf $(type -P ${CHOST}-ld.bfd) "${d}"/ld
--
2.39.1
[gentoo-dev] [PATCH 3/5] toolchain-funcs.eclass: include CXXFLAGS in various tc-enables-* checks
SSP and PIE are relevant to C++ too.
Signed-off-by: Sam James
---
eclass/toolchain-funcs.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index d46104275f8e6..840111f6cc30d 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -1012,7 +1012,7 @@ tc-enables-cxx-assertions() {
# Return truth if the current compiler generates position-independent code
(PIC)
# which can be linked into executables.
tc-enables-pie() {
- tc-cpp-is-true "defined(__PIE__)" ${CPPFLAGS} ${CFLAGS}
+ tc-cpp-is-true "defined(__PIE__)" ${CPPFLAGS} ${CFLAGS} ${CXXFLAGS}
}
# @FUNCTION: tc-enables-fortify-source
@@ -1033,7 +1033,7 @@ tc-enables-fortify-source() {
# -fstack-protector-strong
# -fstack-protector-all
tc-enables-ssp() {
- tc-cpp-is-true "defined(__SSP__) || defined(__SSP_STRONG__) ||
defined(__SSP_ALL__)" ${CPPFLAGS} ${CFLAGS}
+ tc-cpp-is-true "defined(__SSP__) || defined(__SSP_STRONG__) ||
defined(__SSP_ALL__)" ${CPPFLAGS} ${CFLAGS} ${CXXFLAGS}
}
# @FUNCTION: tc-enables-ssp-strong
@@ -1044,7 +1044,7 @@ tc-enables-ssp() {
# -fstack-protector-strong
# -fstack-protector-all
tc-enables-ssp-strong() {
- tc-cpp-is-true "defined(__SSP_STRONG__) || defined(__SSP_ALL__)"
${CPPFLAGS} ${CFLAGS}
+ tc-cpp-is-true "defined(__SSP_STRONG__) || defined(__SSP_ALL__)"
${CPPFLAGS} ${CFLAGS} ${CXXFLAGS}
}
# @FUNCTION: tc-enables-ssp-all
@@ -1054,7 +1054,7 @@ tc-enables-ssp-strong() {
# on level corresponding to any of the following options:
# -fstack-protector-all
tc-enables-ssp-all() {
- tc-cpp-is-true "defined(__SSP_ALL__)" ${CPPFLAGS} ${CFLAGS}
+ tc-cpp-is-true "defined(__SSP_ALL__)" ${CPPFLAGS} ${CFLAGS} ${CXXFLAGS}
}
--
2.39.1
[gentoo-dev] [PATCH 2/5] toolchain-funcs.eclass: add tc-enables-cxx-assertions
Bug: https://bugs.gentoo.org/884417
Bug: https://bugs.gentoo.org/876895
Signed-off-by: Sam James
---
eclass/toolchain-funcs.eclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index b9e956098b3e2..d46104275f8e6 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -996,6 +996,15 @@ gcc-specs-stack-check() {
[[ "${directive/\{!fno-stack-check:}" != "${directive}" ]]
}
+# @FUNCTION: tc-enables-cxx-assertions
+# @RETURN: Truth if the current compiler enables assertions in the C++
standard library
+# @DESCRIPTION:
+# Return truth if the current compiler enables assertions in the C++ standard
+# library. For libstdc++, this is -D_GLIBCXX_ASSERTIONS, and for libcxx/libc++,
+# this is -D_LIBCPP_ENABLE_ASSERTIONS.
+tc-enables-cxx-assertions() {
+ tc-cpp-is-true "defined(_GLIBCXX_ASSERTIONS) ||
defined(_LIBCPP_ENABLE_ASSERTIONS)" ${CPPFLAGS} ${CXXFLAGS}
+}
# @FUNCTION: tc-enables-pie
# @RETURN: Truth if the current compiler generates position-independent code
(PIC) which can be linked into executables
--
2.39.1
[gentoo-dev] [PATCH 1/5] toolchain-funcs.eclass: add tc-enables-fortify-source for FORTIFY_SOURCE
As Zero_Chaos reported on IRC, the check we had wasn't good enough in systemd*
(before we were able to remove it), as it wouldn't fire for e.g. -Os. While we
could've changed it to fail safe (always unset, then set a lower F_S if
possible),
let's add a proper helper instead to the eclass.
Bug: https://bugs.gentoo.org/841770
Bug: https://bugs.gentoo.org/847148
Bug: https://bugs.gentoo.org/876893
Signed-off-by: Sam James
---
eclass/toolchain-funcs.eclass | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index bfcd6819ed0b0..b9e956098b3e2 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -1,4 +1,4 @@
-# Copyright 2002-2022 Gentoo Authors
+# Copyright 2002-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: toolchain-funcs.eclass
@@ -1006,6 +1006,15 @@ tc-enables-pie() {
tc-cpp-is-true "defined(__PIE__)" ${CPPFLAGS} ${CFLAGS}
}
+# @FUNCTION: tc-enables-fortify-source
+# @RETURN: Truth if the current compiler enables FORTIFY_SOURCE at any level
+# @DESCRIPTION:
+# Return truth if the current compiler enables fortification (FORTIFY_SOURCE)
+# at any level (-D_FORTIFY_SOURCE).
+tc-enables-fortify-source() {
+ tc-cpp-is-true "defined(_FORTIFY_SOURCE)" ${CPPFLAGS} ${CFLAGS}
${CXXFLAGS}
+}
+
# @FUNCTION: tc-enables-ssp
# @RETURN: Truth if the current compiler enables stack smashing protection
(SSP) on at least minimal level
# @DESCRIPTION:
--
2.39.1
Re: [gentoo-dev] dev-python/ package naming policy?
On Sun, Jan 29, 2023 at 02:15:19AM +0300, Torokhov Sergey wrote:
> The similar names in PyPi is a real problem for users when trying to
> find associated packages. It's also could be a security issue for them with
> malicious packages named like popular packages. />So in ::guru I try to save package naming even if it's too
> CamelCase.As for replacing dot (".") with hyphen
> ("-") I have PyPi package "FoBiS.py" that is packaged in ::guru just as
> "FoBiS" as I wasn't sure is it worth to store ".py" suffix while github repo
> of this project is just "FoBiS". So there could be a problem if package named
> "fobis" will appear in PyPi.28.01.2023, 19:38,
> "Michał Górny" mgo...@gentoo.org:Hi,
> everyone.TL;DR: I'd like to propose naming dev-python/* packages
> following PyPInames whenever possible, case-preserving, with
> modifications only whennecessary to match PN rules.So
> far the naming in dev-python/* hasn't been exactly consistent. Myself
> I've been mostly following "whatever's the easiest" policy which />generally meant following GitHub project names whenever we fetched from />there.This mostly made sense so far, as I've been thinking of
> dev-python/primarily in terms of dependencies of other packages.
> However, it'sbeen pointed out that this makes it hard for people to
> find packagesthey're looking for.The vast majority of
> packages in dev-python/ are also published on PyPI[1]. They can
> afterwards be installed using tools such as pip, orspecified as
> dependencies of other projects — using their PyPI namesin every
> case.On top of that, it is not unknown for multiple packages with
> verysimilar names to coexis, say "foo", "pyfoo" and "python-foo". When
> GHproject names come into the picture, this can get even more
> ambiguous. Don't even get me started about developers pushing duplicate
> packagesbecause they didn't find the existing instance. />To improve consistency and make packages easier to find, I'd like to />propose going forward that when packages are published on PyPI, we use />their official PyPI names. This also means preserving the case for />the few packages that use CamelCase names and similar.Some
> modifications will be necessary. For example, it is legal for PyPI />package names to include dot (".") — we normally translate that to a />hyphen ("-"). We may also have use cases for creating multiple Gentoo />packages from the same PyPI package (see e.g. dev-python/ensurepip-*). />Then, there are of course Python packages that aren't published on PyPI. />Still, I think as a general rule of thumb this would make sense.
> WDYT?[1] https://pypi.org/;
> target="_blank">https://pypi.org/ class="f55bbb4eeef208e8wmi-sign">-- Best regards,Michał Górny />
Can you send plaintext mail to gentoo-dev? HTML makes it very hard to read your
mails in certain clients.
signature.asc
Description: PGP signature
Re: [gentoo-dev] dev-python/ package naming policy?
On Sat, Jan 28, 2023 at 10:23:45PM +0100, Ulrich Mueller wrote: > > On Sat, 28 Jan 2023, Andrew Ammerlaan wrote: > > > Each of these is a different package. The package you usually want is > > GitPython, but if we would name it gitpython or git-python, things > > would get very confusing very quickly. In fact, this package was > > renamed precisely to avoid this confusion in [1]. This is not the only > > case where there are very similarly named packages on pypi. By having > > a 1 to 1 mapping between names in pypi and names in ::gentoo we avoid > > this confusion. > > Looking at mgorny's list, you cannot have an 1 to 1 mapping anyway, > because that would result in invalid PN names. Should imperfection get in the way of bettering the mapping? signature.asc Description: PGP signature
Re: [gentoo-dev] dev-python/ package naming policy?
On Sat, Jan 28, 2023 at 10:15:02PM +0500, Anna (cybertailor) Vyalkova wrote:
> I'd prefer if PyPI names are guidelines, not a strict policy. I don't
> like CamelCase and separators other than dash ("-") :P
>
> Also I don't like when packages are named "dev-python/python-foo"
> instead of just "dev-python/foo".
So, two simply aesthetic opinions. I'm not sure it's appropriate to
suggest one's aesthetic preference as default when there's no further
benefit.
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH 2/2] verify-sig.eclass: Accept 1-out-of-n sigs on multisig files
If a distfile has multiple detached signatures, pass verification
if at least one of them can be verified rather than requiring all
of them. This is particularly helpful for upstreams where the whole
set of release keys is hard to come by.
Closes: https://bugs.gentoo.org/873211
Signed-off-by: Michał Górny
---
eclass/verify-sig.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass
index 95e8b357893a..2c8311db49f9 100644
--- a/eclass/verify-sig.eclass
+++ b/eclass/verify-sig.eclass
@@ -146,7 +146,7 @@ verify-sig_verify_detached() {
# https://bugs.gentoo.org/854492
local -x TMPDIR=/tmp
gemato openpgp-verify-detached -K "${key}" \
- "${extra_args[@]}" \
+ "${extra_args[@]}" --no-require-all-good \
"${sig}" "${file}" ||
die "PGP signature verification failed"
;;
--
2.39.1
[gentoo-dev] [PATCH 1/2] verify-sig.eclass: Use gemato openpgp-verify-detached
Signed-off-by: Michał Górny
---
eclass/verify-sig.eclass | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass
index 394ce2e44427..95e8b357893a 100644
--- a/eclass/verify-sig.eclass
+++ b/eclass/verify-sig.eclass
@@ -65,8 +65,9 @@ case ${VERIFY_SIG_METHOD} in
BDEPEND="
verify-sig? (
app-crypt/gnupg
- >=app-portage/gemato-16
- )"
+ >=app-portage/gemato-18.0
+ )
+ "
;;
signify)
BDEPEND="verify-sig? ( app-crypt/signify )"
@@ -144,8 +145,9 @@ verify-sig_verify_detached() {
# gpg can't handle very long TMPDIR
# https://bugs.gentoo.org/854492
local -x TMPDIR=/tmp
- gemato gpg-wrap -K "${key}" "${extra_args[@]}" -- \
- gpg --verify "${sig}" "${file}" ||
+ gemato openpgp-verify-detached -K "${key}" \
+ "${extra_args[@]}" \
+ "${sig}" "${file}" ||
die "PGP signature verification failed"
;;
signify)
--
2.39.1
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
> > acct-group/cron > acct-group/fcron > acct-user/cron > acct-user/fcron > dev-libs/libelf > net-misc/curl > sys-process/cronbase > sys-process/fcron > virtual/cron > virtual/libelf > These should probably go to base-system -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
acct-group/fcron acct-user/fcron sys-process/fcron I can proxy-take this -- Best regards, Alexey "DarthGandalf" Sokolov
