Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
Dne 15. 04. 21 v 18:35 Joakim Tjernlund napsal(a): Yes, I found the error in dev-java/icedtea-web. Q: Should one use JDK_HOME or JAVA_HOME in ebuilds? i guess it doesn't matter (at least for packages that inherit java-utils-2.eclass): https://github.com/gentoo/gentoo/blob/master/eclass/java-utils-2.eclass#L2711 However, BDEPEND vs DEPEND is still outstanding. I don't think it is wrong to use BDEPEND here? Also, RDEPEND does not seem to matter, only BDEPEND this thread is about packages inheriting a java eclass, which icedtea-web isn't, so it works in a different way. i never touched that package so cannot give you more details, but you can join us at #gentoo-j...@freenode.net and address gyakovlev there. fordfrog
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
On Thu, 2021-04-15 at 16:35 +, Joakim Tjernlund wrote: > On Thu, 2021-04-15 at 18:28 +0200, Miroslav Šulc wrote: > > Dne 15. 04. 21 v 17:56 Joakim Tjernlund napsal(a): > > > On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote: > > > > Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a): > > > > > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote: > > > > > > in case the package does not work with java > 1.8 (still, i suggest > > > > > > we > > > > > > first try to resolve the issue before we use this restriction as it > > > > > > might cause some issues in the future) > > > > > > virtual/jdk:1.8 > > > > > > virtual/jre:1.8 > > > > > This does not seem to be enforced by java eclasses. Example > > > > > dev-java/icedtea-web has > > > > > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as > > > > > system default will > > > > > try to build with java-11 and the build will fail. > > > > not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. > > > > regular java apps use classes from jre (java runtime engine) and so they > > > > must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this > > > > icedtea-web issue, this should be filed as a bug. thank you for > > > > mentioning this. > > > Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and > > > changed > > > RDEPEND to virtual/jdk:1.8 it still fails. > > yes, looking at that icedtea-web ebuild, it inherits none of java > > eclasses so it can't behave as a package that inherits a java eclass. > > gyakovlev would definitely know better. generally, this thread is meant > > for packages that inherit one of java eclasses, and even that is > > oversimplified. > > > > > > Yes, I found the error in dev-java/icedtea-web. Q: Should one use JDK_HOME or > JAVA_HOME in ebuilds? > However, BDEPEND vs DEPEND is still outstanding. I don't think it is wrong to > use BDEPEND here? > > Also, RDEPEND does not seem to matter, only BDEPEND Filed bug https://bugs.gentoo.org/783027 with a small patch, in case you want to comment.
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
On Thu, 2021-04-15 at 18:28 +0200, Miroslav Šulc wrote: > Dne 15. 04. 21 v 17:56 Joakim Tjernlund napsal(a): > > On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote: > > > Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a): > > > > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote: > > > > > in case the package does not work with java > 1.8 (still, i suggest we > > > > > first try to resolve the issue before we use this restriction as it > > > > > might cause some issues in the future) > > > > > virtual/jdk:1.8 > > > > > virtual/jre:1.8 > > > > This does not seem to be enforced by java eclasses. Example > > > > dev-java/icedtea-web has > > > > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as > > > > system default will > > > > try to build with java-11 and the build will fail. > > > not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. > > > regular java apps use classes from jre (java runtime engine) and so they > > > must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this > > > icedtea-web issue, this should be filed as a bug. thank you for > > > mentioning this. > > Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and > > changed > > RDEPEND to virtual/jdk:1.8 it still fails. > yes, looking at that icedtea-web ebuild, it inherits none of java > eclasses so it can't behave as a package that inherits a java eclass. > gyakovlev would definitely know better. generally, this thread is meant > for packages that inherit one of java eclasses, and even that is > oversimplified. > > > Yes, I found the error in dev-java/icedtea-web. Q: Should one use JDK_HOME or JAVA_HOME in ebuilds? However, BDEPEND vs DEPEND is still outstanding. I don't think it is wrong to use BDEPEND here? Also, RDEPEND does not seem to matter, only BDEPEND
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
Dne 15. 04. 21 v 17:56 Joakim Tjernlund napsal(a): On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote: Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a): On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote: in case the package does not work with java > 1.8 (still, i suggest we first try to resolve the issue before we use this restriction as it might cause some issues in the future) virtual/jdk:1.8 virtual/jre:1.8 This does not seem to be enforced by java eclasses. Example dev-java/icedtea-web has BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system default will try to build with java-11 and the build will fail. not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. regular java apps use classes from jre (java runtime engine) and so they must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this icedtea-web issue, this should be filed as a bug. thank you for mentioning this. Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and changed RDEPEND to virtual/jdk:1.8 it still fails. yes, looking at that icedtea-web ebuild, it inherits none of java eclasses so it can't behave as a package that inherits a java eclass. gyakovlev would definitely know better. generally, this thread is meant for packages that inherit one of java eclasses, and even that is oversimplified. Jocke fordfrog
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote: > Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a): > > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote: > > > in case the package does not work with java > 1.8 (still, i suggest we > > > first try to resolve the issue before we use this restriction as it > > > might cause some issues in the future) > > > virtual/jdk:1.8 > > > virtual/jre:1.8 > > > > This does not seem to be enforced by java eclasses. Example > > dev-java/icedtea-web has > > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system > > default will > > try to build with java-11 and the build will fail. > not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. > regular java apps use classes from jre (java runtime engine) and so they > must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this > icedtea-web issue, this should be filed as a bug. thank you for > mentioning this. Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and changed RDEPEND to virtual/jdk:1.8 it still fails. > > Jocke > > fordfrog > >
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a): On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote: in case the package does not work with java > 1.8 (still, i suggest we first try to resolve the issue before we use this restriction as it might cause some issues in the future) virtual/jdk:1.8 virtual/jre:1.8 This does not seem to be enforced by java eclasses. Example dev-java/icedtea-web has BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system default will try to build with java-11 and the build will fail. not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. regular java apps use classes from jre (java runtime engine) and so they must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this icedtea-web issue, this should be filed as a bug. thank you for mentioning this. Jocke fordfrog
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote: > > in case the package does not work with java > 1.8 (still, i suggest we > first try to resolve the issue before we use this restriction as it > might cause some issues in the future) > virtual/jdk:1.8 > virtual/jre:1.8 This does not seem to be enforced by java eclasses. Example dev-java/icedtea-web has BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system default will try to build with java-11 and the build will fail. Jocke
[gentoo-dev] [PATCH 4/4] elisp-common.eclass: Drop support for EAPI 4
Signed-off-by: Ulrich Müller
---
eclass/elisp-common.eclass | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index f7e3631a965c..90621cbe7b92 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -10,6 +10,7 @@
# Mamoru Komachi
# Christian Faulhammer
# Ulrich Müller
+# @SUPPORTED_EAPIS: 5 6 7
# @BLURB: Emacs-related installation utilities
# @DESCRIPTION:
#
@@ -165,7 +166,7 @@
# to above calls of elisp-site-regen().
case ${EAPI:-0} in
- 4|5|6) inherit eapi7-ver ;;
+ 5|6) inherit eapi7-ver ;;
7) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -361,7 +362,7 @@ elisp-modules-install() {
shift
# Don't bother inheriting multilib.eclass for get_libdir(), but
# error out in old EAPIs that don't support it natively.
- [[ ${EAPI} == [45] ]] \
+ [[ ${EAPI} == 5 ]] \
&& die "${ECLASS}: Dynamic modules not supported in EAPI
${EAPI}"
ebegin "Installing dynamic modules for GNU Emacs support"
( # subshell to avoid pollution of calling environment
@@ -390,7 +391,7 @@ elisp-site-file-install() {
sf="${T}/${sf}"
ebegin "Installing site initialisation file for GNU Emacs"
[[ $1 = "${sf}" ]] || cp "$1" "${sf}"
- if [[ ${EAPI} == [45] ]]; then
+ if [[ ${EAPI} == 5 ]]; then
grep -q "@EMACSMODULES@" "${sf}" \
&& die "${ECLASS}: Dynamic modules not supported in
EAPI ${EAPI}"
else
--
2.31.1
[gentoo-dev] [PATCH 3/4] elisp.eclass: Drop support for EAPI 4 and 5
Signed-off-by: Ulrich Müller
---
eclass/elisp.eclass | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/eclass/elisp.eclass b/eclass/elisp.eclass
index a092041009bf..d763a4944d2d 100644
--- a/eclass/elisp.eclass
+++ b/eclass/elisp.eclass
@@ -9,7 +9,7 @@
# Jeremy Maitin-Shepard
# Christian Faulhammer
# Ulrich Müller
-# @SUPPORTED_EAPIS: 4 5 6 7
+# @SUPPORTED_EAPIS: 6 7
# @BLURB: Eclass for Emacs Lisp packages
# @DESCRIPTION:
#
@@ -40,7 +40,7 @@
# Space separated list of patches to apply after unpacking the sources.
# Patch files are searched for in the current working dir, WORKDIR, and
# FILESDIR. This variable is semi-deprecated, preferably use the
-# PATCHES array instead if the EAPI supports it.
+# PATCHES array instead.
# @ECLASS-VARIABLE: ELISP_REMOVE
# @DEFAULT_UNSET
@@ -62,8 +62,8 @@
# will be generated in src_compile() and installed in src_install().
inherit elisp-common
+
case ${EAPI:-0} in
- 4|5) inherit epatch ;;
6|7) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -73,8 +73,7 @@ EXPORT_FUNCTIONS
src_{unpack,prepare,configure,compile,install} \
RDEPEND=">=app-editors/emacs-${NEED_EMACS}:*"
case ${EAPI} in
- 4) RDEPEND="${RDEPEND%:*}"; DEPEND="${RDEPEND}" ;;
- 5|6) DEPEND="${RDEPEND}" ;;
+ 6) DEPEND="${RDEPEND}" ;;
*) BDEPEND="${RDEPEND}" ;;
esac
@@ -118,17 +117,11 @@ elisp_src_prepare() {
else
die "Cannot find ${patch}"
fi
- case ${EAPI} in
- 4|5) epatch "${file}" ;;
- *) eapply "${file}" ;;
- esac
+ eapply "${file}"
done
- # apply PATCHES (if supported in EAPI), and any user patches
- case ${EAPI} in
- 4|5) epatch_user ;;
- *) default ;;
- esac
+ # apply PATCHES and any user patches
+ default
if [[ -n ${ELISP_REMOVE} ]]; then
rm ${ELISP_REMOVE} || die
@@ -172,10 +165,7 @@ elisp_src_install() {
doinfo ${@/%.*/.info*}
fi
# install documentation only when explicitly requested
- case ${EAPI} in
- 4|5) [[ -n ${DOCS} ]] && dodoc ${DOCS} ;;
- *) [[ $(declare -p DOCS 2>/dev/null) == *=* ]] && einstalldocs
;;
- esac
+ [[ $(declare -p DOCS 2>/dev/null) == *=* ]] && einstalldocs
if declare -f readme.gentoo_create_doc >/dev/null; then
readme.gentoo_create_doc
fi
--
2.31.1
[gentoo-dev] [PATCH 2/4] elisp-common.eclass: Drop deprecated elisp-need-emacs()
Signed-off-by: Ulrich Müller
---
eclass/elisp-common.eclass | 21 -
1 file changed, 21 deletions(-)
diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index bdf97f413033..f7e3631a965c 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -276,27 +276,6 @@ elisp-check-emacs-version() {
fi
}
-# Test if the eselected Emacs version is at least the major version
-# of GNU Emacs specified as argument.
-# Return 0 if true, 1 if false, 2 if trouble.
-# Deprecated, use elisp-check-emacs-version instead.
-
-elisp-need-emacs() {
- local need_emacs=$1 have_emacs
- have_emacs=$(elisp-emacs-version) || return 2
- einfo "Emacs version: ${have_emacs}"
- if [[ ${have_emacs} =~ XEmacs|Lucid ]]; then
- eerror "This package needs GNU Emacs."
- return 1
- fi
- if ! [[ ${have_emacs%%.*} -ge ${need_emacs%%.*} ]]; then
- eerror "This package needs at least Emacs ${need_emacs%%.*}."
- eerror "Use \"eselect emacs\" to select the active version."
- return 1
- fi
- return 0
-}
-
# @FUNCTION: elisp-compile
# @USAGE:
# @DESCRIPTION:
--
2.31.1
[gentoo-dev] [PATCH 1/4] elisp-common.eclass: Add timeout to version detection
Signed-off-by: Ulrich Müller
---
eclass/elisp-common.eclass | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index 832fc19e4675..bdf97f413033 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -219,7 +219,9 @@ _ELISP_EMACS_VERSION=""
# Output version of currently active Emacs.
elisp-emacs-version() {
- local version ret
+ local version ret tmout="timeout -k 5 55"
+ # Run without timeout if the command is not available
+ ${tmout} true &>/dev/null || tmout=""
# The following will work for at least versions 18-24.
echo "(princ emacs-version)" >"${T}"/emacs-version.el
version=$(
@@ -228,7 +230,7 @@ elisp-emacs-version() {
# Redirecting stdin and unsetting TERM and DISPLAY will cause
# most of them to exit with an error.
unset TERM DISPLAY
- ${EMACS} ${EMACSFLAGS} -l "${T}"/emacs-version.el
